Your app is taking off. Sales are going up, but bugs and feature requests are also going up. If you want to keep the momentum, you will need to start fixing bugs and refining features in a timely manner.

“That’s more work than I can handle!”

No problem! It’s time to build a team. Here are my best tips:

Don’t create a monoculture.

If everything is turning into shit, and no one knows what to do about it, it is probably a monoculture.

There are so many places that give an interview which is strongly biased towards a very specific skill set — usually because it is the only thing the people doing the hiring know. When everyone in the team has the same limited set of skills, backgrounds, and interests, simple solutions get overlooked. Simple problems go unsolved. Emerging tools and technologies are off the radar. New potential markets are ignored.

Try to hire a little bit outside of your own expertise. If you have to lean on other experts to do this competently, do it. It will be money well spent.

Beware credentialism.

Programming is an art. Some artists exhibit talent without formal training. Others exhibit formal training without talent. Everyone knows this for things like music and painting. Very few HR departments ever got the message when it comes to programming.

How do you determine an artist’s talent? By his alma mater? By his collection of product certifications? With brain teasers? Judging a guitarist this way is ridiculous. Judging a programmer the same way is every bit as ridiculous.

Don’t staff-up too quickly.

No matter how great your interviewing process may be, absentees, idlers, incompetents, plotters, saboteurs, sowers of discord, and general screw-ups are going to squeak their way in. It takes time and effort to reveal these people for what they are, so it is critical that the first round of hires is fully vetted before you attempt the next round of hires.

Letting a troublemaker slip through the cracks in software development is very dangerous. The longer a bad egg is in your midst, the harder it is to get rid of him. As his knowledge becomes more deeply ingrained into your product, the riskier it becomes to let him go.

Also, adding people to a late project is only going to make it later. Each new addition to the team triggers an explosion of new communications that have to take place, and that level of communication never goes away. You will have twice as many developers, but they will all be less than half as effective with perpetual meetings and phone calls.

What can I do then?

Slow and steady wins the race. Carefully hire a small team. Even when exercising great care, some of your hires may not work out. Quickly cut those people loose. Even if you only have two people left after the cut, those two hires are money in the bank. They can also help you with the next round of hiring and management. Two can become four on the next hiring cycle, eight on the cycle after that… There has to be a culture of excellence in the beginning, for the early hires will eventually have to break-off and build-up their own teams as the product grows.

Don’t micromanage.

When every little decision has to go through a manager, the team’s cumulative knowledge and productivity will be less than that of the person managing them.

  • They will waste a lot of time waiting for an audience with the manager.
  • Their own personal expertise will either be reigned-in or diluted by their manager’s preferences and prejudices.
  • Productive developers will quickly get fed up and leave.
  • Developers who remain, regardless of their own unique skills and perspectives, will become a virtual monoculture under the shackles of micromanagement.

Supervise.

It is not uncommon to interview someone with excellent credentials, good references, years of experience, and decent people skills, who ends up being mostly useless on the job. New guy might be going through a rough patch, or he could be a first-class con artist, or it could be that his heart just isn’t in it anymore. Whatever the case, dead weight needs to be nipped-in-the-bud immediately.

Do spot checks in source control. Spot check the code as well. Make sure everyone is checking in professional-quality code with some regularity. Don’t micromanage. Supervise. When your developers know that you are actually paying attention, and that they will be held accountable for what they check-in, they will either bring their A-game, or they will find another job where they can goof-off in peace.

Build and maintain trust.

The best software is developed by people who are in the zone. When you are in the zone, there is no room left for material considerations like pay, benefits, amenities, status, power, privileges, etc. In the zone, it is all about the code. When you are in the zone, you like to stay in the zone.

One thing that will push your developers out of the zone permanently is screwing them over, so don’t do it. If you do, the best ones will leave. The rest will spend more time on office politics than code. The office will turn into a soap opera with less attractive people. Soap operas are bad enough with attractive people.

If your developers are in the zone, keep them there. Just be honest and fair. Go above-and-beyond on the material considerations so that your developers can focus on the code instead of their health plans. Give credit where credit is due. Uphold the golden rule. Have their backs, and you will all get rich together.


← Older   Newer →

Leave a Reply


<a href="" title="">, <abbr title="">, <acronym title="">, <b>, <blockquote cite="">, <cite>, <code>, <del datetime="">, <em>, <i>, <q cite="">, <s>, <strike>, <strong>