We’re fast approaching the deadline for the end of support for Microsoft Windows 10 (14th October 2025) and, judging by the voices of colleagues in and across the UK, many are in precisely the same position that they were at the end of support for Windows 7 and Windows XP. A large number of schools aren’t ready, and many only began properly planning their upgrade paths in the last 6 months. So why are we here, again?

The answer is both quite simple, and rather complicated. Like many things, we need the complexity first before we can simplify, so let’s start there…

Missing capabilities…

If we listed the high-level capabilities that a Multi-Academy Trust needs within the digital realm, it might look something like this…

In many trusts, if you were to document their current capabilities in the digital realm, it would look something like this…

Many IT teams in schools and trusts know that there’s much more to their world than IT support, but are overwhelmed by a seemingly endless support workload. Educators and leadership teams can often sense the gap in proactive efforts but, in my experience, don’t have a clear understanding of what better would look like.

Matt Setchell wrote recently that “the structure of IT Support in Education needs to change“. The post is excellent and, as Matt rightly points out, there are several separate skillsets and disciplines at play here. The mindset shift from supporting nervous or stressed staff and managing IT infrastructure is significant, and not many people truly excel at both.

With this in mind, let’s look at the simple answer…

A challenge for Leadership…

For me, our sector’s struggle with technology boils down to one question, and it’s the same one that I raised in my last post on cyber security:

Can we prioritise important work that few will notice, over urgent work demanded by many?

Getting this right is something that can only be done through leadership. Leaders create the culture and the space in which important work is either sponsored, prioritised and recognised, or crowded out and forgotten until it’s too late. However, it’s not easy.

To ensure that important security upgrades are applied, or funds are available to upgrade core infrastructure, we have to protect the time, people and budgets required to make it happen. All three of those resources are under pressure. Many of the alternatives on which they could be spent will be laudable, and the emotional case for doing so will often be powerful. For me, this is why it’s important to understand that the capabilities I’ve outlined earlier in this post, and the disciplines that Matt describes, are distinct.

If we were to redeploy all of our English teachers to the Maths department and ask them to teach additional Maths lessons, our students would (at best) get slightly better results. Meanwhile, our English results would plummet, and the intervention required in future years to redress our mistake would be considerable.

For technology to empower a school or trust, it takes an awful lot more than excellent support. In fact, exemplary user experience and support services are built on the other capabilities - without them our IT staff will just be fighting fires that spread faster than they can be extinguished.

A path forwards…

The first step is to understand that there’s an awful lot more to technology than IT support, and to identify and articulate the gaps in our organisation. Then we must address these gaps whilst remaining cognisant of the current support efforts required to keep our organisation running. To extend the fire-fighting metaphor - if the whole town is on fire, it’s no good withdrawing the fire service and simply saying “it’ll be better in 12 months time once we’ve rebuilt it out of something better”. Instead, we need to find the balance between solving pressing immediate issues and building for a much better future. The more we are able to show people a path forwards that they believe in, the more they’ll help us along the way.

In many schools and trusts, IT, technology and data don’t have a proper seat at the table and the kind of transition above only occurs as a result of some crisis or other. That difficult period of just about managing can last years, but knowing that your organisation’s digital estate is tinderbox-dry and ready to combust at the slightest excuse is no way to live.

To my colleagues in technical roles who can see the gap but need support from leadership to start making a change, take agency. It’s not fair for us to bemoan our lack of voice if we never actually speak. Take the time to understand the school and trust in which you work, and show how your suggestions help students, staff, and the school as a whole.

To my colleagues in leadership or education roles who can see that their technical teams are struggling to stay afloat, but perhaps haven’t encountered the concepts I’ve outlined in this post, use them to start asking your team how you can help. Be patient with them - techies are easily spooked, and you might have to build some space and trust with them first.

If I were to attempt to capture the essence of why cyber security is so difficult, I think it would look something like this…

Cyber security relies on our ability to prioritise important work that few will notice, over urgent work demanded by many…

This description is incomplete, but it hints at a few of the reasons that contribute to the challenge:

• It requires intentional leadership

• The individual tasks are in conflict with immediate business priorities

• Success is the absence of an event

When security measures do show up in the land of business staff, it’s often in mandatory training videos or annoying password and authentication restrictions. Unfortunately, there’s a reason that the last 5 podcasts I’ve listened to covering cyber security have jokingly referred to the CISO as the “king of ‘No’”.

With that context in mind, I’m sharing some notes today on a topic I’ve been asked about several times in the past few months - Microsoft Sentinel. This post definitely needs a health warning, in that I’m neither a cyber security expert, nor an expert in Sentinel specifically. I’m also not at liberty to disclose anything too specific about the systems we’re protecting. Hopefully this is a good starting point for discussions around in house capabilities, and ways to develop them without blowing our entire IT budget on security services and tools.

Too many plates to spin…

We, like most trusts with an in-house IT team, are generalists. We lack the scale to build robust capabilities in discrete teams, and therefore whenever we have cause to investigate something in cyber-space, we’re probably dropping some urgent work that’s directly related to a business issue or project.

Microsoft 365 is, these days, pretty good at providing the logs needed for these investigations, but gathering them from across the various admin consoles is a laborious task, and correlating activity from various log sources stretches even my fluency with excel. All of this work needs doing whilst the clock is ticking twice - once for the potential threat burrowing its way into the data that we’re doing our best to protect, and a second time for the business project that we’re delaying, much to the chagrin of our colleagues.

This friction isn’t just frustrating, it also leads to a less thorough investigation. If it’s difficult, our capacity to investigate is decreased.

So, how does Sentinel help…

Enter the SIEM…

Sentinel is a SIEM (Security Information & Events Management) platform with a bunch of SOAR (Security Orchestration Automation and Response) features. At a simple level, you fire a load of logs from different parts of your digital world over to Sentinel, and then you can do cool stuff with them all from a single workspace.

Our start with Sentinel came courtesy of a project with Performanta and the excellent Marcus Burnap. I’d thoroughly recommend a read of his blog where he covers Sentinel with significantly more authority than I have any right to…

Marcus Burnap - Microsoft Security - Sentinel - Defender XDR

Welcome to MB Cloud Teck, a site that aims to share knowledge, increase security, and solve problems with the latest technology. Principal Consultant | Microsoft SME | Cybersecurity | Defender XDR | Sentinel | Copilot For Security

There’s very little technical work that we outsource, but Sentinel set-up is definitely one of those areas where I’d go to the experts. Thanks to their help, we were able to use the full 30-day trial to evaluate the functionality and the value, rather than just getting it working.

New capabilities, new skills

In a recent presentation to a group of IT professionals in Leeds, I shared a list of areas where I thought we needed to invest our time in learning. High on that list was KQL, which (for us) was the greatest immediate benefit of Sentinel. A quick crash course in the basics, and we could replicate hours worth of stitching together audit logs from various admin centres with a single query. Queries are re-usable, and allow us to pivot quickly from evaluating account activity to IP addresses, user agents, link clicks and more. I’m not exaggerating when I say that work that used to take hours was now done in about 10 minutes.

The second benefit is the more advanced alerting that came with the set up that was done for us. We now have much more sophisticated alerting than is provided for within Entra ID, and have responded to and remediated incidents that I’m not sure we’d have previously caught at all.

These two areas are barely scratching the surface of what Sentinel can do, and we’re gradually extending our exploration of the functionality, and other log sources to improve the contextual understanding.

Costs & closing thoughts

Cyber security tools have a reputation for costing £££, and most vendors just don’t seem to be pitching at a place that Education technology budgets can access, but I think this was the greatest surprise for us. After the optimisation work done during our set up process, we’re ingesting far less billable data than I had feared. For us, the costs pay for themselves in technical capacity released for other work, including other security projects, and there’s further improvements to come once we explore some more functionality in the near future.

There are a bunch of log sources that you can ingest for free and with A5 licensing, if you have that, you have an additional allowance per user. Even if there’s no chance of any budget for anything more than that, I’d certainly spend the time to get the free log sources set up.

If you can find a fairly humble amount of cash, I’d genuinely recommend a pilot similar to the one that we started with. If that’s the only time you bring in external support, then you’ll have made several months worth of technical progress in a few days, and can use that as an accelerator to get value out of your new tools far quicker than doing the set up in house.

Roughly 12 months ago, I wrote a note that said we as a sector had the guidance we needed and it was time for action (you can read that post below). If our experience here is representative then it’s also true that the tools are much better, and much more accessible, than one might think.

Copilot for Microsoft 365 is an interesting implementation of Generative AI as it’s baked in to the 365 suite. The documentation, supporting resources, and other launch materials for Copilot for Microsoft 365 are plentiful, with pages of guides on the various work streams and tasks recommended for a successful launch.

Microsoft have iterated on these guides since I first started looking at them and today I want to share some notes on how we handled the “technical readiness” work stream. I do so from part-way through a pilot project of around 30 teaching & learning staff that collectively represent almost every school in our trust and, at this point, have enough confidence to say that we’ve done a reasonable job of it!

Technical Readiness

Microsoft have a boat load of guidance and adoption resources for Copilot in their Technical readiness for Copilot for M365 resources, and I can’t hope to cover those here. Instead, I’m going to talk through my approach to Copilot for Microsoft 365, and a few things that I’d found that were more challenging than I’d thought.

Firstly, It’s possible to group all of the technical preparation into one of two levels:

• Tenant & Environment

• User & cohort

For each level, we need to understand the following aspects:

• Data & governance

• Technical prerequisites

Tenant & environment

The first place to start is the preparation in the tenant and environment. The Copilot success kit has matured since we did the bulk of this work back in the spring, as has the Copilot Optimisation Assessment. Take the time to go through the work in these guides step-by-step, most of the checks are pretty straightforwards and involve making sure that you have the right licensing in place, and that users are using the tools where Copilot is embedded. There’s also a collection of guides on Microsoft Learn which are well worth a read.

When we completed our preparation at this level, we were looking for answers to the following questions:

• Do we have anything that will take significant effort to fix, either before or during a Copilot for Microsoft 365 launch?

• Generally, how ready is our tenant and environment as a whole?

These questions are important. One of the biggest risks that’s been talked about with Copilot for Microsoft 365 is that, if your practices around data are already poor, then Copilot might find data that a user shouldn’t have access to and present it to them.

The problem here is not Copilot for Microsoft 365, it’s that users are not handling data in a way that’s safe and secure. This might mean that you have some work to do across your whole organisation before you come back to Copilot, but delaying your Copilot project does nothing to fix the problem. It’s a risk you’re already carrying and it needs sorting with or without Copilot.

For each check, or test that I used, I had a threshold for acceptance. The threshold varied depending on how critical that particular check was in answering my questions above, and the workload involved in correcting any issues that I found. It’s not possible to just copy and paste these checks between organisations. We started with the checks from the Microsoft documentation and then added more as we went. A few examples are:

• Number of SharePoint sites set to "Public" should be 0.

• Number of users on current release of M365 apps should be > 95%.

• Default sharing link type for all sites should be “People with existing access”.

• …

Once all of your tests are above the threshold, you’re likely ready to move forwards. We couldn’t afford to set the target for every target to 100%, as the effort required to check every permission across every file and folder on SharePoint would be astronomical. Even if you could, the very next day something might well have changed. Instead, we need enough certainty to move forwards, and then to build in further checks and governance processes in the per-user or cohort level work. The thinking behind this is laid out in a previous post titled “Clarity through movement”, linked below.

User & Cohort

This part was initially more difficult. The question I used to frame this was “what’s the individual risk for this user?”. We’re going to have different concerns around data when granting a copilot license to a user with different levels of access, and there are different levels of trust at play too. The other trusts I know deploying Copilot for Microsoft 365 all started with very highly trusted individuals in central teams and leadership positions.

After a few late nights diving into the Sharepoint & Microsoft Graph PowerShell modules, I concluded that the data that I really wanted wasn’t actually available. I could easily get a list of groups that a user was a part of and an indication of what those groups gave a user access to, but there was a gaping hole in the data I’d get back - OneDrive and ad-hoc permissions in SharePoint.

There were a few SharePoint PowerShell commands that looked promising, but every one of them simply errored or timed out. I really wanted to know what data a user could see in others’ OneDrive, and the folders from SharePoint that had been shared with them as it would give me much more confidence that what I think staff are doing is actually whats happening.

Then, I found this endpoint in the Graph API:

https://graph.microsoft.com/v1.0/me/insights/shared

This endpoint is the API behind the “Shared with me” page in OneDrive which might be enough (in combination with other measures) to give us enough certainty to activate a license. We then hit barrier two… a little line in the documentation stating that “Only the user can make requests using the user's ID or principal name.”

I’d been planning to use a simple Forms & Power Automate combination to allow users to register for a pilot project, in which they’d have access to a license, but as the endpoint I needed can only be accessed by the user themselves, I put together a Flask app running on Azure App Service. This onboarding app allows the user to sign in, go through a set of onboarding pages and then calls the graph API endpoint before saving a report to a database for me to review. The whole workflow looks something like this…

At some point I’ll talk through our onboarding & user adoption work in more detail, as I think that’s even more important, but having the technical readiness for a user embedded in the onboarding process allows the work to scale. We can onboard 25 people with checks at the individual level in under an hour as the data that we need to review is collated automatically.

In our internal discussions on this work, we started to use the term “blast radius” for enabling copilot for Microsoft 365. There’s probably better wording for this, but that’s the term that stuck.

What if we miss something?

This is a really important question to have answered. As I’ve noted before, our aim was never 100% certainty as that’s simply not achievable. Instead, we needed to reach an appropriate level of certainty, based on our organisation and our data, and then have pre-agreed plans to implement if something came up.

The starting point for this was, what process do we follow if we find that a user has access to data that they should not have? We already have policies and processes in place for this kind of problem, and so it became a matter of wrapping these in specific training and documentation for staff and leaders across our organisation. The key step here that, from the very small window I have into other organisations, I don’t think is yet widely understood, is that this conversation took place at the executive team. Far too often, trusts and schools have a divide between teaching and non-teaching functions in the organisation, and ensuring that the executive / senior leadership team has a common understanding of the risks & problems (existing over-sharing of data), and agreement on what the plan will be if anything is found (don’t just blame IT) is critical.

Additional tools and licensing

It’s worth noting that some of the tools and licensing that Microsoft links to in their documentation simply isn’t available to us. The A5 compliance suite, and the SharePoint Advanced Management licenses both add some very powerful tools to support your management of data across SharePoint. Unfortunately, with budgets the way that they are, we don’t have access to these.

Adoption & Impact

I’ll save the majority of the adoption & impact work and the thinking behind our internal roadmap for AI for a separate post, but I think there is one aspect that’s worth pulling out here.

Technical readiness isn’t just about safety. It’s just as important that we use these tools to support the adoption & impact work.

In building an application to handle onboarding, we now have the ability to present some information to users during that onboarding journey. In fact, we’ve flipped the experience around. This isn’t a license that IT simply provides once we’re happy, this is something that you sign up for and enable yourself (with an approval step).

The onboarding app presents the outline of our Copilot project and our expectations of staff who are joining it. It explains our rationale behind a pilot, and links to our principles for “Responsible AI”1

In addition to this, we’ve built a series of power automate flows to support the project. One handles the onboarding process, approvals, and activation of licenses (called automatically by the application that creates the report), and another handles project communications, sending automated emails to participants with reminders to complete feedback forms, and hints and tips. The reminders go out a set number of days after sign-up and are pulled from a SharePoint list, so they can be added to and edited on the fly.

Where next?

We’re currently in the middle of a “private beta”2 pilot project with teaching staff from all schools, with a view to assessing the impact of Copilot for Microsoft 365, and whether the cost can be justified for a wider.

We’re also looking for the training and skills needed to get value out of Copilot. Can we get the same value from cheaper / free alternatives without introducing data and security concerns? Should certain knowledge and skills be considered pre-requisites for getting value from Copilot, and how could we embed those into onboarding and wider digital skills initiatives so that more people can get value from it? Should we be looking at AI elsewhere (hint - yes, and we are!), and how can this pilot inform other work on use of AI?

We’ll document and share what we find over the next few months, and look out for more from me here. The next post drops… sometime soon?

Deciding when to push “go” on something is difficult. Over the past 18 months or so, a clear tool to help frame the discussion around readiness has emerged in the way that we’ve been working - a simple pair of questions:

Wherever possible, we separate projects and work into smaller, more manageable tasks, changes and projects; decoupling them as much as possible from one another. This allows us to move forwards with less certainty as we pre-emptively contain any issues that might occur should we run into something that we didn’t expect.

This decoupling is important because the more certainty we need, the harder it is to obtain. Let’s say that we’re 80% certain that we have everything in place for the next step in our project, but we feel that we need to be 95% certain before we can press “go”. We might imagine that the additional work to get that last 15% certainty might look something like this:

Unfortunately, that’s not the case. In almost every case I’ve come across, it actually looks something like this…

That extra 15% certainty represents more than double the effort than is required to get from 0 to 80%. It’s much more effective to break things down into simpler and safer tasks, changes and projects than it is to try and gain that additional certainty.

In an environment where a single misstep isn’t a source of pain or disruption, and even several failed steps strung together don’t jeopardise anything important, we can start to press go on things with a little less certainty.

So, back to those questions…

Are we ready for the next step?

The first question includes much of the obvious preparation work that we would all expect. For me, the important concept to highlight is that, if your answer is “no”, you have two options.

1. Prepare further.

2. Take a smaller, or different, step.

When faced with difficult terrain, or steep ground, taking smaller steps is far more effective, far safer, and far quicker than trying to take big leaps. Sometime, further preparation is crucial, but after a certain amount of preparation you start to see massive increases in effort, and diminishing returns for that effort.

Can we continue to be ready for future steps?

When climbing a mountain, I don’t need to know the exact detail of the terrain on approach to the final summit. I need to know that:

1. My fitness, skills and equipment are commensurate with the challenge

2. The weather forecast is acceptable and suitably accurate that I can set off

3. My high-level plan (planned camps, food and water carried, etc) is viable and gives me plenty of room for manoeuvre

4. I have the knowledge, tools and ability to plan the final ascent in more detail as I get closer.

The same is true for projects and change. At the start of a project, I don’t need to have pinpoint accuracy on how effective an online community would be in helping staff share ideas and experiences with a new piece of technology, I need to build in methods that help me assess how effective this idea sharing is, and have ways to adjust or rethink if necessary.

Clarity through movement

One of the many things that the agile movement got right was that, in scenarios where risk profiles allow, we gain more information and clarity, not by planning in more detail, but by doing things.

By carefully designing projects so that we can adjust course as we go, we can lower the threshold for pressing go on the next step, all whilst charting a smoother and faster course to our destination.

Previously in this series, we’ve talked about why work should be visible, and why the capture process really matters. Today, after a winter hibernation of sorts, we’re back with a look at friction, the quiet killer of best laid plans.

Projects, initiatives, strategies don’t always fail because they’re completely misguided as a whole1; many fail because of the cumulative weight of little unexpected issues that crop up along the way. Occasionally, these problems will be down to a single obvious error, but more often the individual issues are small and relatively easy to address. Over time, each issue causes a little bit of friction. The longer an issue goes unnoticed the greater the friction and, over time, this build-up can grind all progress to a complete halt.

People underestimate friction. Often the instinctive response is to push harder against it, but that often actually increases the friction. Climbers use a technique called “smearing” to find solid foot placements where there are seemingly no footholds and the harder you press into the rock, the better your foot sticks. Simply applying more force to something already stuck due to friction just increases that friction. We might as well bolt it in place.

Of course, friction within an organisation isn’t as obvious as that, and its effects aren’t necessarily as immediate. Friction occurs out of the normal line of sight of the leaders and project managers trying to affect change. This means that we have to deliberately think about it, actively seek it out, and then take the time to address it. Up-front work to reduce or eliminate friction is an investment that pays off later, particularly if the time then saved can be used to address friction elsewhere.

So, what should we be looking out for?

Anything that requires the diversion of attention from a primary task, to a secondary or tertiary function, causes friction. Our teachers know only too well how the friction caused by low-level behaviour issues, or small little technical issues with IT equipment, impacts a lesson. Divert your attention once or twice to address it and your class might well be able to carry on without too much of an issue; but after three, four, five disruptions… forget it.

We can’t ignore it either, else it just escalates. Low-level technical issues will continue to impact lessons, but it takes longer to refocus the class each time a disruption occurs. Teachers start avoiding the use of technology, putting in place workarounds that take more time, but at least feel reliable. This eats into time for other work or evenings and weekends, leading to staff who are more tired, stressed, further reducing their capacity.

Change faces a similar phenomenon. Most changes introduce some level of friction, but beyond a certain threshold, that friction becomes the primary focus.

Change that operates above this threshold is operating within the available capacity. As soon as we fall below the threshold we find ourselves in the “Zone of Rocky Despair”.

Suddenly, rather than cruising safely over the jagged mountains below, we now have to navigate a path between them. Our visibility is now obscured by sheer cliff faces and sharp summits. We’re more affected by adverse weather, and one wrong move would mean a rather sudden impact with a rocky mountainside.

Once we fall below the threshold, it takes a heroic intervention to change our fate. Projects can be successfully marshalled through this zone, in some cases for many years, but it requires many times more effort and the best that is normally achieved is to delay an inevitable collision with the valley floor.

I don’t think that friction should always be avoided, or even that all friction is necessarily bad. I’m saying that it has a cost, and that our teams, projects and organisations can only bear so much. In that sense, it is analogous to a financial budget, and we should be as intentional about hidden “costs” such as friction as we are about financial costs and investments. If the friction we cause now is short-term, quickly addressed, and our change gives us more capacity in the medium and long term, it can often be worth it.

This article follows on from the previous post on making work visible, if you haven't read that yet, you might want to consider having a quick skim through it before continuing here.

In the previous post in this series, we discussed the idea of listing all the work that we might do, then carefully selecting the most important work and devoting our time and attention to that. The concept here is very simple, but executing it well, day after day, can be much trickier that one would expect.

The framework so far is rather simple. Work is only ever added to the parking lot where we gather some initial information, then we regularly select the most important work and do that. The problem is that incoming work is not neat and orderly. It appears in emails, phone calls, meetings and chance conversations. Incoming work is unpredictable, and most of the time will be quite poorly defined.

To address this, we need a process. We need to know exactly what to do with incoming work so that we ensure that we don't miss work that would be important or valuable; and we can field incoming work efficiently, whilst still devoting as much of our time as possible on work already in progress.

The design of this process needs to fit the context in which it is operating. It's important that you develop this with your team, but there are normally two main parts of the process:

1. Record the work, along with any preliminary information (requester, initial ideas or thoughts, context, etc.).

2. Review the information recorded, capture any missing information, and add to the parking lot.

Your initial design for this process will likely need to be adjusted slightly over time, but be sure to give it long enough between changes to understand whether a change is needed or whether you just need better implementation.

As you develop your process, you can create separate paths for capturing different types of work - ideas for future product requests need to be separated from support requests and both should to be separated from bugs needing attention from development teams. A form that asks some initial questions about an idea might place responses into a product management system. Support requests can be directed to a dedicated email address or messaging system that helps triage them effectively. Bug reports can be filed using a separate form that gathers more detailed information needed by development teams.

This type of optimisation is important as it reduces friction and making it much more likely that you, and others, will follow it even under pressure.

All of this is standard practice in IT & development, and there are books, courses, certifications, frameworks, that cover it in minute detail, but the concept of having a defined process for capturing work isn't just relevant when thinking about an IT services team or a product management role; it's a core tool of effective leadership.

This capture process, and broader concepts around work management, helps people with different instincts work effectively together. Action oriented people like to pick things up and run with them. They feel good when moving things forward, and slowing down can be quite uncomfortable for them. This is a great impulse when focussed in the right way, but can very easily create chaos and anxiety if it goes unchecked.

Others are naturally more deliberate and methodical, preferring to carefully plan and proceed at a steady pace. Again, this instinct can be very powerful as consistent, deliberate effort over time yields incredible results. However, at the extreme, this instinct can struggle to respond effectively in fast-changing environments, or create over complex processes that tend towards stagnation.

Capturing things and deliberately not immediately acting on them means that we allow time to complete work already in progress, whilst giving those that crave action an outlet for that impulse, and some certainty over when new ideas and work will be reviewed and possibly progressed.

Even at the level of an individual, this process is useful. If you tend towards immediate action then, instead of messaging people as soon as an idea arrives, try creating a list called "catch up" where you record things that you need to action or discuss with others. Then, you can come back to that list later and only act on the most important items. Your colleagues, particularly those that you line manage, will thank you!

If you have a more methodical tendency, then this making this capture process likely plays to your strengths, but sharing the process will help you channel the energy of those around you that prefer to jump first and build the parachute on the way down.

In closing, I'll leave you with this quote from The Phoenix Project that articulates why I feel this topic is important far better than I ever could.

"Like matter and antimatter, in the presence of unplanned work, all planned work ignites with incandescent fury, incinerating everything around it.”

So much of modern work goes on below the surface. In a previous post, I discussed how the appearance of tech as "magic" creates a natural gap in understanding between techies and the rest of the business.

This post is the first part of a series on change, work management, and process design. As we go through the series we'll talk about how we apply some of the principles, but we're starting with a prerequisite concept at a fairly abstract level.

Make work visible

Almost all parts of every organisation rely upon digital technology to function, and therefore people who can bend the underlying technology to their will are always in high demand.

Projects, changes, initiatives, strategies, and ideas must all compete for this limited capacity to move forward. How we apportion the time and attention of our IT resources is a critical business and education decision.

"Work" is anything that takes our time and attention. Given the importance of focusing our efforts on the right work, we should have a strong desire that this choice is both informed and intentional. To make deliberate choices, we need to know what our options actually are. We need to write them down.

Work in Progress & the Parking Lot

We need a list of all the requests, ideas, changes and projects to which we could devote our energy. These aren't just the things that we plan to do, these are all the things that we might do. For now, we'll call this the "Parking Lot".

From this list, we then select the first things that we should tackle and we'll move these over to a new list called "Work In Progress". This list has a couple of rules:

Rule 1 - Only a small number of things may be on the work-in-progress list at once.

Rule 2 - Things are only added to the work-in-progress list from the parking lot.

Rule 1 is important because the work-in-progress list should contain the most important work at any point in time. If we add too many things to that list then we're failing to decide what's important and what's not. By limiting the number of things on the list we force ourselves to prioritise.

In the long run, this is much faster. Imagine trying to piece together a jigsaw puzzle. Fairly easy, right? Now imagine having the same amount of space on our table, but suddenly we have two different puzzles to work on, or six. All of the pieces are going to get muddled and we'll just end up wasting time sorting them all out again. Very quickly, it's obvious that the fastest way to complete all 6 puzzles is to complete one from start to finish whilst the others are still safely in their boxes, and only move on when the current puzzle is complete and the table is clear.

Now let's take a look at rule 2: Things are only added to the work-in-progress list from the parking lot.

Before things can move from the parking lot to the work-in-progress list, we need to carry out some discovery work to define a few things about them:

• What problem are we trying to solve?

• Why are we trying to solve it?

• What is our proposed solution?

• How will we know that we have succeeded?

• What are the risks and uncertainties?

We must ensure that we have a minimum set of knowledge about a piece of work as it means that we have some information to help us choose what we work on and what we don't.

When we select the things to add to our work-in-progress list, some people will inevitably disagree with our choices. As I said before, directing the time and attention of our IT resource is a critical business and education decision, so we need to make sure that there are voices for these interests involved when deciding what goes on the work-in-progress list. These conversations are informed by the answers to the questions above, so it makes sense to gather them immediately.

Unfortunately, even with the right voices on board, it won't be too long before the ground shifts beneath us and we need to change what we're working on. At this point, we need to rephrase our original concept of "make work visible" so that it's a little clearer...

For us to work on something, it must be visible.

It's fine to have to drop what we're working on to focus our resources on something more important, but we must admit that we're doing that. As soon as our emergency change or project arrives, we should:

1. Add it to the parking lot and carry out the basic discovery work (answer the 5 questions)

2. Move some other work off of the work-in-progress list, back to the parking lot (decide what we're dropping to allow us to respond to the emergency)

3. Add the emergency work to the work-in-progress board.

As before, our representatives from the rest of the organisation should be involved Sometimes, what initially seems to be an emergency will quickly become less urgent when we start having conversations around halting other work already in progress. When other work is paused to make way for emergency work, the rest of the organisation must know.

Summary

Let's quickly recap what we've achieved so far:

• We created a list called the "Parking Lot" and this contains everything that we might work on.

• We have a minimum set of information on each piece of work.

• We have a list of "Work In Progress" that contains the most important work.

• All areas of the organisation agree that the "Work in Progress" is the most important work.

• We know immediately what to do with new work (add it to the parking lot and carry out basic discovery).

• Requests for new work will not sidetrack us from the work that we've already committed to.

• We can be much more efficient by limiting the work in progress, and we have organisational backing for that.

If you haven't read the wonderful novel "The Phoenix Project", then I'd strongly encourage you to do so. It's a masterpiece, and you'll finish it with a visceral understanding of this concept and several more, and thoroughly entertained.

The next post in this series will cover the capture process in detail and discuss the potential of this beyond the world of IT. Look out for it on the 24th of November!

Back in 2019, the ONS published a report titled Exploring the UK’s digital divide. In it, they observed that:

In 2018, 12% of those aged between 11 and 18 years (700,000) reported having no internet access at home from a computer or tablet (PDF, 3.16MB), while a further 60,000 reported having no home internet access at all.

The report wasn't specifically focused on education but it did provide some data to back up what most of us working in Education already knew. Putting it very mildly, students don't all have the same start in life.

Since this report there have been two significant events that have highlighted just how significant the digital divide really is.

The first was the pandemic. Suddenly, students were sent home and schools were closed. Some schools were ready for this as they happened to have already invested heavily in digital technology to support teaching & learning in school. Other schools were blindsided by this new paradigm; staff and students had incredibly limited access to technology, and the students' learning suffered hugely as a result.

The second event is currently gathering speed with the first waves breaking on the shores of education in the last 12 months, and that is the explosion of generative AI. Generative AI brings endless promises along with a similar number of risks.

In different ways, both of these two events demonstrate clearly that the world we are preparing our students for is one that we cannot predict, and one filled with fantastical promises coupled with new challenges to overcome.

Detailed predictions about such an uncertain future are a fool's game, but I do think we can make a couple of general assumptions about the world that we're preparing our students for:

• Technology, and AI in particular, will have an enormous influence on the lives of everyone.

• Those that understand this new technology will be the best equipped to adapt to an uncertain future.

Given this, and the learnings from the pandemic, I would like to make one further assertion...

1:1 devices for students are now critical to their success, it will not be possible to keep up without them.

Technology has always been able to empower and enable both teachers and students, but there is a difference in degree. 20 years ago technology was able to deliver significant, but incremental improvements to the education we could offer our students. AI promises an education that is more personal, carefully crafted to each learner, with tools to guide them into that "flow" state where the real magic happens. The change that AI brings is an order of magnitude.

We no longer need to move on from knowledge that is a prerequisite for future learning, simply because most of the class is ready, forever stranding those few that couldn't quite grasp the concepts in time. 1:1 devices for schools have been enabling this for at least a decade now, but we're in the middle of another step change; the technology is about to get a whole lot more powerful and those without access to it will fall even further behind.

Our collective experience throughout the pandemic taught us that those with the tools to adapt are in a much better place when the paradigm shift occurs. The pandemic changed things temporarily, once it was declared "over", the majority of education snapped back to normality.

AI is different. For one, we can see it coming. Developments are happening at pace, but there is at least time to think, time to test, and time to respond. We do get a little breather between each leap in capability.

There's also no way to put this genie back in the bottle. The idea of a moratorium on AI development is fanciful, and there's no possibility of a vaccine or herd immunity against the change that we'll witness over the next decade.

Let us not miss this opportunity. We owe this to the students that we serve, and we owe it even more to those without the resources and support at home to help them into this new world.

In the last few weeks, there's been some discussion on the DfE's "Cyber Security Scorecard" in the education press. More accurately, the discussion has focussed on the absence of any such scorecard in the light of several cyber security incidents this September.

It's no secret that the Education sector is plagued by cyber attacks, we consistently top the charts on Microsoft's Global Threat Activity dashboard with around 80% of all reported malware encounters. IT teams in education run on threadbare budgets, often operating under significant pressure and overseen by education or finance staff with little understanding of what a technical team needs to be successful. This isn't a slight against those professionals, merely an acknowledgement that a successful career as a teacher and then senior leader in a school doesn't provide the knowledge needed to create an environment where your IT team can succeed.

Some schools outsource their IT function altogether and, while that's a very sensible decision for small schools without the scale to run an in-house service, it doesn't really guarantee an improvement. In fact, most of the successful phishing attacks that I see from other schools come from schools with an outsourced IT function. I've taken over networks from outsourced IT companies where every single staff user had domain admin access to the network.

So it's clear that we have a problem. In my view though, it's not one of insufficient guidance. The DfE may not have launched the promised scorecard, but in October of 2022 they published the Cyber security standards for schools and colleges. These are part of a growing set of standards that give clear benchmarks to help us assess what we do. The NCSC also provides a library of resources to help schools understand and improve their cyber security position and has been publishing such advice for years. We have tools such as Mail Check, Microsoft's Secure Score, Google's security checklists, schemes like Cyber Essentials, and a raft of offerings from companies building and selling security products and services.

Another tool to assess our current position isn't going to achieve anything that previous tools (particularly the DfE standards) haven't already. If anything, I can see it being a distraction.

I wrote a piece for the ANME back in January of this year making the case that the DfE standards were an excellent tool to help raise the discussion around technology up to the level of leadership & executive teams. Your IT teams can't make much progress if the leaders in their organisations don't see what they're doing as important. Initiatives will be delayed, other projects will take precedence, over and over. If the implementation of Multi-Factor Authentication is on hold now because of other more pressing issues, it's likely to stay there.

Cyber Security is one of those classic "important, but not urgent" things, right up until something happens and it's too late. We need to create the space for these important tasks before the urgency comes calling. As a sector we have the guidance, we have the standards, it really is time for us to get to work.

Technical staff build and manage systems that, to those who don't know the trick, look like magic. When something goes wrong we often appear and resolve the issue, accompanied by some well practiced patter, and then vanish until we're next summoned.

This illusion creates a problem though. If the crowd are free to choose any trick they can think of for the magician to perform, and they truly believe in the magic, it's not going to be that long before the magician is asked to actually saw someone in half and put them back together.

Any sufficiently advanced technology is indistinguishable from magic.

- Arthur C. Clarke

"That's ridiculous" you might think, "we'd never ask a magician to really saw someone in half!". You're right, you probably wouldn't, but that's because you know it's a trick. Behind all of the showmanship, the well-practiced patter, the fancy out fist and the incomprehensible language, you know that the magician needs to have their routine prepared. They need to have practiced their art, to have the equipment ready, and to have carried out their routine in a specific order so that everyone is in the right place when the big reveal is made.

No matter how much it might look like magic, technology is not magic, it's technology.

Translate this analogy to the techies working to build you what you need. You know that your current problem could be solved by technology, and it would really help things if you could have your solution ready by the start of the year so that you can introduce it to everyone on the first training day, and have staff and students using it straight away. That leaves three weeks for your techies to work their magic, this should be fine, right?

Maybe...

Maybe it is fine, maybe this is a trick that your techies know already, or one that they've practiced before. Maybe they've not done something exactly like this before, but they've done something similar. They've definitely pulled something from a hat before...

... or maybe not.

Maybe it's a much tougher task to carry out than it looks when you see someone do it. Maybe it's possible, but only with some equipment that we don't have. Perhaps it's possible to achieve with an accomplice, but the accomplice is on holiday for the next two weeks and won't be able to practice enough before the show. Possibly, you could do it, but you'd have to stop preparing for the other show that's already planned You know, the big one? In the 50,000 seat arena?

At this point I fear that my analogy has run away with me! In all seriousness though, this is roughly what it's like to sit in the technical side of the fence. Of course, most people don't see our day-to-day work, so it's to be expected that there's sometimes a gap between what's asked and what's possible. I'll be writing more on that in the future, but for now, I want to lay out some initial actions we can all take to try and alleviate this problem.

For the education & business teams...

• Start talking about what you need early.

• Involve your techies in the design, tell them the problem you're trying to solve and listen to what they have to say.

• Be open to the suggestion that the solution might not be purely technical - It's likely you'll need to work with your techies to make sure that you get something that works.

• Understand that other projects might have to slide, and that might then mean you need to make further difficult choices.

• Ask what they need from you in order to have things ready and then make that your priority.

For the technical teams...

• Do your best to understand the problem you're trying to solve.

• Check your assumptions. Don't assume that a request for a "card trick" means that you have to have the selected card appear in a giant magical fireball.

• Ask about specifics. Does the card have to be the Ace of Clubs, or was that just plucked out as an example?

• Be clear about what you need, and what risks there are to the project.

• Understand how this request fits in to the rest of the show. What other links might be important?

It's my view that every organisation must have IT as a core competency in order to succeed, but this goes far beyond having a very good "magician". Technology offers us an incredible set of tools, and with them we can build wonders; but we have to understand one another or we'll never be able to put on a proper show.

In the world of IT services, we're responsible for planning and implementing change across the technology we manage, and the organisations in which we work. We're also responsible for supporting those affected by the changes we make.

Education is a really interesting sector for this. We have around 13 weeks every year where students aren't in school, and so it's quite easy for us to make changes during normal working hours without affecting many staff. It's actually one of the many benefits of the sector - no shift-work, no weekends on-call for the team.

So the temptation is to plan change for when the staff & students aren't around. That must be best, right? Minimise the disruption? Make the changes when the demand for support is at its lowest?

Well, sometimes...

The thing is, there's more than one type of disruption. With the hectic nature of staff & students returning from their holidays, it's easy to focus on the disruption caused by "carrying out the change", and completely overlook the disruption caused by "having changed things".

From an education & a business perspective, the Summer break is the worst time for IT changes that affect staff & students.

Simply put, the more we change during the holidays whilst people aren't around, the more change they have to adapt to at once. We have 6 weeks to make changes and staff have just one day to work out what we've done!

New terms are often when schools make changes on the business or education side of things too. Just when they're trying to focus on the new changes to how they do their role, they're also having to adapt to the changes that we've made too. In September everyone starts back at, pretty much, the same time. New staff have joined, old staff have left, there are new parents to meet, new students... the list goes on.

The primary currency that we're dealing with isn't (for once) the resource of our technical teams - it the capacity of everyone else to adapt to the change. By changing things during school holidays we place even more demand on that precious currency at the very point where we can least afford it.

Some systems changes can only be done out of hours, and school budgets often prevent the kind of twilight working that is more common in business. If you need to rip the building apart for a large recabling project, then the school holidays is perfect for this, but my suggestion is that we spend this currency deliberately, and sparingly.

From the perspective of the IT team, this also means that we don't have to delay everything until a the next big maintenance window, and then cram everything in. We can break down changes into smaller projects, plan them carefully, and prepare staff for them well. Then, we can execute them during term time.

Staff will have more capacity to keep up with the changes, you'll spread the workload for your support teams, and you'll be able to deal with any issues as they arise, rather than finding out that you missed something 2 weeks ago, and that a whole bunch of other things need to be re-done.

Yes, this process takes more planning, but planning is important:

If you don't have time to plan a change, you certainly don't have time to clean up after the change has gone wrong.

Give it a try with your next suitable project. One thing is for certain, your staff will appreciate coming back to systems that they know and then being around to see the changes happen. You never know, some of them might even thank you!

I've always thought that running events come in three varieties. The first are very casual. Turn up, grab your number, run, go home. The second persuasion of event is the sweet spot, enough of a challenge that you need to prepare, but there's a reasonable chance that, if things go well, you'll finish strong with a good time. The final category contains those races or times that are fanciful, frightening, and "not for the likes of me".

12 months ago, the Dragon Slayer Ultra would have sat firmly in that 3rd category - "not a chance".

In 2016 I ran a trail marathon in Switzerland, followed by a half marathon PB in 2017. Both of these achievements meant a lot to me. I'm not a quick runner, but both were outcomes of significant work over several years and, for that, they held some personal significance.

Following that though, running gradually declined. Life was busy and, with a couple of health issues (at that time unknown) I ended up taking a 6 year hiatus.

In January this year, things finally aligned such that a return to running was possible. I started with "Run Every Day" January, a habit that lasted in to early April, ran the Cloud 9 Hill Race in March, and then, feeling good, started to stretch the distance on training runs.

This is when a 55 km run in the Wye Valley started to look a lot more like a type 2 event (possible but challenging) rather than a type 3 event (hahaha, no). I'm very lucky to have a better half who also loves trail running, and a good friend who was also up for the challenge.

The three of us entered in May, leaving us around three months to build for the event. Training went mostly well and, on Sunday 6th August, we arrived at the start line ready.

The route was a natural one following the Wye Valley Walk for most of the outbound leg, skirting the Southern tip of Monmouth, and then returning to Chepstow along the Offa's Dyke footpath to finish in front of the castle.

We took things steady, walking most of the hills and trying to just keep moving. As Ultramarathons go, this was a baby one, however 55 km is still plenty for the uninitiated with amble opportunity for things to go wrong.

The weather was kind and, though I struggled a little with nutrition towards the end, we had a very successful day with a finish time of just over 7 hrs and 30 mins.

Our education system values grades far more than learning. AI might finally be the technology that forces us to address this.

Chat GPT was a breakthrough event for Artificial Intelligence in the public sphere. For those who've followed AI for the last several years this may have been less of a shock, but to those not watching closely, the beta release of Chat GPT was probably the first time that the term "AI" had tangible meaning.

Since it's release, Chat GPT has "passed" several law school exams, and medical exams, and stirred up a huge amount of hyperbole about the future of AI. Reading these two sources gives a more grounded take on what was actually achieved by Chat GPT, and what help was given by humans, but this is just a marker of what the current technology is capable of.

Google, in their latest blog post on AI, state that:

Today, the scale of the largest AI computations is doubling every six months, far outpacing Moore’s Law

Twitter is awash with educators showing how Chat GPT has saved them hours of time when planning lessons; and educational publications are full of articles, such as this one, opining on what this means for the teaching and learning profession.

All of this is interesting but, for me, there's a more fundamental issue that we need to think about.

AI is a challenge to what it means to have created something. If I enter a prompt in to DALL·E 2 and produce some incredible artwork, have I created it? If I produce an essay for an exam using Chat GPT, is the grade mine? What if I only use it for research? What if I only use it to ask one question about the phrasing of one sentence that I wrote?

Trying to detect AI and treat it as we currently handle cheating will just create an arms race that will incorrectly penalise students for "AI assistance" when there was none, and fail to detect "AI assistance" where it was used to excess.

Students value their grades over the methods by which they achieve them. This is because we value the outcome (the grade) far more than the process (the learning, understanding, and skills that our students develop). There are plenty of teachers that buck this trend, and many care passionately about process, but in UK education, they are swimming against the tide.

For this tide to change, we need to rethink what our exams actually assess, and how we educate, what skills we actually value, and what knowledge is important. This is a huge challenge, and I don't have the hubris to pretend that I know what this looks like, but we do need to start thinking about it. It's probable that AI will create such uncertainty over what was and was not done by a student that the validity of the current exams system will be reduced to zero.

AI presents us an opportunity to reconsider how we educate, prioritising learning and understanding over exam scores. Make no mistake, this would be a fundamental shift from primary school, right through to university and into the workplace. Are we up to the challenge?