Morph of a Nerd CEO – The First Employees

Management is harder than doing everything yourself.  People are a lot harder to program than computers and they can’t be rebooted.  A request for a core dump is likely to be taken as an invasion of privacy.  Some people even have outside interests which get in the way of their programming.  We nerds call people like that “random” but they do exist and there’s a pretty good chance you’ll end up with some of them if you start hiring.

Have I convinced you to remain a sole practitioner yet?  If so, please go to tomorrow’s post (not yet available).  If you are determined to add employees to your sole programming practice, read on and I’ll try to save you from the worst of my mistakes when I first became the boss of people besides myself.

I had already been a manager in other people’s companies.  At one point I’d even had eight people working for me.  I hadn’t been a very good manager.  I set a good example of hard work and optimism, that’s the best that could be said for me.  I hated performance reviews so I didn’t do them on time if ever.  I didn’t like to criticize people so I didn’t until long after their performance deteriorated to intolerable.  Laying people off was so hard that once I procrastinated until my boss had to lay off someone who worked for me.  In short, I’d rather program.

But my one-man company, Solutions, was over-committed.  “We” had more consulting clients than we could handle.  Some consulting gigs turned into contract programming jobs when I convinced customers that it would be cheaper to have me rewrite crummy apps than keep paying me to patch them up.  Saying “no” is almost impossible when you have your own business; you’re afraid people will never ask again – particularly if you remember the panicky days when there was no business at all.

So go hire some folk to do some of the work.  I should have subcontracted at first but I had company-building visions.  A classified ad in the Vermont papers got plenty of responses; Vermont was a very in place to live but there weren’t jobs there.  Interviewing wasn’t (and isn’t) one of my strengths, too much like making small talk.  But interview I did.  Asked for references but never checked any of them.  Hired two men and a woman who seemed smart and that I thought I’d like to work with.  In sudden fear of not meeting payroll, I proposed and got two or three more programming jobs.

We had a 2780 remote job entry terminal so we could test on a mainframe in Baltimore, an 029 keypunch we took turns on, a WATS line which gave us unlimited US calling for just $600/month (for the 2780) and a modem the size of a breadbox so we could get a blazing 2000 baud.  That part was actually OK.

My lack of management skills aside, three was exactly the wrong number of people to hire.  Physics tells us that we can’t do an unquantum leap. Three direct reports require almost twenty hours a week to manage (not that I was doing that).  Moreover, if somebody is going to do programming besides just you, there’s got to be stuff like specs before programming can get done.  If you sold the job, then no one except you knows what the program is supposed to do (often not even the customer).  So now you have to spend time writing specs.  And then there’s quality assurance.  You used to do your own testing and you certainly weren’t perfect but you’re better your employees because you know the customer is the next tester.  So you either hire a QA person (right choice) or do it yourself (wrong decision I made).

You may think that if you add three new programmers to a staff of one that you will have four times the capacity.  Bad math.  The new programmers have lives.  Even if they turn out to be a competent programmers, they aren’t driven super-programming machines like you were before you decided to be a CEO.  A super-programmer is an order of magnitude more productive than a “good” programmer.  Moreover, there are inefficiencies including the need for specs, product reviews, meeting and so on when work is being done by more than one person.  And, of course there is no time for you to program given the load of selling, administration, management, testing and spec writing.  Solutions output with three new employees was considerably less than when I was working alone.

So of course we got behind on all our jobs.  So of course I started programming in order to catch up.  And when I started programming, I stopped managing.  When I stopped managing, productivity went down further and the chance of components actually working together when finished went to zero.  But, after an initial advance, we only got paid on deliverable milestones.  There goes cash flow.  So I had to go out and consult to earn the cash for payroll and the WATS line.

Eventually I had to wind down my first attempt at company building, lay off the people (no one to do it for me now), negotiate time to finish the jobs myself, bring the 2780, the 029, and the files of punch cards and binders of fan-fold paper to my house, and go back to being a sole practitioner with some part time administrative help. Stayed that way happily for quite a while.

With hindsight, I should have “outsourced” overflow to other sole practitioners who knew how to manage themselves.  Maybe today there is an alternative in Bangalore but there wasn’t then.  Once there was work enough to hire seven or eight EXCELLENT (not good) programmers AND an experienced manager, that would have been the time to take the chance at expansion because there would have been a real increase in capacity, not just in headcount.  That could have been a sustainable quantum leap.

If you want to be a CEO, you really have to force yourself to do all the “bullshit” things that come with management.  Objectives, performance reviews, early correction of mistakes, quick termination of poor performers, checking references – these are all unnatural acts for a nerd but the necessary acts of a manager and something a CEO must not only do but also force other people to do.  If you don’t want to do them, stay a sole practitioner (see yesterday’s post) – there’s a lot to be said for that.

I’ve blogged some hints for CEOs on managing programmers here, here, here, and here.

Just to evenhanded, I’ve also blogged on how programmers can manage technical and nontechnical CEOs.