Engineering Team Management for CTOs: Best Practices and Hard Truths

I've managed engineering teams from 3 people to 200. The technical challenges change at each scale. The people challenges are eerily consistent. Here are the lessons that took me years to learn and that I now share with every client within the first month.

Delegate by Asking, Not Assigning

The instinct when delegating is to identify a task, identify the person best suited for it, and assign it to them. This works for individual tasks. It fails for ownership.

Instead, ask: "What do you want to take off my plate?" The difference is subtle but powerful. When someone chooses their area of ownership, they're accountable to themselves. When you assign them an area, they're accountable to you — which means they'll come to you for every decision instead of making it themselves.

I watched a client's engineering lead transform his team with this one change. Instead of assigning on-call responsibilities, sprint planning duties, and vendor management, he asked each senior engineer what they wanted to own. The engineer who chose on-call built a better rotation than the one that had been assigned for two years. The one who chose vendor management renegotiated three contracts in the first month.

There's an important corollary: if someone says "this is what I'm good at" and then doesn't deliver, that's on them — they chose it. If you assign them something and they don't deliver, that's on you — you chose wrong. This accountability difference changes the dynamic completely.

What You Measure Is What You Get

If you want lines of code, they're going to give you lines of code. If you want quick delivery, they're going to give you quick delivery. If you want test coverage, they'll write tests — but maybe not good tests, just tests that hit the coverage number.

Be very deliberate about which metrics you make visible to the team. They will optimize for whatever they see being tracked. This is human nature, not a character flaw.

My recommendation: maintain a full dashboard for yourself — everything from deployment frequency to code review turnaround to incident counts. Show the team a filtered view with only the metrics that drive the behavior you want. If you're trying to improve reliability, show them change failure rate and time to restore. If you're trying to improve velocity, show them lead time for changes and deployment frequency.

If you show everything, they'll either get overwhelmed or game the wrong numbers. Focus drives results. Diffusion drives mediocrity.

PRs Are Work, Not Extra Work

Code review is consistently under-invested in growing engineering teams. Engineers treat it as an interruption — something they do between "real work." The result: PRs sit for days, feedback is shallow, and the value of code review (catching bugs, sharing knowledge, maintaining consistency) evaporates.

Code review should be treated as a first-class activity, not a side task. It should be planned into sprint capacity. If you expect meaningful code review — not rubber-stamping, actual review — it takes time. A significant portion of an engineer's week should go to reviewing others' code, and that should be reflected in sprint planning and capacity calculations.

When I implement this at client companies, the pushback is always "we can't afford to spend that much time on reviews." My response: you can't afford not to. Every bug caught in review is a bug that doesn't make it to production. Every design issue caught in review is a refactor you don't have to do next quarter. Every knowledge-sharing comment in a review is documentation you didn't have to write.

The "Divorced Parent" Problem

New team members — especially confident, skilled ones — will tell different leaders different things. One leader hears "I've been given permission to rewrite the authentication system." Another hears "I'm just doing a small cleanup of the auth module." They're playing what I call the divorced parent game, getting approval from whichever authority figure is most likely to say yes.

This isn't necessarily malicious. Often the new hire is genuinely enthusiastic and interprets a vague "sounds interesting" as explicit approval. But it creates chaos when leaders discover they've approved contradictory scopes.

The fix: when someone says "the CTO approved this" or "I talked to the VPE and they're fine with it," verify before acting. Not because you distrust the person — because misunderstandings at the leadership level compound into wasted engineering weeks.

Channel Energy, Don't Block It

When someone new comes in hot — excited about the codebase, full of ideas about what to fix, wanting to make an immediate impact — the temptation is to slow them down. "Learn the system first. Understand why things were built this way. Don't change anything yet."

This kills morale instantly. Instead, channel the energy. Let new hires tackle tech debt or refactoring — but with guardrails. Time-box it: two weeks to show results. Work within the existing system, not a parallel rewrite. The goal is visible improvement to the current application, not a competing architecture that exists in a branch nobody will ever merge.

Every new developer wants to rewrite the entire stack. Always. That's not a character flaw — it's what happens when a skilled engineer encounters unfamiliar code. The job of leadership is to redirect that instinct toward productive improvement without killing the energy behind it.

When Process Stalls, Do a Working Session

Sometimes the right move isn't another planning meeting. It's: book a 2-hour session where everyone does the thing together, live, on camera. Push the buttons. Deploy the code. Run the migration. Configure the service. Together, right now.

I've broken more process logjams with working sessions than with any amount of documentation, planning, or delegation. Something about doing it together, in real time, with the awkwardness of silence if nobody knows the next step, forces resolution in a way that async communication never does.

Under-Promise, Over-Deliver

I've made the mistake too many times of giving optimistic timelines to stakeholders. The pressure to say "two weeks" when you know it's probably four is enormous — from the business, from yourself, from the desire to seem capable.

Resist it. Give the honest timeline, add a buffer, and deliver early. The reputation you build by consistently delivering ahead of schedule is worth infinitely more than the temporary relief of an optimistic estimate that you'll miss.

This applies at every level: individual task estimates, sprint commitments, quarterly roadmaps, and project timelines. The teams I've managed that consistently under-promised and over-delivered had the highest trust with stakeholders, the lowest stress levels, and paradoxically, the highest velocity — because they weren't wasting cycles on firefighting, apologizing for missed deadlines, and re-planning.