What I Learned Building Engineering Teams From Scratch—Three Times

The first time you build an engineering team from scratch, you’re mostly reacting. You hire who you can find, you build the processes you remember from somewhere else, and you make a lot of mistakes. The second time, you’re more deliberate. By the third time, you start to see the patterns clearly.

I’ve done this at Communication Service for the Deaf, Student Loan Genius, and LEANSTACK—three very different companies with different constraints, different regulatory environments, different scales. Here’s what stayed consistent.

Hiring for ownership before skill

Technical interviews reliably tell you if someone can code. They’re pretty bad at telling you if someone will own their work—if they’ll flag a problem proactively instead of waiting to be asked, if they’ll care about the thing they built after it ships.

At every company I’ve run engineering at, the biggest hiring mistakes were on the ownership dimension, not the skill dimension. I’ve hired strong engineers who treated their work like a deliverable to be handed off. And I’ve hired less experienced engineers who treated it like something they were responsible for. The latter always outperformed.

The interview fix isn’t a clever question. It’s looking carefully at how someone talks about past work—specifically who they say “we” vs. “I” about, and how they describe handling problems that weren’t technically their problem.

CI/CD is a culture artifact, not a tooling decision

When I joined Communication Service for the Deaf, the team deployed weekly, by hand, with a prayer. When I left, we were deploying daily, automatically, with confidence. That’s usually described as a tooling upgrade. It’s really a culture change.

Weekly deployments accumulate fear. You batch things together because deploying is expensive. The batch grows. The fear of the batch grows. You avoid deploying even more. CI/CD breaks that loop, but only if people trust it—which means it has to work reliably, which means someone has to care about it, which means you have to make caring about it a team value, not an afterthought.

Remote-first is a practice, not a policy

I’ve been managing distributed teams since 2008, when it was still unusual. The teams that worked were the ones where remote wasn’t an accommodation—it was how we designed the work. Written communication as the primary artifact. Decisions documented. Context shared proactively.

The teams that struggled were the ones where remote was grafted onto an in-person workflow. Where the Slack message was a substitute for a hallway conversation rather than a first-class way of working.

What I’m still figuring out

Technical leadership at a two-person startup and at a twelve-person team and at a forty-person org are genuinely different jobs. The interpersonal surface area, the communication overhead, the right amount of process—all of it changes at each threshold. I don’t think I’ve fully cracked the transitions yet. But I’ve gotten better at seeing them coming.