Confessions of a crappy manager

Posted under Blog Posts, Software Design

Imagine me in a job interview where the interviewer asks the obligatory question “What was your biggest mistake and what did you learn from it?”

If I’m ever asked that question, I will respond by asking “Don’t you read my blog?”

In my early days as a developer, I enjoyed the fast track to management.  I had proven myself as a charismatic and technical “fixer” and I became in charge of a sprawling project with a single developer that was way off the rails.  My role soon evolved into constantly explaining “why things aren’t done yet.”  The following is my mea culpa and my cautionary tale about newbies who manage software projects.

This is a story about my third major software project.  It involved a completely new product, and I inherited the project a few months after it had started.  It was already hopelessly out of control.  For the next two years, I spent 95% of my time trying to quantify the work remaining, bugs identified, and schedule slippage, but didn’t have the experience identify the real problems;  1) Too many cooks directing the requirements of the software and 2) not enough technical horsepower to accomplish the development tasks. 

In retrospect, I recall asking my manager for one or more new developers to eventually usurp or replace the existing developer, but was told “no.”  In that sense, I failed miserably.  I should have fired the existing developer anyway even though I was constrained to only one developer, and then let my manager deal with the consequences.  Or I should have quit right then and moved on. 

Spreadsheets, Spreadsheets…

No matter how many spreadsheets I made, or how many Microsoft Project files I created, or how many attempts I made to apply methodologies, I wasn’t measuring the right stuff.  I didn’t understand that software development is no different from any other craft.  It’s about smart people doing expert-level work with tools they understand completely. 

It’s not rocket science, and there is no ancient Chinese secret.  Good people doing good work with good tools will make good products.  If you mess with that formula, you will fail.

Ultimately, the underlying problem with this particular project wasn’t “methodology” or “process.”  The problem was that the technical demands of the project exceeded the abilities of the developer, and he wasn’t experienced enough to get it right;  He was a bright (if not quirky) guy that hadn’t mastered the art or the tools of software development. 

Excuses, Excuses…

Unfortunately for everyone involved, I didn’t have enough visibility into the technical issues that plagued the project, and no one else around me was qualified to see them, either.

The entire project was being written in an arcane and boutique development language that few people on earth truly understood.  I won’t tell you the name of it, but it was a ‘templated Windows code generator’ environment with zillions of nooks and crannies and leaky abstractions in which the developer could get lost for days.  I went to some classes and read some books on the language, but there was just too much that I didn’t understand about software languages.  As a result, I put too much faith in the developer-as-god dogma, and then fell into the developer-as-devil trap because I had not yet mastered the art of software project management. 

I was in no way qualified to fix this project.  If someone handed me a project like that today, I would stop, wipe the slate clean and start it over with new people, tools, and platforms.  My favorite manager from the past once told me, “You don’t regret the employees that you fire; you regret the ones you don’t.”

As it was, I stayed on with the project, watched my manager do exactly what I was told that I couldn’t do, took my obligatory bitch slap from upper management, and struggled through an astounding amount of bullshit in the interim.  I now now drive the architecture for a team of five brilliant and innovative developers on the next generation of the original product.  I’m having a blast, and I wear my battle scars with a combination of pride and shame. 

“Dev Team, Manage Thyself”

Our current dev team has an organic authority structure, and we make self-directing decisions every day.  Not surprisingly, we usually make the right decisions without a formal “upper management supervisory process.”  Our morale is also at an all time high.

Today, we are adding more and more developers to our team, and we will soon encounter communication and collaboration problems requiring… formal project management.  This poses an interesting challenge for anyone hoping to “formally manage” this project.  When it comes time to introduce a “non-technical manager” to this already successful workflow, the manager will need to have a mature understanding of his/her role as observer, conveyor of status reports, writer of executive summaries, and deliverer of messages from upon high-level board members.  Luckily for us, we already have that person on staff and are preparing him for that role.

Gunslingers need not apply

In a different world, if we brought in a young hotshot gunslinger, the dev team would simply grind to a halt when the new manager started enforcing his/her role as the new “tank commander.”  Sure, I would do everything within my powers to help that fictional new manager avoid a train wreck, but you just can’t change the fundamental nature of people.

I like gunslingers.  Gunslingers are great for projects that need to be shaken up, slates wiped clean, and that need their entrenched and worthless cronies eliminated.  That said, gunslingers are instant death for successful projects that are already running successfully and autonomously.

I’ll add on to what my favorite manager from the past once told me by reminding fellow developers that  “If you need to, you can fire your boss.”