Your Engineering Team Is Not Your First Team

Most CTO job descriptions read like a résumé for a senior engineer who got promoted into budget authority. Languages mastered, architectures designed, platforms built. The implicit claim: the more technically credentialed you are, the better CTO you will be.

I went through dozens of LinkedIn profiles to confirm this. I found what I expected: technical depth, technical depth, and more technical depth. A handful of outliers leaned toward the business side. The majority were tech-babble heavy.

What I did not find was the harder question: what is a CTO actually accountable for delivering?

The conventional answer organizes the role around technical excellence. The CTO owns the technical vision, evaluates emerging technology, and builds the engineering org. Below them, functional managers own their domains: the Dev Manager owns velocity and code quality, the QA Manager owns reliability and test coverage, the DevOps Manager owns infrastructure and deployment. Each manager optimizes their specialty. The assumption is that three well-run technical teams produce a well-functioning whole, and a well-functioning whole produces business results.

That model is not wrong. It is operating below what is possible.

Here is what it produces in practice. Each manager sees their team's capacity, not the aggregate. When a major release approaches, product owners can add scope because no one at the management level is looking at the release as a whole system. The Dev Manager sees development load. The QA Manager sees test coverage. The DevOps Manager sees deployment stability. Nobody owns the seam. Decisions that require cross-team visibility don't get made close to the information; they escalate, or they slip through to production. The constraint is not incompetence. It is operating model design.

I have watched managers push back against the expectation that they operate above their specialty. Not out of bad faith: because it is genuinely difficult to step back from the work you know best, the work your team is doing right in front of you, and hold the larger picture. And many managers of managers never ask them to. The CTO absorbs the bigger picture burden, and the management team stays in their lane. It is the path of least resistance. It is also a ceiling on what the whole organization can achieve.

The leaders who break through that ceiling are not more technically excellent than you. They stopped accepting an accountability structure that guaranteed specialty-level thinking. And the structure is yours to redesign.

Patrick Lencioni's First Team concept names the reframe precisely. A leader's primary team is not the team they lead; it is the team they are part of. For a Dev Manager, the first team is not the development team; it is the management team alongside QA and DevOps. The development team is what they deliver through; the management team is where they perform. This requires an explicit design decision: what is each manager accountable for? If the answer is their specialty, you have built a management team that optimizes functions. If the answer is the release outcome, you have built a management team that owns the whole.

Accountability structure determines operating level. If you evaluate a Dev Manager only on development velocity, you have structurally guaranteed they will optimize development velocity and leave the rest to someone else. We tie technical debt payment to security review outcomes and customer retention: not as a reframe, but because that is the actual relationship. When technical work is anchored to a business outcome, the accountability question answers itself.

This applies at the CTO level as well. The role is not to be the most technically excellent person in the room; it is to deploy technical capability in service of business outcomes. That includes questions most technically-framed CTOs treat as secondary: how should the API develop as the technical landscape shifts? How does AI function as a strategic partner, not just a tooling decision? How does a technical organization operating with independence stay aligned inside a larger enterprise without losing velocity? These are not technical questions. They are business questions that require technical fluency to answer. The CTO's first team is the executive leadership team. Not the engineering org.

Look at your last three escalations. Were they technical problems, or coordination problems that nobody owned because they sat at the seam between specialties?

If the answer is mostly the latter, the constraint is the operating model. Not the team.

I write about structural leadership for technical leaders in high-stakes operating environments. If you're reading this outside the daily email, subscribe free: https://technicalleader.coach/daily-email

---

I write about structural leadership for technical leaders in high-stakes operating environments. If you want to see where your system is load-bearing on you personally, the LeadershipOS™ Scorecard maps it: https://theleadershiposbook.com/scorecard