From helping tutors to questioning service measures

Mandate

Make internal systems and service measures reflect the employee work they are intended to support.

Outcomes

• Corrected superseded first results in a defined internal-search review
• Reopened 44 support requests whose employee tasks remained unresolved
• Preserved historical identity while reconciling an office integration

Decisions in context

The CIO appointment expanded my responsibility from running IT to explaining how internal technology supports the organisation's work. I lead four managers and thirty-three colleagues, with authority over the agreed operating expenditure and responsibility for its service consequences. I report to the chief executive and present internal-technology matters to directors, but I hold no board seat. The recent cases required a more honest account of our own systems: an indexed page was not necessarily current guidance, a closed request was not necessarily recovered work and a matching name was not necessarily the same historical identity. I work with departmental owners to resolve those questions without assuming their authority. The continuing task is to make that cooperation part of ordinary service delivery, so a business decision does not disappear beneath a technically successful release or a reassuring monthly measure.

Reason for the move

Current role; strengthening accountability across internal digital services.

Mandate

Connect applications, employee devices and support into a coherent internal service.

Outcomes

• Introduced task-context reviews alongside service availability measures
• Clarified ownership of internal guidance used in applications
• Connected support handovers with release and departmental decisions

Decisions in context

Leading IT brought the employee's full working environment into view. A colleague might move between an application, a device and a support conversation while each technical team measured only its own part. I worked through three leads to connect those responsibilities and identify where the person remained unable to complete the task. The role also required clearer expenditure decisions: a new tool could be affordable while the ownership needed to maintain its content was absent. I began discussing that continuing obligation with business sponsors before recommending purchases. We introduced small reviews of real work alongside the established availability measures. Those reviews did not replace technical monitoring, but they exposed questions that a service dashboard could miss. The CIO appointment followed because the next stage required executive agreement about the responsibilities represented in internal systems, beyond the boundaries of the IT function alone.

Reason for the move

Appointed CIO as internal technology became a wider executive responsibility.

Mandate

Deliver internal application changes with usable guidance and accountable handovers.

Outcomes

• Included departmental decisions in release readiness discussions
• Reconciled user guidance with changed application behaviour
• Made unresolved process questions visible to the support team

Decisions in context

As applications lead I stopped being the person who could personally investigate every difficult request. I had to develop ten colleagues' judgement and give support staff enough context to explain a release after the project team moved on. We learned that passing a technical test did not ensure that user instructions described the same process. I worked with departmental owners to reconcile those differences before asking employees to use the change. The role also made me more careful about unresolved questions. If a department had not decided who could approve an exception, the application team could not safely invent the rule merely to finish a screen. I became responsible for explaining that dependency and agreeing a workable next step. That combination of technical delivery and organisational ownership prepared me to lead devices, support and applications together in the following appointment.

Reason for the move

Promoted to lead the wider internal-technology function.

Mandate

Understand the task and departmental decision behind an internal application request.

Outcomes

• Documented competing meanings of shared application statuses
• Connected user reports with underlying records and process owners
• Prepared change requirements that distinguished technical and business decisions

Decisions in context

Joining a software-quality business did not mean its own internal applications were free of ambiguity. I analysed employee requests and followed the problem through the records and departments involved. A status that meant complete to one team might mean ready for review to another. My early instinct was to fix the transfer between systems, but I learned that faster transfer could merely spread the disagreement. I asked owners to explain the action their status supported and recorded what remained undecided. The IT manager approved changes and expenditure; my contribution was analysis and a clearer account of the requirement. I also spent time with support colleagues to see whether a proposed correction made sense to the person receiving it. That habit helped me move into applications leadership, where I had to make the same understanding available to a team rather than keep it in my own notes.

Reason for the move

Promoted to lead internal applications and their continuing support.

Mandate

Help tutors and administrators use class and attendance applications accurately.

Outcomes

• Investigated missing-list reports without assuming the underlying record was lost
• Maintained clear notes for unresolved application questions
• Improved practical explanations given to tutors during support

Decisions in context

My first job combined routine application maintenance with questions from tutors and administrators who needed to complete the next task. I learned that proving a record still existed was not enough if the person could not use it in the required class list. Under a systems supervisor, I checked the data, explained an available route and recorded the underlying issue for further work. I had no authority to change teaching policy or purchase new systems independently. The role taught me to separate immediate assistance from a final technical correction, while making sure neither was forgotten. It also helped me become comfortable asking a user to show the task in their own terms. After almost five years, I wanted to understand larger internal workflows. The systems-analyst position offered that opportunity and a more structured way to turn practical observations into change requirements.

Reason for the move

Moved into systems analysis at a growing software-services company.