I took a brief break from writing about software to write about cardboard creations (there will be more), but now I’ll come back to writing about software. Specifically, I want to talk about the small team and how to actually get things done.

We’ve covered the logistics of having a small team, and now I’ll tie this train of thought together. In order to deliver software, you need to be able to accomplish the following tasks (at least), in my opinion:

The position you frequently get into is that you have your developers, all of whom can write, and some are able to do bits of the non-programming tasks above. Because of this, in my experience, a small team will really struggle with the entire life-cycle.

In a larger organization, this can be compensated for by having external groups (DBAs, Devops) support. Going back to my post on Vertical Integration, it won’t be hard to see that I’m not totally comfortable with the outsourced approach afforded by these external teams. I believe that a team needs a high degree of vertical integration, and that means that I feel that you ought to have some degree of expertise with all of the support processes.

This Means You

Yes, team leader, most of the time, this means you. If you want to keep your programmers programming, you only have one extra set of hands for all the other stuff, and those hands are yours. It is very tempting to use your programming skills to make more output for your team – in many cases, you are among the most skilled programmers you have available. However, it is your team, and its success hinges on you. You may very well need to be the one who handles all the non-programming tasks of your team, and probably even some of the programming.

Who Do You Trust?

One of the realities of being a programmer is that programmers like to program. Often, they love it, which is one of the great things about our industry. We really like what we do. So trying to get a programmer not to program is a bit like trying to get your young kid to stop talking about making traps for bad guys. It’s very hard to do, and it might work for a bit, but before you know it, your kid is back to alerting you that we need to make more traps for bad guys who come into the yard at night… but I digress.

If you tell your programmer that they need to work on deployment scripts for a few days, they might be really into it, or they might do a half-assed job and return to programming. Both of these outcomes are just fine, because in our industry, people are specialized.

If you do have a developer that will dig into tasks other than programming, that developer has a lot of potential. If they do a good job, you know that you have a person on your team who will broaden their skills and areas of knowledge so that they might eventually lead a team. However, it’s equally likely that that developer would just rather be programming. Which is ok, too.

In either case, the person upon whom responsibility truly lies is you. You also probably trust yourself to see the project through. So you can either find a reliable member of your team and delegate those scripts, or you can do it yourself. If you delegate, you still need to know the broad brush strokes of that your team member is doing. The same goes to design, planning support, etc. There is a reason Bill Gates would reply to emails from customers. It’s the only way to see how people truly like your software.

Team <your name here>

When a project ends, your team’s reputation is attached to your name. That lives with you for a long time. It takes a spectacularly bad non-leader on a team to change a ‘Mike’s Team didn’t do a good job’ to ‘Mike’s team didn’t do a good job because if Bob’. It also, incidentally, takes a spectacularly bad leader to actually force that narrative change.

In order to be really successful, regardless of whether your organization has strong support groups, it’s your responsibility to ensure that you know all aspects of the product you are delivering. You might not know every detail of every use cases, or all the ins-and-outs of PKI, but you if no one else on your team knows how to do something, it’s up to you to step in and figure it out.

n.b. In no way do I feel that it’s a bad thing to specialize and not be interested in non-programming tasks. It’s just a part of the industry. Some people are single-task people. Some are not. As a leader, it’s good to learn the difference.

Also: Even if you have external teams, you should have dedicated liaisons who can work alongside those teams to understand them and what they do, and to incorporate their best practices into your team. There is a lot to learn from specialist external teams.

Next: Finding and Adding a new member