Technistas

Yesterday I had lunch with an old friend and colleague who like me, is between jobs. After talking about the kids and the family, the conversation turned to shop talk, which for my friend and I is the software business. Both of us are experienced managers, in my case having led teams anywhere from 4 to 45 persons, and for my friend, organizations upwards of 200 developers. What emerged from the conversation was our common view that the single most important thing that a manager can do to ensure a successful software product is to hire and train the right people.

Now, this may seem obvious, but there are managers out there who for whatever reason believe that the development process is the most important factor in team and product success. That you can take mediocre talent, insert it into a formal process, and have superior code emerge from the other end. At the risk of starting a flame war between the process-centric and people-centric folks out there, let’s examine the single equation that rules the software industry: People + Process = Product.

If you walk into a development shop and ask about process, chances are you will get a different answer from everyone you speak with. Managers will often fire off a list of “things that we do” and pass it off as process. Engineers on the other hand, tend to chuckle, smirk and give you a more direct answer, usually something like “I look at my list of defects and features and then write code to resolve them”. If asked about the details of the process, you will get as many different answers as there are team members. This is my first point: your process more likely than not, isn’t what you think it is.

Now, go and ask the same development team about people, and I suspect you will hear a different story: Joe is the best algorithm guy I’ve ever worked with. Jane can step up to unfamiliar code, grok it instantly, and fix nasty bugs quickly. Bob writes useful unit tests. This is my second point: the team knows intuitively who does what best, and if pressed, why those roles are critical to the success of the team.

When asked to come in and fix a troubled team, my friend doesn’t inquire directly about the process when interviewing the team. Rather he asks: what’s working around here? Usually there are 3 or 4 things that the team does well, that can and should be used as the basis of a new process. The interviews also tend to give him a sense of who the top talent is, and who the laggards are. This sets the stage for shifting people into the most effective roles, and adjusting the process – in that order. Similarly, when I have been asked to build a team from scratch, process is the last thing I think of. The first thing is hiring and training top talent. Once there is a critical mass of developers (usually at least 4), a funny thing happens. The developers, if they are truly top-notch, will start to self-organize and suggest a process. At this stage, I step in and help the team put some formalism around the process so that we can measure our progress, and the race is on.

To sum it up:
1. Your process is what your engineers actually do, not what you’ve written up on paper.
2. Great engineers deliver great products.
3. Process is a guideline to keep the greatness wheels turning.
4. If a team is underperforming, focus on your people first, then fix the process.

If you’re managing a large organization or a complex set of deliverables, there’s no question that your development process is important – it needs to be scalable, easy to measure, and non-obtrusive. But, as anyone who has watched the 0-14 Detroit Lions lately knows, without talent in all key positions, no amount of process can produce magic and turn a sow’s ear into a software silk purse.