The Swiss Army knife is a popular tool. Since its origin in the Swiss Army -- yes, really -- in the late 19th century, they've become so popular that they've also turned into a colloquialism for adaptability and usefulness. There's only one problem with that: The Swiss Army Knife is not the greatest knife. It's also not the greatest can opener. Nor is it an awesome screwdriver, or a stellar saw. So why the appeal? Because it's better than not having a given tool at all. After all, a decent screwdriver is better than nothing. The same goes for a can opener and a saw... and a knife. You actually have three choices here:
- Don't have the tool at all. This is the kind of behavior that leads to either using odd tools (a dime to turn a screw), or to borrowing someone else's saw.
- Have the best version of the tool. Buy the best knife you can find, a good can opener, a great saw, etc. It's expensive and takes up a lot of room, but it's doable.
- Compromise. This is how you end up with a Swiss Army knife. It's not the best of anything, but it's convenient and relatively cheap.
The Swiss Army Knife of Engineers
The same is true when it comes to engineering. Particularly in Agile methodologies, there's a lot of talk of generalists being more desirable than specialists. SCRUM is predicated on the idea that the team can pick up each other's work to meet their collective commitment, which implies that each member can do each task. In other words, they're generalists. Kanban is similar. Engineers don't take the top thing off the backlog that meets a particular team member's skill set. They just take the top thing off the backlog. Again, generalists. Generalists are the Swiss Army knife of software engineers. They probably aren't as good at any one thing as a specialist (a database engineer, for example, or a release engineer). The theory is that the generalist is good enough, and that versatility is more important than the improved quality of specialization. It's convenient and relatively cheap.
The Right Tools and the Right Team
When I'm putting together an engineering team, one of the first decisions I have to make is whether to build a team of generalists, specialists, or no team at all. Let's look at those three choices again, this time through the lens of software:
- Don't have the engineer at all. This is doable, as long as the company is willing to use compromise tools (Wordpress instead of a custom website, for example), or is willing to borrow engineers when they're needed. For companies whose business isn't technology, this is often a great choice. I have a client whose business is selling toys. They don't need a software department; they need to hire a development firm when they have a software project.
- Have the best version of the engineer.Hire a great database engineer, and a stellar designer and someone who breathes JavaScript. It's expensive -- specialists who are that good command a premium. It creates bottlenecks in software development since, say, no database work is going to get done when your database engineer is on vacation.This option's also sometimes worth the increased expense and development overhead, particularly when you face special software or market needs. Several years ago, I worked for a company which differentiated itself with amazing UI design and a great user experience. It hired designers -- specialists -- because they were worth the expense and development slowdown.
- Compromise. Hire engineers who can work on a a database schema in the morning and a JavaScript-heavy UI in the afternoon. They won't be the best at either, but they'll often be good enough, and the team's overall delivery speed will be much faster than it would be with specialists. An engineer is out sick? No problem. Another can pick up the last of his tasks and get the feature done. For most of my clients, where speed of delivery is more important than pushing technical boundaries, this is a perfectly acceptable way to build a team.
Like a tool set, an engineering team is about balancing cost and specialization. Your challenge is to make the choice that's right for you and for the problem you've got to solve. Image:
Victorinox
