From CTO to Senior Engineer: Who Owns What in Engineering? I Read 115 Job Posts

Each level decides the what for the level below and proposes the what to the level above. I checked that model against 115 job posts from Europe: the strategy staircase holds, hands-on work is a U, and seven other titles fit around it.

By Maksym Shykov, Engineering Manager14 min read

Every engineering organisation has a version of the same staircase: CTO, Head of Engineering, Engineering Manager, engineer. Everyone agrees the levels are different. Fewer people can say what exactly each level owns, and where its job stops.

Here is the model I use. Then I checked it against 68 job posts published in Europe this autumn, because a model that only lives in my head is an opinion. The second half places the titles that don't fit the four steps neatly: Team Lead, Tech Lead, Staff and Principal Engineer, Director, VP and the architects, based on 47 more posts.

In short

  • The model: each level decides the what for the level below and owns the how of what comes from above. It also proposes its own what upward: work flows down, agenda flows up.
  • The strategy staircase holds. In the job posts, the share of responsibilities that are strategic falls step by step: about 45% for a CTO, 32% for a Head of Engineering, 23% for an Engineering Manager, 14% for a senior engineer.
  • Hands-on work is a U, not a line. Senior engineers spend most of their listed responsibilities on their own hands-on work (59%). Engineering Managers almost none (5%). Then it rises again: 11% for a Head of Engineering and 25% for a CTO, almost entirely in small companies.
  • Head of Engineering and CTO are each two different jobs. In a startup they are player-coaches who still write code. In a large company they lead leaders and do not.
  • The Engineering Manager job is tactics. 71% of the listed responsibilities are about how the team works: people, hiring, delivery, process.
  • The other titles fit around the staircase. Team Lead is an EM who still codes, Tech Lead owns the how of one team, Staff and Principal are the engineer track, Director and VP lead managers, and most architects face customers rather than the team.

The model

CTO, Head of Engineering, Engineering Manager and engineer as bars split between strategy and tactics: 45, 32, 23 and 14 percent strategy. Decisions go down one level at a time; results, risks and ideas go back up.STRATEGYWhat to doTACTICS · TASKSHow to do itCTO45%Bets, budget,org shapeHead32%Plan, hiring,quality barEM23%Team, priorities,deliveryEngineer14%Build, ship,raise risksthe whatresults, risks, ideasDecisions: the what goes to the level belowReality: results, risks and ideas go up% = share of listed responsibilities that are strategy
Decisions flow down, reality flows up, one level at a time. Each bar is one level, split at its share of strategy in 68 job posts from Europe, autumn 2026.

Two axes. Across: strategy (what to do) on one side, tactics and tasks (how to do it) on the other. Down: the four levels.

  • CTO decides the bets: which technology the business is built on, the budget, the shape of the organisation.
  • Head of Engineering turns those bets into a plan: which teams, which hires, what quality bar.
  • Engineering Manager turns the plan into a team that delivers: priorities, people, delivery.
  • Senior engineer builds and ships, and raises the risks nobody above can see.

The rule that connects them: each level decides the what, and the level below owns the how. A CTO who decides how a team should structure its sprints has stepped down a level. An engineer who decides alone which market the company enters has stepped up two. Both happen, and both usually end badly.

One thing the model is not: the business decides, engineering implements. Each level decides the what for the level below and proposes the what to the level above. A Head of Engineering or a CTO who waits for the business to hand over an agenda is doing the job one level down. At the top, engineering brings its own agenda to the table: which risks must be fixed now, which capabilities the product could have that nobody has asked for yet, and what should stop.

How I checked it

I collected 68 job posts published between September and October 2026 in Europe (plus remote roles open to Europe):

LevelPostsWhere from
CTO14Himalayas (public job board)
Head of Engineering20LinkedIn, top of the search results, plus company career pages and Himalayas
Engineering Manager19Company career pages (Greenhouse, Lever, Ashby)
Senior backend or full-stack engineer15Company career pages, Landing.jobs

One post per company per level. For each post I sorted the listed responsibilities into three groups:

  • Strategy: what and why. Vision, roadmap, architecture direction, organisation design, budget, alignment with the business.
  • Tactics: how the team works. Delivery, process, people, hiring, standards, stakeholders.
  • Tasks: the person's own hands-on work. Writing and reviewing code, designing and building, debugging, on-call.

Three honest limits. First, a job post describes what a company says it wants, not what the person ends up doing. Second, the sorting is mine; another reader would land a few points differently. The samples are small, so read the numbers as direction, not as proof. Third, the samples differ by company size: 4 of the 14 CTO posts come from companies of up to 50 people, and none of the EM posts do. Company size moves every level, and that is my next article.

The strategy staircase holds

LevelStrategyTacticsTasks
CTO45%30%25%
Head of Engineering32%57%11%
Engineering Manager23%71%5%
Senior engineer14%27%59%

Strategy falls at every step, as the model says. Two things in the table surprised me.

No level is pure. Even senior engineers own a slice of the what: 7 of the 15 posts ask them to shape the roadmap or the technical direction of their team. One Berlin company put it well: a senior engineer has real authority over how things are built, not just what gets built. The model is a staircase, not a set of boxes.

The clearest description of the rule came from a job post, not a book. A Hungarian software company wrote that Product decides what and why we build, and engineering owns how, the capacity, the commitments and the long-term sustainability. That is the model in two lines. Note the second half: capacity, commitments and long-term sustainability are an engineering agenda, not an order book.

The hands-on curve is a U

Strategy is a staircase. Hands-on work is not.

LevelPosts that expect some hands-on work (code or reviews)Tasks share
Senior engineer15 of 1559%
Engineering Manager9 of 195%
Head of Engineering10 of 2011%
CTO9 of 1425%

The low point is the Engineering Manager. Half the EM posts want someone who stays close to the code, reviews designs or steps in when needed, but only one asks the EM to contribute to the codebase as part of the job. One London startup is explicit: its EM is not a hands-on technical lead position. An Amsterdam payments company: not a hands-on coding role, but it is a technical one.

Then the curve rises, and company size explains almost all of it. In leadership posts from companies with up to 50 people, the person's own hands-on work averages about 43% of the listed responsibilities. In leadership posts from companies with more than 1,000 people, it is about 3%.

So does a CTO write code? has a clear answer from this sample: in a startup, yes, often more than half the job. In a company of thousands, no.

Two jobs called Head of Engineering

The 20 Head of Engineering posts split into two groups that share a title and little else.

The player-coach. One team of 5 to 10 engineers, a startup or a small scale-up, reports to the founders, the CEO or the CPO. A Copenhagen startup expects the role to stay about 50-60% hands-on in the first year. A London martech company: roughly half your time in the code.

The leader of leaders. Several teams through engineering managers or team leads, 20 to 50 engineers, a larger company, reports to a CTO or a VP. Zalando, Adyen, Riverty and Centric Software all describe this version, and none of them asks for production coding.

One more pattern: in 6 of the 20 posts there is no CTO above the Head of Engineering at all. The Head reports to the CEO, the founders or the COO. In those companies, the Head is the top of the technical staircase.

Two jobs called CTO

The CTO posts split the same way, only more sharply.

The founding CTO builds the first version: four of the 14 posts are for companies with up to 50 people, and in those the person's own hands-on work is 45-80% of the job. One mobile-app CTO post is, in practice, a lead developer role with a bigger title.

The organisation CTO owns the leadership layer. A mobile-money company in West Africa asks its CTO to lead about 132 engineers through five direct reports. An IT services firm wants a CTO for transformation and bids. Neither mentions writing code.

Public CTO posts also lean small: large companies rarely advertise the role. Four of the 14 posts came from recruiters rather than from the company itself.

The Engineering Manager job is tactics

Seven out of ten responsibilities in the EM posts are about how the team works. Every one of the 19 posts makes hiring the EM's job. Only 5 of 19 give the EM ownership of the team's technical strategy; in most, a tech lead or staff engineer owns the technical direction and the EM owns people, delivery and the roadmap with Product.

That matches what I wrote in Do Engineering Managers Need Technical Skills?: technical skill is the licence to do the job, not the job itself.

The other titles, and where they sit

The four-step staircase is the spine of most engineering organisations, but it is not the whole org chart. Most other titles are one of three things: a step between two levels, a second track for engineers who don't manage people, or a role that sits beside the staircase. To place them, I read 47 more posts from the same months for seven titles.

TitleTrackWhere it sitsManages peopleWrites code
VP of EngineeringManagementBetween the CTO and the directors: runs engineering as an organisationManagersRarely
Director of EngineeringManagementAbove engineering managersManagers (7 of 8)No
Team LeadManagement, first stepSame row as an EM, with more hands-on workOne teamYes (6 of 8)
Tech LeadA role, not a stepInside one team, next to the EMSometimes (3 of 7)Yes (7 of 7)
Staff / Principal EngineerEngineer (IC) trackParallel to EM and Director, without reportsNoYes (7 of 7)
Software / Enterprise ArchitectBeside the staircaseTechnical strategy across systemsRarelyRarely
Solutions ArchitectBeside the staircaseOne solution for one customer or projectRarelyRarely

Team Lead: an EM who still codes

All 8 Team Lead posts manage one team of 2 to 8 people, and 6 of the 8 expect the lead to write code. One database company says the job is about half your time designing, coding and reviewing. The titles blur: one post is titled Development Team Lead and calls the same person a Tech Lead in the text, and another company's Engineering Lead works next to a separate Tech Lead. On the staircase, a Team Lead sits on the Engineering Manager row, with a bigger share of tasks.

Tech Lead: owns the how, not always the people

Every Tech Lead post expects hands-on work, but only 3 of 7 include managing people. The others are explicit that it is a technical role. One infrastructure startup put it best: You are not a people manager, but you are the engineer the team copies. A Tech Lead owns the how of one team's technology: design reviews, standards, the hard parts of the code. Who owns the people depends on the company, so ask before you accept the title.

Staff and Principal Engineer: the engineer track

None of the 7 Staff and Principal posts include managing people, all 7 expect code, and every one describes a scope bigger than one team: an initiative, a platform, a business area. A Berlin voice-AI company: Staff means harder problems and more ambiguity, not less hands-on work. This is the track for engineers who want the scope of a manager without the reports. In many career ladders, Staff sits beside a senior EM and Principal beside a director.

Director of Engineering: the manager of managers

7 of 8 Director posts lead through engineering managers or team leads, and none ask for production code. The scope is a domain or a site: one fintech's Director leads a hub of more than 200 people, an online pharmacy's Director co-owns roadmaps with Product and the commercial team. In a large company, Head of Engineering is often this level under another name: Adyen's Head of Engineering post asks for a manager of managers with 25 to 50 engineers.

VP of Engineering: runs engineering as an organisation

VP roles are rarely advertised: I found only 3 public posts. Two describe the classic version: one VP reports to a Chief Data and Technology Officer and owns strategy, organisation and execution for a whole area; another runs engineering as a function, from allocating people (and AI agents) to hiring and compensation, as the CEO's partner. A common split is that the VP owns how engineering runs and the CTO owns which technology bets the company makes. The third post is a small company's VP who builds automation systems hands-on: a reminder that titles inflate as companies shrink.

Architects: beside the staircase

The 14 architect posts split in two. 8 of 14 face customers, sales or consulting clients: pre-sales solution designs, partner enablement, proofs of concept. Even a post titled Principal Enterprise Architect at a process-mining company measures success in revenue. The other 6 are internal: they own the technical what across systems, such as target architecture, standards, build-versus-buy and governance, without owning the people who build it. On the staircase, an internal architect works on the strategy side next to the Head of Engineering and the CTO; a solutions architect sits at the edge between sales and engineering.

What this means

If you are a senior engineer thinking about management: the biggest change is not less code. It is that your hands-on share drops from about 60% to about 5%, and tactics go from a quarter of the job to most of it. Ask yourself whether you enjoy the tactics.

If you are an Engineering Manager looking at Head of Engineering roles: decide which of the two Head jobs you want. The player-coach Head in a small company is closer to a senior EM who still ships. The leader-of-leaders Head expects years of managing managers.

If you write job posts: say who the role reports to, how big the team is, and how much hands-on work you expect. None of the 19 EM posts said who the EM reports to; 15 of the 20 Head posts did.

Where I fit

I'm looking for my next role, so here is my own reading. I'm an engineering manager who sets the engineering agenda and still ships: teams of 5 to 9, hands-on with code and AI-assisted delivery. In this model that is the player-coach end: a Team Lead, Engineering Manager or Head of Engineering in a small or mid-size product company.

Frequently asked questions

What is the difference between a Head of Engineering and an Engineering Manager?

An Engineering Manager leads one team and owns how it works: people, hiring, delivery. A Head of Engineering owns the plan across teams. In the job posts I read, strategy is about 23% of an EM's listed responsibilities and about 32% of a Head of Engineering's. In small companies the Head of Engineering often leads a single team and still writes code.

Does a CTO write code?

It depends on company size. In the 14 CTO posts I read, the four from companies with up to 50 people made hands-on building 45-80% of the job. In larger companies the CTO leads through other leaders and does not write production code.

Does an Engineering Manager need to code?

Usually not as part of the job, but they need to be technically credible. 9 of 19 EM posts expected some hands-on involvement, such as reviewing designs or code; only one asked the EM to contribute to the codebase regularly.

What does a senior engineer own?

The how of their part of the system: design, building, operations. In 7 of 15 posts, senior engineers also shape the team's roadmap or technical direction.

What is the difference between a Tech Lead and a Team Lead?

In the posts I read, a Team Lead manages one team of people and still writes code; a Tech Lead owns the team's technical direction and often does not manage people (only 3 of 7 Tech Lead posts included it). Some companies use the two titles for the same job, so read the post.

What does a Solutions Architect do?

In 8 of 14 architect posts the role faced customers, sales or consulting clients: designing a solution for a specific customer, running proofs of concept and supporting deals. Internal architects own technical standards and target architecture across systems instead.

Method and data

115 job posts, published September-October 2026 (68 for the four main levels, 47 for the other titles), roles in Europe or remote within Europe. Sources: LinkedIn search results (Head of Engineering, collected 22 October), public job-board APIs of Greenhouse, Lever and Ashby (company career pages), Himalayas and Landing.jobs. One post per company per level. Responsibilities sorted by hand into strategy, tactics and tasks; company size estimated from public information where the post did not state it.