An IT director’s first 100 days

As IT Director, I was responsible for systems, infrastructure, networks and security, as well as the team, budget and suppliers. I worked directly with the board.

My work included an audit, a development plan agreed with the board, budget negotiations, security policies, a helpdesk, documentation and team training.

That IT management experience informs the proposal below: what to agree at the start of a new role and how to assess progress.

The first agreement with my line manager concerns the outcomes I am accountable for and the authority I have. A broad remit such as “IT management” leaves too much room for different expectations.

I suggest recording answers to a few specific questions:

• Which decisions can I make independently, and which need board approval?

• Who resolves conflicting priorities between departments?

• Who can accept the risk of leaving a significant problem unresolved?

• Which decisions about spending, suppliers and the team fall within my authority?

• What outcomes does my line manager expect, and when will we review progress together?

The discussion should produce a short record of responsibilities, decision boundaries and escalation rules. The initial agreement should make it possible to act from the outset. Once the situation is clearer, I suggest refining it, particularly if expectations exceed the available resources.

I distinguish between two areas in the proposed plan.

The first is protecting business continuity. I suggest checking which services are critical to the company, who owns them, what evidence we have that they can be restored, and where we depend on a single person or supplier. The result should identify urgent actions, accountable owners and risks that need a decision.

The second area is new initiatives: developing systems, automation, integrations or replacing existing solutions. Each proposal should identify a business problem, an owner accountable for the outcome, the expected benefit, and the money and staff time required.

In the budget, I suggest showing service operation, risk reduction and development separately. The board can then make an informed decision about what to fund, what to defer and which consequences it accepts.

If the same people are expected to maintain critical systems and deliver a new implementation, their availability needs to be agreed. Adding a project to the plan does not create extra delivery capacity.

For more on connecting business objectives with this choice of priorities, see From business goal to IT priority.

The periods in the table are indicative and overlap. An urgent risk requires an immediate decision; major implementations may extend beyond this timeframe.

“Owner” means the person accountable for reaching the stated agreement or decision; they do not have to perform all the work themselves. The measures are proposals to agree once the baseline has been established.

Each measure needs a data source, a review frequency and someone responsible for reporting. Recovery tests also need an agreed scope, success criteria and a definition of what counts as current evidence. For percentages, the denominator must be explicit: exactly what is included, and whether it has changed since the previous measurement.

A lack of reliable baseline data should be visible. Without it, a promised reduction in incidents or percentage saving cannot be justified.

Discussions with the team should produce a map of responsibilities: who maintains each service, who can provide cover, and where documentation or training is needed. If essential knowledge sits with one person, the agreement should specify what must be transferred and how we will check that cover is possible.

Discussions with the business should produce an agreed order for tackling problems. For each problem, I need a clear description of its business impact, the process owner and the condition that will show improvement.

These agreements help assess whether the leader listens and turns their findings into decisions. The number of meetings alone tells us little.

When assessing the first few months, I suggest being precise about the stage the work has reached.

I would consider a helpdesk operational when the agreed reporting channel works, responsibilities are assigned, prioritisation rules are defined and real requests can be traced through the process. That does not yet demonstrate better support. I would assess that using data from an agreed period and feedback from users.

Similarly, adopting a security policy confirms a decision about the rules. Evidence that people follow them is separate: for example, checks of selected cases and how exceptions are handled.

For a major implementation, the first 100 days may produce agreed requirements, a sponsor, funding, a plan and a completed preparation stage. Completing the whole implementation requires the acceptance criteria to be met, including user readiness and a handover to ongoing support. “Project started” should remain distinct from “solution accepted”.

I would not wait until the audit was complete if an identified problem required a decision beyond the IT Director’s authority. In the proposed approach, this applies particularly when:

• continuity of critical business operations is at risk, and protection requires extra funding, downtime or acceptance of risk;

• the expected deadline or scope exceeds the team’s availability and budget;

• departments have conflicting priorities that cannot be resolved within the agreed authority;

• a significant problem has no business owner or requires a change to an earlier board decision.

I would present an escalation as a decision brief: what we know, what we do not yet know, the potential business impact, the options, my recommendation and when a decision is needed. I would also state the consequence of not deciding.

During an ongoing incident, I would escalate while taking protective action within my authority.

The aim of the first 100 days is to give the board a coherent picture: the most significant risks are understood, priorities and funding are agreed, responsibilities are assigned and progress can be checked. For unresolved problems, we know what is blocking them and who needs to make the next decision.

For a prospective line manager, this would demonstrate that the leader can connect technical assessment with responsibility for how the business operates. For a headhunter, it provides a concrete basis for discussing the role’s scope, decisions and working relationship with the board.

About the author: Rafał Mokrowiecki has more than 20 years of IT experience, from ERP development to managing a team and budget. He served as IT Director from October 2024 to September 2025. Since October 2025, he has worked as an independent IT advisor.

Let’s discuss the scope of a permanent IT leadership role — decision-making authority, responsibility and expectations for the first few months, particularly in a manufacturing company.

This article draws on the author’s professional experience and sets out a proposed approach to starting a new role.