The First 90 Days Test Both Sides of the Table

Demanding a roadmap won’t settle it either. A plan can expose the decisions ahead without proving the leader can make them. The more useful evidence is what they’ve learned, how that changed a recommendation, and what happened when someone tried to act on it.

Listening that changes a decision

Ask about conversations beyond the executive team. What has the leader heard from sales about technical promises, or from customer support about tickets that keep reopening? Have they asked senior engineers what they’ve stopped asking for, and why?

Lara Hogan’s questions for a first one-on-one include asking what someone needs from their manager, team, and peers. These are questions about the conditions around a person’s work. Applied to an incoming CTO, they offer a way to investigate a complaint before prescribing a technical fix.

If the complaint is slow delivery, for example, a recommendation to rewrite a service needs to explain why the service is the constraint. Take a delayed release and trace the work through its tickets, approval messages, and deployment record. Where did it wait, and what finally allowed it to move? A release waiting for an executive’s approval calls for a different intervention than a release blocked by a failing system. Both can appear as a missed date on the same roadmap.

The leader should be able to show you how they made that distinction, including what remains uncertain. Can they name the person carrying more responsibility than their title suggests, and explain how the work comes to depend on that person? Can they identify a discrepancy between the architecture document and the running system that changes what they’d do next?

Specificity matters because you can check it. It also gives people who disagree something to correct. A diagnosis that survives those corrections earns more confidence than one that merely repeats the language of the hiring brief.

The credibility tax

A leader can finish listening, develop a sound point of view, and still have nobody willing to commit to it. The diagnosis asks people to believe the leader understands the problem. Execution asks them to trust the leader with changes to their own work. That’s the credibility tax: confidence in one hasn’t yet earned confidence in the other.

An early improvement gives people something firmer to judge. In Genesis Advisers’ account of Michael Watkins’s transition framework, early wins should matter to the organization and be achievable with the resources available. Gaining stakeholder support is part of the leader’s work. The advice leaves little room for declaring a proposal sound while treating everybody else’s objections as an inconvenience.

Suppose your cloud bill is rising, and the CTO proposes shutting down environments with no named owner. That could remove waste. It could also shut down a customer dependency nobody documented. Missing ownership tells you what needs investigation; it doesn’t tell you what can safely be deleted.

Before calling this a quick win, the leader needs evidence about usage and dependencies, including work that doesn’t run during the inspection. The people who would deal with a mistake need to agree on how to test the dependent work and recover if the change breaks it. A cheaper bill accompanied by a broken service would be a poor demonstration of judgment.

An unexplained dependency may justify keeping the environment running. It also gives the review something concrete to examine: which dependency prevented the change, and what check would resolve the uncertainty?

Suppose instead the checks support retiring an environment. Verify that the dependent work still runs and identify the charges that actually stopped. A lower total bill could reflect less traffic elsewhere, so it can’t establish the saving from this change on its own. Keep any new maintenance work in the account, too.

Even then, the easiest improvement may tell you little about the reason you hired a CTO. If the remit was to resolve a disputed architecture choice, cloud housekeeping gives you evidence about housekeeping. Credit the saving without treating it as a blank cheque for the whole strategy. The review still needs to follow a recommendation about that choice.

Follow the recommendation through the room

Now suppose the cloud recommendation is supported, but it sits untouched. Nobody volunteers to own it. You still have several possible explanations.

The engineering lead might have no capacity without dropping an existing commitment. The team might be unsure whether the fractional CTO can authorize the change. Or the CTO might have failed to explain the evidence well enough for anyone to accept the risk. A lack of volunteers cannot distinguish those problems.

Follow the actual decision. Did the CTO ask for a specific owner and explain what the work would displace? Did the person with authority approve that tradeoff? If you endorsed the saving but kept every existing commitment in place, you left the team to resolve a conflict you own. If the CTO never raised the conflict, finding it belongs in their performance review.

A team can also have a sound reason to reject the proposal. Perhaps the saving is smaller than the maintenance burden of the new policy. A leader who changes their recommendation after learning that has done useful work. Agreement with the incoming executive is a poor measure of the organization’s ability to learn.

What you’re evaluating is a pair: the leader’s judgment and the organization’s capacity to act on it. Shared responsibility calls for locating the failure precisely. It gives neither side a general excuse. Repeated recommendations that ignore known constraints are evidence against the leader; repeated approvals without the authority or capacity to execute are evidence against the sponsor’s follow-through.

The engagement may also be solving the wrong problem. If an internal engineering lead already understands the issue and needs permission to stop lower-priority work, you can make that decision directly. More outside diagnosis adds little. If the job is temporary hands-on delivery, the fractional CTO owning a fix can be exactly what you agreed to buy. It becomes a dependency problem when developing internal ownership was part of the remit and no transfer happens.

At the 90-day review, bring the original recommendation and the record of what happened to it. Check the CTO’s account with the person expected to carry out the work. If the change remains unfinished, distinguish what the investigation established from the benefit that remains unproven.

A generic explanation from the CTO deserves challenge. So does a specific request you agreed to and never acted on.

What have you learned here that changed what you think we should do?