A private self-assessment calibrated to your specific role — the decisions, blind spots, and leadership behaviors that matter most at the Head and CTO level. Different from the team quiz and the 360: this is just you, honest with yourself, about what you're actually doing vs. what you're capable of.
⚙️ Head of Engineering
·
📋 Head of Product
·
✏️ Head of Design
·
🔄 Head of Program / Agility
|
🏛 CTO
Head of Engineering
Am I building the system — or being the system?
The Head of Engineering's maturity gap is almost always the same: moving from being the team's best technical resource to being the person who builds the conditions for others to become one. These questions are designed to surface that gap honestly.
Eng Leader
🦸
How I lead vs. how I solve
The pull toward solving is strongest for engineering leaders. It's faster, more satisfying, and immediately visible. But every problem you solve is a decision you've kept.
Leading vs. Solving
When a hard technical problem surfaces, what do I actually do?
Be honest about the last three times something difficult came up. Did you take it on? Delegate it fully? Stay involved longer than you needed to? What was your reason?
When I'm not in the room, how well does my team make technical decisions?
1
Things stall or default to safe choices
2
Decisions get made but I often revisit them
3
Mostly well — with a few gaps I recognize
4
As well as when I am — I've built real judgment in others
Blind spot check
"What would my team say I do when they've already figured something out — do I affirm their solution, or do I refine it? What signal does that send about whether I trust their judgment?"
🔲
Where my role ends and others begin
Engineering leaders frequently absorb scope that belongs to product, to design, or to their own managers. The question is whether that absorption is deliberate leadership or unexamined drift.
Role Boundary
Where am I doing work that isn't mine to do?
Think about the last month. Are there decisions you made that should have been made by an engineering manager below you? Scope conversations you led that belonged to product? Hiring calls that bypassed your managers?
Where am I not doing work that is mine to do?
The flip side. Engineering leaders sometimes avoid the organizational work their role requires — culture, development, headcount planning, hard conversations about performance. What are you deferring?
🔗
How I show up cross-functionally
Engineering maturity isn't just about how the engineering org runs — it's about whether engineering is a full partner in product decisions, or an executor of them.
Cross-Functional
Am I a co-author of product direction or an executor of it?
When was the last time engineering proposed a product direction based on a technical possibility rather than a customer request? When did your team push back on a roadmap item for strategic reasons, not just feasibility?
Honest signal
If a product decision was made in the last quarter that you privately disagreed with but didn't push back on — what stopped you? That answer is usually more revealing than any other question in this section.
🔕
What I'm avoiding
Every leader has a category of conversation or decision they defer past the point it's useful. For engineering leaders it's usually performance clarity, architectural debt acknowledgment, or succession honesty.
Avoidance
The performance conversation I've been putting off
Name the person or situation. Not to commit to acting on it here — just to make it visible to yourself. How long has it been clear? What has deferring it cost?
The architectural truth I haven't named publicly
Most engineering orgs carry technical debt that leadership knows is a strategic risk but hasn't acknowledged clearly to stakeholders. Is there a version of this in your system right now?
🗺️
Where I am on the maturity arc — and what I'm committing to
Stage 1
Foundational
Stage 2
Developing
Stage 3
Integrated
Stage 4
Market Leading
One commitment — observable, within 30 days
Complete this: "The one behavior I'm going to change is [specific action]. I'll know it's working when [observable signal]. I'm giving [name of peer] permission to ask me about it."
Head of Product
Am I holding a strategy — or managing a backlog?
The Head of Product's maturity gap is often the distance between executing the loudest stakeholder's priorities and genuinely owning a product strategy they'd defend under pressure. These questions are designed to surface that gap honestly.
Product Leader
🧭
Strategy vs. stakeholder management
Product leaders often mistake managing stakeholder expectations for holding a product strategy. They're related — but one is a consequence of the other, not a substitute for it.
Strategy
Can I articulate what we are explicitly not doing — and why?
A real strategy has a clear "no" as much as a clear "yes." If your roadmap is largely shaped by what stakeholders have asked for, the strategy may be absent — or implicit — rather than owned.
When my strategy is challenged by a strong stakeholder, what typically happens?
1
I usually find a way to incorporate their view
2
I push back but often compromise on substance
3
I hold my position and explain my reasoning clearly
4
I hold position and others defer to my read — trust is earned
Blind spot check
"Is my roadmap a strategy or a prioritized list of requests? Could someone read it and understand what we believe about our customers and market — or does it only make sense knowing the political context?"
👁️
Customer proximity vs. customer insight
Most product leaders talk to customers. Fewer are building genuine insight — the kind that leads you somewhere the customer couldn't have told you directly to go.
Customer
When did my customer understanding last surprise me?
If every customer conversation confirms what you already believed, you may be listening for validation rather than signal. Real insight is disruptive — it changes something about how you think.
How much does engineering and design have their own customer understanding?
If your team can only answer customer questions by asking you, you've created a dependency rather than a shared context. What would it take for them to have direct access?
🔕
What I'm avoiding
For product leaders, avoidance usually clusters around three things: the strategic conversation with engineering they keep deferring, the stakeholder relationship that's become political rather than productive, and the honest outcome review they haven't done.
Avoidance
The outcome I haven't reviewed honestly
Name something you shipped in the last two quarters. Do you actually know if it worked? If the answer is "we moved on before we found out" — what did moving on protect you from knowing?
Honest signal
Is there a stakeholder relationship that has become primarily about managing their expectations rather than making good product decisions together? Name it — and what it's cost the product direction.
🗺️
Where I am on the maturity arc — and what I'm committing to
Stage 1
Foundational
Stage 2
Developing
Stage 3
Integrated
Stage 4
Market Leading
One commitment — observable, within 30 days
Complete this: "The one behavior I'm going to change is [specific action]. I'll know it's working when [observable signal]. I'm giving [name of peer] permission to ask me about it."
Head of Design
Am I shaping the product — or finishing it?
The Head of Design's maturity gap is almost always about influence and timing — whether design thinking enters the process early enough to shape what gets built, or arrives late enough to only shape how it looks. These questions are designed to surface that gap honestly.
Design Leader
⏱️
When design enters the process
The most important design decisions aren't made in Figma — they're made when someone decides what to build and why. Where in that process is design genuinely present?
Influence & Timing
At what point in the last major initiative did design enter the room?
Be specific. Was it at problem definition? After a solution was scoped? At wireframe review? After engineering had started? Each answer describes a different level of design influence — and maturity.
How often does design input change what gets built — not just how it looks?
1
Rarely — we improve execution of what's already decided
2
Sometimes — we reshape scope occasionally
3
Often — design regularly redirects the approach
4
Consistently — design co-authors what gets built from the start
Blind spot check
"When I raise a concern in a product meeting, what happens? Do people engage with it as a strategic input, or do they receive it as an aesthetic preference? What does that tell me about how I've positioned design in this org?"
🌐
Design thinking beyond the design team
A mature design organization doesn't hoard user empathy — it distributes it. If user understanding lives only in the design team, the design team becomes a bottleneck rather than a multiplier.
Distribution
How much has the rest of the org absorbed design thinking?
Can an engineer or PM in your organization lead a user journey exercise without a designer facilitating? When they talk about users, do they use specific, empathetic language — or generic categories? The answer reflects how well design thinking has spread beyond design.
🔕
What I'm avoiding
For design leaders, avoidance tends to cluster around two things: the case they haven't made for design's strategic role, and the system health conversation they've been softening.
Avoidance
The argument I haven't made for design's seat at the table
Not the complaint — the case. Is there a specific decision-making forum, a specific process, or a specific relationship where design should have more influence than it does? Have you made that case directly and clearly — or have you absorbed the exclusion?
Honest signal
Is the design system a living standard that the whole team holds — or a document that designers maintain and reference alone? If it's the latter, the design org may be operating as a service layer rather than as an embedded standard of quality.
🗺️
Where I am on the maturity arc — and what I'm committing to
Stage 1
Foundational
Stage 2
Developing
Stage 3
Integrated
Stage 4
Market Leading
One commitment — observable, within 30 days
Complete this: "The one behavior I'm going to change is [specific action]. I'll know it's working when [observable signal]. I'm giving [name of peer] permission to ask me about it."
Head of Program / Agility
Am I enabling flow — or managing process?
The Head of Program and Agility's maturity gap is the distance between being the keeper of the process and being the person who makes it possible for the org to move well together. These questions are designed to surface that gap honestly.
Agility Leader
🌊
Process keeper vs. flow enabler
Process that no one owns becomes bureaucracy. Process that everyone owns becomes culture. The question is which one you're building — and whether you can tell the difference in this org right now.
Process vs. Flow
What processes are we running that are costing more than they're producing?
Be honest about the ceremonies, the cadences, the reporting. Which ones produce real decisions or learning? Which ones are theater — things the team shows up to because they're scheduled, not because they're useful?
When something in the org moves slowly, what's the most common cause?
1
Process gaps — no clear path to move
2
Process friction — too many steps or approvals
3
Unclear ownership — no one knows who decides
4
Culture — people wait to be told rather than move
Blind spot check
"Do the people whose work I coordinate see me as someone who makes their work easier or someone who generates reporting requirements? When did I last ask them directly?"
🏗️
My relationship to organizational health
Program and agility leaders often see organizational dysfunction before anyone else — because they sit at the cross-functional seams where it shows up first. The question is what you do with what you see.
Org Health
What organizational dysfunction am I absorbing rather than naming?
Program leaders often become the shock absorbers between dysfunctional teams or leaders — smoothing over friction that should be resolved at its source. What are you currently managing around rather than through?
Am I building the org's agility or maintaining my own relevance?
A mature program leader works toward an org that needs less coordination overhead — not more. Are the teams you work with becoming more self-organizing over time, or are they becoming more dependent on you to function?
🗺️
Where I am on the maturity arc — and what I'm committing to
Stage 1
Foundational
Stage 2
Developing
Stage 3
Integrated
Stage 4
Market Leading
One commitment — observable, within 30 days
Complete this: "The one behavior I'm going to change is [specific action]. I'll know it's working when [observable signal]. I'm giving [name of peer] permission to ask me about it."
CTO — Senior Leadership Layer
Am I leading the organization or the technology?
The CTO role spans all four disciplines and sits above them. The maturity questions are different from the Heads — they're about whether you're operating at the right altitude, building an org that outlasts you, and holding the whole system honestly when each function reports to you. These questions don't have easy answers. That's the point.
CTO
🔭
Altitude — am I operating at the right level?
The most common CTO failure mode isn't incompetence — it's altitude. Doing engineering manager work instead of org design work. Doing architecture review instead of technical strategy. The role requires staying high enough to see the whole system.
Altitude
Where am I operating below my level?
Be specific. Which meetings are you in that your direct reports should own? Which decisions are coming to you that should be made a level below? Which relationships are you holding that one of your Heads should be owning?
Where am I operating above my level — vision without grounding?
The other failure mode: strategy that isn't connected to what's actually happening in the org. Are there areas where you're setting direction without enough understanding of the constraints your teams are operating in?
🏛️
Org design — am I building what the next stage requires?
The CTO is the primary owner of how product, engineering, design, and program/agility are structured and how they work together. That structure either accelerates or constrains everything else. When did you last examine it honestly?
Org Design
Is the current org structure built for where we are or where we need to go?
Most org structures are inherited or evolved rather than designed. The seams between functions, the reporting lines, the team sizes — do they reflect a deliberate choice about how the org should work, or the accumulated result of hiring decisions and historical convenience?
Honest signal
Are the four Heads who report to you operating as a genuine leadership team — making decisions together and holding each other accountable — or as four separate functions that coordinate through you? If it's the latter, you may be the integration point that's preventing integration from being built into the system.
🌱
Succession — is the org genuinely independent of me?
The hardest question for any CTO: if you left tomorrow, what would break? The honest answer to this question is the most accurate measure of your leadership maturity — not what the org does when you're present, but what it does when you're not.
Succession
What would break first if I left tomorrow?
Don't soften this. Be specific about the decisions, the relationships, the cultural standards, the technical direction that depends on you specifically being here. Each item on that list is a succession risk and an org design problem.
Who is my successor — and what am I actively doing to develop them?
Not a name on an org chart — an actual person making decisions you'd have made, in areas you've deliberately moved out of. If the answer is "no one yet," that's the most important thing this assessment surfaced.
🔕
What I'm avoiding — the CTO version
CTOs avoid different things from their Heads. The avoidance here tends to be structural: the org design conversation that would disrupt relationships, the performance clarity about a senior leader, the strategic pivot that would require admitting the current direction needs to change.
Avoidance
The structural change I know needs to happen but haven't made
Not a process tweak — a real structural decision. A reporting line that needs to change, a team that needs to merge or split, a Head role that needs to be redefined. How long have you known? What has deferring it cost?
The thing I know about my technical strategy that I haven't said clearly
Every CTO carries a view about where the technical direction needs to go that hasn't fully been named — either because it's uncomfortable, because it requires resources that aren't there, or because it implies a mistake was made. What's yours?
🗺️
Where I am on the maturity arc — and what I'm committing to
Stage 1
Foundational
Stage 2
Developing
Stage 3
Integrated
Stage 4
Market Leading
One commitment — observable, within 30 days
Complete this: "The one behavior I'm going to change is [specific action]. I'll know it's working when [observable signal]. I'm giving [name] permission to ask me about it."
For CTOs: the person you give permission to hold you accountable should be a peer CTO, a board member, or an executive coach — not one of your direct reports. The accountability relationship needs to be genuinely lateral or above, not beneath.