I’ve been explaining the kinds of projects I like to work on and I tend to go back to an old post of Jeff Atwood’s about Commandos, Infrantry, and Police. Briefly, the analogy is to software developers in their role at a projects. The first people in being the commandos:
A start-up’s biggest advantage is speed, and speed is what commandos live for. They work hard, fast, and cheap, though often with a low level of professionalism, which is okay, too, because professionalism is expensive. Their job is to do lots of damage with surprise and teamwork, establishing a beachhead before the enemy is even aware that they exist. Ideally, they do this by building the prototype of a product that is so creative, so exactly correct for its purpose that by its very existence it leads to the destruction of other products. They make creativity a destructive act.
Obviously this aligns well with startup concerns and is where I like to be. Though, this stage doesn’t seem to last too long before you have to consider the infantry-type jobs.
These are the people who hit the beach en masse and slog out the early victory, building on the start given them by the commandos. The second-wave troops take the prototype, test it, refine it, make it manufacturable, write the manuals, market it, and ideally produce a profit. Because there are so many more of these soldiers and their duties are so varied, they require an infrastructure of rules and procedures for getting things done — all the stuff that commandos hate. For just this reason, soldiers of the second wave, while they can work with the first wave, generally don’t trust them, though the commandos don’t even notice this fact, since by this time they are bored and already looking for the door.
I figure this one is what it’s like to be an early employee at a startup. By the time you are hiring you need to start thinking about refining products, tests and all the other stuff I only like to do when necessary. Lastly, there are the police:
These third-wave troops hate change. They aren’t troops at all but police. They want to fuel growth not by planning more invasions and landing on more beaches but by adding people and building economies and empires of scale. AT&T, IBM, and practically all other big, old, successful industrial companies are examples of third-wave enterprises. They can’t even remember their first- and second-wave founders.
These are the kinds of jobs I avoid. These positions tend to be filled with the kind of people who want a great job rather than want to make great software.
In the startup world all developers are basically “commando” or “infantry”. In a way, it’s not enough for a team’s first people to just be infantry, there have to be some commandos in there to really get some shit done and a ball rolling. I would actually worry about hiring someone who’s been doing too many “police” type jobs into a startup at all; you want someone who also codes on the weekend for fun and makes projects, even if they’re pointless, just for fun. When I worked at SAP (definitely a police-institution) I seemed to be the only one who worked on other projects when I got home. Google was different though; people there just seemed to love coding and were grateful to be at a company who gave them the famous 20% time (commando-time).
Everyone likes the idea of a commando-employee. On paper it sounds like you drop one into a project and all of the sudden its up and running in a few weeks. Every now and then you hear about a big company wanting developers that fit the commando description, but they’d soon realize that they couldn’t handle a team like that. The trouble is, not everything about the commando breed is great. They get bored easy, distracted by other projects, and really don’t like being restricted by any bureaucracy. I’m not even sure how a big company could handle a commando-type.
There’s also an element of project being bigger than one team and that’s why you can’t let these types run rampant. You basically want to avoid the situation that this tweet so geniously explains:
When I hear “JUST BANG OUT CODE THAT WORKS” I think of all the apps I don’t use anymore because they gradually lost the ability to iterate.
— Avdi Grimm (@avdi) March 16, 2012
It’s nice having an MVP up and running in no-time, but in the startup world iteration is the key and if you lose your ability to do that you’re done. Not to say commandos necessarily are prone to that, but there’s a reason we have process in software development. If you find a commando who can hammer out something well-structured with tests in short order: do whatever it takes to keep him.
Back in the startup world, I’m not sure whether the best technical co-founder would be a commando himself or just someone best described as infantry who can manage commandos in a way that a non-technical person would never be able to. I’d just avoid police-types. Founders looking for a technical founder tend to get desperate enough that they’d take anyone who can hammer out their app idea, but if it’s not the right type they may not be used to hammer out things quickly as required in startups. There might also be too many expectations in regards to short-term compensation and health-plans.
If you’re looking to recruit commandos for whatever reason, I’d suggest hackathons. That seems like the ultimate commando proving ground where small teams have to make a deliverable from scratch with a small team in a short period of time. It’s a special kind of coding that translates well to the startup world. As tempting as it sounds to have the academic programmer working on neural processing on your team, you need someone who can make a deliverable in a 2 days rather than a model of something in a few years. Hackathons will show you who have this ability.
Speaking of which, IronHacker 2013 coming soon.


