Programming is a bit of a mystery to people. It generates a lot of distrust in an organization. In general, when you don’t understand what it takes to do something, everything seems plausible. You may think that a house can be built in a couple of weeks if you have never gone through the process. In truth they could probably finish construction in that time, but not as a sustainable business. If you watch a house being built and track the progress, you can physically see the foundation being poured, the framing of the structure, etc. It’s easy to understand because you see it physically. Writing code for a computer application or a website is not so obvious.
The code is invisible to everyone except the programmer. It’s like the magic that takes place behind the curtain. Any team has to trust a programmer about what is and isn’t possible. The best course of action, estimates, and progress updates are subject to developer input. There are many type A personalities who have problems with this, but it goes further.
The first problems arise when a customer decides what he wants and when he needs it. Dirty people want to sell. Telling the customer that they have unrealistic expectations does not close the sale. And he shit, is that a recipe for disaster? I have seen account service cut estimates in half and move money around to accommodate their sale and commission. At the end of the day, it looks like the programmers are screwing up. They do it because it’s easy to blame the programmers.
They don’t teach office politics in school. They should, but that’s a different story all together. A programmer has to be quietly concentrating on mental gymnastics to produce clean working code. It is difficult and requires all your energy. There is no time to run to see who will throw you under the bus. Games account service plays have consequences.
At a previous agency I worked at, I watched a 7-figure project go up in flames. Who caused the problem? Was it the industry-leading group of programmers who worked 70+ hour weeks to accommodate the client’s arbitrary schedule, or was it the account service staff who agreed to everything the client asked for?
I’m not saying that programmers never cause trouble. If you’ve ever watched the Seconds From Disaster TV show, catastrophic problems arise from a mix of people not doing their jobs. But I saw the programmers doing their job. I’m not sure what everyone else was doing.
So what did the agency think? They fired (fired) every single one of those programmers. However, all of the account servicing still works there. After that demoralizing death march, no one wanted to be there anyway.
The programmer’s road to hell is paved with the word yes. To police their own world, they must be aware of what is feasible. Being analytical, they usually put a lot of effort into an estimate. From what I’ve seen, it’s usually more effort than most because they’re adept at thinking through multiple scenarios. Unfortunately, I have seen good estimates ignored or questioned. The more realistic they are, the more it is scrutinized for some reason.
It’s hard to go back to the customer with a set of realistic expectations. It makes closing much more difficult. You run the risk of someone else agreeing to the job (which will fail). But the programmer’s job is no less difficult. Actually, they are the only group of people who are capable of understanding everything. They know the code and they know the business problem. They may not be good at customer management, but they can certainly understand what’s going on.
Trust your programmers. They are not only engineers and craftsmen, but also entrepreneurs. They will know from experience what happens to customer relationships when someone makes promises that no one else can keep.