Introduction
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.
