Should I hire bootcamp grads? Or, “The design of engineering teams”

The managers I coach sometimes ask if they should hire a boot camp grad. Here’s what I tell them every time:

You can hire boot camp grads when you have a place to put them. And you have a place to put them when you design your teams with clear roles.

CEOs apply design principles to their companies, dividing up the organization into various functions. Developers apply the design principles to software applications. A good engineering manager does that same design work at the team level.

To understand that better let’s first talk about the people who stand around you when you go in for surgery.

In a hospital operating room the surgical team functions as a unit. There are not just surgeons and nurses; each person is essential to the success of the procedure. And every role — even non-surgeon roles — are both important and highly specialized. So much so that nobody can perform every job.

John’s Hopkins divides divides a surgical team into the following roles:

• surgeon
• anesthesiologist
• nurse anesthetist
• operating room nurse
• surgical tech
• medical students
• physician assistant
• vendor representative.

There are some variations to the above roles (the vendor is rarely necessary, the team is larger for more complex operations, etc.) but modern hospitals have learned to divide up the work in two directions: First, by separating the tasks into separate roles and second by creating a place for junior professionals.

Most software teams don’t have specific roles available. The work is divvied up by who’s interested in or good at various components. So there’s no real team — it’s just a collection of people working on independent projects. If we did this in an operating room the surgical teams would look like this:

• surgeon
• surgeon
• experienced surgeon
• very excitable surgeon
• junior surgeon
• surgeon who’s good at noticing when the patient stops breathing and then freaking out and heroically solving the problem, sometimes by wholly replacing the patient.
• frontend surgeon
• backend surgeon

This is terrible.

The few roles we use are ‘tech lead’ (or ‘architect’) and the people manager. Everybody else is just a developer working on some stuff. This has two serious implications:

1. These teams do not have consistent high output. The highest performing sport or military teams are ones that make real investments in the team itself. Each member learns to anticipate the actions of the others.
2. It’s hard to recognize the work of individual team members. How do you reward the person who cleaned up a bunch of libraries (in a way that was entirely out of scope)? How do you reward someone for onboarding two new hires but having almost zero commits to their own names? For being a full-time mentor? For communicating well with other teams?

Developers on non-designed teams get ahead by personally owning a project and leveraging those who contribute to it. Many promotion systems only recognize this one expression of technical seniority. And succeeding in this way is often only possible at fast-hiring companies. Because a tech lead isn’t a tech lead without lots of tech followers.

The ideal software team

When I think about the software teams that have really excelled they have (usually unacknowledged) specializations within them. The team is actually that — a team. Not a collection of talented individuals but a unified operating unit. There are many people contributing changes to the code but there are leaders in each discipline, an overall technical owner, a product owner, a support person, an eager junior person, etc. And teammates respect and value these roles — even if implicitly.

The best teams I’ve witnessed in my career have hidden roles in each. There is plenty of variation but they all deviate only slightly from a particular structure. The team template looks something like this:

• Product & Comms Lead
• People Lead
• Technical Lead (one per technical discipline within the product)
• Designer (1+ if producing user interfaces)
• Tools person (1+)
• Technical teacher (1+)
• Student (1+)
• Veteran/internal liason

That’s eight people, of whom at least five are contributing code. Teams get larger by giving some of the roles to multiple people.

Notice that there isn’t anyone on the list who’s just “developer”. Nobody is generic. If you don’t know how to build the product you’re the student. If you can build the product but don’t fit into one of the other roles then — surprise — you’re in a teaching role and you’ll be doing your work in a way that incorporates training.

Let’s break those roles down a little more.

Product and Comms Lead

This is likely the PM, if you’ve got one. If you don’t, somebody needs to step into this role who is willing to take responsibility for the experience of the end-user of the team’s work. For an internal product the end user might be execs or the whole company or other developers. Anyone who is willing to represent this group’s needs can do this role. If you cannot identify the end user then the team should be immediately disbanded.

For some teams the work might be light and can be combined with another role.

Example: Christina has built models for how our product’s pricing might work and how our features should be bundled. She’s creating our A/B tests and she talks to customer support every day to check how our work is affecting users. She also sends a weekly message to the whole company with our latest metrics and everyone seems excited about what we’re doing.

People Lead

This person is responsible for crafting the team and ensuring that it functions as a healthy unit. They manage people through the team and, while they may have deep technical opinions, their voice is weighed the same as other teammates on technical decisions. Their domain is the team, the meta-product, and their job is to build it, deploy it, monitor it, and maintain it just as the rest of the team does with the digital product.

This role is massively overloaded in most companies. People leads are also tech leads and cultural liaisons and responsible for products and god knows what else. This makes it hard for veteran leads to treat their reports well but it makes it damn near impossible for a first-time people manager to do so. It’s hard enough to craft a team, clearly communicate its values and mission and therefore goals, externalize and document exactly how the team members will be evaluated, and reflect on this process periodically to mitigate the influence of the people lead’s implicit biases. A people lead doesn’t need more jobs than that.

Example: Natalie used to coach soccer teams and, even though she only has one year of professional software experience, she’s skilled at creating healthy team boundaries, setting measurable expectations, and communicating. We’re trusting her to make sure we have the people and support we need and to be our representative to the rest of the company. She’s written down her performance evaluation system and we can all plainly see how we’ll be measured quarterly.

Technical Lead

The team needs somebody who takes the time to anticipate technical problems. This person needs experience but more than that they need the willingness to perform planning work and to establish internal team technical culture.

This person needn’t be the most senior developer. It’s a job, not a title¹. A junior person may find this very difficult but I’ve seen fresh college grads succeed in this role (through an incredible amount of focused work and getting lots of help).

The tech lead is expected to be available for code review when a team member feels stuck and to contribute significantly to the layer of technology just one level below where the rest of the team operates (e.g. fixing the framework, crafting appropriate libraries).

Example: Alli was a PM in her previous career and has been working in this codebase for two years now. She’s put together an 18-month plan for this application and gotten buy-in from the org. She’ll direct our work and help us stay on track. She’s found people to train her in our internal libraries and as of now has the most recent commits in each.

Tools Person

Our industry is a little weird in that we build the tools we use to do our work. And we use our work to build our tools. Externalizing the tools part of that cycle outside of a product-shipping team is often unnecessary and, in practice, there’s still going to be somebody on each team fixing the tools that the team uses.

If your company is more than a week old then there is some collection of scripts or libraries or cloud infrastructure that was built in-house and is slowly rotting. Someone is going to come in early and stay late trying to fix this stuff because they’re frustrated with how it’s slowing both them and their teammates down. Simply allowing them to do it during normal working hours means you can avoid their inevitable burnout and limit the number of product people you’ll have to peel off to form yet another infrastructure-like team².

Example: Madeleine has been improving the selenium tests and has a branch open to replace them with a more modern test framework. We’re going to let her focus on this and on our internal libraries so she can make steady progress and we’re connecting her with people in similar roles on other teams.

Technical Trainer

Every performance evaluation should open with this line: “The people who credit you with their professional growth this quarter are …” If there are no names at the end of that list then the manager failed to coach the person to be a mentor.

Mentorship is hard to come by in this industry. Not because there aren’t mentors available, but because we fail to create the affordance for mentorship.

First, we fail to create mentorship because we evaluate people by the breadth of their impact. We can fix the first by adding the breadth times the depth. We should evaluate based not only on how much of the organization did you influence but how great that influence was in specific places. If you made logging 0.02% faster across all of Google that’s fantastic. If you are largely responsible for a single person shipping their first cross-team feature that’s equally fantastic. And I’d say the latter is going to be more valuable in the long run. Code gets replaced but investing in people pays off for decades.

The second way we fail is we require every individual on a team to have their own visible output. We can fix this by having actual, real teams. If the team is evaluated on its output rather than each individual then it’s not costly for a person to mentor. It’s costly not to mentor because the team needs everybody brought up to speed.

This is why, in a well-designed engineering team, the developers who aren’t taking on the more specialized roles should be the ones shouldering the burden of bringing all junior folks up to speed.

Example: Sarah was the tech lead for the last major launch and wanted to step down from that role. Marie is a new grad who’s been at the company a year but she really understands our code base. Now that Sarah and Marie are in trainer roles we’ve accepted two bootcamp grads onto the team because we know we have the bandwidth.

Veteran / Internal Liason

This role isn’t always necessary. But when your company has enough history and enough different teams this is increasingly important. Your team may block other teams, may empower or disempower other teams, or may be able to benefit from another team — and somebody has to manage that process.

In a modern company whatever one team produces limits or enhances what other teams can do. The technical effectiveness of any team depends on its ability to use external resources and the cultural effectiveness of a team depends on its ability to provide them.

Someone can fill this liaison role if they’ve been around a long time and can intuit the needs of other teams. But even a newcomer can do it if they source input from across the org and mitigate conflict with the roadmap of other teams.

Example: Teresa has been at the company 3 years and the team is relying on her to integrate the latest deployment tool that the platform team is rolling out. We’ll be able to launch a month early because she knows the details of our legacy infrastructure and she’s collaborating with that team to bring us into the future.

Student

A common refrain in Silicon Valley companies is that they’re looking to hire more senior people. This is not a symptom of these companies having hired too junior, it’s an implicit acknowledgement that they have no idea how to manage developers. They can only hire people who can manage themselves and work in total chaos. They don’t give their teams time to clean up their area of ownership so it requires a superhero to be effective. But if your people are well organized, clean up their domain, and there is someone who can fulfill the role of Technical Trainer around then you can hire a person right out of a (400-hour minimum) boot camp.

Particularly if they’re a second-career developer they may contribute only small amounts to the product but they’ll immediately contribute to the team. Someone who’s worked outside software is typically able to spot dysfunctions that lie in the blind spots of those of us who’ve grown accustomed to La Croix.

The first time you hire some boot camp grads it will be hard to onboard them because few of us have entered the industry that way. But once you hire your second cohort you can just assign the onboarding task to the first cohort and you’ll see incredible results. Because if there’s one thing I’ve learned to be true about grads of intensive boot camps it’s that they work their asses off. If there’s a second thing I’ve learned it’s that they see what’s wrong with our industry better than us and they will fix it given half a chance.

Yeah, but what about…

“These aren’t the roles we need on my team.”

Each time you charter a new team you’ll be doing it to solve a specific problem. Maybe the product infrastructure isn’t up to par, maybe there’s a need for a new product, etc. Design the team around solving that problem and create roles that fit. The important part is that each role feeds into the team’s deliverables so nobody has to work outside the team.

“I don’t want to hire a boot camp grad and train them and then just have them leave.”

How about don’t be an awful place to work and they won’t leave? Focus on doing the right thing for them at all times and they’ll stay long past when it would be best for them to move on. Make it an environment where they grow and have the ability to profoundly help the customers and their peers and then — when it is time for them to leave — send them off with the best wishes and the strongest letter of recommendation you can write. The valley is small and careers are long; the way you treat people determines your fate in this industry.

“Medical students only exist at teaching hospitals. We don’t want our engineering team to be a teaching hospital.”

Yes you do. Teaching hospitals provide measurably better care. This may be due in part to the paradox of expertise — teaching hospitals avoid the trap of trusting essential tasks to people whose skills are fading or outdated. They also provide an essential service to the world.

“Software organizations don’t work this way.”

Neither did medicine or aviation decades ago. There was a time where aviation was some hotshot pilot who survived a war and was willing to take people into the sky for money. But that industry has rigorously improved itself to the point that there were zero commercial aviation fatalities in 2017. And medicine has a long way to go toward that standard but they’re far ahead of us.

“This might work at a BigCo but it doesn’t work at my startup”

Nothing works at a startup. You’re so lucky to have any developers at all and at such a small scale it takes almost zero time for a boot camp grad to start being effective. When the entirety of your source code can be read in a week anybody with a little skill can do exactly that and then start contributing.

You could do worse than adding someone who has had a whole other career to your team and who’s willing to work for cheap (relatively to what BigCo pays).

Follow me (Jack Danger) on Medium if you want all of: More posts like this, writings on the psychodynamics of relationships, slightly funny satirical posts, and the occasional romantic poetry. I dunno how to make Medium separate that stuff so you get it all. My deepest apologies.

[1] Also, titles are terrible. Only give people jobs with clear roles. It’s healthy to say what you do at the company. It’s unhealthy to say what you are at the company.

[2] If you’ve ever seen this pattern you may have seen that this tools team is composed of people of a very similar — slightly grumpy — disposition. And moving them off product teams means they have less leverage over how product teams use these tools — leading to increased grumpiness. In my opinion they should stay on product teams until the tools themselves become a product.