What Is Engineering Leadership? A View From Central Europe

289 engineering managers. 173 directors and heads of engineering. 132 founders. 88 CTOs. 44 VPs of engineering.

That is who is on the roll, counted from our own member records in August 2026 rather than from a survey panel or a course brochure. The standard definition of engineering leadership leaves out the part of the week those people find hardest.

Engineering leadership, defined

Engineering leadership is the work of turning a group of engineers into outcomes that someone outside engineering will count.

Three jobs run at once. The technical judgment to pick work worth doing. The people work to keep the humans doing it. And the one most definitions skip: restating both in the units the person holding the budget already reports in, before they ask for them.

Harvard Business School Online defines leadership through Professor Anthony Mayo as “mobilizing others so they can execute a set of individual and collective tasks.” Correct, and it covers the first two.

Who engineering leaders are, counted rather than guessed

Search “engineering leaders” and you get lists of famous people. Here is a census instead.

Recorded title	Members
Engineering Managers	289
Directors and Heads of Engineering	173
Founders	132
CTOs	88
VPs of Engineering	44

Read from the 1,263 member profiles carrying a title we could parse. Every row is a floor, not a share, for reasons set out in the method note at the bottom.

The second row is the one that will not hold still. Counted on a stricter base, those directors and heads of engineering write their job titles 63 different ways.

The last two rows read oddly against every career guide ever written, because the seat that is supposed to come first holds half as many people as the seat above it. That is its own post.

The shape holds at conference scale. Of the 500+ people at our 2025 conference, 43% were engineering leadership and 22.6% senior ICs and tech leads, which is the pipeline into it.

The useful definition of an engineering leader is behavioural rather than hierarchical: anyone accountable for the output of engineers they do not personally manage line by line. That catches the tech lead with no direct reports and the CTO with 200. It leaves out the manager who is a very senior individual contributor with a calendar problem.

What the job is made of, by what the room asked for

The definitional articles on this topic list the skills their authors think matter. I would rather show you what 30 rooms voted for with their evenings.

All 30 talks, coded on primary subject, one bucket each. The titles are public, so you can redo it and tell me where I am wrong.

What the talk was about	Talks
Org design, process and team structure	7
Hiring, onboarding and growing people	5
Delivery, product and value flow	4
AI adoption	4
Personal craft, transitions, leading across distance	4
Proving engineering’s worth to non-engineers	3
Personal career and market value	3

Org design wins. That is neither the answer I expected nor the one that flatters my argument, and it is what 30 evenings of programming says. My first pass at this table got a different answer, and the method note explains why I threw it away.

The thread worth pulling is the small one at the bottom. Six of the thirty are about making a case for worth, engineering’s or your own. On the published reading list for this discipline that is a footnote. So I went to check whether that is a local quirk or simply what 2024 to 2026 felt like everywhere.

The difference is the register, not the subject

I coded 119 talk titles from LeadDev London and New York and from QCon’s leadership tracks over the same window, January 2024 to June 2026, using the same rules.

	Our archive	LeadDev and QCon
Titles containing value, ROI, impact or worth	8 of 30	6 of 119
Talks substantively about justifying engineering’s worth	6 of 30	16 of 119

The first row looks like a landslide, 27% against 5%. The second row is the honest one: 20% against 13%, a difference of a few talks on samples this size. These two rooms care about the subject about equally.

So the difference is not what people worry about. It is the register they worry in.

The Anglo-American programme treats proving engineering’s worth as a measurement problem. Nicole Forsgren on developer experience as competitive advantage. Randy Shoup on doubling engineering productivity at eBay. A talk titled Quantifying technical debt. DORA, SPACE, DevEx: an entire instrumentation discipline built to answer the question.

Our archive treats it as a persuasion problem. Sell your technical ideas. Show me the ROI. Prove your impact is worth $10M+.

The sharper way to say it: there is almost no instrumentation programming in our archive at all. Nobody here has run a DORA evening. Instrument it, or argue for it. I think that maps onto who owns the roadmap, though that last step is a hypothesis rather than something I counted.

The canon assumes you own the roadmap

Most engineering leadership writing in English is aimed at people who set direction. The Stanford and MIT program pages, the HBS explainer, Gregor Ojstersek’s Engineering Leadership newsletter. All good. All quietly assuming the reader has authority over what gets built. If you own the roadmap, instrumenting your work is enough, because the decision is already yours to make.

A lot of engineering leaders here do not own it, and the reason is structural rather than cultural. ABSL’s 2025 report counts 2,081 business service centres in Poland employing 488,700 people, and 84.3% of that employment sits in foreign-owned centres. Kraków alone holds nearly 108,000 of those jobs. The Czech sector runs on the same model, around 200,000 people in IT and business services as of 2025.

That is evidence about who owns the site, not a headcount of engineers.

This is a claim about a segment, not about a region. The census above holds 132 founders and 88 CTOs who own their roadmaps outright. But for the leader running a delivery site or an R&D centre for a headquarters three timezones away, the shape of the job changes. The roadmap arrives. Headcount is approved elsewhere. What they control is the quality of the argument they can make about work they did not choose.

When the roadmap arrives from another timezone, the argument is the part of the job you control.

Mirek Stanek writes the best-known engineering leadership newsletter from this region, out of Kraków, where he is an engineering director and site lead at Papaya Global. Site lead is an ordinary title here and a rare one in the American canon, which is most of my point.

Line up the canon’s chapter headings against talks from the archive:

The canon’s chapter heading	A talk this room asked for
Set the technical vision	How Strong Tech Leaders Prove Their Impact is Worth $10M+
Manage your stakeholders	Show Me the ROI: Selling Engineering Ideas Without the BS
Communicate with influence	Learn to Sell Your Technical Ideas to Match Product Impact
Hire strong people	Stop Hiring Unicorns. Start Growing Leaders
Lead a distributed team	Culture Clash: Leading Engineers Around the Globe

Same left column as any leadership curriculum. The right column is sharper, more defensive, more concerned with evidence.

Four things the archive keeps coming back to

If you are in the segment above, here is what two and a half years of programming suggests the job asks for. Each is a thread through several talks rather than a single evening.

• Price the work in the units the budget holder already uses. Not story points, not velocity, whatever your headquarters’ finance function reports in. Show Me the ROI and How Strong Tech Leaders Prove Their Impact is Worth $10M+ are both built on this, and the second put a currency figure in its title because that is the register the conversation happens in.
• Write the quarterly narrative before anyone asks for it. A review you walk into cold is a review someone else has already framed. This one is my own practice rather than a talk from the archive, so weigh it accordingly.
• Make the work legible across a timezone gap. When the person deciding sees your team through a monthly summary, that summary is the team as far as they are concerned. Culture Clash: Leading Engineers Around the Globe was our session on it, and it is the photograph at the top of this page.
• Grow your successors locally. A senior leader is unlikely to be shipped to you from headquarters, so the bench is one you build. Stop Hiring Unicorns. Start Growing Leaders is the title our members picked for that.

That first one has a before and an after I can put a name to. Jiří Petržilka, CTO at PalmApp, started mentoring with me buried in the day-to-day of running engineering, and the mechanics he names from the first three months run two sentences: “How to build a quarterly roadmap that survives contact with the board. How to actually get budget approved instead of just asking for it.” Asking is your number, sent upward in hope. Approved means the same work arrived already converted into the units the board decides in.

The Anglo-American programme covers this ground too, as the table above showed. What it rarely does is teach it as persuasion, addressed to someone who has to win the argument rather than instrument it.

Leadership and management collapse in a smaller org

The standard distinction says management is the role and leadership is the influence, and that you can lead without managing. In a 4,000-person company that separation is real and useful.

In a 40-person engineering site it mostly is not. One person owns headcount, performance, architecture direction, the quarterly narrative to headquarters, and the hiring pipeline. Asking whether they are leading or managing this afternoon is an academic question.

The practical question is which of those five they are underinvesting in, and how top heavy the org got while they were busy. That last one is measurable. Across this member base 69% sit at manager level or above and 21% are senior or staff individual contributors, and you can compare your own org against that in the leadership ratio benchmark rather than against a US industry report.

Where people get better at this

Start with the move that costs nothing. Take the last thing your team shipped and write two sentences about it in your headquarters’ own reporting units. If you can’t, that is your gap, and it is a more useful finding than any definition on this page.

After that, this skill tends to transfer between people in the same situation faster than it transfers from a book.

• Meetups. 40+ held since 2019, now running at 12 a year across four cities with 120+ in the room. The archive is public, so judge the level before you spend an evening on it.
• Circles. 5 peer cohorts running now, for the conversations that are too specific for a stage.
• One to one. When the problem is yours rather than the category’s, mentoring moves faster than a talk. Which of the three you need, and in what order, is its own question.

You don’t have to accept my definition. The 30 talks are public, the census comes from our own member records, and the ABSL report is one click away.

One question worth sitting with, if you lead engineers from a site whose headquarters is somewhere else. When your funding is reviewed next quarter, will the person deciding know what your team shipped, or only what it cost?

Come argue about it in person.

How I counted

Everything above is checkable, and some of it is weaker than it looks. Collected here so the argument runs uninterrupted.

The census. Titles come from our own member records, classified by regex from job title with a fallback to the profile headline. 1,263 of 3,184 members carry a title we could parse, and the five rows in the table account for 726 of those. The other 537 are individual contributors, specialists and titles the classifier could not resolve. About 60% of the whole member base carries no readable title at all, so each figure is a floor and none of them is a share of the community.

The talk coding. My first pass counted titles containing value, ROI, impact or worth, got 8 of 30, and I nearly built this post on it. Reading them properly killed that: two of the eight are about owning a roadmap or a product, which is the opposite of what I was using them to prove, and two are about personal career moves. The keyword was doing the work, not the argument. The table above is the recode, by primary subject, one bucket per talk.

The archive is not a survey. All 30 evenings were programmed by one person, me. It measures my taste as much as it measures a region, and meetup titles are written to fill a room in a way conference titles selected through a CFP are not. Some of the vocabulary gap in the first table is probably that.

The control set. 119 talk titles from LeadDev London, LeadDev New York, StaffPlus and QCon leadership tracks, January 2024 to June 2026, coded by the same two rules. CTO Craft Con and SREcon are missing because their agenda pages no longer resolve, and LeadDev London supplies about 69% of the titles, so the comparison is UK-weighted and thin on 2024. Adding CTO Craft would probably raise the Anglo-American count, not lower it.

The ABSL figures. They count the whole business-services sector, which is mostly finance, HR and procurement operations with IT and R&D as a slice, so they are evidence about ownership structure rather than a headcount of engineers. The 84.3% foreign-ownership split is Polish. ABSL Czechia publishes sector size but I did not find an equivalent published ownership split there, and I have no Slovak figure at all.

Which six. The semantic row in the comparison table counts talks about justifying engineering’s worth to a non-engineering audience: #14, #15, #22, #23, #28 and #38. Note that #22 and #23 sit in the delivery bucket in the table above, because their primary subject is owning the work rather than defending it. A talk can be about value and about ownership at the same time; the buckets force one choice per talk and the semantic count does not.

What is not evidenced. Neither dataset records where anyone’s headquarters is. The link between running a foreign-owned site and framing the job as persuasion is the most quotable thing here and the least proven. Treat it as a hypothesis I hold rather than a finding I established.