building teams from scratch
· 6min · leadership, career
vibe check
I was hired in December of 2024 as a Team Lead with the mandate to build an engineering organization in the United States, with the bulk of the longer-tenured engineers in a distributed office. The exact engineering profiles are in my purview, but there are definitely some anchor requirements set by the home region.
While the profile might be different than what many are going through (such as building teams in Poland or Brazil instead of the US being the satellite team), the fundamentals should translate.
So here’s my approach, and hopefully there are some solid takeaways that others can benefit from.
the culture myth
Spicy take: I don’t really like the idea of a “culture fit,” since too many times it really means “someone that brings nothing new or challenging to the team.”
Too many times, ‘culture fit’ really means someone that brings nothing new or challenging to the team.
This is actively detrimental to how the team grows, since (especially in a small team) new perspectives, lived experience, and non-technical opinions make a team better. Obviously, someone openly antagonistic or that has differing values to the team or company is an obvious no. You still have to work with them, but I don’t think you need to hire only people that you could hang out with on a weekend.
Unfortunately, culture is also a shorthand for organizational values or non-negotiable hiring requirements. While also being a lightning rod in the United States currently for political disagreements.
The way I approach culture fit these days is to describe the current snapshot of the team and company. Our tech stack, the kind of work we do, legacy versus greenfield projects, some of the warts and whether we have the ability to fix them. As I’m going through these items, I give space for the candidate to ask questions or react, or I probe into how they would feel about certain things. I’ve seen good engineers leave previous organizations because they were working in a PHP legacy monolith when they thought they were hired for greenfield Python work.
This may seem like it takes up a large portion of the interview, but how someone will react to the work that you actually do day-to-day, regardless of tech stack, is valuable and defines the true culture fit.
Barring everything above, go get coffee with the candidates and a couple current team members or regular stakeholders and office folks. Don’t talk about work, just vibe check it. You’ll get pretty close.
office culture, remotely
Regardless of what workers want or expect these days, an ever-increasing number are being asked to return to the office (RTO) at least some of the time, me included. Many theses have been written on RTO from both viewpoints, so I will skip rehashing that here. Instead, I’ll focus on how to approach office culture in multiple regions.
I have two main offices, both with engineering teams, separated by multiple timezone hours (more than five, less than ten usually). With the hybrid schedule, we promote regularly the “office culture,” which is pretty accurate in a single region. What I’ve experienced, though, is that people forget that the offices are remote to each other, and that we should probably write more things down.
The benefit to building a team from scratch though is that you can incorporate the remote-first mentality into them right away.
- Everything goes in a public channel and out of DMs unless it contains sensitive information
- If you ask a question and receive an answer, go write it down in Confluence
- Build a bank of permissions and who owns giving those to the team, then also consider if the team needs or wants those permissions.
growing too fast but also not fast enough
We hired three people (including myself) within four weeks of each other. This obviously put a huge strain on everyone that was involved in bringing us up to speed, whether that means finding work for us to do, or leading app walkthroughs, or answering questions both technical and non. Additionally, our hiring dates were spaced out just enough to not benefit from the economies of scale, as there was no “onboarding class.” We turned it around pretty quickly, but that was as much luck as anything else most likely.
As I build out the rest of the team, I’m focusing on slow, thoughtful, sustained growth for a few reasons.
- I want to promote one of my engineers to a team lead, and I don’t want to shoulder them with four team members at once
- We are a unique team in the organization, so our technical needs are evolving rapidly and we may need to change the hiring profile between hires
- We can absorb continuous, small slowdown while we bring someone up to speed, but could not sustain a near full-stop for at least one engineer at any given time until the team could contribute
- I want to get a lot of feedback with these first hires about the onboarding process and improvements so that after the first ten hires the next fifty go smoothly
In other circumstances, I may think differently, but the balance of disruption, skills, and future productivity should all be in the mix.
The balance of disruption, skills, and future productivity should all be in the mix.
finding the perfect dev
Example 1: the instantly productive, super fungible dev
Example 2: your exact tech stack, expected experience, and other requirements
Example 3: loyalty to their company, but willing to move for you
These engineers either don’t exist, or they are so rare that they might as well not exist.
This one will be pretty short. These engineers either don’t exist, or they are so rare that they might as well not exist. You shouldn’t focus too much on these things. Sure, if you can land a unicorn, do everything in your power to do so. In my experience though, finding smart, hungry people that like challenges that you then reward for joining your team by making good on your promises works pretty well in developing long-term team members.
If you find that you’re going weeks without seeing a single resume, or no one is getting past the screening, or even if you have a gut feeling that the search is too restrictive, you should re-evaluate the criteria with everyone involved in the process.
should you refer?
I have worked with some amazing engineers that I would love to work with again. I’ve mentored a few people from mid-level to senior, senior to staff, and beyond. I’ve helped people transition from individual contributor track into management.
But would I refer them into my organization? Absolutely not.
That’s not quite true, but in my current position and the mandate to build a team from scratch, I would only refer in people that I consider exceptional and I would try to ensure they came in understanding that they hold my entire reputation in their hands.
I would only refer in people that I consider exceptional—and I would try to ensure they came in understanding that they hold my entire reputation in their hands.
What I am really saying is: be careful. The “from scratch to engineering organization” has a few stages to it, and in the early stage it is tempting to get the crew back together. But it’s also a great time to see fresh talent and build something yourself, and then in later phases reach out to your network and invite them to come work within the organization that you have built.
one last thing
Have an idea of what you’re building the team to do, own, and accomplish. Everything is better that way.