What your first ninety days as an IT leader should uncover

A new IT leader is expected to notice things. There will be invitations to fix an unpopular system, replace a supplier or settle an old disagreement. Some of those invitations will be useful. Others will be attempts to reopen decisions without explaining why they were made.

I would treat the first ninety days as a period for building a reliable picture of the work, while acting on exposures that cannot reasonably wait. Listening and intervening are compatible. The difficulty is knowing which conclusions are strong enough to act on.

An early restructure is a particularly expensive way to test an incomplete understanding.

Find the promises before making new ones

Start with what the organisation has already committed to. Read the contracts, approved projects, audit actions and service commitments. Ask for the next renewal and notice dates, not merely a list of suppliers. Find out which delivery dates have been promised outside the technology team.

The official project list will only tell part of the story. Ask each team member what work they believe they owe someone. Ask business leaders the same question. Differences between the two lists are worth discussing without assuming either side is being unreasonable.

Useful listening questions are specific:

• Which deadline would cause the most trouble if we missed it?
• What does IT currently do that you cannot see in a service report?
• Which decision has been waiting longest, and who can make it?
• What is working well enough that you would not want it disrupted?

Record the origin of each obligation. A signed commitment, an executive preference and an informal request need different treatment. The distinction will matter when you begin changing priorities.

Observe the work at its handovers

Meetings with managers are necessary, but they are not a substitute for watching work move. Follow a request through approval, fulfilment and closure. Look at an incident that needed more than one team. Examine how a project becomes a supported service.

Ask people to show the tools and records they use. A process diagram can say that access is removed promptly while the person responsible is waiting for an email that arrives unpredictably. Understanding that gap is more useful than declaring the process immature.

In a fictional first-week review, a new leader might discover that several routine changes wait for one engineer's informal check. That could indicate unnecessary control. It could also reveal that the engineer is catching defects nobody else has been trained to recognise. Removing the check before understanding it would be careless.

Look for capability as well as weakness. Someone may be quietly maintaining a dependable reconciliation, supplier relationship or recovery procedure. Preserve that knowledge before changing who owns the work.

Intervene where waiting creates a clear exposure

You do not need a complete organisational assessment before acting on a credible security exposure or a critical service with no usable recovery path. Verify the evidence, involve the right specialists and choose a proportionate response.

An early intervention should have a narrow purpose. Restrict an unsafe access path, arrange a recovery test, clarify an incident contact or put a looming renewal in front of its owner. Explain what you know, what remains uncertain and why the action cannot wait for the wider plan.

Avoid presenting an untested concern as a confirmed failure. "We have not yet verified that the restore works" is different from "the backups are useless". The first statement justifies investigation without unfairly discrediting the people who have been operating the service.

Keep a record of urgent changes so they do not disappear into the discovery period. Temporary controls need an owner and a review date. Otherwise the new leader starts by creating another layer of undocumented work.

Build an assessment people can challenge

By the middle of the period, share a working picture rather than a verdict. Describe services, obligations, capability gaps and the decisions that repeatedly stall. Invite correction from the people whose work you are describing.

Separate observations from interpretations. "Approval waited for six working days" is an observation if the records support it. "The manager does not trust the team" is an interpretation that may be wrong. A missing delegation, unclear financial limit or absence could explain the delay.

Use the same discipline with staffing. A busy team is not automatically understaffed, and a small team is not automatically efficient. First inspect demand, role coverage and the amount of rework. The discussion in choosing an IT operating model is easier once those constraints are visible.

Ask what evidence would change your current recommendation. That question helps prevent the assessment becoming a justification for the structure you preferred before arriving.

Leave behind decisions, not a discovery presentation

At the end of the period, I would want an agreed short list of interventions, a defensible account of the main exposures and clarity about which decisions the team can make without waiting for me.

Some findings should become immediate work. Others should become funded options or explicitly accepted deferrals. Explain the difference to the team. People who contributed candidly deserve to know what happened to their input, including suggestions that will not be pursued.

Review your own behaviour too. If everything now comes through your office, the discovery process may have created a new bottleneck. Delegating technology decisions belongs in the early plan, not after you have become indispensable.

Ninety days does not entitle a leader to certainty. It should produce enough shared understanding to make the next decisions with fewer assumptions, and enough trust for people to correct the leader when those assumptions turn out to be wrong.