Most leadership problems don’t exist because teams lack skill, but because leaders avoid asking tough questions.

If you’re a CTO, these tough questions will expose the system and make it hard to keep pretending things are “basically fine.”

Your system is the way it is because it has the perfect conditions that shape it. So, ask the following systemic questions, and if any of them irritates you, that’s probably the first place to start.

As Donella Meadows explains in Leverage Points, the most powerful changes don’t come from working harder inside a system, but from questioning its goals, rules, and assumptions.

systemic questions for CTOs

And the follow-up:

Who pays the price?

If the same people always benefit and the same people always absorb the cost, this isn’t an execution problem, but a design choice.

Example: in a tech org working with Scrum and estimations, every sprint is planned, but every day the Product Manager, other teams and stakeholders insert more urgent tasks. Who benefits here? Who pays the price?

Slow delivery, meetings replacing decisions, being late, not tracking OKRs, ignoring business results, high attrition, lack of trust.

If you call it “the new reality,” it’s exactly the time to answer.

Quality, transparency, ethics, integrity, autonomy, safety, respect, courage, kindness, collaboration, innovation.

Values only exist when they cost something. Everything else is a poster on the wall.

If the answer is “nothing,” the problem isn’t really a problem and might even be self-deception. Persistent problems create routines and justification for control.

Example: the need to inspect the engineering managers’ priorities and decisions and correct them frequently.

The part that needs certainty, avoids conflict, wants to be needed, hates being wrong.

Your org can’t outgrow the leader you protect.

Example: a manager who cannot delegate a task because it will not be done at the same level of quality and speed, fear of engineers talking to clients, fear of putting pressure on teams, fear of communicating bad news, emotional comfort in not providing positive or negative feedback, and accepting bad relationships as an unchangeable fact.

What if your best engineers are pushing back because they see risks you don’t want to face, or have different values?

Resistance is data. Check what’s behind it.

Example: you’re pushing for a no-code system integration to replace a lot of engineering work and allow any business person to modify it, but it has no versioning, staging environment, observability and is not testable, so it will not be able to provide the value in the first place.

Not the version you show the board, in all-hands or just for managers, but an honest one.

Then ask:

What will make us move just half a point?

Transformations can be high-risk and block other things for a long time. Half-points compound.

Examples of dimensions to examine: system uptime, DORA metrics, retention, goal achievement, collaboration, customer satisfaction.

Somewhere in your org, the desired state may already exist.

And then the interesting question:

Why are we treating that as an exception instead of a guide?

Examples: several product-engineering teams that are agile, talk to customers and drive high customer satisfaction, teams that improved their DORA metrics, teams with high retention, teams that deliver on time and budget.

Not the market, industry, or tech debt, but rather inside us collectively.

Many obstacles are not external, even when it’s convenient to attribute.

Examples: belief that customers, Marketing or Sales must know features and launch dates, belief that the company’s DNA forbids questions, fear of losing control, addiction to urgency, comfort with heroics.

Metaphors are powerful because they bypass politics and cognitive thinking.

Examples: The Turnaround, Good to Great, Simplifying, Discovering the Terrain, Winning the Race, Ruthless Prioritization, Focus.

If nothing would make you stop it, it’s not an experiment.
It may be a belief you’re afraid to test.

Example: doing full-time pair programming for the next month, with check-ins in the middle and at the end to review the change in DORA metrics, stopping if they drop to the level of X.

Sometimes leadership sets doing goals for being problems.

You don’t need more tools or frameworks, but a clear strategy.

Examples: be agile – not just do agile, be a customer-driven org, an org that values quality, an org that values speed, a collaborative org, a performance org, an operational excellence org.

If you can “see” the timeline, this is no longer abstract.

Examples: on-calls constantly wake people up more than once every night, employees keep asking about transparency on decisions, priorities and direction, the system reaches its technical scaling limits, but there is no discussion or decision.

If these questions feel provocative, good – that’s not resistance, but information, and not all questions need an answer right now.

Your system is working exactly as designed. If you’re wondering about people’s behaviors, look for the incentives.

The only questions left are whether you need to modify the system, are willing to redesign parts of it, and make a small reversible experiment.

If you need help asking questions, reach out to me or to other coaches.

Subscribe to my newsletter

Leave a Reply

×