From One Engineer to Fifteen: What Co-Founding Taught Me About Engineering Leadership

I went from sole engineer to running a fifteen-person engineering organization over four years at PopSocial. The hardest lessons weren't about code.

I co-founded PopSocial in 2015 and was the only engineer on the platform for the first six months. By the time I left in 2019, the engineering organization was fifteen people across backend, frontend, and DevOps. Most of what I learned in that stretch was not technical. It was about the messy, tactical, embarrassing-in-hindsight job of building and running a team while still also writing code.

Six lessons that I would have benefited from someone telling me explicitly on day one. Most of them I had to learn by getting them wrong first.

Lesson 1: The day you stop coding is the day the team starts performing

For the first eighteen months I was both the engineering manager and the senior IC. I told myself this was the responsible thing to do as a founder — keep the burn low, keep my hands on the codebase, ship fast. The actual effect was that nothing else got built well.

I was the bottleneck on every PR review, every architectural decision, every onboarding session. Engineers waited on me to make decisions instead of making them themselves, because they could see I'd weigh in eventually. The team was technically functional but learning slowly because they had a senior IC two layers above them.

The week I stopped writing code in the main path of any feature, three things happened almost immediately. The team's PR cycle time dropped by about 40%. Engineers started making the architectural decisions I'd been making, and most of them were right. And I started having time to do things only I could do as the leader: hiring, fundraising, customer conversations, planning.

The lesson, simply: a founder who continues to be the senior IC is paying a hidden tax that compounds. Stop coding (in the main path) sooner than feels comfortable. You can keep your hands on by writing tooling, paying down infra debt, or pairing with an engineer on something hard — but get out of the production path.

Lesson 2: You hire too slowly and fire too late. Plan accordingly.

The conventional wisdom is "hire slow, fire fast." Almost everyone gets the first part right and the second part wrong. The result is that bad hires linger for months while you tell yourself the situation will improve.

The most expensive hires of my career were the ones I should have ended at the 60-day mark and instead held on to for another five months because firing felt cruel. By the time I let them go, I'd lost five months of progress, demoralized the team that had been picking up their slack, and damaged my own credibility as a leader because everyone else could see what I couldn't.

The framework that finally worked: a written, explicit "first 60 days" expectations document for every hire. We'd review it at day 30, day 60, day 90. If we got to day 60 and the new hire wasn't on track to meet the day-90 expectations, we'd have a direct conversation. Most fixed themselves with that conversation. The ones that didn't, didn't, and we let them go at day 75 or 90 instead of month seven.

This is not heartless management. The opposite — telling someone explicitly what's going wrong and giving them a clear shot at fixing it is more respectful than letting them stay and dragging them along.

Lesson 3: Title inflation is a tax you pay later

In year two we needed to hire a backend lead. The candidate we were closing wanted "Director of Engineering" as a title, even though the team was three engineers including him. I gave it to him. Five months later we needed to hire a senior engineer. We couldn't offer "Senior" because the existing team's titles had inflated past it.

Title inflation creates two compounding costs. First, it sets a ceiling that future hires have to be promoted past, which creates artificial pressure and weird performance dynamics. Second, it muddles the actual seniority of the team — when you have three Directors of Engineering and one IC, your engineering org chart is broken.

The fix in retrospect: pick a clean ladder, write it down, and don't deviate. "Engineer / Senior Engineer / Staff Engineer / Engineering Manager / Director of Engineering" — five rungs, defined, with explicit criteria for each. If a candidate insists on a higher title, that's a signal to dig into why. Almost always it's about cash compensation and there's a better way to solve the problem.

Lesson 4: One-on-ones are the highest-ROI thing on your calendar

I started 1-on-1s as a checkbox item I felt I had to do. By the end I considered them the most leveraged hour on my week.

The format that worked, refined over time: 30 minutes weekly. Three sections — what's blocking you, what's bothering you, what are you working on. The first two are non-negotiable; the third is sometimes obvious from context and can be skipped.

The reason 1-on-1s are high-ROI is that engineers tell their manager problems an hour before they tell anyone else. By having the meeting on the calendar at a known cadence, you catch the problems an hour earlier than you would have otherwise. Over a year, that's the difference between a team that runs into the same brick walls repeatedly and a team that pivots before they hit them.

The mistake I made for too long: treating 1-on-1s as status updates. They're not. They're the channel for the things engineers won't say in standup or in Slack.

Lesson 5: The interview process IS the culture

Whatever you do during an interview is what the candidate believes the company is like every day. If your interview is rushed, disorganized, and poorly calibrated, the candidate (correctly) infers the company is rushed, disorganized, and poorly calibrated. They take that information into their accept-decline decision.

I spent year three rebuilding our interview process from scratch. The big changes that mattered most:

• Written rubrics for each round. Every interviewer knew what they were evaluating and how to score it. Eliminated the "I dunno, I have a good feeling about him" bias that was driving who we hired.
• Calibration sessions every six weeks. The interview team would do a debrief on a recent candidate against the rubric, surface scoring disagreements, and recalibrate. Caught drift before it became a hiring problem.
• A take-home that respected the candidate's time. Two hours, not eight. With a clear evaluation criteria. We'd accept partial submissions if the candidate explained why.
• A close-the-loop debrief 24 hours after the final round, written. Every candidate got a yes/no decision in writing within a day. Even the no's. Especially the no's.

The team's hiring quality improved measurably. The brand impact among the candidate pool — who talk to each other — improved even more.

Lesson 6: Performance reviews suck. Do them anyway.

Almost no founders enjoy performance reviews. Almost all teams need them. The mismatch is why they get skipped, deferred, or done badly.

The version that works at startup scale: light, honest, twice a year. Two questions in writing — what's going well, what's the one thing you'd change. From the engineer about themselves, from the manager about the engineer, from peers when relevant. A 30-minute conversation about both sides of the answers. A written outcome doc.

The version that doesn't work: annual 360 reviews with five rating dimensions and bell-curve calibration. At 15 engineers, that's bureaucratic theater. At 200 engineers, you grow into it.

The reason to do the light version even at small scale is that without it, you have no shared written record of expectations and progress. When you eventually need to make a tough call (promotion, demotion, termination, raise), you have nothing to reference. With it, you have six months of explicit notes from both sides about what good looks like.

The thing that actually matters: clarity about what's good

If I had to compress all of this into one principle, it's this. The job of an engineering leader at a small startup is to make it explicit what good looks like.

Good code looks like X. Good design conversations sound like Y. Good 1-on-1s feel like Z. Good performance from this engineer at this level means producing this kind of output at this kind of pace. Good interviews ask these questions and listen for these answers.

Most engineering leadership failures at small startups are failures of clarity. The team doesn't know what good is, so the team isn't sure when they're doing well, and the leader is unhappy with the output but can't articulate why. Codifying "good" in writing — even sketchy first drafts — fixes more problems than any other intervention.

Would I do it again?

Yes. But differently. I'd hire my first engineer slower and more carefully. I'd stop coding in the main path at month nine instead of month eighteen. I'd codify the title ladder before the second hire. I'd write the rubrics before the third interview. I'd start performance reviews at five engineers instead of ten.

The good news: most of these mistakes are recoverable, and even at the time, the team got better, the product shipped, and we ended up with a strong organization. But "got there eventually" is not the bar I want to hit if I do this again. The bar is "got there with the team intact, the leaders developed, and the company strong enough to handle the next stage."

That's the bar I'm using as I help founders make these calls now. Most of the lessons I'm sharing in this post are lessons I learned on the job. The point of writing them down is that the next founder doesn't have to.