Managing CEOs for Programmers (Continued)

As difficult as it is for a programmer to manage a non-technical CEO (yesterday’s post), managing a CEO who is technical or thinks he or she is technical is much harder.  A CEO who knows programmer-speak can be very difficult to manage.

[full disclosure:  I was a programmer first and a CEO second.  For much of my career I was both which was fine when I was the only employee in the company but not so good when there were other people that needed to be managed.]

No previous generation of programmers has any respect for the generation that comes after.  How can someone have any problem getting a program done when there is so much memory available?  After all, the technical CEO remembers, the first Mac had only 128K.  Its successor with 512K was called the “fat Mac”.  There was no hard drive at all on that early machine.  “Today’s programmers,” an old timer would say, “can’t write ‘hello world’ without at least one meg of RAM for the code to run in and 10 gig hard drive to hold the paging file and object library.”

Bill Gates was the epitome of the technical CEO when I was at Microsoft.  He remembered writing a Basic compiler for a 2K (or was it only 1K?) machine in a plane on the way to a meeting.  We old guys wrote macros to ease some of the drudgery of assembler but couldn’t tolerate the fat code generated by Pascal or C compilers (Cobol was for people in a different universe).  Now here we old guys are managing a bunch of kids who are whining that their options haven’t yet paid for their first Maserati and who just need to drag a bunch of high-level objects into the right place on a screen in order to write a “program”.  And they still can’t get it done on time.  See how hard we are to work for?

Technical CEOs have age-inflated memories of how hard they worked in their day.  I can distinctly remember sitting in front of my screen 48 hours at a stretch – or was it 72?  When a project was late, we went to the pizzas the way a mafia clan in The Godfather goes to the mattresses during a turf war.   We didn’t go HOME!  We never went home.  Pride came with how much dust our cars accumulated in the parking lot.  So how do you work for someone like this and still have a life?

One way to manage a formerly technical CEO is to take advantage of how quickly we get obsolete and how impossible it is for us to admit our obsolescence.  If we’re old enough, we understand macros and subroutines and bound variables but are a little fuzzy on objects and methods and class libraries.  Make sure to talk jargon to us – it shows respect; and, if it’s new jargon, we won’t know what it means and we’ll be afraid to ask.

You can also take advantage of the fact that us old guys and girls suffer from a shortage of unoccupied neurons.  And all CEOs, regardless of age, have short memories – they’re flushed every quarter.  So, if you’re careful, you can slowly slide a schedule or erode a feature set over time without getting caught.  This can be a risky strategy, though.  I learned a counter-strategy from Bill Gates.  He remembered some things in great detail from every meeting.  I’m not sure whether he wrote them down or not.  If something he happened to remember wasn’t the same at the next meeting, look out!  Since his algorithm for deciding what to remember was uncrackable, it was unsafe to try to sneak in any changes.

The ultimate strategy for dealing with the technical CEO is to get him or her on the critical path.  Get us to accept responsibility for a subroutine or whatever the unit of programming is these days and we’ll simply never get it done.  CEOing and the concentration required for programming are antithetical.  If the CEO hasn’t delivered her part, you’re off the hook. We can always be suckered in if you tell us that we are the only ones that can do something.  Our only revenge is that you may be a CEO yourself someday and some young squirt’ll outsmart you.

A million years ago in the mainframe era I was teaching (mentoring hadn’t been invented yet) a young man who had no college and had started his career as an operator in the machine room.  I taught him all the intricacies of IBM’s OS/MVT Version 11 for the 360.  He was good and about to be promoted to full programmer status and I treated him to a celebratory dinner before going back to work.  “Next week,” I said, “IBM is releasing Version 13 (12 never got out).  You know what that means?”  I expected him to be suitably humbled.

“Yeah,” he said.  “We’re even.”  I never did learn as much about Version 13 as he did.

Yesterday’s blog was on managing the non-technical CEO.

Since I’ve been both a CEO and a programmer, I’ve also blogged on CEOs managing programmers.

Part 1 of this series is a phrase book of programmer-speak.

Part 2 is the meaning of “done” and how to know when you’ll get there.  There’s another Bill Gates story here as well.

Part 3 is about features that kill projects.

Part 4 is about super debuggers.