ed weissman

The #1 question to ask when selling to the enterprise is, “What are the spending authority cut-offs?” Nothing means more. 

Funny, in my experience, the 5K and 100K numbers are pretty accurate. 

I recently assisted in the purchase of business intelligence package. The CIO (my contact) had authority to spend up to $100K. Anything more had to go the board, and that “just wasn’t going to happen”. One vendor knew what to ask and bid $93K. The two others were much higher. Guess who (automatically) got the sale. The other 2 may have been better, but we’ll never know. They were effectively eliminated by rules they never asked about. 

At the low end, almost everyone has authority to spend up to $5K, even users. They bring in desktop software or SAAS under IT’s radar. There’s “huge” demand for solutions to their problems that fit under their spending limits. 

In enterprise IT, we have 2 kinds of vendors, those we actively embrace and those who hold us hostage. 

The biggest fear in making any major IT purchase is not the price, the conversion, or the change in culture; it’s the potential loss of options in how we run our own business. 

I’ve seen it over and over again: competitive pressure requires us to make a change in the way we run our business, but we can’t. For all kinds of reasons. The license agreement kills any possible ROI. We don’t have the needed IT support because so much of it is spent on keeping current. The systems don’t talk to each other. The feature we need is still 18 months away. And probably most of all, the software is not as excellent as we need it to be (let’s just leave it at that). 

Long gone are the days when you needed IBM’s permission to fart. Guess who the biggest culprit is today? 

Just because you go with someone doesn’t necessarily mean you like it. Almost every enterprise IT department I know would love an alternative to Microsoft. (And make no mistake about it, the enterprise is Microsoft’s strength, much more so than the consumer.) 

Sure, pissing off your customers may pad today’s bottom line. How do you think those customers will feel when your landscape changes and they have more choices? 

[Entered using ie7 on xp pro. I didn’t have a choice.] 

If it worked for Leonardo da Vinci, maybe it could work for me. The next time I’m looking for a job, I’ll try this: 

“Most Illustrious Proprietor, Having now sufficiently considered the specimens of all those who proclaim themselves skilled developers of applications of business, and that the invention and operation of the said programs are nothing different from those in common use: I shall endeavor, without prejudice to any one else, to explain myself to your Company, showing your Management my secret, and then offering them to your best pleasure and approbation to work with effect at opportune moments on all those things which, in part, shall be briefly noted below. 

1. I have a sort of extremely light and strong functions and modules, adapted to be most easily ftp’d, and with them you may pursue, and at any time combine them with others, secure and indestructible by standard mean time to failure of hardware and denial of service, easy and convenient to compile and catalog. Also methods of unzipping and storing the data of the customers. 

2. I know how, when a website is besieged, to shard data onto the cloud, and make endless variety of mirrors, and fault tolerant disks and RAIDs, and other machines pertaining to such concerns. 

3. If, by reason of the volume of the data, or the structure of the b-trees and its indexes, it is impossible, when conducting a search, to avail oneself of sub-second response time, I have methods for benchmarking every process or other function, even if it were interpreted, etc. 

4. Again, I have kinds of functions; most convenient and easy to ftp; and with these I can spawn lots of data almost resembling a torrent; and with the download of these cause great terror to the competitor, to his great detriment and confusion. 

5. And if the processing should be on the desktop I have apps of many machines most efficient for data entry and reporting; and utilities which will satisfy the needs of the most demanding customers and users and consumers. 

6. I have means by secret and tortuous scripts and modules, made without leaving tracks, to generate source code, even if it were needed to run on a client or a server. 

7. I will make secure firewalls, safe and unattackable, which, entering among the hackers with their utilities, there is no body of crackers so great but they would break them. And behind these, software could run quite unhurt and without any hindrance. 

8. In case of need I will make big properties, methods, and collections and useful forms, out of the common type. 

9. Where the operation of compiling might fail, I would contrive scripts, functions, routines, and other parameter driven processes of marvelous efficacy and not in common use. And in short, according to the variety of cases, I can contrive various and endless means of data entry, reporting, and storage. 

10. In times of low revenue I believe I can give perfect satisfaction and to the equal of any other in maintenance and the refactoring of code public and private; and in guiding data from one warehouse to another. 

11. I can carry out code in Javascript, PHP, or C, and also I can do in network administration whatever may be done, as well as any other, be he who he may. Again, the intranet app may be taken in hand, which is to be to the immortal glory and eternal honor of all your customers of happy memory, and of the illustrious house of Google. 

And if any of the above-named things seem to anyone to be impossible or not feasible, I am most ready to make the experiment in your data center, or in whatever place may please your Businessperson - to whom I comment myself with the utmost humility, etc.” 

“So here it is, the most plain, powerful, single word you have to know, and use when managing a project: NO” 

If you aspire to mediocracy in an enterprise, then this “may” help you survive. Otherwise, it’s horrible advice.

If you have serious competitors, then you have to find YES.

If you are attempting to do something extraordinary or for the first time ever, then you have to find YES. 

If you are building a startup, then you most certainly have to find YES. 

I am not saying that all things are possible. I am saying that you need to find YES.

Once you get into the habit of saying NO, you forget how to find YES. 

A simple (and timeless) example. Your customer wants Deliverable X in Time Y using Resource Z. You know it’s too much and will disappoint. So instead of saying NO as OP recommends, you find a way to do what can be done. It may have a few less features, may need an extra resource, or may take a little more time. 

Or better yet, you analyze the constraints long enough to find methods or tools you hadn’t considered to say 

YES to all of it. (We never would have found Framework ABC if the customer hadn’t forced us.)

I have often been to only person finding YES when I was surrounded by others pre-programmed to saying NO. 

That’s how they survived. Usually in an enterprise or institution. That same thinking is a disaster in an achievement oriented environment. 

Finding YES forces you to stretch beyond your previously perceived limits. Settling for NO dooms you to mediocracy forever.

Some may call this a semantic argument. I call it state of mind. How badly do you want it? Find YES. 

A smart accountant once told me that the answer to “How much money did you make?” is always, “Who wants to know?” If it’s an investor, the answer is “A lot.” If it’s a customer, the answer is “A little.” If it’s the IRS, the answer is “None.”

Same thing here. The answer to “Who is a superstar developer?” is always, “Who wants to know?”
 
To a project manager, the programmer who hits every deadline (regardless of quality) is a superstar.

To a customer, the programmer who solves their problem quickest is a superstar.

To a business owner, the programmer who makes them the most money is a superstar.
 
To a PHB, the programmer who makes them look the best is the superstar.

To a journalist, the programmer who tells the best stories is the superstar.
 
To a junior programmer, the best mentor is the superstar.

To another programmer, the programmer they are most likely to want to go into battle with is the superstar.

There were many times when something I did seemed “too easy”. So many times I’d listen to the user, understand their problem, and help them solve it with software. No big deal. Many of us have been doing that for years. Then the user would say, “Thank you, thank you, thank you!” “You’re so much better than anyone else we’ve tried,” or “This software is incredible! You should take it to market.”

Or when I got compliments I didn’t think I deserved. People called me “the smartest programmer I ever met,” “brilliant,” or “head and shoulders above the rest”, and I knew it wasn’t true, but accepted their praise anyway. And believe me, I’m not bragging, I’m just sharing experiences that many others probably had too. Others thought we were geniuses and we thought that we were just doing our jobs.

So why don’t I feel like a fraud? Because I paid my dues. I may not the smartest or most gifted guy, and I’m certainly no genius, but I know I did the hard work.

While others were partying, I was debugging til 2 in the morning. While others were at lunch, I was eating a sandwich at my desk trying to find a better way to do something. While others promoted “good enough” software, I dug down 5 more levels to overcome the tradeoff. And while others accepted the status quo, I wrote my own framework to provide software that was in a different class from theirs.

I bet many of you share the same experience. Sure, we have been given gifts that many others never got, but those gifts only took us so far. We had to learn how to use those gifts. The real successes came from hard work. The kind of hard work that many people I know never do.

So if someone “overpraises” me, that’s OK. I know I don’t deserve it, but I accept it anyway. Kinda makes up for all those hours when I was slaving away and no one said anything at all.

Examples are everywhere. In fact, almost every human interaction is an example. Here are a few off the top of my head: 

Quality control rejected one program because it was indented 4 spaces instead of the standard 5, but accepted another, even though it had enough memory leaks to crash the server under certain conditions. The first was a detail; the second was an issue. It took me 2 days to get Q.C. to understand the difference. 

A friend recently arrived for a dinner party an hour late and then complained to me that another spoke with her mouth full. As far as I was concerned, the first was an issue and the second was a detail. My friend thought otherwise about both. 

Accounting recently spent 3 days implementing a new key policy for the private rest rooms (presumably to prevent theft) and then wrote off $50,000 of inventory because no one could find the proper paperwork. IMO, the former was a detail upon which much time was wasted and the latter was an issue that never actually got dealt with. 

We spent the first hour of a recent meeting trying to determine naming conventions, but ran out of time before we decided if the customer’s credit limit should be split between 2 divisions. Again, wasting time on details and not dealing with real issues. (This is a great example. One of the best ways to lose your shirt is to not deal with credit/collection/accounts receivable issues.) 

I have a simple guideline for real life interactions with others that carries over quite well on-line, “Deal with issues; ignore details.” 

It’s amazing how well this works in person, especially when trying to get something done. My number one question to another is probably, “Is that an issue or a detail?” We can almost always decide together which it is. Then, if it’s an issue, we deal with it, and if it’s a detail, we move on to the next issue. 

This has also saved me countless hours and aggravation on-line. If I post something and someone disagrees, I quickly decide whether or not it’s really an issue and only engage the other if it is. I realize that this is just a judgment call, but I’d estimate about 90% of on-line disagreements are just details. In these cases, I think it’s best to simply move on. 

I am 55 and absolutely do not care what anyone else thinks about it.

When I first started out I quickly rose through the enterprise ranks and was never taken seriously because of my age. As a wimpy looking nerd, I had always been underestimated by others and I found a way to use that to my advantage. When the time was right, I would just shoot them between the eyes with the right solution. My young age didn’t matter.

Fast forward 30 years. I “never” notice age discrimination. It may be there, but I simply don’t notice it. I think being in IT and in my 50’s is a “tremendous advantage”.

For every issue I have to address, I have that many more instances of experience dealing with something like that. Many more iterations of similar patterns to draw from.

IT is one field where you can actually get “better” with age. You don’t have to run fast or carry heavy loads, but you do have to think nimbly and get things done, both of which get better with lots of practice.

IT is also one field where “what you get done” is more important than “who you are”. This is always good news for us hackers and makers, regardless of age, sex, background, or anything else.

I am currently writing the best software of my life, by far. Not just “how” I’m writing it, but “what” I’m writing. I have seen so much that I have a natural instinct for what is needed, what works, and how to best go about it. New technologies keep me fresh and engaged. I feel perfectly at home here among younger programmers. I can’t imagine a better place to be, with 21st century technology and 30 years experience!

To me it’s odd that others in my age group don’t feel the same way. Then again, maybe it’s just state of mind.

My grandmother taught me one of the most important lessons of my life, “If you look hard enough for trouble, you’ll probably find it.”

There is negativity everywhere, about ageism and a million other things. The secret is that it’s only data to process as you choose. I have decided to ignore it and continue to do what I love and love what I do.

“I have not seen these things be successful, therefore they “can’t” be successful”. 

This kind of thinking scares me, not so much because it’s so myopic, but because it becomes a self-fulfilling prophecy: “I have never seen success” becomes “Success is not possible” which becomes true because we stop trying.

Mere mortals throw up their hands in futility, blaming the user, the state of the art, or the alignment of the planets, without ever understanding the fundamental principal that great systems accommodate great needs and the greatest need of all is constant change. 

“the company recategorizes its product line based on utility and lifestyle rather than brand and designer”

This is incredibly common and can easily be accommodated with proper database design, decoupling products from their associated attributes. 

“the parent company divests itself of you and withdraws the connection to its parts and inventory database” 

So now you have to treat them like any other vendor? You do have some of those, don’t you? 

“a manufacturer starts using more than one UPC per product because they changed the packaging” 

A simple database design consideration. “One to one” is just a special case of “one to many”. 

“the law now requires that national holidays must be counted against vacation time if the employee takes a vacation day immediately before/after that holiday” 

Rule driven logic. What’s the big deal? (Your logic was rule-driven from the outset, not hard-coded, right?) 

“a loan company files to become a bank and store deposits that earn interest” 

Additional logic to existing data. We do this all the time. 

“CSV files exchanged with a partner were always denormalized, but then one company starts using normalized records with mixed column mappings” 

Any decent batch file processor should be able to handle anything thrown at it. Companies that do a lot of this build uncertainty into the design of their systems.

“another partner decides to ditch file transfer as a way to submit data, and creates a web service that you’re supposed to invoke commands on”

Sounds like you’ll need an extra piece of software to create a feed. Not exactly like no one’s ever done this before. 

“the shipping carrier reveals that their tracking numbers are all recycled at the end of each year” 

Not a problem if they were never used as the primary key to a table. 

“new rules require every credit card number to be encrypted, but you still have to be able to quickly search for matches in a database of millions” 

Ahh, but the last 4 digits do not have to be encrypted. Start your search with them and resolve synonyms. Pretty standard stuff. 

“a partner switches to mixed-case alphanumeric PO numbers” 

As an identifier, a PO number is always a string even if it looks like it’s numeric. (When was the last time you added 2 PO numbers together?) 

OP’s roadblocks are experienced developers’ speed bumps. Just because he hasn’t done it doesn’t really mean that “Nobody knows what they’re doing”.