It's common knowledge among programmers that most of the ills of the software industry, and most particularly the companies where we work, could be solved by simply letting the technical people make the technical decisions. In fact, that sounds so obvious that you might be tempted to shake your head and wonder what planet I come from. Obviously, since this is so incredibly logical and sensible, it's a given that most companies leave management decisions to managers, and technical decisions to techies, right?
Hey, you. Yeah, you. The one in the back staring at your compiler errors. You're laughing in all the wrong places. At least let me finish, and then we can all laugh together about how silly an assumption this is. Now, as I was about to say, anyone who's ever been paid for writing code already knows that regardless of how sensible it might be to let the people with the expertise make the decisions, that's just not the way it happens in the real world. In fact, in the overall scheme of things, when it comes to decision making power, programmers are at the bottom of the food chain, whether the issue is technical or not.
In short, no matter how silly it may be, most critical technical decisions in the software development business are made by middle or upper management, a class of creature who only rarely possesses any in depth technical expertise. This, in and of itself, wouldn't be so bad. It is, after all, management's area of expertise to keep the company on track and make the sweeping decisions requiring someone with a wide angle view of the business. The problem with this scenario is that an extremely high percentage of the time, these decisions are made without consulting the technical staff about the feasibility and consequences of the decision. Worse still, management often makes decisions for their own reasons over the loud protests of their technical staff, ignoring the recommendations made by those who have the greatest skills in that arena. It's a wonder that any software ever ships at all.
Corporate waste
In fact, the combination of project disasters and fickle or crisis driven management frequently insures that we don't ship software. Talking with an old friend and fellow programmer a few weeks ago, we tried to put a number to this. What we came up with was that of all the projects we'd worked on, only 10% of the code we'd written ever saw the light of day by being released as a product for use by customers, whether it was shrink wrapped products or internal IT systems. This means that 90% - yes, you heard me right, 90% - of all the projects we've worked on died a premature death and never saw implementation in the field. Sometimes it's a good old fashioned project disaster (I don't think I need to define that term with this crowd). Other times, it's simply capricious decision making, constantly changing direction to go with whatever is trendy or politically expedient. And of course, there's always crisis management, where a project never gets completed because it's put on hold so that we can be assigned to putting out a different fire, only to be pulled off that effort for yet another.
In other words, 9 times out of 10, all of the time, effort, blood, sweat and tears we put into those systems, not to mention the financial cost incurred, was for nothing. The code was simply thrown away. Yes, we try to stash away the clever bits of code we've written to be used later, but the rate that technology changes usually minimizes the benefits of this. Overall, it's just money out the window.
Having heard this story over and over again from developers the world over, it slowly became clear to me over the years that this wasn't an uncommon scenario. As my mind reeled over the staggering amount of waste that is the norm in the development industry, one question kept recurring over and over again. Why? Why would any company willingly throw that kind of money into the fireplace, shrug it off as business as usual, and then embark on yet another project that would ultimately suffer the same fate? If you think of a business as an organization which exists for the purpose of making a profit, your brain will eventually reboot. It just doesn't make any sense. Or does it?
Remember the human factor
Businesses are run by people, and people all fall prey to the frailties of human nature. When considering the matter at hand, the people in question are known as management, and they are no less human than the rest of us, no matter what speculation you might hear from programmers when hanging out by the espresso machine. That means that decisions aren't always made for the most altruistic of reasons. Every person has their own career ambitions, their own vanities and ego, and their own personal agenda.
Furthermore, they're spending someone else's money, a point not to be taken lightly. I can assure you, if the money were coming out of their personal bank accounts, you'd see an entirely different set of priorities. Instead, this money just isn't real to them. Rather, it's an abstract set of figures on a spreadsheet simply referred to as "the budget". I'm making a point of this because if you expect that mentioning the financial consequences of the decisions is all that will be necessary for the logical mind to see things your way, you're in for rapid disappointment. This isn't their money, and it's too difficult for them to translate it to the impact on their personal paycheck. It's not like they spent the family's savings on a red sports car and have to explain the decision to their significant other.
This sort of waste and history of project disasters would never happen if the techies were in charge of the decisions. However, before we get too proud of ourselves, it's worth pointing out that it would be due to a completely different motivation than making the company money. Programming is our art and our passion. We just couldn't bear the thought of pouring all that effort into our latest masterpiece and then simply tossing it in the waste bin. We're emotionally attached, and it also goes against every logical bone in our bodies. There's only one problem. We're not in charge.
We've all had the experience of arguing with our superiors until we're blue in the face, trying to explain why the technical direction they want to take is either completely pointless or disaster waiting to happen. If you didn't have the conversation out loud, you certainly had it in your head. Either way, the end result is all too often the same. We're either patronized because "we don't understand the big picture" or we're simply told, effectively, to sit down and shut up. And so, given that we work for others, in the end it's our job to do what we're told. Disaster ensues, the project dies or is swept under the rug, and then here we are in the conference room again, having exactly the same argument over yet another doomed project. I often get visions of the Flying Dutchman.
What if the programmers were in charge?
The other side of this coin is that had our recommendations been heeded, a huge amount of this waste would have been averted. Either the disaster would never have taken place, or time and money wouldn't have been wasted on a project that was obviously never going to see fruition in the first place. So the real question is this: how do we convince our superiors to trust us and follow our lead in the arena we know best?
There is no single silver bullet that will solve this problem. People are complex creatures, and you can't expect to deal with them successfully without taking a number of things into consideration. However, I want to touch on something here that is an important consideration if you truly wish to effect change in your organization: credibility. It might surprise you to learn that in the scenarios and conference room skirmishes I've just outlined, we have none.
What's that you say, how could we possibly have no credibility when we can list disaster after disaster in our own defense? Simple. Those disasters, all those failed projects you can list at the drop of a hat? They were all our fault. Yes, you heard me right. From management's perspective, the reason they failed was not because the task was illogical or impossible. It failed because the programmers simply didn't get it done. Where else could the blame possibly lie? You certainly don't expect management to take the heat, do you? How do you think they got to be managers in the first place?
Credibility
So, the next time you speak up questioning the path of the new project, don't be surprised that your recommendations and concerns are summarily dismissed. You have a history of failed projects. You have no credibility.
With that in mind, we must learn how to accumulate this rare and valuable commodity, for programmers are not as helpless as the description I've given would seem to indicate. At least, they don't have to be. First, let's look at the benefits that we bring to the party. If programmers ran the farm, the company would benefit by having better functionality, higher quality, improved integration, dependable timelines and the completed projects would actually be used and produce benefits.
By bringing benefit to the company you work for, the project will also make your management look good, thus improving their chances to get what they personally want. And even though nobody cares what your personal desires are, there are at least two people who care about your management's private agenda: them and you.
This is a critical point to comprehend. Programmers have wasted enough breath in logical arguments to provide the world with wind generated electricity for the next century. The reason it's a waste of time is that it's the wrong battle to fight. The decision makers above you are going to make their choices based on their own agenda. If you take the time and effort to understand their needs and then learn how to help them achieve them, you're halfway home. Make sure that they know you're responsible for helping them attain their desires, and you become something very powerful in the business world: a person with credibility.
A new set of priorities
So, in order to better steer the ship that we would ultimately go down with should our efforts fail, we need to accomplish two things. First, we need to build credibility with those who have the power to effect change. Secondly, we need them to know that we're looking out for their personal objectives and are successful in our desires to support them.
In the beginning, this may mean that rather than fighting the big project battles that you want to fight, you instead lower your voice and give your attention to smaller matters. You won't get political clout overnight. Trust and confidence happen gradually, so you need to factor this into your plans.
First, practice thinking from your manager's point of view. You have plenty of opportunity for interaction. If you make it a priority, it's not hard to listen a bit harder and discern what their goals are. People are typically happy to talk about their dreams and desires, both large and small. In casual conversation, take an active interest in what your manager's are. Does he want to be the CEO someday? Is he more focused on getting a good raise or bonus?
What's the criteria for which those chunks of money are handed out? Do his superiors care about immaculate reporting, reduced costs, increased sales, or is it more political than that? Would they be impressed if your boss passed along insights and tidbits of internal company goings on that would allow them to pursue their own agenda? No matter what your superior's goals are, if you listen, ask questions, and express a sincere and active interest, you'll hear them. If you're happy to help them wherever possible, whether it's kicking out a great report for them in your spare time or passing along what you hear, your influence is going to rise accordingly.
Don't make an offer of your spare time services. You'll get taken advantage of. Instead, simply drop by one day and say, "By the way, I heard you talking about how your boss really wanted more detailed reporting from you, so I kicked one out in my spare time that should really impress him. Here's a sample printout. Gotta run, got things to do, see you later...." If you perceive, anticipate, and quietly fill needs without being asked, in a casual and business as usual manner, you're going to get noticed. He may not say anything, but believe me, it'll happen.
Incremental successes
Building credibility is a similar approach. You've probably been spending all your time trying to do the job you were hired to do, right? Silly you. That needs to be dealt with, of course, but your priorities are all wrong if you truly want to change the world. Credibility is an incremental affair. You don't gain it by having one huge success. Furthermore, that's too risky. One huge success could easily turn into one huge failure. Instead of rolling the dice on all or nothing at all, we instead simply leave a trail of small successes, so frequent and consistent that there can be little doubt that betting on your opinions is a sure thing.
Even if the project you're working on now is scheduled for imminent failure, you can still get mileage out of it. The first step is shifting your thinking to a very fine granularity. Almost any task can be broken down into a sequence of small, consecutive actions. Let's say that you wanted to bench press 300 pounds, and you had a body that was capable of doing so. Here's two different descriptions of accomplishing that task.
Approach one
- Took a deep breath and lifted the weights.
Approach two:
- Set the alarm clock
- Went to bed at reasonable hour
- Got up on time
- Took a shower
- Dressed in appropriate clothes
- Walked to weight room
- Set machine for 300 pound bench press
- Reclined on the bench
- Grabbed the weight bar
- Took a deep breath
- Focused
- Invoked upper body muscles
- Raised weights to full arm extension
- Took deep breath
- Lowered weights to resting position
- Rose from the bench to conclude exercise
Yes, I know, it seems kind of silly to go to all that detail when all you did was lay down and just punch up the weights. However, the first approach shows only that you succeeded in one effort. In the second approach, you have 16 consecutive successes on operations that each could have failed or encountered problems. Now who would you rather put your trust in, the guy who did one thing right, or the guy who did 16 things in a row right? This is how you must approach every job you do. From the smallest coding task to the largest documentation effort, there are a host of things that you have to do right to succeed. Take the time to write them down so that you can always refer to your notes instead of having to recount your successes from memory.
Advertising
Of course, it matters little to have ten thousand successes if the decision makers don't know about it. Consequently, like anything else in the business world, if you want positive results, you have to do a little advertising. Care must be taken in how you go about it, however. You don't want to be one of those obsequious little weasels that pander after a manager constantly recounting the fact that you did something right. Such creatures garner no respect. To give you an idea of a more subtle approach, consider the following example.
Let's say that you were tasked with writing a small, simple, dialog based, an affair that should only take around a week. First, do your homework. Fire up a spreadsheet and do your estimating, in quarter hour granularity as I've discussed in the past. Next, having summarized the tiny detail into somewhat larger modules, take any meetings, time off or other work distractions into account and project dates for each module. Yes, it's a small, brainless little app, but anything can be broken down into modules. If you're looking at a week's worth of work, you should be able to come up with at least 5 modules, one for each day.
Now, print that spreadsheet out, casually toss it on the manager's desk on your way past, saying, "By the way, I'm working on that app you wanted and here's the timeline and milestones. I'll let you know when it's done." Then keep walking. You don't want to make a big deal out of it.
As you complete your each task, pay attention to how long it took you, and punch that number into the spreadsheet, right then and there. Tedious, perhaps, but you have larger goals in mind, so it's worth it. Now, at any point in the week when the manager walks by and says, "Hey, how's that app coming?" (and you know they will), you quickly fire up the spreadsheet from the shortcut you keep on the desktop and say, "Right on track. As you can see, I've hit the milestones for Monday and Tuesday, and so far today I'm right on schedule for completing on time." When you've finished the project on time and per your own schedule, drop off a printout of the updated spreadsheet on his desk in the same casual manner, saying, "Here's the information on the project I just completed. Thought the data would be useful to you. Gotta run, got things to do...".
Regardless of whether it's coding projects or accomplishing any task under the sun, find a way to break it down, project it, track it and show not just an overall success, but a history of successes. Additionally, always be on the lookout for things you can provide or do that will bolster your manager's position, and then do it quietly in the background without anyone knowing. Once it's done, again hand off the benefits to your manager in a casual, "oh, by the way, here's just a little thing that I thought would be useful to you" kind of manner, including the documentation of incremental successes that you encountered while making it happen.
By not making a big deal out of any particular incident, you don't look like a weasel and you don't raise any defensive flags in his mind that you've done something and now he owes you. Instead, you're building an image, one of a worker that he can trust and count on, and one who's watching his back even when he doesn't realize it. Keep that word in your mind - image. That's what your priority is.
Enjoying the benefits
The payoff is huge and yet subtle. We started out talking about the monumental waste that goes on in this business, and how so much of it could be averted if techies were just given a little more horsepower in the decision making process. Here's how it works.
The meeting rolls around for what looks to be yet another project disaster kickoff. Stupid, illogical requests are made of the developers by an apparently clueless management group. Programmers' voices are raised pointing out the logical problems, the logical solutions and the obvious consequences of ignoring their advice. They get passionate, they wax eloquent. Ultimately, they are completely ignored. All the time, you sit quietly in the corner, saying nothing.
Sometime later, after the meeting is over, you collect your thoughts regarding all the beneficial suggestions made by the team. Put together a very, very, small and simple spreadsheet or document, no more than one page, that highlights the suggestions along with the benefits. Summarize, summarize, summarize! Later that day, or the next, casually drop by the manager and drop off another "by the way" printout. Having already thought of how the benefits you've summarized could play to the personal advantage of your manager, briefly mention things in that light. "I was on my way to go do something else, but it occurred to me that the points that Joe and Fred made had an interesting side effect (note that you're not taking credit for someone else's idea, and you're also subtly building credibility for your team mates). If we gave their approach a shot, it would actually help you with this goal that you've been trying to accomplish. Anyway, here's a couple of notes on how it would help you, I thought it was something you'd appreciate. Gotta run...".
Of course, you'll have to replace that vaguely worded statement with specific mention of the benefits to your boss, but you get the idea. At this point, you've built up some credibility. Instead of insisting that the developers to get their way, you're once again been seen by your boss as obviously trying to cover his posterior. Furthermore, and this is critical, you drop the carefully orchestrated information into his lap, and then walk away. When he makes the decision, it needs to be his idea, not yours. Leave your ego at the door. We're interested in results here. Never let on that the idea was other than his.
Another way this often plays out is that in the aforementioned meeting, after you have a history of being a trusted, behind the scenes lieutenant, he may ask you point blank, "What do you think?" Of course, you don't want to trot out the benefits to his personal agenda in front of the group, but you can give low key support to your fellow developers by pointing out the benefits at the management and business level. And if you do it low key enough, your manager will very likely pull you aside the next day and say, "Hey, tell me more about this stuff you were talking about." There is often far more power in having the King's ear than in being the King.
Of course, these are just general ideas and scenarios to get you thinking. You're smart enough to outfox the compiler, so you're obviously smart enough to do the math on each situation on your own. All you really need is to change your priorities and approach. Instead of bold, loud, bloody frontal assaults on the bastions of corporate waste, learn to work quietly, behind enemy lines. You're not going to change the world. And you may only move that 90% waste figure to 70%. But when that 20% gain in productivity is in your turf, it feels really, really good. And who knows, if we all learn to fight behind the lines, maybe we will change the world of software development. Just realize that it will only happen one project at a time.