wagnerblog.com

This time I want to write about  team / management structure and how it may affect the quality of your end product.

Recently I commented on the book “Founders at Work”. Specifically the interview with the founder of ArsDigita. Some time has passed, but even now I find myself rerunning a couple of lines of this interview in my mind. Specifically a section in which Philip Greenspun talks about the importance of giving programmers a role in the interaction with customers. ArsDigita would run small 3 person teams who were solely responsible for the profit or loss of their project. If the project succeeded, the team would get half the profit as a bonus. Nice. Greenspuns interview reminded me of the time I spent being self-employed. I ran a small consulting company for six years. As a consultant I would meet with customers and hammer out the project. I had direct input not only over how something would be built but also over what the project was in the first place, the requirements in their schedule. This afforded me unprecedented involvement from the first exploratory discussion to the final deliverable and acceptance test. My consultancy went under during the last dotcom bust.

I’ve spent the past five years in 3 companies working with varying sized teams and methodologies I firmly believe the reason my consultancy had an unheard of 90% on time / on budget record was simply because of the way we worked.

Larger companies seem to think that adding “Project Managers” between programming teams and customers is the way to go. In my experience it is not. An well run team of three can outperform many of these larger companies.

I’ll let you in on a dirty little secret: The reason these companies have “Project Management Offices” and in some cases as many PM’s as there are coders is simply because they are badly managed . Its true. There is nothing that prevents these companies from hiring very capable individuals and run projects on the basis of the small team concept I’ve outlined. The only reason I can imagine that keeps managers from using this approach is some sort of fear. After a certain period of time as a technical manager you tend to get this nagging feeling that your not totally on top of all the development related advances. Lets not event talk about senior management. I have been a VP of Technology in two companies and even knowing everything that I know about this danger, I found myself falling into the same trap.

Management needs to understand that software development cannot be done by following the methodologies of early industrialization. Bill Gates is not Henry Ford, and as much as management attempts to shoe-horn development processes into neat little kanban cards… it won’t work. Your end product will suffer. By the way that’s not a slight against JIT production. To the contrary. Toyotas Quality Assurance is fantastic. Small teams have a big impact at that company. Heck the Prius is a computer on wheels and Toyota had something like 10 prototypes of it simultaneously. You can’t do that unless you have a good handle on what determines your products quality.

The more removed from writing code you are, the more comforting it becomes to look at your programmers as interchangeable resources. Efficient Heizelmännchen (elves) who sit and wait for a Fogbug that requests some new feature or bug fix. Greenspun is right when he says that its easy to offshore programmers if they are treated as drones. Many of the consulting projects I used to bid on five years ago are now being bid on by offshore companies. That impacts the business of those few consultants who are out there trying to make a difference.   It makes me sad because in a way that perpetuates the idea of lego-block programmers who can just be swapped out without much regard for anything else. Hopefully between the rise in offshore salary levels and drop in quality of people entering the development field in other countries the pendulum will eventually swing the other way again. Heck even locally I’ve seen this attitude produce horrible software because its predicated on the notion that one programmer is just like another and that context switching is not an issue. So I’ve seen projects go through several hand-overs and suffer tremendously as a result.

Programmers most certainly are not blindly interchangeable “parts”. Great teams are literally worth their weight in gold. Maybe if you are in the league with IBM Global Services or some Big 6 accounting company it might make sense to have lots of PM’s and various layers between the customer and the team —– but for most of us this does not make as much sense as some people would have you believe.