Management is Engineering

10 04 2010

I recently completed a software management course. I am a technical person who likes being a technical person, but as an architect I have enough responsibility to justify learning how the other half lives. Almost everyone managing engineering projects at any level below that of a VP (and many VP’s too) has a technical background. Many of them, however, have let their degrees expire while they’ve pursued other interests. There’s nothing wrong with this, but I find it curious that many in upper management make the same silly assumption that many individual contributors make: that management and engineering are somehow mutually exclusive.
Most of my classmates were not technical leads. Most were product development leads and control account managers. Many were on the track to become program managers, directors and the like. I may have been the only technical lead. I’m not sure. However, in the class exit interview I was asked about my decision to take the class, considering my role. My interviewer didn’t think it was inappropriate for me; indeed she was happy I enrolled. What she wanted to know was the secret to getting more technical people involved in these sorts of classes. It seems that managers sometimes view true-to-the-bone engineers – the sort who would never considering entering management – a bit like parents see their teenage children. What makes them tick? How do you put a finger on those ineffable qualities that make something or someone “cool”? Why are they so sullen all the time? How do we keep their attention and get them to respect us? And why do they sleep all day?
I consider myself one of those true blue technical folks. I’ve always loved math and science. I was never undeclared in college, never unsure of my general direction in life. I have seen most episodes of Star Trek several times. Basically, I’m a rather boring stereotypical geek. And I swore to myself I would never become Dilbert’s pointy-haired boss. But these things creep up on you, like the dawning realization that what you think of as the “new” Perl Jam record came out ten years ago. Do you want to know my answer to why more technical people don’t take management classes? Managers, like parents, have to realize that it is not their job to be cool. They should revel in their dorky middle-agedness. What engineers have to realize is that they’ve been looking at management all wrong.
Isn’t management just another form of engineering? Besides the human resources issues, engineering management is about solving technical problems using data. When done right, they involve no fewer neurons than more typical engineering problems. And they are no less essential just because the output is a schedule or a budget. Often the output is a work flow of sort sort, which even makes the exercise close to programming. We do have a name for this, after all, and we call it software engineering. Programming is something you can do by yourself. Software engineering requires an organization that is smart about process, and every process needs its champions.
The experience that first changed my attitude was my first attempt at an integrated schedule and budget. My initial approach to the task was bravado. I said to myself, “I have an advanced degree; if I can survive non linear dynamical systems I can fill out some dates and dollars.” We’re the engineers; we’re the gifted wunderkinds who carry the company on our backs. However, my first pass through the numbers reminded me of a Rubik cube, or one of those puzzles where you have to slide the tiles around to make a pictures. My frustration came from all the effort I put in to creating tidy patches of sense, only to watch them melt away when I tried the make the whole story hang together. Have you ever seen some with a half-solve Rubik cube that he proudly left on a shelf, never to be touched again? He managed to massage one side into a solid color and settled for half a victory rather than risk total failure by reaching for the complete solution. That was me.
And it was my own fault. All I did at first was feed numbers into the beast, willy-nilly. I tried one thing, and if that didn’t work I tried something else. Is that how my momma taught me to solve problems? I realized that somewhere along the way, I lost my discipline. Although engineers might experiment from time to time, they don’t usually come across coherent designs by just trying stuff until it works. Nobody has enough monkeys or enough typewriters. After years of practice at creating preliminary designs, writing test cases and refining my code bases, I through away all my experience the moment I encountered a problem that didn’t strike me as “an engineering problem.” I should’ve known better, considering that I did take operations research once upon a time. Not only did my efforts frustrate me, they’d bored me. I told myself, this is proof that you’re not cut out for this.
But then I saw how it could be solved by analyzing the pieces and working toward a solution using a plan. And wouldn’t you know, I wasn’t the first person to put together a budget and schedule scheme? There were techniques, and those techniques bore an uncanny resemblance to my old friend, engineering. I look upon my former self with embarrassment. I can barely bring myself to admit my naivete. Really. It was, however, an enlightening mistake. It was not an example of stupidity, foolishness or even inexperience. It was an example of how the categories with which we use to organize the world prevent us from seeing how alike we may be to people we regard as our opposites




One response

10 04 2010

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: