[{"content":"A couple of things came up at work recently that I keep thinking about. Neither of them was broken, which is sort of the point.\nThe distribution list # We had an all-staff distribution list that ran off a dynamic filter. New starters get added, leavers drop off, nobody has to touch it. Which is great, until you realise nobody has looked at it in ages either.\nI got a ticket to tidy it up, so I exported the membership. It had shared mailboxes in it. Service accounts. A couple of people who\u0026rsquo;d already left.\nWhen I dug into why, the filter was basically \u0026ldquo;anyone with a mailbox and a job title.\u0026rdquo; Most real people have a job title, so that sort of works. But shared mailboxes and service accounts can have job titles too, and some of ours did. So in they went.\nThe filter wasn\u0026rsquo;t wrong exactly. It did what it was set up to do. It just wasn\u0026rsquo;t what everyone thought it was doing.\nAnd yeah, it\u0026rsquo;s only a distribution list. Worst case, a shared mailbox gets the Friday update. But if that same logic was deciding who could get into the finance share, I\u0026rsquo;d be a lot less relaxed about it.\nThe enrolment guide # The second one was a guide I was updating for setting up phones. Screenshots, steps, and a QR code that enrols the device into the organisation.\nIt\u0026rsquo;s a good guide. It works. Which is exactly the problem, because anyone who gets hold of a copy can enrol a device. It had been written as a how-to and was being passed around like any other Word doc, but really it\u0026rsquo;s closer to a key.\nNobody had done that on purpose. When you write a guide, you\u0026rsquo;re thinking about making it easy to follow. You\u0026rsquo;re not usually thinking about who else might end up following it.\nWhile I was in there I also noticed the token behind the QR code had a creation date that made me think it might have already expired. So the guide was potentially too powerful and potentially broken at the same time, and we wouldn\u0026rsquo;t have found out either way until someone tried to use it.\nWhat they had in common # Neither of these was a big deal on its own. But they\u0026rsquo;re the same kind of problem. Something gets set up, it seems to work, and from then on everyone just assumes it\u0026rsquo;s still fine. Nobody\u0026rsquo;s done anything wrong. It\u0026rsquo;s just that nobody\u0026rsquo;s checked.\nI\u0026rsquo;ve noticed I ask myself a few things now that I didn\u0026rsquo;t used to. What do we think this does? Is it actually doing that? And if someone asked, could we prove it?\nThe distribution list is a good example. If you\u0026rsquo;d asked anyone, they\u0026rsquo;d have said \u0026ldquo;leavers come off automatically.\u0026rdquo; Totally confident. But to actually know, someone had to export it and read through it. Until then it was just something we believed.\n\u0026ldquo;It\u0026rsquo;s fine, it\u0026rsquo;s automated\u0026rdquo; # I\u0026rsquo;ve said this. Probably more than once. A lot of support runs on that sort of confidence. \u0026ldquo;That group\u0026rsquo;s been right for years.\u0026rdquo; \u0026ldquo;Only IT has that doc.\u0026rdquo; \u0026ldquo;It\u0026rsquo;s on a schedule, it\u0026rsquo;ll be fine.\u0026rdquo;\nMost of the time it is fine. The problem is you don\u0026rsquo;t know which times it isn\u0026rsquo;t, and you won\u0026rsquo;t find out until something goes wrong.\nThere\u0026rsquo;s a difference between saying something is happening and being able to show it. \u0026ldquo;We check access regularly\u0026rdquo; is one thing. A dated list showing what was checked, what got removed and who did it is something else. I didn\u0026rsquo;t really think about that distinction until fairly recently, and now I see it everywhere.\nA lot of that has come from spending time with ISO 27001. It\u0026rsquo;s not that the standard told me anything I didn\u0026rsquo;t already half know. It\u0026rsquo;s more that it keeps coming back to the same question: how do you know? Once you start asking that about the stuff you look after every day, it\u0026rsquo;s hard to stop.\nWhat I do now # Nothing fancy. Mostly it\u0026rsquo;s just little habits.\nIf something\u0026rsquo;s automated, I look at what it actually produces rather than just reading how it\u0026rsquo;s configured. The config can look perfect and the output still be wrong.\nIf a document or link would let someone get in, enrol something, reset something or approve something, I treat it differently. It\u0026rsquo;s not really documentation at that point. I think about who actually needs it and where it lives, not just whether the steps are right.\nI check dates. Tokens, certificates, secrets, they all expire, usually at the worst possible moment. A guide that was right in March might not be now.\nAnd I write down what I found and what I changed. Partly for the next person, partly because if I can\u0026rsquo;t show I checked it, I\u0026rsquo;ve only really said I did.\nAnyway # Both fixes ended up being small. Tweak a filter, clear a few fields, lock a document down, sort out a new token. The hard bit was noticing in the first place, and that only happened because I exported a list and actually read it, instead of trusting it.\nThat\u0026rsquo;s probably the main thing I\u0026rsquo;d take from it. Automation\u0026rsquo;s brilliant, but it\u0026rsquo;s easy for it to become the reason nobody looks anymore.\nIf there\u0026rsquo;s something in your environment that everyone\u0026rsquo;s sure is fine, it might be worth a quick look. It probably is fine. But it\u0026rsquo;s nice to actually know.\n","date":"25 October 2026","externalUrl":null,"permalink":"/blog/acontrolnobodychecksisjustanassumption/","section":"Field Notes","summary":"Two small things that weren’t broken, and why ‘it’s automated’ isn’t the same as knowing it works.","title":"A Control Nobody Checks Is Just an Assumption","type":"blog"},{"content":"","date":"25 October 2026","externalUrl":null,"permalink":"/categories/blog/","section":"Categories","summary":"","title":"Blog","type":"categories"},{"content":"","date":"25 October 2026","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"25 October 2026","externalUrl":null,"permalink":"/tags/continual-improvement/","section":"Tags","summary":"","title":"Continual Improvement","type":"tags"},{"content":"Things I\u0026rsquo;ve learned through working in IT, from troubleshooting real problems to understanding the processes, services and people around them. Practical observations from the work, the things I\u0026rsquo;m studying, and figuring out what works in the real world.\n","date":"25 October 2026","externalUrl":null,"permalink":"/blog/","section":"Field Notes","summary":"Things I’ve learned through working in IT, from troubleshooting real problems to understanding the processes, services and people around them. Practical observations from the work, the things I’m studying, and figuring out what works in the real world.\n","title":"Field Notes","type":"blog"},{"content":"","date":"25 October 2026","externalUrl":null,"permalink":"/tags/information-security/","section":"Tags","summary":"","title":"Information Security","type":"tags"},{"content":"","date":"25 October 2026","externalUrl":null,"permalink":"/tags/it-support/","section":"Tags","summary":"","title":"IT Support","type":"tags"},{"content":"","date":"25 October 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"I\u0026rsquo;m That Bearded IT Guy. I work across Microsoft 365, Intune, Entra ID and day-to-day IT support, with a focus on understanding what is actually happening rather than just treating the symptom.\nThis site is where I document the things I work on, the projects I build, the things I\u0026rsquo;m learning and the lessons that come from working in IT.\n","date":"25 October 2026","externalUrl":null,"permalink":"/","section":"That Bearded IT Guy","summary":"I’m That Bearded IT Guy. I work across Microsoft 365, Intune, Entra ID and day-to-day IT support, with a focus on understanding what is actually happening rather than just treating the symptom.\nThis site is where I document the things I work on, the projects I build, the things I’m learning and the lessons that come from working in IT.\n","title":"That Bearded IT Guy","type":"page"},{"content":"","date":"2 September 2026","externalUrl":null,"permalink":"/tags/jml/","section":"Tags","summary":"","title":"JML","type":"tags"},{"content":"","date":"2 September 2026","externalUrl":null,"permalink":"/tags/service-management/","section":"Tags","summary":"","title":"Service Management","type":"tags"},{"content":"There\u0026rsquo;s a natural tendency when improving an IT process to add things.\nAdd another check. Add another approval. Add another step. Add another bit of information.\nIt makes sense. If something is missing, you add it.\nBut sometimes the better improvement is to remove something.\nI\u0026rsquo;ve recently reviewed and cleaned up a fair bit of documentation, comparing how the documented process actually reflected the process in place. One of the documents that stood out to me was a Joiner, Mover and Leaver process, and how much old information can build up over time.\nNot because anyone has done anything wrong.\nThe environment just changes.\nThe process can change without the document changing # IT environments don\u0026rsquo;t stand still. Systems get replaced, platforms get retired, responsibilities move between teams and the way people access services changes. Things that were once essential can eventually become irrelevant.\nThe problem is that documentation doesn\u0026rsquo;t always change at the same speed.\nYou can end up with a process containing instructions for systems or actions that haven\u0026rsquo;t been relevant for a long time. The document still exists and it still looks reasonably complete, but parts of it no longer describe what actually happens.\nThat\u0026rsquo;s what I found when reviewing the JML documentation. There were legacy steps relating to systems and administration that were no longer relevant to the current environment.\nThey didn\u0026rsquo;t need improving.\nThey needed removing.\n\u0026ldquo;Just ignore that step\u0026rdquo; isn\u0026rsquo;t really a solution # One option when you find old documentation is to leave the step there and add a note.\nSomething like:\nThis step is no longer required.\nThat technically tells the reader what to do. But it still leaves the old instruction sitting in the middle of the process.\nNow someone has to read it, understand that it doesn\u0026rsquo;t apply, and remember to ignore it. That\u0026rsquo;s not really simplifying the process. It\u0026rsquo;s just adding another decision for the person following it.\nIf a step genuinely isn\u0026rsquo;t required anymore, I\u0026rsquo;d rather remove it.\nThe person following the process shouldn\u0026rsquo;t have to know the history of the environment to understand what they\u0026rsquo;re supposed to do today.\nJML is a good example # Joiner, Mover and Leaver processes can involve multiple systems, teams and types of access. A new starter needs the right accounts and equipment. Someone changing roles may need their existing access reviewed. Someone leaving will need their access removed and equipment dealt with appropriately.\nThere are already enough moving parts without adding instructions that no longer apply.\nIf an engineer is working through a leaver process and the documentation tells them to perform an action in a system that isn\u0026rsquo;t used anymore, that\u0026rsquo;s unnecessary friction.\nThey might know to ignore it. Someone new to the environment might not. They might spend time looking for the system, asking someone else, or wondering whether they\u0026rsquo;ve missed something.\nNone of that is a major incident, but it\u0026rsquo;s wasted time. Repeated often enough, small amounts of friction start to matter.\nSometimes removing something is the improvement # This is something I\u0026rsquo;ve started to appreciate more as I\u0026rsquo;ve gained experience.\nImprovement doesn\u0026rsquo;t always have to be visible as something new. Sometimes the improvement is that something unnecessary isn\u0026rsquo;t there anymore.\nThere\u0026rsquo;s a natural instinct to make documentation more detailed when we\u0026rsquo;re trying to make it better. But a useful question when reviewing a process is:\nWhat can we remove?\nDoes this step still exist because it is needed, or because it has always been there?\nIf it\u0026rsquo;s needed, keep it. If it\u0026rsquo;s changed, update it. If it isn\u0026rsquo;t needed anymore, remove it.\nThat doesn\u0026rsquo;t mean removing things just to make a process shorter. You still need to understand why something exists before deciding it can go.\nA step might look unnecessary but have a good reason behind it. That\u0026rsquo;s why reviewing the process itself matters, rather than simply editing the document.\nThere\u0026rsquo;s a service impact too # It\u0026rsquo;s easy to think of JML as an internal administrative process, but there\u0026rsquo;s a service behind it.\nA joiner needs to be ready to work. A mover needs the right access for their role. A leaver needs their access dealt with appropriately.\nThe people affected by those changes don\u0026rsquo;t particularly care what the internal process looks like. They just need the outcome to happen properly.\nThat means the process supporting it needs to be clear, accurate and usable by the people carrying it out, especially in a support environment where different engineers may handle the same type of request.\nSometimes improvement is smaller than you think # I think this is something I\u0026rsquo;ve started to appreciate more as I\u0026rsquo;ve gained experience in IT support.\nWhen you hear \u0026ldquo;improvement\u0026rdquo;, it\u0026rsquo;s easy to imagine a big project, a new system or a complete redesign of how something works.\nIt doesn\u0026rsquo;t always have to be that.\nSometimes you notice that something isn\u0026rsquo;t quite right, work out why, make a sensible change and leave things a little better than you found them.\nThat\u0026rsquo;s essentially what this piece of work felt like. There wasn\u0026rsquo;t a need to reinvent the JML process. It just needed some of the history taken out of it.\nIt\u0026rsquo;s another example of how my view of support has changed # Earlier in my IT career, I probably would have looked at a process and thought about whether I could follow it to complete the task.\nNow I\u0026rsquo;m more interested in the process itself.\nDoes it make sense? Does it reflect the environment? Is there anything unnecessary? Would someone else know what to do?\nAnd perhaps most importantly:\nAre we doing something because it is actually needed, or because we\u0026rsquo;ve always done it that way?\nI don\u0026rsquo;t think every process needs constant attention. But environments change, and processes need to keep up with them.\nSometimes that means adding something. Sometimes it means changing something. And sometimes, the best improvement is simply removing something that no longer belongs there.\nA few old steps disappear. The process becomes a little clearer. The next engineer has less to work out.\nIt might not look like a big change, but if it makes the work easier and more consistent, I\u0026rsquo;d count that as a worthwhile improvement.\nSometimes good IT service management isn\u0026rsquo;t about doing more.\nSometimes it\u0026rsquo;s about making sure we\u0026rsquo;re only doing what still needs to be done.\n","date":"2 September 2026","externalUrl":null,"permalink":"/blog/sometimesimprovingaprocessmeansremovingthings/","section":"Field Notes","summary":"Why sometimes the best way to improve an IT process is to remove the things that only add unnecessary complexity.","title":"Sometimes Improving a Process Means Removing Things","type":"blog"},{"content":" Summary # This site itself is one of my projects. It\u0026rsquo;s a static site built with Hugo, using the Blowfish theme as a base, with the source sitting in a GitHub repository. Every time I push a change to the main branch, a GitHub Actions workflow builds the site and the finished result ends up live on Hostinger within a minute or two, with no manual upload step in between.\nI picked this setup over a full CMS or a drag-and-drop website builder for a few reasons. I wanted something lightweight to maintain long term, rather than a heavier platform with a database and an admin panel to keep patched and secure. I wanted the entire site, content included, to be version-controlled from day one, so nothing exists in a single unrecoverable place. And I wanted writing a new article to mean adding a text file and pushing it, not logging into a separate system every time.\nIt also meant I could build the whole thing without paying for anything beyond a domain name and a fairly basic hosting plan, since Hugo doesn\u0026rsquo;t need a server running behind it. It just needs somewhere to serve the plain HTML, CSS and JavaScript it produces.\nThe rest of this write-up covers the process I actually followed, including a full follow-along section at the end for anyone who wants to set up the same GitHub-to-Hostinger auto-deploy pipeline for their own Hugo site.\nStack # Hugo, a static site generator that turns markdown content and Go templates into plain HTML at build time, rather than generating pages on every request Blowfish, an open-source Hugo theme, added as a Git submodule and customised through site-level overrides rather than by editing the theme directly Git and GitHub, used both for version control of the source and as the trigger for the deployment pipeline GitHub Actions, to install Hugo, build the site, and publish the compiled output to a dedicated branch on every push Hostinger, connected to that dedicated build branch through its Git integration, watching it for new commits and deploying automatically Follow-Along Guide # 1. Decide what the site actually needs to do # Before touching any tooling, I worked out what the site was for: somewhere to write about IT, document a few homelab projects, and give a quick overview of my background. That decided the sections I\u0026rsquo;d need later, a home page, a blog, a projects area and an about page, rather than trying to work that out once I was already halfway through building something.\n2. Install Hugo and scaffold a new site # Hugo is a single binary with no dependencies to install separately. Once it\u0026rsquo;s installed, scaffolding a new site takes one command:\nhugo new site mysite cd mysite git init This gives you a working project structure straight away: folders for content, layouts, static assets, and configuration, all ready to be filled in.\n3. Add a theme as a Git submodule # I added Blowfish as a submodule rather than downloading and copying its files into my own repository:\ngit submodule add https://github.com/nunocoracao/blowfish.git themes/blowfish Keeping the theme as a submodule means it stays cleanly separated from my own content and configuration, and I can pull in theme updates later without that update touching anything I\u0026rsquo;ve written myself. Most themes, Blowfish included, ship with example configuration you can copy in as a starting point rather than configuring everything from a blank file.\n4. Plan the content structure before writing anything # I set up the top-level sections next: content/en/blog, content/en/projects, and a couple of standalone pages for home and about. Getting this in place before writing meant every article had an obvious home as soon as I started writing it, rather than deciding where things belonged after the fact.\n5. Write real content before customising the design # I wrote several blog posts using the theme\u0026rsquo;s default styling before changing anything visually. That confirmed two things early: that I actually had enough to say, and that I enjoyed the process of writing it. Once there was real content in place, the visual decisions that followed were much easier, because I was designing around actual pages rather than guessing at layouts for content that didn\u0026rsquo;t exist yet.\n6. Push the source to GitHub # Once there was something worth keeping, I created a repository on GitHub and pushed the project to it:\ngit add . git commit -m \u0026#34;Initial site content\u0026#34; git branch -M main git remote add origin https://github.com/yourusername/yourrepo.git git push -u origin main From this point, main holds the actual Hugo source, the content, templates, configuration and the theme submodule reference, not the finished website. That distinction matters for the next part.\n7. Add a GitHub Actions workflow to build the site automatically # Hugo needs a build step to turn that source into the plain HTML a browser can actually display, and Hostinger\u0026rsquo;s own Git integration deploys whatever is committed to a branch without running a build command itself. So rather than deploying the raw source, I set up a GitHub Actions workflow that builds the site on every push to main and publishes the result to a separate branch, which I called build.\nThe workflow file lives at .github/workflows/deploy.yml:\nname: Build and deploy site on: push: branches: - main jobs: build: runs-on: ubuntu-latest steps: - name: Checkout repository uses: actions/checkout@v4 with: submodules: recursive - name: Setup Hugo uses: peaceiris/actions-hugo@v3 with: hugo-version: \u0026#34;latest\u0026#34; extended: true - name: Build site run: hugo --minify --gc - name: Publish build output to build branch uses: s0/git-publish-subdir-action@develop env: REPO: self BRANCH: build FOLDER: public GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} MESSAGE: \u0026#34;Build: ({sha}) {msg}\u0026#34; A quick rundown of what each part does: checkout pulls the repository, including the Blowfish submodule; the Hugo setup step installs the extended version of Hugo, which Blowfish needs for its Sass/SCSS processing; the build step runs Hugo itself, producing a public folder full of finished HTML, CSS and JS; and the last step pushes just that public folder to the build branch, using the token GitHub provides automatically, so no separate credentials need setting up.\nAfter this is in place, every push to main results in a fresh, built version of the site landing on the build branch a short while later, with the source and the compiled output kept clearly separate.\n8. Connect the build branch to Hostinger # With the build branch producing a real, finished site on every push, the last piece is telling Hostinger to watch it:\nIn hPanel, go to Websites, select your site, and open its Dashboard. In the sidebar, go to Advanced → Git. Click Continue with GitHub and authorise the Hostinger GitHub App when prompted. Choose the repository from the list, refreshing it if it doesn\u0026rsquo;t appear straight away. Set the branch to build, the one the Actions workflow publishes to, not main. Leave the deploy directory as public_html unless you have a reason to target a subfolder. Click Deploy to run the first deployment. Once that initial deployment finishes, Hostinger sets up a webhook on the repository behind the scenes. From then on, any new commit that lands on the build branch triggers an automatic redeployment, no manual step required. Since the Actions workflow is what puts new commits on that branch, the end-to-end effect is that pushing to main is enough to update the live site a minute or two later.\nThe Deployments tab in the same panel shows a history of what\u0026rsquo;s been deployed, including commit references and timestamps, and there\u0026rsquo;s a manual Redeploy button if you ever need to force a redeploy without a new commit.\n9. Customise the theme through overrides, not by editing it directly # Where I needed something the theme didn\u0026rsquo;t do out of the box, I added site-level template overrides in my own layouts/ folder rather than editing Blowfish\u0026rsquo;s files directly. Hugo automatically prefers a site-level template over the theme\u0026rsquo;s version of the same file, which means theme updates continue to work normally rather than silently wiping out my own changes.\n10. Test properly before calling anything finished # Before treating a change as done, I checked it on a phone as well as a desktop, in both light and dark mode, and on the actual pages affected rather than just the home page. A good few small fixes, spacing, image sizing, contrast in dark mode, only turned up once I actually looked properly rather than assuming a change that looked fine in one place looked fine everywhere.\n11. Keep iterating after launch # The site went live before it was \u0026ldquo;finished\u0026rdquo;, and I don\u0026rsquo;t think it\u0026rsquo;s finished now either. I keep coming back to adjust layout, fix things that only became obvious once real content was in place, and add new sections as the site grows. The auto-deploy pipeline makes that easy, since every one of those changes is just a normal commit and push away from being live.\nLessons Learned # Write real content before customising the design. It\u0026rsquo;s far easier to design around something real than to guess at layouts for content that doesn\u0026rsquo;t exist yet.\nKeep the theme as a submodule and customise through overrides rather than editing it directly, so pulling in theme updates doesn\u0026rsquo;t undo your own work.\nDeploy a built, static output rather than raw source. Hostinger\u0026rsquo;s Git integration deploys whatever is on the branch you point it at, so a dedicated build branch keeps the messy source separate from the finished site.\nPublish early rather than waiting for a finished version. A live site you keep improving beats a perfect one that never leaves your laptop.\nTest on more than your own screen and your own colour scheme before calling something done.\nWhat\u0026rsquo;s Next # I want to add a proper preview step before changes go live, so I can catch issues on a draft build before they reach the real site rather than after. Longer term, I\u0026rsquo;d like to tie that into the homelab setup I\u0026rsquo;ve written about elsewhere, running checks on my own infrastructure rather than relying entirely on the hosting provider\u0026rsquo;s pipeline.\n","date":"30 August 2026","externalUrl":null,"permalink":"/projects/building-this-website-with-hugo/","section":"Projects","summary":"How I planned, built and published this site using Hugo, the Blowfish theme, GitHub and Hostinger, with a full follow-along guide to set up the same auto-deploying pipeline yourself.","title":"Building This Website With Hugo and Blowfish","type":"projects"},{"content":"","date":"30 August 2026","externalUrl":null,"permalink":"/tags/hugo/","section":"Tags","summary":"","title":"Hugo","type":"tags"},{"content":"","date":"30 August 2026","externalUrl":null,"permalink":"/categories/projects/","section":"Categories","summary":"","title":"Projects","type":"categories"},{"content":"","date":"30 August 2026","externalUrl":null,"permalink":"/projects/","section":"Projects","summary":"","title":"Projects","type":"projects"},{"content":"","date":"30 August 2026","externalUrl":null,"permalink":"/tags/self-hosting/","section":"Tags","summary":"","title":"Self-Hosting","type":"tags"},{"content":"","date":"30 August 2026","externalUrl":null,"permalink":"/tags/web-development/","section":"Tags","summary":"","title":"Web Development","type":"tags"},{"content":"When I first moved into IT support, a lot of the job seemed fairly straightforward in my head.\nSomething was broken.\nFind out why. Fix it. Move on to the next one.\nThat\u0026rsquo;s still a big part of what I do.\nIf someone\u0026rsquo;s laptop isn\u0026rsquo;t working, they need their laptop working. If they can\u0026rsquo;t access something they need for work, that needs sorting. If Outlook has stopped behaving, they aren\u0026rsquo;t particularly interested in my thoughts on service management.\nThey need Outlook working.\nThat\u0026rsquo;s the reality of support, and restoring service matters.\nBut I\u0026rsquo;ve started thinking a little more about what happens after the immediate problem has been fixed.\nWhat if it keeps happening? # This is where things get more interesting for me. If I fix something once, that\u0026rsquo;s useful.\nIf I fix the same thing three times, I start wondering whether there is something else going on.\nMaybe the underlying technical issue hasn\u0026rsquo;t really been addressed. Maybe the process around it is causing the problem. Maybe the documentation isn\u0026rsquo;t clear. Maybe the same mistake keeps being made. Maybe there is a dependency that nobody has documented.\nThere are plenty of possibilities, and I don\u0026rsquo;t think you can assume you know the answer straight away.\nThe important part is noticing the pattern. If something keeps coming back, the individual ticket is telling you something.\nDocumentation was one of the things that changed my thinking # I\u0026rsquo;ve worked on documentation where the written process no longer matched what was actually happening.\nAt first glance, that can seem like a fairly minor problem. But if someone is following an outdated process, they can waste time, follow steps that no longer apply or create another problem further down the line.\nI\u0026rsquo;ve seen this particularly through work on Joiner, Mover and Leaver documentation, where I helped remove legacy steps that no longer reflected the way the environment was actually being managed.\nThe immediate task was updating the documentation.\nBut there was something bigger behind it.\nThe information people rely on is part of the process. If it\u0026rsquo;s wrong, the process isn\u0026rsquo;t working as well as it should.\nThat made me think differently about documentation. It\u0026rsquo;s not just something you write down after the work is finished. It can directly affect how the work gets done.\nThis is one of the reasons I\u0026rsquo;ve enjoyed studying ITIL v5 alongside working in support.\nI was already noticing recurring issues, documentation gaps and processes that didn\u0026rsquo;t always match reality. The courses gave me a way of understanding those observations.\nThere is obviously a place for restoring service and dealing with the immediate incident. But there is also value in stepping back and asking whether something needs to improve.\nI don\u0026rsquo;t think that means turning every ticket into a formal problem-management exercise.\nSometimes noticing something and raising it with the right person is enough. Sometimes the improvement is simply updating a document. Sometimes there is nothing worth changing at all.\nFor me, the useful part is having the mindset to recognise the difference.\nI\u0026rsquo;ve started seeing more of the service around the ticket # This is probably the biggest change in how I think about support.\nA ticket doesn\u0026rsquo;t exist on its own. There is a person raising it.\nThere is a process behind it.\nThere might be a team responsible for the service.\nThere might be another team responsible for part of the technology.\nThere are systems, information, policies and dependencies involved.\nThe technical fault is only one part of the picture.\nWorking in an MSP environment has probably reinforced that for me because I\u0026rsquo;ve seen a lot of different customer environments and different ways of working.\nThe same type of technical problem can have a completely different context depending on the customer, the users affected and the service involved.\nYou have to understand the environment you\u0026rsquo;re actually dealing with. That has also changed the way I think about the work I do myself.\nIf I\u0026rsquo;m investigating an issue, I\u0026rsquo;m not only thinking about what will make the error disappear. I\u0026rsquo;m also thinking about whether the information I\u0026rsquo;m leaving behind will help the next person, whether the issue is likely to return and whether there is anything about the process that is making the problem harder than it needs to be.\nI\u0026rsquo;m not always going to find something that needs changing.\nBut I\u0026rsquo;m more likely to notice it now.\nI don\u0026rsquo;t think every problem needs a big answer # This is important because it\u0026rsquo;s easy to take the idea too far.\nSometimes the answer really is:\nFix the thing and move on.\nNot everything needs a process review. Not every repeat issue needs a project. Not every documentation gap needs a new system.\nSometimes you just need to update a page, improve a knowledge article or tell someone what happened.\nThe point isn\u0026rsquo;t to make everything bigger.\nIt\u0026rsquo;s to recognise when there is an opportunity to make something better and decide whether that improvement is actually worth doing.\nI\u0026rsquo;ve found that to be a much more practical way of looking at continual improvement.\nYou don\u0026rsquo;t need to improve everything. You need to notice what could be improved and make a sensible decision about it.\nI\u0026rsquo;m still a technical support engineer # This hasn\u0026rsquo;t changed.\nI still troubleshoot devices. I still investigate Microsoft 365 issues. I still work with Entra ID and Intune.\nI still deal with printers, access problems, applications and all the other things that turn up during a normal week.\nI\u0026rsquo;m not trying to move away from the practical side of IT.\nThat practical experience is the foundation for everything else I\u0026rsquo;m learning.\nWhat has changed is that I\u0026rsquo;m increasingly interested in what sits around the technical problem.\nWhy does this keep happening? Could we make this clearer? Is the process actually helping? What information are we missing? Could the service work better?\nThose are questions I probably wouldn\u0026rsquo;t have thought about in quite the same way when I first moved into IT.\nNow I find myself asking them more often. And I think that\u0026rsquo;s a good thing.\nI\u0026rsquo;m still fixing the problem in front of me.\nI\u0026rsquo;m just getting more interested in understanding what happens around it.\n","date":"28 August 2026","externalUrl":null,"permalink":"/blog/fromfixingproblemstoaskingwhytheykeephappening/","section":"Field Notes","summary":"How my thinking has developed from fixing individual issues to looking at the service around them.","title":"From Fixing Problems to Asking Why They Keep Happening","type":"blog"},{"content":"","date":"23 August 2026","externalUrl":null,"permalink":"/tags/itil/","section":"Tags","summary":"","title":"ITIL","type":"tags"},{"content":"","date":"23 August 2026","externalUrl":null,"permalink":"/tags/learning/","section":"Tags","summary":"","title":"Learning","type":"tags"},{"content":"I\u0026rsquo;ve completed ITIL v5 Foundation, Strategy and Product now, and one of the things I\u0026rsquo;ve found most useful about the courses is that I\u0026rsquo;m able to relate quite a lot of the material back to things I\u0026rsquo;ve already experienced in IT support.\nI\u0026rsquo;m not saying I\u0026rsquo;ve suddenly become a service management expert because I\u0026rsquo;ve completed a few courses. I haven\u0026rsquo;t. A lot of what I\u0026rsquo;ve learned is still theory that I haven\u0026rsquo;t had the opportunity to apply in a formal service management role.\nWhat I do have is a few years of practical experience to compare it against.\nThat\u0026rsquo;s probably why the learning has been useful to me. I\u0026rsquo;m not learning the concepts in complete isolation. I\u0026rsquo;ll come across something in the course and think about a ticket I\u0026rsquo;ve worked on, a customer visit I\u0026rsquo;ve been involved in, a process I\u0026rsquo;ve had to document or an issue that kept coming back.\nSometimes the course gives me a better way of understanding something I\u0026rsquo;ve already seen.\nI\u0026rsquo;ve started thinking more about the outcome # One of the things that has stuck with me is the difference between doing something and actually creating a useful outcome.\nIn IT support, it\u0026rsquo;s very easy to focus on the activity in front of you. A ticket comes in, you investigate it, you fix the issue and you close the ticket.\nThat\u0026rsquo;s obviously important. If someone can\u0026rsquo;t work because something isn\u0026rsquo;t functioning properly, getting them back up and running is the immediate priority.\nBut I\u0026rsquo;ve found myself thinking a little more about what happens around that.\nDid we actually restore what the person needed? Was the fix appropriate? Did we understand what caused the problem? Is there something useful we should record? Is this likely to happen again?\nThat\u0026rsquo;s where the idea of value co-creation made more sense to me.\nThe value isn\u0026rsquo;t created by the IT team simply completing an activity. There is a relationship between the people providing the service and the people using it, and both sides contribute to the outcome.\nI\u0026rsquo;ve seen this in quite ordinary support situations.\nA user can explain what they\u0026rsquo;re trying to achieve in a way that gives you information you wouldn\u0026rsquo;t get from the ticket alone. An engineer can investigate the technical side, but the user understands the impact on their work. Putting those two things together gives you a much better chance of reaching the right outcome.\nIt\u0026rsquo;s made me think less about \u0026ldquo;closing the ticket\u0026rdquo; as the end of the story and more about whether we\u0026rsquo;ve actually achieved what was needed.\nThe four dimensions helped me look beyond the technology # The four dimensions were another part of the course that I found easy to relate back to real work.\nWorking in IT support, it\u0026rsquo;s natural to spend most of your time thinking about technology. If a device isn\u0026rsquo;t compliant, you look at the device. If someone can\u0026rsquo;t sign in, you look at authentication. If an application isn\u0026rsquo;t working, you start investigating the application.\nBut the technology is only one part of what makes a service work.\nThere are people and organisations involved. There is information and technology. There are partners and suppliers. There are value streams and processes.\nI\u0026rsquo;ve seen examples of all of these in my own work.\nA technical problem can sometimes be made harder by a process that isn\u0026rsquo;t clear. An escalation can be delayed because the right information hasn\u0026rsquo;t been captured. A customer issue can be more difficult to understand because the technical description doesn\u0026rsquo;t really explain the impact on the person trying to work.\nNone of those are purely technical problems.\nThat doesn\u0026rsquo;t mean every support issue needs to become a service-management exercise. It just means I\u0026rsquo;ve become more aware that the technology I\u0026rsquo;m troubleshooting is sitting inside a much bigger system.\nValue streams made me look at what happens between the ticket being raised and the outcome # This is probably one of the areas I\u0026rsquo;ve found most interesting.\nWhen you\u0026rsquo;re working on a ticket, you\u0026rsquo;re naturally focused on the part of the process in front of you.\nA user raises something. I pick it up. I investigate it. Maybe I resolve it, or maybe it needs to go to another team.\nBut there is a lot happening around that ticket.\nInformation has to be gathered. Someone has to decide what needs to happen next. There might be an approval. Another team might need to investigate something. The issue might come back because the original information wasn\u0026rsquo;t enough.\nWhen you look at the whole flow, you start to see where work can get slowed down.\nI\u0026rsquo;ve experienced that through escalations and through working across different customer environments. Sometimes the technical issue itself isn\u0026rsquo;t particularly difficult. The difficult part is getting the right information to the right person, understanding ownership or working out what needs to happen next.\nThat\u0026rsquo;s what I find interesting about looking at the value stream.\nYou stop looking only at your part of the process and start asking whether the whole thing is working well.\nContinual improvement doesn\u0026rsquo;t have to mean rebuilding everything # Continual improvement is another area where the theory connected quite easily with things I\u0026rsquo;ve already done.\nWhen you hear the word \u0026ldquo;improvement\u0026rdquo;, it\u0026rsquo;s tempting to imagine a big project with a new system, a new process and months of planning.\nIt doesn\u0026rsquo;t always need to be like that.\nI\u0026rsquo;ve worked on documentation where the existing information no longer matched the way the process actually worked. In that situation, the improvement wasn\u0026rsquo;t some huge transformation programme. It was looking at what was there, understanding what had changed and making the information more useful.\nI\u0026rsquo;ve also seen recurring issues where the useful question isn\u0026rsquo;t just how to fix the individual ticket, but whether there is something that could be changed to reduce the chance of the same issue happening again.\nSometimes the answer will be no.\nSometimes the issue is unavoidable.\nSometimes the improvement is simply making a knowledge article clearer or making an escalation contain better information.\nI like that approach because it feels practical.\nYou don\u0026rsquo;t need to make everything bigger than it needs to be in order to improve it.\nStrategy made me think more about why the service exists in the first place # The Strategy course was probably the point where I started thinking more about IT beyond the immediate support activity.\nWhen you\u0026rsquo;re working in support, it\u0026rsquo;s easy to focus on whether something is working.\nBut services exist for a reason.\nThey\u0026rsquo;re there to enable people and organisations to achieve something.\nIf a system is unreliable, if users can\u0026rsquo;t access something they need or if a process constantly creates delays, that eventually has an impact beyond the individual support ticket.\nI\u0026rsquo;ve seen this from the support side.\nYou can resolve the immediate issue, but there can still be a wider effect on the customer or the organisation.\nI\u0026rsquo;m not involved in setting organisational strategy in my current role, and I wouldn\u0026rsquo;t claim that I am. What the course has done is make me more aware of the connection between the work happening at the support level and the outcomes the wider organisation is trying to achieve.\nThat\u0026rsquo;s a useful perspective to have.\nProduct made me think about services as things that need to be looked after # The Product course built on some of this for me.\nI found myself thinking more about the fact that a product or service isn\u0026rsquo;t something that can simply be created, handed over and forgotten about.\nThe environment changes.\nTechnology changes.\nPeople\u0026rsquo;s needs change.\nRequirements change.\nThe way people use something can change as well.\nThat means there needs to be some thought about how the service continues to provide value as those things change.\nAgain, I\u0026rsquo;ve seen smaller versions of this in support.\nDocumentation becomes outdated.\nA process changes.\nA device configuration needs to be reviewed.\nA workaround that was useful six months ago is no longer appropriate.\nThose things don\u0026rsquo;t necessarily look like \u0026ldquo;product management\u0026rdquo; when you\u0026rsquo;re dealing with them on a Tuesday afternoon, but the underlying idea is there. Things need to be looked after and reviewed rather than assuming that because something works today, it will always work tomorrow.\nThe biggest thing ITIL has given me is a different way of looking at work # I think that\u0026rsquo;s probably my biggest takeaway from the courses.\nI haven\u0026rsquo;t suddenly started approaching every ticket by thinking about ITIL terminology.\nIf anything, I\u0026rsquo;d find that quite frustrating.\nWhat has changed is the questions I sometimes ask myself while I\u0026rsquo;m doing the work.\nIs this actually achieving the outcome the user needs?\nWhy does this keep happening?\nWhere is this work getting stuck?\nIs the process helping or getting in the way?\nDoes the person I\u0026rsquo;m handing this over to have what they need?\nIs there something we could improve?\nAre we creating value for the people using the service?\nThose questions are useful even if you never use the ITIL terminology.\nThe framework just gives me a better way of understanding why those questions matter.\nI\u0026rsquo;m still learning # There is still a big difference between studying service management and spending years working in a formal service management role.\nI\u0026rsquo;m conscious of that.\nWhat I can say is that studying ITIL v5 has changed the way I look at the work I\u0026rsquo;m already doing.\nI\u0026rsquo;m still troubleshooting devices, investigating Microsoft 365 issues, working with Entra ID and Intune, supporting users and dealing with the practical problems that turn up in an IT support environment.\nThat hasn\u0026rsquo;t changed.\nWhat has changed is that I\u0026rsquo;m increasingly aware of the service around those individual problems.\nFor me, that\u0026rsquo;s the useful combination.\nThe practical experience gives me something real to relate the learning to, and the learning gives me a better way of thinking about what I\u0026rsquo;m seeing.\nI think that\u0026rsquo;s a much more useful outcome than simply having another certificate on the wall. For me, that\u0026rsquo;s the useful combination.\n","date":"23 August 2026","externalUrl":null,"permalink":"/blog/whatiactuallytookawayfromitilv5/","section":"Field Notes","summary":"The parts of ITIL v5 that have actually changed how I think about my day-to-day work.","title":"What I Actually Took Away From ITIL v5","type":"blog"},{"content":"","date":"18 August 2026","externalUrl":null,"permalink":"/tags/iso-27001/","section":"Tags","summary":"","title":"ISO 27001","type":"tags"},{"content":"I\u0026rsquo;ve spent the last few years working in IT support, and over that time I\u0026rsquo;ve become increasingly interested in the parts of IT that sit behind the technology itself.\nWhen I first moved into IT, my focus was naturally on the technical side. Getting users back up and running, troubleshooting devices, working through Microsoft 365 issues and understanding why something wasn\u0026rsquo;t behaving as expected. That\u0026rsquo;s still a big part of what I do, and I enjoy it.\nBut the more experience I\u0026rsquo;ve gained, the more I\u0026rsquo;ve started paying attention to what sits around those technical problems.\nHow is something actually being managed? Why does a particular process work the way it does? Who is responsible for it? What happens when the documented process doesn\u0026rsquo;t match what people are actually doing? How do you know that the controls you have in place are doing what you expect them to do?\nThat\u0026rsquo;s where my interest in ISO 27001 has come from.\nIt\u0026rsquo;s more than the technology # Working in IT, it\u0026rsquo;s very easy to think about security in terms of the technology in front of you. MFA, Conditional Access, device compliance, permissions, endpoint controls and logging are all things I work with as part of my normal role.\nThey\u0026rsquo;re important, but they\u0026rsquo;re only part of the picture.\nThe technology sits inside a much wider environment of people, processes, information and responsibilities. A technical control can be configured correctly and still not achieve what you expect if the process around it isn\u0026rsquo;t clear, or if nobody really understands who is responsible for maintaining it.\nThat\u0026rsquo;s one of the things I find interesting about information security.\nIt\u0026rsquo;s not simply about finding the right setting in a portal. There is a much bigger question around how an organisation understands and manages its information and the risks associated with it.\nRisk is the part that really interests me # I\u0026rsquo;m still learning about this, so I\u0026rsquo;m not going to pretend I have years of information security or GRC experience behind me.\nWhat I do find interesting is the idea of understanding risk properly rather than simply reacting to individual problems.\nWhat are we actually trying to protect? What could affect it? What would the impact be? What controls do we already have? Are those controls appropriate? Are they actually working? And perhaps most importantly, how do we know?\nThose questions feel quite natural to me because they are not completely separate from the way I already approach troubleshooting.\nWhen something doesn\u0026rsquo;t work, I don\u0026rsquo;t want to immediately start changing things. I want to understand what is happening first. I\u0026rsquo;ll look at the available evidence, work through what I can establish and then decide what needs to happen.\nI\u0026rsquo;m finding that I have a similar interest in the security side of things. Understand the situation first, then work out what needs to be done about it.\nI\u0026rsquo;ve already seen some of this in my day-to-day work # I\u0026rsquo;m not implementing ISO 27001 in my current role, and I wouldn\u0026rsquo;t claim that I am.\nWhat I have done is work with areas that have made me more interested in the wider subject.\nI regularly deal with identity and access, device compliance, authentication, Conditional Access and audit information. I\u0026rsquo;ve also worked on documentation and processes where the information available no longer matched the way something was actually being done.\nOne example was reviewing Joiner, Mover and Leaver documentation and removing legacy steps that no longer reflected the current environment.\nThat was a relatively practical piece of work, but I found myself thinking about the wider process rather than just editing the document. Why was the process written that way in the first place? Which parts were still relevant? What information did someone actually need to complete the task properly?\nThat sort of thing has made me more interested in the relationship between technology, process and control.\nThis is also where my ITIL studies have helped # I\u0026rsquo;ve spent a lot of time recently working through ITIL v5, including Foundation, Strategy and Product.\nI\u0026rsquo;m not trying to turn everything I do into an ITIL exercise, but studying service management has changed the way I look at some of the work I\u0026rsquo;m already doing.\nIt has made me more conscious of things like outcomes, processes, value, dependencies and continual improvement. It has also made me more interested in what happens around an individual technical issue rather than just the issue itself.\nThat way of thinking connects quite naturally with what I\u0026rsquo;m finding interesting about information security.\nA problem doesn\u0026rsquo;t always exist in isolation. There is usually something around it that explains why it happened, how it is managed and what could be done differently.\nI\u0026rsquo;m working towards ISO 27001 # This is an area I\u0026rsquo;m genuinely interested in developing in, which is why I\u0026rsquo;m working towards further ISO 27001 training.\nI\u0026rsquo;m particularly interested in understanding the standard properly rather than simply collecting another qualification. I want to understand how an information security management system works in practice, how organisations approach risk, how controls are selected and managed, and how you can use evidence to understand whether things are actually working.\nI\u0026rsquo;m also interested in the auditing side of it because there is something I find appealing about looking at what an organisation says it does and then being able to establish what is actually happening.\nThat is still something I\u0026rsquo;m learning about rather than something I currently do professionally, and I think it\u0026rsquo;s important to make that distinction.\nWhy I think it suits the way I work # The more I learn about ISO 27001, the more I can see why it interests me.\nI like understanding how things work. I like looking for gaps. I like working through evidence rather than making assumptions, and I like the idea of improving something rather than simply accepting that it has always been done that way.\nThat doesn\u0026rsquo;t mean every problem needs a complicated process or another document.\nSometimes the right answer is very simple.\nBut I think there is real value in being able to look at something and ask whether it is working as intended, whether the risks are understood and whether there is evidence to support what we believe is happening.\nThat\u0026rsquo;s the part of ISO 27001 that interests me. I\u0026rsquo;m still learning it, and I have plenty more to learn.\nBut it\u0026rsquo;s an area that genuinely interests me, and I\u0026rsquo;m looking forward to seeing where that learning takes me.\n","date":"18 August 2026","externalUrl":null,"permalink":"/blog/whyiminterestediniso27001/","section":"Field Notes","summary":"Why information security and ISO 27001 have become areas I’m genuinely interested in learning about.","title":"Why I'm Interested in ISO 27001","type":"blog"},{"content":"","date":"21 July 2026","externalUrl":null,"permalink":"/tags/documentation/","section":"Tags","summary":"","title":"Documentation","type":"tags"},{"content":"Documentation is probably one of those parts of IT that everyone agrees is important, but it isn\u0026rsquo;t always the first thing that gets done.\nThere\u0026rsquo;s usually something more immediate.\nA user has a problem. Something needs investigating. A device needs rebuilding. Someone needs access. A customer needs support.\nYou fix the thing, the user is happy and the ticket moves on.\nThen you remember that the documentation probably needs updating.\nEarlier in my IT career, I probably saw documentation as something to deal with after the work was finished.\nThe more I\u0026rsquo;ve worked with processes and documentation, the more I\u0026rsquo;ve realised that it is actually part of the work.\nI\u0026rsquo;ve seen what happens when documentation doesn\u0026rsquo;t match reality # One of the better examples of this for me has been working on Joiner, Mover and Leaver documentation.\nThe existing process contained legacy steps relating to systems and administration that were no longer part of the current environment.\nOn paper, the process was there. The problem was that parts of it no longer reflected what actually happened.\nSomeone who doesn\u0026rsquo;t know the environment very well could follow the document exactly as written and still end up doing something that isn\u0026rsquo;t relevant anymore.\nThe document hadn\u0026rsquo;t necessarily failed because it was badly written. It had failed because the environment changed and the information didn\u0026rsquo;t keep up.\nThat was useful to see first-hand. It made the importance of keeping information current much more obvious to me.\nWriting something down can expose problems # There\u0026rsquo;s another thing I\u0026rsquo;ve noticed when working through processes.\nSometimes you don\u0026rsquo;t realise something is unclear until you try to explain it.\nYou start writing down the steps and suddenly find yourself asking questions.\nWhat happens before this? Who is responsible for this part? Does another team need to do something first? Where does this information come from? What happens if that step doesn\u0026rsquo;t work?\nThose questions can reveal that the problem isn\u0026rsquo;t necessarily the documentation. It might be the process itself.\nThat\u0026rsquo;s what I find interesting about documenting work. It can force you to look at how something actually happens, rather than how you think it happens.\nWorking in an MSP makes that even more important # The other reason I\u0026rsquo;ve become more conscious of this is the environment I work in.\nI\u0026rsquo;m supporting different customers, technologies and ways of working. I\u0026rsquo;m not always going to be the person dealing with the same issue next time. Someone else might pick it up.\nA different team might need to understand what has already happened.\nI might not even remember the details of something I worked on several months ago.\nUseful documentation gives the next person somewhere to start.\nIt doesn\u0026rsquo;t replace experience, and it doesn\u0026rsquo;t mean every possible scenario needs to be written down.\nIt just means useful knowledge shouldn\u0026rsquo;t exist only in someone\u0026rsquo;s head.\nWhat makes documentation useful? # I\u0026rsquo;ve seen documents that technically contain the information you need, but finding the useful part isn\u0026rsquo;t particularly easy.\nI\u0026rsquo;ve also seen information that was accurate when it was written but became less useful as the environment changed.\nFor me, the question has gradually become much simpler: If I needed to do this tomorrow and had never done it before, would this actually help me?\nIf the answer is yes, it\u0026rsquo;s probably doing its job.\nIf the answer is no, it probably needs some attention.\nThat doesn\u0026rsquo;t mean every document needs to be rewritten from scratch.\nSometimes it\u0026rsquo;s a small change.\nRemove an old step. Clarify something. Add the information people keep asking for. Make the order of the process clearer. Point someone towards the system or team they actually need.\nSmall changes can make a document considerably more useful.\nDocumentation is part of the work # This is probably the biggest change in how I think about it.\nIf I\u0026rsquo;m investigating an issue and discover something that another engineer would benefit from knowing, that\u0026rsquo;s part of the work.\nIf I\u0026rsquo;m reviewing a process and find that some of the information is no longer accurate, fixing that is part of the work.\nIf I\u0026rsquo;ve had to work something out that isn\u0026rsquo;t documented anywhere, there\u0026rsquo;s probably some value in leaving that information behind.\nThe person dealing with the problem next time shouldn\u0026rsquo;t necessarily have to repeat the same investigation just because I happened to be the person who found the answer first.\nITIL has given me a better way of looking at it # My ITIL studies have given me a better framework for understanding something I\u0026rsquo;d already experienced in practice: useful knowledge needs to be available when it\u0026rsquo;s needed.\nWhen information is clear and current, it makes the work easier.\nWhen it isn\u0026rsquo;t, people spend time trying to work out what should already be known.\nI don\u0026rsquo;t need to think about ITIL terminology every time I update something. It\u0026rsquo;s just something I\u0026rsquo;ve experienced through the work.\nThe course has given me a better way of understanding why it matters.\nI\u0026rsquo;m not trying to document everything # There\u0026rsquo;s a danger of going too far with this. I don\u0026rsquo;t think every task needs a ten-page procedure.\nSometimes the useful information is a few lines. Sometimes it\u0026rsquo;s a checklist. Sometimes it\u0026rsquo;s a knowledge article. Sometimes it\u0026rsquo;s simply making sure the right person knows where something is recorded.\nThe important thing is that it helps the person who needs it.\nI\u0026rsquo;d much rather have a short, accurate document that someone actually uses than a huge document that nobody wants to read.\nThe technical fix isn\u0026rsquo;t always the end # When I first moved into IT, I was mainly thinking about solving the problem in front of me.\nThat\u0026rsquo;s still important.\nBut now, if I\u0026rsquo;ve had to work something out, or I\u0026rsquo;ve noticed that a process doesn\u0026rsquo;t quite match reality, I\u0026rsquo;m more likely to think about what should happen with that information afterwards.\nShould it be documented? Does something existing need changing? Would another engineer benefit from knowing this? Is there a wider process issue behind the problem?\nSometimes the answer will be no.\nSometimes it\u0026rsquo;s just a small update.\nBut I think that\u0026rsquo;s the difference for me.\nDocumentation isn\u0026rsquo;t something I want to produce just because I\u0026rsquo;m supposed to.\nI want useful information to be there when someone needs it, so the work is easier and the next person doesn\u0026rsquo;t have to start from zero.\nThe technical fix might solve today\u0026rsquo;s problem.\nGood documentation can make tomorrow\u0026rsquo;s problem a little easier.\n","date":"21 July 2026","externalUrl":null,"permalink":"/blog/documentationisntjustsomethingyouwriteaftertheworkscomplete/","section":"Field Notes","summary":"Why useful, current documentation is part of delivering a good service.","title":"Documentation Isn't Just Something You Write After the Work's Complete","type":"blog"},{"content":"","date":"7 July 2026","externalUrl":null,"permalink":"/tags/evidence/","section":"Tags","summary":"","title":"Evidence","type":"tags"},{"content":"One of the easiest traps in IT support is assuming that the first description of a problem is the problem itself.\nI\u0026rsquo;ve done it.\nIt\u0026rsquo;s very easy to read a ticket, see a familiar symptom and immediately start thinking about what you believe the cause is.\nThe problem is that the person raising the ticket is describing what they are experiencing. They aren\u0026rsquo;t necessarily describing what is happening underneath.\nThat distinction has become something I\u0026rsquo;m much more conscious of as I\u0026rsquo;ve gained experience in support.\nThe ticket is someone\u0026rsquo;s view of the problem # When someone raises a ticket saying they can\u0026rsquo;t sign in, that\u0026rsquo;s useful information.\nThey\u0026rsquo;re telling me what they\u0026rsquo;re experiencing.\nThey\u0026rsquo;re not necessarily expected to know whether the problem is authentication, Conditional Access, device compliance, licensing or something else. That\u0026rsquo;s part of what I\u0026rsquo;m there to investigate.\nThere\u0026rsquo;s a difference between:\nI can\u0026rsquo;t sign in.\nand:\nThe sign-in attempt is being blocked by a specific Conditional Access policy.\nThe first tells me about the user\u0026rsquo;s experience.\nThe second is something I\u0026rsquo;ve established through investigation.\nGetting from one to the other is where the actual troubleshooting starts.\nI saw this with a Conditional Access issue # I\u0026rsquo;ve had an authentication issue where the initial symptom looked like a fairly general access problem.\nFrom the user\u0026rsquo;s perspective, they simply couldn\u0026rsquo;t sign in.\nThere are quite a few possible reasons for that, so rather than assuming it was an account or application problem, I looked at the Entra sign-in information.\nThat changed the picture.\nThe sign-in information showed that a specific Conditional Access policy was responsible for the request being blocked. In this case, it was the blocked-countries policy.\nThat was much more useful than simply knowing the user couldn\u0026rsquo;t sign in.\nIt gave me something concrete to work with and explained why the sign-in was being denied.\nThe important part wasn\u0026rsquo;t that I knew the name of the policy beforehand.\nI didn\u0026rsquo;t need to.\nThe investigation gave me the answer.\nThe same thing happened with an Excel issue # I had a similar experience with an Excel co-authoring issue.\nThe initial problem was straightforward enough. Users were trying to work on a workbook together and the co-authoring behaviour wasn\u0026rsquo;t working as expected.\nThere were plenty of things that could potentially have caused that.\nIt could have been related to the Microsoft 365 service, permissions, the user\u0026rsquo;s device, the Office client or something about the file itself.\nRather than immediately changing something, I looked more closely at the workbook.\nIt was an .xlsb file.\nConverting it to .xlsx resolved the issue.\nThe fix itself was simple.\nThe investigation was what established that it was the file format that mattered.\nAgain, the original ticket wasn\u0026rsquo;t wrong.\nThe users really couldn\u0026rsquo;t co-author the workbook.\nIt just didn\u0026rsquo;t tell me why.\nThat\u0026rsquo;s why I like working from evidence # The more I\u0026rsquo;ve worked in support, the more I\u0026rsquo;ve tried to separate two things in my head.\nWhat is the user experiencing?\nAnd what is the system telling me?\nBoth are important.\nThe user gives me the context and the impact. They can tell me what they were trying to achieve, what happened and whether something has changed.\nThe technical information helps me understand what is actually happening underneath.\nIf I only look at one side, I\u0026rsquo;m missing part of the picture.\nThis is particularly useful when dealing with things like authentication and device issues, where the visible symptom can be fairly generic but the underlying reason can be much more specific.\nIt also stops me getting too attached to my first idea # If someone tells me their laptop can\u0026rsquo;t access an application, there are plenty of things I could immediately start checking.\nI could look at the network.\nI could look at the application.\nI could look at the device.\nI could look at the user\u0026rsquo;s account.\nI could look at Conditional Access.\nBut I don\u0026rsquo;t know which one matters until I have something to support that direction.\nSo I try to start with relatively simple questions.\nWhat actually works?\nWhat doesn\u0026rsquo;t?\nIs it only this user?\nIs it only this device?\nDoes the same thing happen somewhere else?\nHas anything changed?\nWhat does the relevant log show?\nEach answer gives me another piece of information.\nSometimes it confirms the direction I was already thinking about.\nSometimes it sends me somewhere completely different.\nSometimes your first assumption is right # There\u0026rsquo;s nothing wrong with having an initial theory.\nIf I have seen a particular type of issue before, it makes sense that I might have an idea about where to start.\nIf I think something might be related to DNS and the testing supports that, that\u0026rsquo;s useful.\nIf I think a device compliance issue might be responsible and the device state confirms it, that\u0026rsquo;s useful too.\nThe problem isn\u0026rsquo;t having an assumption.\nThe problem is treating the assumption as the answer before you\u0026rsquo;ve checked it.\nI\u0026rsquo;ve found it much more useful to be willing to change direction when the evidence doesn\u0026rsquo;t support my first thought.\nThat\u0026rsquo;s part of troubleshooting.\nYou start somewhere, you test it, you learn something and then you decide where to go next.\nThe investigation is useful even when someone else needs to fix it # This is also where it connects with the way I approach escalations.\nSometimes I\u0026rsquo;ll investigate an issue as far as I can and find that another team needs to take it further.\nThat\u0026rsquo;s fine.\nThe work I\u0026rsquo;ve already done still has value.\nIf I\u0026rsquo;ve established that the user can access the service from one device but not another, that\u0026rsquo;s useful.\nIf I\u0026rsquo;ve found a Conditional Access result that explains why authentication is being blocked, that\u0026rsquo;s useful.\nIf I\u0026rsquo;ve tested something and ruled it out, that\u0026rsquo;s useful too.\nIt means the next team isn\u0026rsquo;t just receiving the original symptom.\nThey\u0026rsquo;re receiving part of the investigation.\nThat\u0026rsquo;s one of the reasons I think evidence-led troubleshooting and good escalation go together.\nDocumentation means the investigation doesn\u0026rsquo;t have to disappear # If I\u0026rsquo;ve worked through something that could be useful again, I want the important parts recorded.\nThat doesn\u0026rsquo;t mean writing a ten-page document every time something goes wrong.\nSometimes the useful information is simply the cause, the resolution and a couple of checks that helped identify it.\nI\u0026rsquo;ve become more conscious of this through the documentation and knowledge work I\u0026rsquo;ve done.\nIf the same issue appears again, having something useful to refer back to can save time.\nIt can also help another engineer understand what happened without having to repeat the entire investigation.\nAnd sometimes recording something helps reveal a pattern that wasn\u0026rsquo;t obvious from one ticket alone.\nThe first description is still important # I don\u0026rsquo;t think the answer is to distrust tickets or assume that users don\u0026rsquo;t know what they\u0026rsquo;re talking about.\nQuite the opposite.\nThe user\u0026rsquo;s description is where the investigation starts.\nThey\u0026rsquo;re the person experiencing the problem, so their description of what happened and what they were trying to do is important.\nI just don\u0026rsquo;t want that description to become the diagnosis automatically.\nThe user might say they can\u0026rsquo;t sign in.\nThe evidence might show a Conditional Access policy blocking them.\nThey might say Excel co-authoring isn\u0026rsquo;t working.\nThe investigation might show that the file format is the problem.\nBoth users described their problems accurately.\nThe investigation simply gave me a better understanding of what was happening underneath.\nWhat I\u0026rsquo;ve taken from this # I\u0026rsquo;ve become much more comfortable with the idea that I don\u0026rsquo;t need to know the answer immediately.\nI need to know how to find it.\nThat means starting with the user\u0026rsquo;s experience, gathering the relevant information, testing what I can and being prepared to change direction when the evidence points somewhere else.\nSometimes the first idea will be right.\nSometimes it won\u0026rsquo;t.\nEither way, the important thing is that the investigation is based on what you can actually establish rather than what you think is probably happening.\nThe ticket tells me where to start.\nThe evidence tells me where to go next.\n","date":"7 July 2026","externalUrl":null,"permalink":"/blog/thetickettoldmeonethingtheevidencetoldmeanother/","section":"Field Notes","summary":"Why the first description of a problem is the starting point, not always the diagnosis.","title":"The Ticket Told Me One Thing. The Evidence Told Me Another.","type":"blog"},{"content":"","date":"7 July 2026","externalUrl":null,"permalink":"/tags/troubleshooting/","section":"Tags","summary":"","title":"Troubleshooting","type":"tags"},{"content":"","date":"3 July 2026","externalUrl":null,"permalink":"/tags/docker/","section":"Tags","summary":"","title":"Docker","type":"tags"},{"content":"","date":"3 July 2026","externalUrl":null,"permalink":"/tags/homelab/","section":"Tags","summary":"","title":"Homelab","type":"tags"},{"content":"","date":"3 July 2026","externalUrl":null,"permalink":"/tags/plex/","section":"Tags","summary":"","title":"Plex","type":"tags"},{"content":" Summary # Plex was one of the first real services I deployed once Docker was running, and honestly the original reason I built the homelab in the first place.\nIt runs as a container alongside everything else, pulling media from a dedicated storage share. Genuinely useful way to get comfortable with hardware transcoding, volume mounts, and network configuration, all of which map onto broader self-hosting skills.\nStack # Docker container running the official Plex Media Server image A dedicated storage volume for media, kept separate from the container itself Network configured for local access, with remote access handled carefully rather than just opened wide Follow-Along Guide # 1. Plan your storage layout before deploying anything # Decide where your media is actually going to live before you deploy the container. I keep media on a separate mounted volume from the Docker host\u0026rsquo;s own disk, so the container itself stays disposable and the media survives even if I rebuild the container from scratch.\nmkdir -p /mnt/media/{movies,tv,music} 2. Create the compose file # services: plex: image: plexinc/pms-docker:latest restart: unless-stopped network_mode: host environment: - PUID=1000 - PGID=1000 - TZ=Europe/London volumes: - ./config:/config - /mnt/media:/media Using network_mode: host avoids some of the local network discovery headaches Plex can have behind Docker\u0026rsquo;s default bridge networking, at the cost of a bit less network isolation. Worth the trade-off for a homelab.\n3. Deploy the container # docker compose up -d 4. Complete setup through the web UI # Access Plex at http://\u0026lt;vm-ip\u0026gt;:32400/web and step through the setup wizard: sign in, name your server, and add your media libraries pointing at the mounted paths from inside the container, /media/movies, /media/tv, and so on.\n5. Set up hardware transcoding if your hardware supports it # If your host has an iGPU capable of hardware transcoding, passing it through to the container significantly reduces CPU load when streaming to devices that need the stream transcoded rather than played back natively. Needs the device passed through at both the Proxmox VM config level and the Docker container level, so worth doing once storage and basic playback are already confirmed working.\n6. Be deliberate about remote access # Plex offers built-in remote access, which is convenient but worth understanding before switching on. I run it through my reverse proxy with access restricted rather than exposing the Plex port directly to the internet. Partly for security, partly because it gave me a reason to actually learn reverse proxy configuration properly rather than skipping it.\nLessons Learned # Keep media storage separate from the container so rebuilding the container doesn\u0026rsquo;t touch the media itself.\nnetwork_mode: host solves more local discovery problems than it causes issues, for a homelab context specifically.\nHardware transcoding is worth the setup effort if your CPU would otherwise be doing the work.\nDon\u0026rsquo;t expose ports directly to the internet without thinking it through first. Route through something you control.\nWhat\u0026rsquo;s Next # Want to add proper monitoring around transcoding load and storage usage. Likely feeding into the same dashboard I\u0026rsquo;m building out for the rest of the homelab, so there\u0026rsquo;s one place to see the health of everything rather than checking each service individually.\n","date":"3 July 2026","externalUrl":null,"permalink":"/projects/plex-media-server-setup/","section":"Projects","summary":"How I deployed Plex as a Docker container on my Proxmox homelab, with a full follow-along guide.","title":"Setting Up Plex on My Homelab","type":"projects"},{"content":" Summary # Once Proxmox was running, the next decision was how to actually deploy the services I wanted to self-host. Plex, a reverse proxy, a handful of small utilities.\nRather than a full VM for each one, I run a single lightweight Ubuntu VM and deploy everything inside it as Docker containers, managed through Compose. Each service is isolated. Easy to update independently. Easy to tear down and rebuild without touching anything else running alongside it.\nTurned out to be a genuinely good way to practice change management thinking on a small scale too. Every container is its own blast radius. If an update to one breaks something, it doesn\u0026rsquo;t take the others with it. Rolling back is usually just pulling the previous image tag.\nStack # Ubuntu Server VM running on Proxmox Docker Engine and Docker Compose Portainer for a web UI to manage containers without living in the CLI full time A reverse proxy container (I use Caddy) to handle routing and HTTPS certificates for services Follow-Along Guide # 1. Provision the VM # Create a new Ubuntu Server VM in Proxmox with a reasonable baseline: 2 vCPUs, 4GB RAM, and 32GB disk is enough to start, scaling up if you add more services later. Install Ubuntu Server as normal and apply updates.\n2. Install Docker # sudo apt update sudo apt install -y ca-certificates curl gnupg sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg echo \u0026#34;deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release \u0026amp;\u0026amp; echo \u0026#34;$VERSION_CODENAME\u0026#34;) stable\u0026#34; | sudo tee /etc/apt/sources.list.d/docker.list \u0026gt; /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin Add your user to the docker group so you\u0026rsquo;re not prefixing every command with sudo:\nsudo usermod -aG docker $USER Log out and back in for that to take effect.\n3. Set up a project structure # I keep each service in its own directory with its own docker-compose.yml, rather than one giant compose file for everything. Keeps updates and rollbacks scoped to a single service.\nmkdir -p ~/docker/portainer cd ~/docker/portainer 4. Deploy Portainer first # Portainer gives you a web UI over Docker itself, which makes managing the rest of the stack much easier than pure CLI, especially early on.\nservices: portainer: image: portainer/portainer-ce:latest restart: unless-stopped ports: - \u0026#34;9443:9443\u0026#34; volumes: - /var/run/docker.sock:/var/run/docker.sock - portainer_data:/data volumes: portainer_data: docker compose up -d Access it at https://\u0026lt;vm-ip\u0026gt;:9443 to finish setup.\n5. Add a reverse proxy # For anything you want accessible with a proper domain and HTTPS rather than an IP and a port number, a reverse proxy is worth setting up early rather than bolting it on later once you\u0026rsquo;ve got a dozen services to retrofit.\n6. Deploy services one at a time # Add new services the same way. Their own directory, their own compose file, tested individually before moving on. That\u0026rsquo;s where the isolation really pays off. If a new service\u0026rsquo;s compose file has an issue, it doesn\u0026rsquo;t affect anything already running.\nLessons Learned # One compose file per service rather than one giant stack file. Keeps updates and rollbacks scoped properly.\nSet up Portainer early. Makes the rest of the process considerably less painful.\nNamed volumes over bind mounts where possible. Migrating a named volume to new hardware later is simpler.\nTest each new service in isolation before assuming it\u0026rsquo;ll play nicely alongside everything else.\nWhat\u0026rsquo;s Next # Want to move from manually running docker compose up per service toward proper GitOps. Compose files in a Git repo, deployed automatically, tying into the same GitHub Actions pipeline I\u0026rsquo;m planning for this site.\n","date":"27 June 2026","externalUrl":null,"permalink":"/projects/docker-homelab-services/","section":"Projects","summary":"How I moved my homelab services into Docker containers on top of Proxmox, with a follow-along guide to set it up yourself.","title":"Running My Homelab Services in Docker","type":"projects"},{"content":"","date":"23 June 2026","externalUrl":null,"permalink":"/tags/field-support/","section":"Tags","summary":"","title":"Field Support","type":"tags"},{"content":"","date":"23 June 2026","externalUrl":null,"permalink":"/tags/service-delivery/","section":"Tags","summary":"","title":"Service Delivery","type":"tags"},{"content":"A lot of IT support can be done without physically being in the same place as the user.\nI\u0026rsquo;ve spent plenty of time working remotely, and for a lot of issues that\u0026rsquo;s exactly what you want. You can look at logs, check device information, investigate Microsoft 365 services, work through Intune or Entra ID and speak to the user without ever leaving your desk.\nBut working on-site is different.\nI\u0026rsquo;ve regularly been trusted to act as the lead engineer during customer visits, sometimes as the only engineer on-site. Over time, I\u0026rsquo;ve found that being physically in the environment gives you a different perspective on the work.\nYou\u0026rsquo;re not just looking at the ticket anymore.\nYou\u0026rsquo;re seeing the environment that the ticket came from.\nYou see things that aren\u0026rsquo;t in the ticket # A ticket is usually a very small description of a much bigger situation.\nIt might tell me that a user can\u0026rsquo;t access something, that a device isn\u0026rsquo;t working or that an application has a problem.\nWhen I\u0026rsquo;m on-site, I can see what is actually happening around that issue.\nI can see where the device is being used, how the user is interacting with it and whether there is anything else going on nearby that might be relevant.\nSometimes it\u0026rsquo;s something obvious, like a physical issue that wouldn\u0026rsquo;t be visible remotely. Other times it\u0026rsquo;s much less obvious. You might notice that several people are having similar problems, or that something about the environment doesn\u0026rsquo;t quite match what the original ticket suggested.\nThose details aren\u0026rsquo;t always available when you\u0026rsquo;re working remotely.\nPeople explain problems differently when they\u0026rsquo;re standing next to you # I\u0026rsquo;ve found this particularly useful.\nA user might put \u0026ldquo;Outlook isn\u0026rsquo;t working\u0026rdquo; into a ticket, which doesn\u0026rsquo;t give you much to go on.\nWhen you\u0026rsquo;re actually sitting beside them, you can ask them to show you what they\u0026rsquo;re doing.\nThat\u0026rsquo;s often when the problem becomes clearer.\nYou can see the exact point where something goes wrong. You can ask what they were expecting to happen. You can find out whether it has always worked that way or whether something has changed.\nIt also gives the user a chance to explain the problem in their own words rather than trying to translate it into technical language for a ticket.\nThat conversation can sometimes tell you more than the original ticket ever could.\nBeing the engineer on-site changes the responsibility # When I\u0026rsquo;m the sole engineer on-site, I\u0026rsquo;m not simply there to work through a predefined list of tickets.\nThere might be planned work for the visit, but there will usually be other things that come up as well.\nA user might need help with something unexpected. A device might have a problem. Something might need escalating. A piece of work might take longer than expected.\nYou have to make decisions about what needs attention and what can wait.\nThat doesn\u0026rsquo;t mean making every decision yourself. In fact, knowing when something needs to go to another team is just as important.\nWhat I try to do is take responsibility for the issue while I\u0026rsquo;m there, even if I\u0026rsquo;m not the person who ultimately fixes it.\nIf I can\u0026rsquo;t resolve something on-site, I want the investigation to be useful and the handover to give the next team enough information to continue.\nYou have to be comfortable working things out # Being the only engineer on-site also means you don\u0026rsquo;t always have someone sitting next to you who can immediately give you the answer.\nThat\u0026rsquo;s actually something I\u0026rsquo;ve come to enjoy.\nIt means I have to think through the problem myself.\nWhat do I know?\nWhat don\u0026rsquo;t I know?\nWhat can I check?\nIs this something I can resolve here?\nDoes it need another team?\nWhat information will they need if I escalate it?\nThat doesn\u0026rsquo;t mean I expect myself to know everything. I don\u0026rsquo;t.\nIT is too broad for that.\nBeing able to recognise when you don\u0026rsquo;t know something, investigate it properly and then find the right person or resource is much more useful than pretending you already have the answer.\nSite visits also expose the difference between a process and the real world # This is probably one of the things I\u0026rsquo;ve found most interesting about being on-site.\nA process can look completely reasonable when you read it on paper.\nThen you actually have to use it with a real person, in a real environment, with the constraints that happen to exist that day.\nThat\u0026rsquo;s when you start noticing things.\nMaybe a step isn\u0026rsquo;t clear. Maybe the documentation is out of date. Maybe there is something happening in the environment that the process doesn\u0026rsquo;t account for. Maybe the process itself works fine, but the information needed to complete it is difficult to find.\nI\u0026rsquo;ve come across enough of this in my work to become much more interested in documentation and process improvement.\nIt doesn\u0026rsquo;t automatically mean the process is bad.\nSometimes it just needs to be made clearer or brought back in line with what is actually happening.\nSupporting wider technical and project teams # Some of the on-site work I\u0026rsquo;ve been involved in has also meant supporting teams outside of the immediate service desk function.\nFor example, I\u0026rsquo;ve supported project teams during customer deployments and other pieces of planned technical work by providing an on-site presence. That can involve readiness checks, helping users, dealing with issues as they appear, carrying out triage and making sure anything that needs further investigation gets back to the right team.\nI think there is real value in having someone on-site during this sort of work.\nThe project team might be responsible for delivering the technical change, but the person on the ground is often the one dealing with the practical reality of what happens when that change meets the users and the environment.\nSometimes everything goes to plan. Sometimes it doesn\u0026rsquo;t.\nWhen something unexpected comes up, being there means I can investigate it, resolve what I can and provide the project team with useful information about what is actually happening rather than simply passing on a problem.\nI\u0026rsquo;ve found that this kind of work gives me a good appreciation of how different parts of IT need to work together. The service desk, project teams, technical teams and the customer all have their own responsibilities, but ultimately they\u0026rsquo;re working towards the same outcome.\nSometimes the quickest way to understand a problem is to see it # I\u0026rsquo;ve had plenty of situations where investigating something remotely has been enough.\nBut I\u0026rsquo;ve also had situations where being there makes the difference.\nYou can see the setup.\nYou can talk to the person.\nYou can reproduce the issue yourself.\nYou can notice things that wouldn\u0026rsquo;t necessarily make it into a ticket.\nThat\u0026rsquo;s particularly useful when you\u0026rsquo;re dealing with problems that are difficult to describe.\nA user might not know which technical detail is important, and that\u0026rsquo;s completely understandable. They\u0026rsquo;re trying to get their work done, not diagnose the issue for me.\nPart of my job is working out which details matter.\nBeing on-site gives me a lot more of those details to work with.\nIt has changed how I think about support # I think this is probably the biggest thing I\u0026rsquo;ve taken from customer site work.\nWhen you\u0026rsquo;re working remotely, it can be easy to become focused on the ticket and the technology.\nBeing on-site reminds you that there is always a person and a working environment behind it.\nThe laptop isn\u0026rsquo;t just a laptop.\nThe application isn\u0026rsquo;t just an application.\nIf something isn\u0026rsquo;t working, someone is usually trying to do something with it.\nThat doesn\u0026rsquo;t mean you should ignore the technical side. You still need to investigate properly and find the right solution.\nBut understanding the impact makes the work more meaningful.\nIt has also made me more interested in the service around the technology # This connects quite naturally with the service-management learning I\u0026rsquo;ve been doing.\nI\u0026rsquo;m increasingly interested in what happens around the technical problem.\nWhy did the issue happen?\nIs the process clear?\nDoes the documentation help?\nWas the right information available?\nCould something be improved?\nDoes the person using the service actually get the outcome they need?\nI don\u0026rsquo;t think every site visit needs to turn into a process review. Most of the time, you fix the problem and get on with the day.\nBut when you start noticing the same gaps or patterns, those observations are useful.\nThat\u0026rsquo;s where I think on-site support gives you a perspective that you don\u0026rsquo;t always get from a service desk queue.\nWhat I\u0026rsquo;ve learned from being on-site # Being on-site hasn\u0026rsquo;t necessarily made me a better engineer because I\u0026rsquo;ve learned a load of new commands.\nIt\u0026rsquo;s helped me become better at understanding the bigger picture.\nI have to communicate with users, make decisions, manage competing priorities, investigate problems and know when to involve someone else.\nI\u0026rsquo;ve also learned that taking ownership doesn\u0026rsquo;t necessarily mean personally fixing everything.\nSometimes ownership means getting the right information, involving the right team and making sure the issue doesn\u0026rsquo;t simply disappear into another queue.\nThat\u0026rsquo;s probably the biggest lesson I\u0026rsquo;ve taken from being the engineer on-site.\nRemote support is incredibly useful, and a huge amount of IT can be done perfectly well from behind a screen.\nBut sometimes you need to see the environment, talk to the person and experience the service from their side.\nThat\u0026rsquo;s when a ticket starts to become something a bit more real.\n","date":"23 June 2026","externalUrl":null,"permalink":"/blog/whatchangeswhenyouretheengineeronsite/","section":"Field Notes","summary":"What I’ve learned from being the engineer responsible for customer support on-site.","title":"What Changes When You're the Engineer on Site","type":"blog"},{"content":"","date":"20 June 2026","externalUrl":null,"permalink":"/tags/proxmox/","section":"Tags","summary":"","title":"Proxmox","type":"tags"},{"content":" Summary # Proxmox VE is the foundation everything else in my homelab sits on. A free, Debian-based hypervisor. Lets me run multiple VMs and containers on a single box, with a proper web interface instead of SSH-only tinkering.\nI run it on a repurposed mini PC. It now hosts my Docker containers, my Plex server, and a few test environments I use for practicing things I write about on the blog.\nI picked it over alternatives like ESXi mainly because it\u0026rsquo;s genuinely free, no feature-gated licensing, and it gave me hands-on exposure to virtualisation concepts that translate directly to enterprise environments.\nStack # Mini PC host (any reasonably modern x86 box with virtualisation extensions enabled in BIOS) Proxmox VE (latest stable release) A USB drive for the installer A second drive or partition for VM storage, separate from the boot drive if possible Follow-Along Guide # 1. Prepare the installer # Download the Proxmox VE ISO from the official site and flash it to a USB drive using a tool like Balena Etcher or dd on Linux:\nsudo dd if=proxmox-ve_8.x.iso of=/dev/sdX bs=4M status=progress conv=fsync Double check /dev/sdX is actually your USB drive before running this. It\u0026rsquo;s destructive.\n2. Check BIOS settings before installing # Boot into BIOS and confirm virtualisation extensions (Intel VT-x or AMD-V) are enabled, along with VT-d or AMD-Vi if you plan to pass through hardware like a GPU or a USB device later. This is the step I missed first time round. Meant a full reinstall rather than a five second BIOS toggle.\n3. Run the installer # Boot from the USB, select Proxmox VE, and step through the installer. Key choices:\nTarget disk for the Proxmox install itself Country, timezone, keyboard layout A strong root password Network configuration, ideally a static IP so the management interface doesn\u0026rsquo;t move around on you 4. First login and updates # Once installed, access the web UI at https://\u0026lt;your-proxmox-ip\u0026gt;:8006 and log in as root. Before anything else, update the system:\napt update \u0026amp;\u0026amp; apt full-upgrade -y If you\u0026rsquo;re not using a paid subscription, you\u0026rsquo;ll also want to switch to the no-subscription repository so updates don\u0026rsquo;t fail against the enterprise repo:\nsed -i \u0026#39;s/^deb/#deb/\u0026#39; /etc/apt/sources.list.d/pve-enterprise.list echo \u0026#34;deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription\u0026#34; \u0026gt; /etc/apt/sources.list.d/pve-no-subscription.list apt update 5. Set up storage properly # Add your secondary drive as a storage target under Datacenter \u0026gt; Storage, separate from the boot drive. Keeping VM disks off the boot drive makes reinstalling Proxmox itself far less risky later.\n6. Create your first VM or container # For lightweight services I lean toward LXC containers over full VMs where I can, since they share the host kernel and use noticeably less overhead. For anything needing a different OS or kernel-level isolation, a full VM makes more sense. Most of my Docker workloads fall into that camp.\n7. Set up backups before anything else goes on top # The step I\u0026rsquo;d tell anyone not to skip. Configure scheduled backups under Datacenter \u0026gt; Backup before you build anything on top of the host. Learned this one the hard way after losing a VM to a bad update with no snapshot to fall back on. Wrote about that one on the blog.\nLessons Learned # Check BIOS virtualisation settings before installing, not after.\nKeep VM storage on a separate drive from the Proxmox boot install.\nSet up scheduled backups immediately, not once something\u0026rsquo;s already gone wrong.\nLXC containers for lightweight services, full VMs for anything needing kernel isolation.\nWhat\u0026rsquo;s Next # Working toward automating VM and container provisioning with Ansible rather than clicking through the web UI each time. Eventually want to run this site\u0026rsquo;s build pipeline through an Ubuntu VM on this same host, via GitHub Actions.\n","date":"20 June 2026","externalUrl":null,"permalink":"/projects/proxmox-homelab-setup/","section":"Projects","summary":"How I built a Proxmox VE host as the base of my homelab, and a full follow-along guide to set up your own.","title":"Setting Up Proxmox: My Homelab Foundation","type":"projects"},{"content":"","date":"20 June 2026","externalUrl":null,"permalink":"/tags/virtualisation/","section":"Tags","summary":"","title":"Virtualisation","type":"tags"},{"content":"","date":"9 June 2026","externalUrl":null,"permalink":"/tags/msp/","section":"Tags","summary":"","title":"MSP","type":"tags"},{"content":"One of the biggest things I\u0026rsquo;ve gained from working in an MSP environment is the variety.\nI\u0026rsquo;m not talking about having a few different applications to support. I\u0026rsquo;m talking about moving between different customer environments, different technologies, different ways of working and completely different problems, sometimes within the same day.\nI\u0026rsquo;ve worked across Microsoft 365, Entra ID, Intune, Active Directory, Exchange Online, SharePoint, Teams, endpoint management and a whole range of business applications. I\u0026rsquo;ve also spent a fair amount of time on-site with customers, dealing with everything from user issues and device rebuilds to larger pieces of work such as Windows 11 migrations.\nThat variety can be challenging, but I think it has had a big influence on how I work.\nYou can\u0026rsquo;t assume every environment works the same way # One of the things you quickly learn in an MSP is that knowing one environment doesn\u0026rsquo;t mean you know the next one.\nYou might be very comfortable working in one customer\u0026rsquo;s Microsoft 365 environment, then find yourself dealing with a completely different setup somewhere else. The same technology might be there, but the configuration, policies, processes and expectations can be different.\nThat means I\u0026rsquo;ve had to become comfortable with not immediately knowing the answer.\nI don\u0026rsquo;t think there\u0026rsquo;s anything wrong with saying, \u0026ldquo;I don\u0026rsquo;t know yet.\u0026rdquo;\nThe important part is what happens next.\nI can look at the information available, understand the environment I\u0026rsquo;m actually working in and start investigating from there. I\u0026rsquo;ve found that much more useful than trying to make a familiar solution fit a situation where it doesn\u0026rsquo;t quite belong.\nIt\u0026rsquo;s also made me more comfortable picking up things I\u0026rsquo;ve not dealt with before. I don\u0026rsquo;t need to know everything about an environment before I can start understanding a problem.\nThe variety of work has been a big part of my experience # My day-to-day work isn\u0026rsquo;t just one type of support.\nThere are the Microsoft issues you\u0026rsquo;d expect, such as authentication problems, licensing, Conditional Access, Exchange Online, Teams and SharePoint. There are endpoint issues involving Intune, compliance and device configuration. Then there are the things that don\u0026rsquo;t fit neatly into one category.\nI\u0026rsquo;ve built and rebuilt PCs, provisioned tablets, dealt with printers, worked through VPN issues and supported users on-site. I\u0026rsquo;ve investigated issues using sign-in activity, device state, logs and policy behaviour, and I\u0026rsquo;ve had plenty of occasions where the first description of a problem hasn\u0026rsquo;t really told me what the underlying issue is.\nThat range has been useful because it means I\u0026rsquo;m constantly having to work out what kind of problem I\u0026rsquo;m actually dealing with before deciding how to approach it.\nBeing on-site has taught me a lot as well # One of the parts of my role that I particularly enjoy is customer site work.\nI\u0026rsquo;ve regularly been trusted to act as the lead engineer on-site, sometimes as the only engineer there, which means the responsibility is slightly different from sitting behind a service desk.\nYou\u0026rsquo;re not just working through a queue of tickets.\nYou have to look at what is happening around you.\nYou might arrive with a list of planned work and then have users coming to you with issues that weren\u0026rsquo;t on the list. You have to work out what needs attention first, what you can resolve yourself and what needs to be passed back to another team.\nBeing there also gives you information that isn\u0026rsquo;t always obvious from a ticket.\nYou can see how people are actually using the technology. You can ask questions directly. You can sometimes spot that what looked like an individual issue is actually part of something wider.\nI\u0026rsquo;ve found that particularly useful because it gives me a much better understanding of the difference between the technical problem and the experience of the person dealing with it.\nThe Windows 11 migration was a good example # One of the larger pieces of work I\u0026rsquo;ve supported was a Windows 11 migration involving more than 200 users.\nMy involvement included readiness checks, on-site support, floor-walking, triage and escalation.\nOn paper, a migration like that is obviously a technical exercise. There are devices to prepare, compatibility to consider and issues to resolve.\nIn reality, there\u0026rsquo;s a lot more going on.\nYou\u0026rsquo;re dealing with users who need to be able to work. You\u0026rsquo;re dealing with different devices and different problems. Some issues can be resolved immediately, while others need to be investigated or escalated.\nThat experience reinforced something I\u0026rsquo;ve noticed throughout my time in IT: the technical work is only part of delivering something successfully.\nYou also need communication, coordination and a good understanding of what needs to happen next.\nYou start to notice where processes don\u0026rsquo;t quite work # Working across different customer environments has also made me much more aware of documentation and processes.\nYou can have a process that looks perfectly reasonable when you read it.\nThen you actually have to use it.\nThat\u0026rsquo;s when you sometimes find that a step no longer applies, something isn\u0026rsquo;t documented properly or there is a dependency that nobody has written down.\nI\u0026rsquo;ve experienced this directly through working on JML documentation.\nSome of the existing documentation contained legacy steps that no longer reflected the environment, including old Citrix and Google administration activities. Reviewing that meant looking at what the process was supposed to achieve and then bringing the documentation back into line with what actually needed to happen.\nI found that work more interesting than I probably would have expected when I first moved into IT.\nIt isn\u0026rsquo;t particularly glamorous work.\nNobody is going to get excited about updating a process document.\nBut when the documentation is wrong, it creates problems for the person trying to follow it. Fixing that can make the process easier and more consistent for everyone who uses it afterwards.\nEscalation has become part of the job # Working in an MSP also means you\u0026rsquo;re often working as part of a much bigger chain of support.\nThere are plenty of problems where I can investigate a long way but ultimately need another team to take it further.\nI\u0026rsquo;ve become quite conscious of the quality of those handovers.\nIf I escalate something with:\nUser can\u0026rsquo;t access application. Please investigate.\nI\u0026rsquo;ve probably not done enough.\nIf I\u0026rsquo;ve included what the user was trying to do, what I\u0026rsquo;ve tested, what the logs show, what I\u0026rsquo;ve ruled out and what I think the next team needs to look at, that\u0026rsquo;s a much more useful escalation.\nI\u0026rsquo;m still learning here, but I\u0026rsquo;ve found that taking the time to structure an escalation properly can save someone else from starting the same investigation all over again.\nFor me, that\u0026rsquo;s still part of taking ownership of the issue, even if I don\u0026rsquo;t own the final fix.\nWorking across customers has changed how I troubleshoot # I think this is probably the biggest technical lesson I\u0026rsquo;ve taken from MSP work.\nYou can\u0026rsquo;t always rely on the answer you\u0026rsquo;ve used before.\nYou have to understand the environment in front of you.\nThat has made me more comfortable starting with evidence.\nIf something isn\u0026rsquo;t working, I want to know what the device is reporting. If it\u0026rsquo;s an authentication issue, I want to know what the sign-in logs show. If it\u0026rsquo;s a Conditional Access problem, I want to understand which policy is actually affecting the request.\nThe same applies to more straightforward support issues.\nWhat has changed?\nWhat works?\nWhat doesn\u0026rsquo;t?\nIs it one user or several?\nIs it one device or several?\nWhat has already been tried?\nThose questions sound simple, but they\u0026rsquo;re useful because they stop me jumping too far ahead.\nIt has also changed how I think about service management # This is probably where my recent ITIL learning has connected most with my day-to-day experience.\nWorking in an MSP means you\u0026rsquo;re constantly seeing the relationship between people, technology, processes and the services they\u0026rsquo;re trying to deliver.\nA technical issue might be the immediate problem, but the reason it takes so long to resolve might be something else.\nIt could be missing information.\nIt could be an unclear process.\nIt could be a poor handover.\nIt could be something waiting on another team.\nIt could be documentation that hasn\u0026rsquo;t been updated.\nOnce you start looking at those things, you begin to see that good IT support isn\u0026rsquo;t just about knowing how to fix technology.\nIt\u0026rsquo;s also about understanding how the work gets done.\nThat\u0026rsquo;s one of the reasons I\u0026rsquo;ve enjoyed studying service management alongside my support role. I\u0026rsquo;m seeing examples of the concepts in the work I\u0026rsquo;m already doing, rather than learning them in isolation.\nMSP work can be busy, but that\u0026rsquo;s part of the value # There are definitely days when the variety is the difficult part.\nYou can be working through one issue and suddenly have something completely different land in front of you. Priorities change, customers need different things and sometimes you have to switch between technical investigation, customer communication and practical work very quickly.\nBut I\u0026rsquo;ve found that useful.\nIt has forced me to become more adaptable and comfortable working things out as I go, without losing sight of the fact that the work still needs to be done properly.\nI\u0026rsquo;ve gained experience across a much broader range of technology and environments than I would probably have seen working in just one organisation.\nMore importantly, I\u0026rsquo;ve started to understand that good support isn\u0026rsquo;t simply about how quickly you can find a technical fix.\nIt\u0026rsquo;s about understanding the problem, taking responsibility for what you can control, communicating properly, documenting what matters and recognising when something needs to be improved rather than simply fixed again.\nThat\u0026rsquo;s probably the biggest thing working in an MSP has taught me. That\u0026rsquo;s probably the biggest thing I\u0026rsquo;ve taken from it.\n","date":"9 June 2026","externalUrl":null,"permalink":"/blog/whatworkinginanmsphastaughtmeaboutit/","section":"Field Notes","summary":"What working across multiple customer environments has taught me about support, communication and service.","title":"What Working in an MSP Has Taught Me About IT","type":"blog"},{"content":"There\u0026rsquo;s a running joke in IT that every problem eventually turns out to be DNS.\nIt\u0026rsquo;s funny because DNS does cause a lot of problems.\nBut there\u0026rsquo;s another lesson in it that I think is more useful.\nA familiar explanation can become a trap.\nThe danger of the obvious answer # When you\u0026rsquo;ve seen the same sort of issue enough times, your brain starts filling in the gaps.\nCan\u0026rsquo;t connect? Probably DNS.\nCan\u0026rsquo;t access an application? Probably DNS.\nSomething suddenly stopped working? Have you checked DNS?\nSometimes that instinct is useful. Experience gives you an idea of where to start.\nThe problem is when the likely answer becomes the assumed answer.\nIf I\u0026rsquo;ve already decided something is DNS before I\u0026rsquo;ve checked, I can end up looking for evidence that proves me right instead of finding out what is actually happening.\nI\u0026rsquo;ve learned to slow down at the beginning # When I\u0026rsquo;m working through a connectivity issue, I want to establish what is actually failing.\nCan the device connect to the network?\nDoes it have the expected IP configuration?\nCan it resolve the name?\nCan it reach the destination?\nIs the service itself responding?\nIs it one device or several?\nThose checks start narrowing things down.\nIf the evidence points towards DNS, great. I can investigate DNS.\nIf it doesn\u0026rsquo;t, I can move on.\nThat sounds obvious, but when you\u0026rsquo;re dealing with a busy support queue and a familiar-looking problem, it\u0026rsquo;s easy to jump ahead.\nThe same thing happens outside networking # I\u0026rsquo;ve seen the same assumptions with Microsoft 365, identity and endpoints.\nA user can\u0026rsquo;t sign in. It must be their password.\nA device isn\u0026rsquo;t accessing something. It must be Intune.\nAn application isn\u0026rsquo;t working. It must be the application.\nSometimes it is.\nBut the symptom doesn\u0026rsquo;t necessarily tell you the cause.\nI\u0026rsquo;ve had an authentication issue where the user simply couldn\u0026rsquo;t sign in. Looking at the Entra sign-in information showed that a specific Conditional Access policy was actually blocking the request.\nThe initial symptom was correct.\nThe assumption about the cause would have been wrong.\nThat\u0026rsquo;s why I try to separate what the user is experiencing from what the system is telling me.\nEvidence keeps you honest # The more I\u0026rsquo;ve worked in support, the more I appreciate having something concrete to work from.\nA log entry. A policy result. A device state. A test result. Something as simple as:\nIt works on this device but not that one.\ncan completely change the direction of an investigation.\nIf the same account works elsewhere, that\u0026rsquo;s useful.\nIf several users have the same problem, that\u0026rsquo;s useful.\nIf something can be ruled out, that\u0026rsquo;s useful too.\nThe aim isn\u0026rsquo;t to collect every possible piece of information.\nIt\u0026rsquo;s to find the information that helps narrow the problem down.\nYour first idea can still be right # I\u0026rsquo;m not against having a theory.\nIf I\u0026rsquo;ve seen a particular issue before, it makes sense that I might have an idea about where to start.\nIf I suspect DNS and the evidence confirms it, great.\nThe important part is that I checked.\nExperience should help you know where to look first.\nIt shouldn\u0026rsquo;t stop you looking elsewhere when the evidence tells you to.\nDon\u0026rsquo;t investigate forever either # There\u0026rsquo;s another side to this.\nNot every connectivity issue needs a complete investigation into every possible layer of the network.\nIf the evidence clearly shows that DNS is the problem and fixing it resolves the issue, that\u0026rsquo;s probably enough.\nFix it, make sure it works, record anything useful and move on.\nThe point isn\u0026rsquo;t to investigate everything forever.\nIt\u0026rsquo;s to investigate enough to be confident that you\u0026rsquo;ve understood what is happening and that the change you\u0026rsquo;re making is appropriate.\nSo yes, check DNS # Of course you should.\nDNS really does cause plenty of problems.\nBut I\u0026rsquo;ve found that the better approach is to start with an idea without becoming attached to it.\nLook at the symptom.\nGather the evidence.\nTest what you can.\nFollow where the investigation takes you.\nSometimes it really is DNS.\nAnd sometimes it really, really isn\u0026rsquo;t.\n","date":"26 May 2026","externalUrl":null,"permalink":"/blog/itsalwaysdnsuntilitisnt/","section":"Field Notes","summary":"Why familiar troubleshooting assumptions can sometimes send you in the wrong direction.","title":"It's Always DNS... Until It Isn't","type":"blog"},{"content":"","date":"26 May 2026","externalUrl":null,"permalink":"/tags/networking/","section":"Tags","summary":"","title":"Networking","type":"tags"},{"content":"","date":"12 May 2026","externalUrl":null,"permalink":"/tags/excel/","section":"Tags","summary":"","title":"Excel","type":"tags"},{"content":"","date":"12 May 2026","externalUrl":null,"permalink":"/tags/microsoft-365/","section":"Tags","summary":"","title":"Microsoft 365","type":"tags"},{"content":"One of the things I like about troubleshooting is that the amount of work involved in finding an answer doesn\u0026rsquo;t always have much to do with how complicated the eventual fix turns out to be.\nI had a good example of this with an Excel co-authoring issue.\nThe eventual fix was fairly simple.\nGetting to that fix took a bit more investigation.\nThe problem # The issue was around users trying to co-author an Excel workbook.\nThey expected to be able to work on the file together, but the co-authoring behaviour wasn\u0026rsquo;t working as expected.\nAt that point, there are quite a few places you could start looking.\nIs it a Microsoft 365 issue?\nIs it SharePoint or OneDrive?\nIs it permissions?\nIs there something wrong with the Office client?\nIs the device causing the problem?\nOr is there something about the actual file?\nThat\u0026rsquo;s the problem with a fairly broad symptom. There are plenty of things that could potentially be responsible.\nSo rather than immediately changing something, I started narrowing it down.\nStart with the actual situation # I wanted to understand exactly what was happening rather than just treating it as \u0026ldquo;Excel co-authoring doesn\u0026rsquo;t work\u0026rdquo;.\nWhat type of file was it?\nWhere was it stored?\nWas the problem affecting everyone?\nWas it happening with every workbook or just this particular one?\nWhat happened when the users tried to work on it?\nThose questions started to reduce the number of possibilities.\nThe file itself became more interesting as the investigation continued.\nIt was an .xlsb workbook.\nThat turned out to be an important detail.\nThe eventual fix # The solution was to convert the workbook from .xlsb to .xlsx.\nOnce that was done, the co-authoring issue was resolved.\nThat\u0026rsquo;s it.\nNo complicated script.\nNo major Microsoft 365 configuration change.\nNo rebuilding the user\u0026rsquo;s machine.\nJust changing the file format.\nIt would be easy to look at that afterwards and think the problem was simple.\nIn one sense, it was.\nBut that doesn\u0026rsquo;t mean the investigation wasn\u0026rsquo;t necessary.\nThe fix isn\u0026rsquo;t always the interesting part # This is something I\u0026rsquo;ve come to appreciate more as I\u0026rsquo;ve gained experience in IT support.\nWhen you know the answer, the answer can look obvious.\nBefore you know the answer, there are usually several possible explanations.\nIf I\u0026rsquo;d immediately assumed this was a permissions issue, I could have spent time looking in the wrong place.\nIf I\u0026rsquo;d started changing Office settings, I could have made things more complicated.\nIf I\u0026rsquo;d rebuilt the user\u0026rsquo;s device, I\u0026rsquo;d have been solving a completely different problem.\nThe investigation gave me enough information to make a sensible change rather than just trying things until something worked.\nThat\u0026rsquo;s an important difference.\nI try not to change things just for the sake of changing them # There\u0026rsquo;s a temptation in troubleshooting to feel like you need to be doing something all the time.\nClick this. Change that. Restart something. Reinstall something. Clear something.\nSometimes that\u0026rsquo;s exactly what you need to do.\nBut if you haven\u0026rsquo;t established what you\u0026rsquo;re trying to prove, you can easily end up making changes without really learning anything from them.\nI\u0026rsquo;ve found it more useful to treat each check as a way of narrowing the problem down.\nIf something works on one device but not another, that\u0026rsquo;s useful.\nIf another user can open the same file, that\u0026rsquo;s useful.\nIf the issue follows the file rather than the user, that\u0026rsquo;s useful.\nYou don\u0026rsquo;t necessarily need a complicated troubleshooting methodology.\nYou just need to pay attention to what each result is telling you.\nThe simple fix is still a good outcome # I actually think there is something quite satisfying about finding a simple answer to a problem that initially looked more complicated.\nYou haven\u0026rsquo;t failed because the final fix was straightforward.\nQuite the opposite.\nThe point of the investigation was to get to the right answer with as little unnecessary change as possible.\nIn this case, the final solution was simply using a file format that supported the co-authoring scenario properly.\nThe work was in figuring that out.\nIt also reminded me not to get too attached to my first idea # This is probably the bigger lesson I took from it.\nWhen you\u0026rsquo;re troubleshooting something you\u0026rsquo;ve seen before, it\u0026rsquo;s very easy to think you already know what the problem is.\nSometimes you do.\nSometimes you don\u0026rsquo;t.\nI\u0026rsquo;ve had plenty of situations where the initial description of an issue pointed me in one direction and the evidence took me somewhere else.\nThat\u0026rsquo;s normal.\nThe important thing is being willing to change your mind when the evidence doesn\u0026rsquo;t support your first assumption.\nThat\u0026rsquo;s something I\u0026rsquo;ve found useful beyond troubleshooting # This is also one of the reasons I\u0026rsquo;ve enjoyed studying service management.\nI\u0026rsquo;m increasingly interested in the thinking behind the work rather than just the technical action that resolves the immediate issue.\nWhat is actually happening? Where is the problem occurring? What is the impact? What information do we have? What do we need to change? And, once it is fixed, is there anything useful we should take from it?\nThe Excel issue was just a support problem.\nBut it was a good reminder that a technical fix is only one part of the investigation.\nThe best fix isn\u0026rsquo;t necessarily the most complicated one # I think there\u0026rsquo;s sometimes an assumption that a difficult problem needs an impressive solution.\nI\u0026rsquo;m not sure that\u0026rsquo;s true.\nA good troubleshooting process should ideally make the final solution simpler, not more complicated.\nIn this case, the investigation started with a fairly broad Microsoft 365 problem and eventually came down to the format of a single Excel workbook.\nThat\u0026rsquo;s a much better outcome than changing half the environment and hoping for the best.\nSo these days, when I come across a problem that looks complicated, I try not to make it more complicated than it needs to be.\nStart with what I know.\nFind out what I don\u0026rsquo;t.\nUse the evidence to narrow it down.\nThen make the smallest sensible change.\nSometimes, after all that, the fix is surprisingly simple.\n","date":"12 May 2026","externalUrl":null,"permalink":"/blog/whenthefixissimplerthantheinvestigation/","section":"Field Notes","summary":"A real Excel co-authoring issue where the investigation was more complicated than the final fix.","title":"When the Fix Is Simpler Than the Investigation","type":"blog"},{"content":"","date":"28 April 2026","externalUrl":null,"permalink":"/tags/conditional-access/","section":"Tags","summary":"","title":"Conditional Access","type":"tags"},{"content":"Conditional Access can be one of those things where a user says:\nI can\u0026rsquo;t sign in.\nAnd the immediate assumption is that a policy has blocked them.\nSometimes it has.\nBut I\u0026rsquo;ve found that the useful part of the investigation is not simply finding a policy that was involved.\nIt\u0026rsquo;s understanding why it applied and what the rest of the sign-in information is telling you.\nStart with the sign-in # When I\u0026rsquo;m investigating an authentication issue, I want to see what Entra is actually reporting.\nThe message the user sees gives me the symptom.\nThe sign-in logs give me something much more useful to investigate.\nI can look at the sign-in attempt, authentication details and the Conditional Access results to understand what happened.\nThat starts turning a vague access problem into something I can actually work with.\nInstead of:\nThe user can\u0026rsquo;t sign in.\nI\u0026rsquo;m trying to get to:\nThis sign-in attempt was evaluated against these conditions, and this is what happened.\nThat gives me somewhere to go next.\nOne investigation that stuck with me # I had an authentication issue where a user was unable to access what they needed.\nIt would have been easy to treat it as a general login problem.\nInstead, I went into the sign-in information and looked at what was actually happening.\nThe results showed that a specific Conditional Access policy was affecting the request. In this case, it was the blocked-countries policy.\nThat changed the investigation completely.\nIt wasn\u0026rsquo;t a mysterious authentication failure.\nThere was a control being applied, and the sign-in information showed me which one.\nThat meant I could investigate the actual reason for the denial rather than starting to change unrelated settings.\nThe lesson wasn\u0026rsquo;t that Conditional Access was the problem # The lesson for me was much simpler.\nFollow the evidence.\nConditional Access can involve different conditions and policies, and the user isn\u0026rsquo;t necessarily going to know which part of that process has stopped them.\nIf I simply assume the policy is wrong, I could end up changing something that is actually working exactly as intended.\nThe first question should be why the policy applied.\nThen I can work out whether that behaviour is expected.\nIf it is, the solution might not involve changing the policy at all.\nContext matters # One of the things I find interesting about identity issues is how much can sit behind a very simple error message.\nThe user experiences:\nI can\u0026rsquo;t sign in.\nBut behind that request there is information about the user, the device, the authentication attempt and the policies being evaluated.\nThere can also be information about the device\u0026rsquo;s compliance state and the circumstances of the sign-in.\nThe user sees the outcome.\nThe logs help explain how that outcome was reached.\nThat\u0026rsquo;s why I prefer looking at the actual sign-in information before making assumptions about what needs changing.\nDon\u0026rsquo;t change the control just to make the error disappear # This is probably the biggest practical lesson I\u0026rsquo;ve taken from working with access issues.\nIf a security control is doing what it was designed to do, removing or weakening it simply because one user is being blocked isn\u0026rsquo;t necessarily a solution.\nFirst, understand why it applied.\nThen establish whether that behaviour is expected.\nIf it isn\u0026rsquo;t expected, investigate why.\nIf it is expected, the answer might be something else entirely.\nThe user may need a different access route.\nThere may be another way of meeting the requirement.\nThe policy may genuinely need reviewing.\nOr nothing may need changing at all.\nYou can\u0026rsquo;t really make that decision until you understand what happened.\nThis is the part of troubleshooting I enjoy # I like problems where the first description doesn\u0026rsquo;t give you the whole picture.\nNot because I want to make things complicated.\nQuite the opposite.\nI want to take something vague and turn it into something I can understand.\nA user can\u0026rsquo;t sign in.\nI look at the sign-in.\nI see what happened.\nI check the relevant policy result.\nI work out whether the behaviour is expected.\nThen I know what I\u0026rsquo;m actually dealing with.\nThat\u0026rsquo;s much better than changing a setting and hoping the error disappears.\nThe practical takeaway # When someone can\u0026rsquo;t sign in, I try not to start with:\nWhich setting should I change?\nI start with:\nWhat does the sign-in tell me?\nThat small change in approach can save a lot of time.\nMore importantly, it means I\u0026rsquo;m trying to fix the actual problem rather than changing things until the error goes away.\nSometimes Conditional Access really is the reason someone can\u0026rsquo;t get in.\nBut finding a policy involved in a failed sign-in isn\u0026rsquo;t the end of the investigation.\nIt\u0026rsquo;s the point where the useful investigation starts.\n","date":"28 April 2026","externalUrl":null,"permalink":"/blog/conditionalaccessthepolicyisntalwaystheproblem/","section":"Field Notes","summary":"A practical look at following the evidence through an authentication investigation.","title":"Conditional Access: The Policy Isn't Always the Problem","type":"blog"},{"content":"","date":"28 April 2026","externalUrl":null,"permalink":"/tags/entra-id/","section":"Tags","summary":"","title":"Entra ID","type":"tags"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/escalation/","section":"Tags","summary":"","title":"Escalation","type":"tags"},{"content":"There is a big difference between escalating a ticket and handing someone a problem they can actually work with.\nWorking in an MSP environment means that I\u0026rsquo;m often dealing with issues where I can investigate a long way, but the eventual fix belongs with another team. That is just part of working in a wider support structure.\nWhat I\u0026rsquo;ve learned is that an escalation shouldn\u0026rsquo;t mean I\u0026rsquo;ve simply moved the ticket somewhere else.\nIf I\u0026rsquo;m handing an issue to another team, I want to give them a useful starting point.\nThe first thing is making sure they understand the problem # The person picking up an escalation wasn\u0026rsquo;t necessarily involved when the issue was first reported, so I try to make sure they can understand what is actually happening without having to go back through the entire ticket themselves.\n\u0026ldquo;User cannot access application\u0026rdquo; doesn\u0026rsquo;t tell them very much.\nWhat was the user trying to do? What happened when they tried? When did the problem start? Has it ever worked? Is it affecting one person or several? What is the actual impact?\nThose details give the next engineer some context before they start looking at the technical side.\nI\u0026rsquo;ve found this particularly important with issues where the original user description is fairly broad. A user might report that they can\u0026rsquo;t sign in, for example, but the investigation might eventually show that the problem is related to a particular Conditional Access policy, device state or another part of the authentication process.\nThe escalation needs to reflect what I\u0026rsquo;ve actually found rather than just repeating the original ticket.\nI want the next team to know what I\u0026rsquo;ve already checked # This is probably the most important part of an escalation for me.\nIf I\u0026rsquo;ve already checked the sign-in logs, I want that recorded. If I\u0026rsquo;ve looked at Conditional Access, device compliance, licensing or application behaviour, I\u0026rsquo;ll include that where it\u0026rsquo;s relevant.\nThe reason isn\u0026rsquo;t to prove how much investigation I\u0026rsquo;ve done.\nIt\u0026rsquo;s to stop the next engineer having to repeat the same work.\nIf I\u0026rsquo;ve tested the user\u0026rsquo;s account on another device and it works, that\u0026rsquo;s useful information. If another user can access the same application, that\u0026rsquo;s useful too. If I\u0026rsquo;ve found something in the logs that changes the direction of the investigation, that needs to be included.\nEven when a test doesn\u0026rsquo;t find the answer, it can still be useful because it rules something out.\nThat gives the next person a better place to start.\nEvidence is more useful than assumptions # When I\u0026rsquo;m investigating an issue, I try to work from what I can actually establish rather than what I think is probably happening.\nThat becomes even more important when I\u0026rsquo;m escalating something.\nDepending on the problem, the useful evidence could be sign-in information, audit logs, application logs, Event Viewer information, screenshots, PowerShell output, network testing, device information or configuration details.\nI don\u0026rsquo;t think an escalation should just contain every piece of information you\u0026rsquo;ve collected.\nMore isn\u0026rsquo;t necessarily better.\nThe useful question is whether the evidence helps explain the problem or supports something you\u0026rsquo;ve already established.\nIf a particular log entry shows the failure, include it.\nIf a test demonstrates that the issue only occurs on one device, explain that.\nIf you\u0026rsquo;ve ruled something out, say how you ruled it out.\nThat gives the receiving team something they can actually work with.\nThe things that don\u0026rsquo;t happen can be useful too # One thing I\u0026rsquo;ve become more conscious of is the value of knowing what has already been ruled out.\nFor example, if the same user can sign in successfully from another device, that tells me something.\nIf another user can access the same service, that tells me something else.\nIf the issue follows the user rather than the device, that changes where I would look next.\nNone of those tests necessarily fixes the problem, but they reduce the number of possibilities.\nWhen I include that information in an escalation, I\u0026rsquo;m effectively passing on part of the investigation rather than handing over the original symptom and asking someone else to start from scratch.\nThe impact matters as well # There\u0026rsquo;s also a difference between understanding what is technically wrong and understanding what the problem means for the user.\nIf one person has an inconvenience, that\u0026rsquo;s different from a whole department being unable to work.\nIf someone is completely blocked from doing their job, that needs to be understood by the team receiving the escalation.\nI\u0026rsquo;ve become more conscious of capturing that context because the technical description doesn\u0026rsquo;t always show the real impact.\nThe receiving team needs to understand not only what is happening, but why it matters.\nThat can help them make better decisions about what needs attention first.\nEscalating something doesn\u0026rsquo;t mean giving up on it # I think this is an important distinction.\nThere are plenty of issues where the service desk isn\u0026rsquo;t the team that owns the final fix. That doesn\u0026rsquo;t mean the service desk hasn\u0026rsquo;t taken ownership of the issue.\nFor me, ownership means doing what I reasonably can to understand the problem, gathering the right information and making sure it gets to the people who can take it further.\nIf I\u0026rsquo;ve investigated an issue properly and then escalated it with a clear explanation of what I\u0026rsquo;ve found, I still feel responsible for making sure the handover is useful.\nI\u0026rsquo;m not passing the problem away and forgetting about it.\nI\u0026rsquo;m moving it to the team that is better placed to resolve the next part.\nA good escalation should tell a story # When I look back at the escalations I\u0026rsquo;ve found most useful, they generally have a simple flow to them.\nThis is what the user was trying to do.\nThis is what happened.\nThis is what I\u0026rsquo;ve checked.\nThis is what the evidence shows.\nThis is what I\u0026rsquo;ve ruled out.\nThis is the impact.\nAnd this is where I think the investigation needs to go next.\nIt doesn\u0026rsquo;t need to be a huge amount of writing. It just needs to give the next person enough information to understand the situation and continue the investigation without starting again from the beginning.\nThat\u0026rsquo;s particularly important in a busy support environment, where the difference between a useful escalation and a poor one can be another engineer spending an hour repeating checks that have already been done.\nIt\u0026rsquo;s something I\u0026rsquo;m still improving # I\u0026rsquo;m not going to pretend I\u0026rsquo;ve mastered the art of escalation.\nThere are always things that could have been explained better, and sometimes you only realise what information was missing after the next team comes back with another question.\nThat\u0026rsquo;s part of learning.\nThe more technical investigations I\u0026rsquo;ve worked through, the more I\u0026rsquo;ve understood what information is likely to be useful to someone else.\nI\u0026rsquo;ve also become more aware that a good escalation is part of good service delivery. The technical investigation might have happened at the service desk, but the quality of the handover affects what happens next.\nFor me, that\u0026rsquo;s what a good escalation really comes down to.\nI don\u0026rsquo;t necessarily need to fix the problem myself.\nI do need to make sure that when it moves to someone else, they have a clear understanding of what happened, what has already been investigated and what they need to look at next.\nThat is still taking ownership.\n","date":"14 April 2026","externalUrl":null,"permalink":"/blog/whatagoodescalationactuallylookslike/","section":"Field Notes","summary":"What I try to include when handing a technical issue to another team.","title":"What a Good Escalation Actually Looks Like","type":"blog"},{"content":"There is nothing wrong with closing a ticket.\nThat\u0026rsquo;s what we\u0026rsquo;re there to do. If someone can\u0026rsquo;t work because something isn\u0026rsquo;t functioning properly, getting them back up and running is important.\nWhat I\u0026rsquo;ve become more conscious of, though, is what happens when the same issue keeps coming back.\nYou can fix the individual ticket every time, but eventually you have to ask whether there is something behind the pattern.\nA ticket can be fixed and the problem can still exist # Imagine something breaks.\nYou investigate it, find the cause, apply a fix and the user is back up and running.\nGood. The ticket can be closed.\nThen the same thing happens again next week.\nYou fix it again.\nThen it happens to someone else.\nAt that point, the individual ticket isn\u0026rsquo;t necessarily the most interesting part anymore. The pattern is.\nI\u0026rsquo;ve become much more aware of this through working in support and studying service management. A recurring issue can be a sign that something else needs looking at.\nIt might be a configuration issue. It might be a process that isn\u0026rsquo;t working particularly well. It might be a documentation gap. It might be something owned by another team entirely.\nYou don\u0026rsquo;t necessarily know until you start looking at what is happening across the individual incidents.\nThe support queue can tell you more than you might think # You don\u0026rsquo;t always need complicated reporting to notice that something keeps happening.\nSometimes you just recognise it.\nYou\u0026rsquo;ve seen the same application issue several times. You\u0026rsquo;ve answered the same question from different users. You\u0026rsquo;ve seen the same type of access problem come through again. You might even find yourself giving people the same workaround repeatedly.\nThose things start to stand out when you\u0026rsquo;ve been working in support for a while.\nWhen I notice something like that, I try to think about whether there is anything useful behind it.\nIf I\u0026rsquo;m answering the same question repeatedly, perhaps the information isn\u0026rsquo;t easy enough to find.\nIf I\u0026rsquo;m seeing the same type of issue on different devices, perhaps there is something worth raising.\nIf a process keeps creating confusion, perhaps the process or its documentation could be clearer.\nThat doesn\u0026rsquo;t mean every repeated ticket needs to turn into a project.\nSometimes there is nothing that needs changing.\nBut if you don\u0026rsquo;t notice the pattern in the first place, you never get the opportunity to decide whether it is worth doing anything about.\nI\u0026rsquo;ve seen this with documentation # One of the more obvious examples for me has been documentation.\nI\u0026rsquo;ve worked on documentation where the information no longer matched the way the environment actually worked. In particular, I\u0026rsquo;ve been involved in reviewing Joiner, Mover and Leaver documentation and removing legacy steps that were no longer relevant.\nThe immediate task was updating the documentation.\nBut there is a bigger point behind that.\nIf the information people are relying on isn\u0026rsquo;t accurate, it can create problems further down the process. Someone following the document might waste time looking for something that no longer exists or take a route that doesn\u0026rsquo;t reflect how the environment is actually managed.\nUpdating the document doesn\u0026rsquo;t necessarily feel like a major technical achievement.\nBut it removes a source of confusion for the people who need to use it.\nThat\u0026rsquo;s the sort of small improvement I\u0026rsquo;ve started to appreciate more.\nSometimes the answer is simply better information # I\u0026rsquo;ve also seen situations where the same information needs to be explained repeatedly.\nA user asks a question.\nSomeone answers it.\nAnother user asks the same question a few days later.\nThen someone else asks it again.\nAt some point, it\u0026rsquo;s worth asking whether the answer should exist somewhere that people can find it themselves.\nThat could mean a knowledge article, better documentation or simply making an existing piece of information easier to find.\nThe aim isn\u0026rsquo;t necessarily to stop people contacting support.\nThere will always be reasons for users to need help.\nIt\u0026rsquo;s more about making the information available when it is straightforward and repeatable, while allowing support time to be spent on the things that actually need investigation.\nThe same thinking applies to processes # Documentation is only one example.\nA process can work perfectly well most of the time and still have a part that regularly causes confusion.\nMaybe information isn\u0026rsquo;t available when someone needs it.\nMaybe an approval isn\u0026rsquo;t clear.\nMaybe an escalation route isn\u0026rsquo;t obvious.\nMaybe there is a step that made sense when the process was created but doesn\u0026rsquo;t really fit the environment anymore.\nI\u0026rsquo;ve come across enough examples of this in my own work to have become more interested in what happens around the technical issue.\nThe technology might be working exactly as configured.\nThe difficulty might be in how the work moves around it.\nThat\u0026rsquo;s one of the things that studying service management has helped me recognise more clearly.\nThis is where continual improvement started making more sense to me # Before studying ITIL, I probably would have thought of improvement as something much bigger.\nA new system.\nA major project.\nA significant process change.\nThe more I\u0026rsquo;ve learned about continual improvement, the more I\u0026rsquo;ve appreciated that it can also be much smaller than that.\nChanging a document because it is out of date is an improvement.\nMaking an escalation clearer is an improvement.\nSpotting a recurring issue and raising it with the team responsible for the service is an improvement.\nMaking information easier to find can be an improvement.\nNone of these things are particularly dramatic on their own.\nBut if they make the service easier to support or reduce unnecessary work, they\u0026rsquo;re still useful.\nI\u0026rsquo;m careful not to assume every repeat issue needs fixing # There is a balance here.\nI don\u0026rsquo;t think every recurring ticket is automatically evidence of a major underlying problem.\nSometimes things just happen.\nSometimes a user is new and needs the same information that everyone else needed when they started.\nSometimes a problem is unavoidable.\nSometimes the cost of changing something would be greater than the benefit.\nThat\u0026rsquo;s why I think the important part is noticing the pattern rather than immediately deciding that something must be changed.\nOnce you\u0026rsquo;ve noticed it, you can ask whether it is actually worth investigating.\nThat feels much more sensible to me than trying to turn every repeated issue into a continual improvement exercise.\nWhat I\u0026rsquo;m trying to do differently # When I see something recurring, I try to pause for a moment and think about what might be sitting behind it.\nIs there something missing from the documentation?\nCould the process be clearer?\nIs there information that would help the next person?\nIs this something the resolver team should know about?\nIs there a wider pattern worth raising?\nSometimes I\u0026rsquo;ll find that there isn\u0026rsquo;t anything particularly useful to do.\nThat\u0026rsquo;s fine.\nOther times, it might be worth making a small change or raising something with the team that owns the service.\nThe important thing for me is that the question gets asked.\nClosing the ticket is still important # I\u0026rsquo;m not against ticket closure.\nA support team still needs to restore service, keep work moving and make sure issues are dealt with.\nThe point is that closing the ticket doesn\u0026rsquo;t always have to be the end of the thinking.\nSometimes the right thing to do is fix the issue, document what happened and move on.\nSometimes you fix it and notice that the same thing has happened several times before.\nThat\u0026rsquo;s when I think it\u0026rsquo;s worth looking a little further.\nThe individual ticket tells you what happened to one person at one point in time.\nA pattern of tickets can tell you something about the service itself.\nThat\u0026rsquo;s one of the things I\u0026rsquo;ve started paying more attention to as I\u0026rsquo;ve gained experience in support and learned more about service management.\nYou don\u0026rsquo;t need to turn every incident into a major improvement project.\nSometimes you just need to notice that something keeps happening, ask why, and decide whether there is anything worth doing about it.\n","date":"31 March 2026","externalUrl":null,"permalink":"/blog/theproblemwithjustclosingtheticket/","section":"Field Notes","summary":"Why resolving an incident can be useful while still leaving a wider problem worth looking at.","title":"The Problem With Just Closing the Ticket","type":"blog"},{"content":"One of the most common things you get in IT support is a ticket that basically says:\nIt\u0026rsquo;s not working.\nSometimes that\u0026rsquo;s enough to get started.\nUsually it isn\u0026rsquo;t enough to solve it.\nThe first job is turning that statement into something you can actually investigate.\nWhat does \u0026ldquo;not working\u0026rdquo; mean? # A user might say they can\u0026rsquo;t access something, but that can mean quite a few different things. They might not be able to sign in at all, they might be able to sign in but not open the application, or the application might open but a particular function isn\u0026rsquo;t working. It might work perfectly well on another device, or it might have stopped working for everyone rather than just one person.\nThose are all very different problems, even though the ticket might simply say \u0026ldquo;can\u0026rsquo;t access the application\u0026rdquo;.\nThe wording of the ticket is the starting point, not necessarily the diagnosis.\nSo I try to establish what the user is actually seeing. What were they trying to do? What happened? What did they expect to happen? When did it start? Has it ever worked? Is anyone else affected? What has already been tried?\nThat usually gives me something much more useful to work with.\nIt also gives me a better idea of where to start looking rather than immediately jumping to a particular cause.\nThen I start looking for evidence # This is where I prefer to slow down rather than immediately start changing things.\nDepending on the problem, that might mean looking at sign-in logs, device state, Conditional Access results, Event Viewer, application logs, network information or PowerShell output.\nThe evidence is often more useful than the error message on its own.\nFor example, an access problem might look like a generic authentication failure from the user\u0026rsquo;s point of view. But if I can see the sign-in attempt and the policies that were evaluated, I have something much more concrete to work with.\nThe same applies to endpoint problems. If a device says something isn\u0026rsquo;t compliant, I want to understand what the device is reporting and which requirement isn\u0026rsquo;t being met.\nI\u0026rsquo;m not trying to collect every possible log or check every setting I can find. I\u0026rsquo;m trying to find the information that helps narrow down the problem.\nThat distinction is important because it\u0026rsquo;s very easy to spend a lot of time looking at information that doesn\u0026rsquo;t actually help you get any closer to an answer.\nDon\u0026rsquo;t make five changes at once # This is one of those habits that sounds obvious until you\u0026rsquo;re under pressure.\nIf I change five things and the problem disappears, I know the problem is gone. I don\u0026rsquo;t necessarily know why.\nThat can make the next incident harder, particularly if one of those changes wasn\u0026rsquo;t actually necessary.\nWhere possible, I prefer to test one thing at a time and use the result to decide what to do next. Sometimes the answer is obvious and sometimes it takes longer, but I\u0026rsquo;d rather understand what fixed something than accidentally stumble across the answer.\nIt also means that if the problem comes back, I\u0026rsquo;ve got a much better idea of what to look at.\nI\u0026rsquo;m not saying you should never make multiple changes. Sometimes you have to, particularly when you\u0026rsquo;re dealing with an issue that needs restoring quickly. But where I can, I like to understand the reason behind the change rather than just trying things until something works.\nThe initial symptom isn\u0026rsquo;t always the cause # I\u0026rsquo;ve had issues where the first description pointed in one direction and the investigation took me somewhere else.\nThat\u0026rsquo;s normal.\nA user sees the result of a problem. They don\u0026rsquo;t necessarily see the thing causing it.\nThat\u0026rsquo;s why I don\u0026rsquo;t think troubleshooting should start with deciding what the cause is. It should start with understanding what is happening.\nThere is a subtle difference.\nIf I decide too early that something is a licensing problem, a network problem or a Conditional Access problem, I can end up looking only for evidence that supports that assumption.\nIf I start with the evidence, I have a better chance of finding what is actually happening.\nI\u0026rsquo;ve seen this with authentication issues in particular. From the user\u0026rsquo;s perspective, they simply can\u0026rsquo;t get into something. Once you start looking at the sign-in information, though, you can sometimes see that there is a much more specific reason behind it.\nThe same thing happens with devices and applications. The first symptom gives you somewhere to start, but it doesn\u0026rsquo;t necessarily tell you where you\u0026rsquo;ll finish.\nA good investigation doesn\u0026rsquo;t have to be complicated # There is sometimes a temptation in IT to make a problem sound more complicated than it is.\nI don\u0026rsquo;t think that\u0026rsquo;s helpful.\nThe tools can be complicated. The environment can be complicated. The process of getting to the answer can take time.\nBut the explanation should be as simple as it can reasonably be.\nIf I can explain what happened, why it happened and what fixed it, that\u0026rsquo;s much more useful than filling the explanation with technical detail that doesn\u0026rsquo;t actually help anyone understand the issue.\nThis is something I\u0026rsquo;ve become more conscious of as I\u0026rsquo;ve gained experience. Knowing how to investigate something is important, but so is being able to explain what you\u0026rsquo;ve found to someone else.\nThat might be another engineer picking up the ticket, a resolver team you\u0026rsquo;ve escalated to, or the user themselves.\nThe technical detail should support the explanation, not become the explanation.\nWhat I\u0026rsquo;ve learned # Working in support has made me appreciate that the first few minutes of an investigation can make a big difference.\nIf I understand the problem properly, I can investigate it properly.\nIf I don\u0026rsquo;t, I can spend a lot of time solving the wrong problem.\nThat\u0026rsquo;s probably one of the reasons I enjoy troubleshooting. There is something satisfying about taking a vague problem, working through what you actually know, finding the evidence and gradually narrowing it down until the answer becomes clear.\nIt doesn\u0026rsquo;t always happen quickly.\nSometimes you have to escalate it. Sometimes another team has information or access that you don\u0026rsquo;t have. Sometimes the answer isn\u0026rsquo;t obvious at all.\nThat\u0026rsquo;s part of the job.\nSo when a ticket says \u0026ldquo;it\u0026rsquo;s not working\u0026rdquo;, I don\u0026rsquo;t really see that as the problem.\nIt\u0026rsquo;s the beginning.\nThe useful bit is finding out what \u0026ldquo;not working\u0026rdquo; actually means, and then working from there.\n","date":"17 March 2026","externalUrl":null,"permalink":"/blog/whenitsnotworkingisntenough/","section":"Field Notes","summary":"Why turning a vague support issue into something you can actually investigate matters.","title":"When \"It's Not Working\" Isn't Enough","type":"blog"},{"content":"","date":"3 March 2026","externalUrl":null,"permalink":"/tags/army-to-it/","section":"Tags","summary":"","title":"Army to IT","type":"tags"},{"content":"","date":"3 March 2026","externalUrl":null,"permalink":"/tags/career/","section":"Tags","summary":"","title":"Career","type":"tags"},{"content":"Before I moved into IT, I spent more than 13 years in the British Army.\nIt probably isn\u0026rsquo;t the background you\u0026rsquo;d expect to see on an IT support website, but looking back at how I work now, I can see quite a few things that came with me when I left.\nThe technology is obviously very different.\nThe way you approach responsibility, preparation, people and problems isn\u0026rsquo;t always quite so different.\nTaking responsibility for what is in front of you # One of the biggest things I took from the Army is that if something is your responsibility, you need to know what\u0026rsquo;s going on.\nThat doesn\u0026rsquo;t necessarily mean you have to be able to do everything yourself. It means you need to understand the situation, know what has been done and have a clear idea of what needs to happen next.\nI\u0026rsquo;ve found myself working in much the same way in IT.\nIf I\u0026rsquo;m dealing with a complicated support issue, I want to understand what has actually happened rather than simply passing it somewhere else because it looks difficult.\nIf I\u0026rsquo;m the sole engineer on a customer site, I need to know what work is planned, what issues have appeared and what needs to be dealt with before I leave.\nIf something needs to be escalated, I want to make sure the next team has enough information to continue the investigation rather than simply receiving the same problem I was given.\nThat doesn\u0026rsquo;t mean I always own the final solution.\nThere are plenty of issues where another team is responsible for the technical fix. What I can control is the quality of the investigation I\u0026rsquo;ve done, the information I\u0026rsquo;ve gathered and how well I\u0026rsquo;ve communicated what I\u0026rsquo;ve found.\nThat way of thinking feels very familiar to me.\nPreparation makes things easier when something goes wrong # The Army put a lot of emphasis on preparation.\nYou don\u0026rsquo;t want to discover that something important is missing when you actually need it. You want to have thought about what you\u0026rsquo;re doing, what you might need and what could go wrong before you get there.\nObviously, IT isn\u0026rsquo;t the same environment.\nBut the principle has stuck with me.\nGood preparation in IT might be making sure you have the right information before starting an investigation. It might be checking a device before a customer visit, understanding what work is planned or making sure documentation is available when someone needs it.\nI\u0026rsquo;ve become particularly interested in this through the work I\u0026rsquo;ve done around documentation.\nA process can be perfectly reasonable, but if the information someone needs to follow it is missing or out of date, they\u0026rsquo;re starting at a disadvantage.\nI\u0026rsquo;ve seen this when working through existing documentation and finding that parts of it no longer reflected the environment.\nThe answer wasn\u0026rsquo;t necessarily to create something complicated.\nIt was to make sure the information was accurate and actually useful.\nThat distinction matters to me.\nI don\u0026rsquo;t like documentation that exists simply because somebody decided there should be a document.\nI\u0026rsquo;d rather have something that someone can actually use.\nAccountability isn\u0026rsquo;t just keeping track of things # A significant part of my Army experience involved equipment and logistics.\nYou need to know what you have, where it is, what condition it\u0026rsquo;s in and who is responsible for it.\nThat might sound a long way removed from IT, but I\u0026rsquo;ve found there are some obvious similarities.\nIn IT, there are devices, accounts, access, information and services that all need to be managed properly.\nThe details are different, but the basic idea of knowing what you have and understanding its status still matters.\nI\u0026rsquo;ve worked with asset lists, device preparation, rebuilds and provisioning as part of my current role, and I think my previous experience has probably made me naturally conscious of the importance of accurate information.\nIf the records say one thing and reality says another, that\u0026rsquo;s worth investigating.\nYou can\u0026rsquo;t make good decisions about something you don\u0026rsquo;t properly understand.\nThings don\u0026rsquo;t always go according to plan # One thing you learn pretty quickly in any environment where you\u0026rsquo;re responsible for getting things done is that the plan is rarely the complete story.\nSomething changes.\nSomething doesn\u0026rsquo;t work.\nSomeone needs something you weren\u0026rsquo;t expecting.\nYou have to adapt.\nI\u0026rsquo;ve experienced plenty of that in IT.\nA ticket can start as a straightforward access issue and turn into an investigation involving sign-in activity, device state and Conditional Access.\nA customer visit can have planned work, only for users to raise completely different issues once you\u0026rsquo;re there.\nA piece of technical work can uncover something that needs another team involved.\nI\u0026rsquo;ve found that the best response isn\u0026rsquo;t to immediately start changing things because the original plan no longer fits.\nI try to work out what I know, what I don\u0026rsquo;t know and what information I need before deciding what to do next.\nThat sounds simple, but staying calm enough to actually do it is important.\nLeadership isn\u0026rsquo;t always about the title # During my Army career, I had responsibility for people and led teams of up to 10.\nThat experience taught me quite a lot about what leadership actually looks like when you\u0026rsquo;re responsible for getting a job done.\nIt isn\u0026rsquo;t just telling people what to do.\nYou need to make sure people understand what is expected, give them what they need to do the job, keep things moving and step in when something isn\u0026rsquo;t going to plan.\nI\u0026rsquo;ve found some of that carries across into IT.\nI don\u0026rsquo;t need to be someone\u0026rsquo;s manager to help them work through a difficult problem.\nSometimes a colleague just needs another person to talk through an investigation with.\nWhat have you checked?\nWhat does the evidence show?\nWhat haven\u0026rsquo;t you ruled out?\nIs there another angle worth looking at?\nWhat does the next team actually need from you?\nSometimes helping someone structure a problem is more useful than taking the problem away from them.\nThat\u0026rsquo;s something I enjoy doing.\nDocumentation has always mattered to me # This is probably one of the strongest connections between my Army experience and the way I work in IT.\nWhen you\u0026rsquo;re responsible for equipment, people or tasks, accurate information matters.\nYou need to be able to trust the records you\u0026rsquo;re working from.\nI\u0026rsquo;ve carried that into IT.\nI\u0026rsquo;ve worked on knowledge articles and process documentation, and I\u0026rsquo;ve seen what happens when information becomes outdated or doesn\u0026rsquo;t reflect the way something is actually done.\nIt\u0026rsquo;s easy to think of documentation as something separate from the actual work.\nI don\u0026rsquo;t really see it that way.\nIf the next person needs to complete a task, investigate an issue or understand a process, the information available to them is part of what allows them to do that properly.\nI\u0026rsquo;ve also found that reviewing documentation can expose things that aren\u0026rsquo;t obvious when you\u0026rsquo;re simply following the process.\nIf the document says one thing but everyone is actually doing something else, that\u0026rsquo;s worth understanding.\nIt might be that the process has changed.\nIt might be that the documentation was never quite right.\nEither way, you\u0026rsquo;ve found something worth looking at.\nYou learn to rely on the people around you # Another thing the Army taught me is that you don\u0026rsquo;t get very far by trying to do everything yourself.\nDifferent people have different responsibilities, skills and experience.\nThe important thing is knowing what you can deal with, when you need help and how to work effectively with the people around you.\nThat\u0026rsquo;s very relevant to IT.\nThere are plenty of problems where I can investigate the issue but eventually need another team to take it further.\nThat isn\u0026rsquo;t a failure.\nThe important thing is making sure the handover is useful and that I\u0026rsquo;ve done what I reasonably can before it gets there.\nI\u0026rsquo;ve also found that working across an MSP environment means communicating with a lot of different people. Customers, users, service desk colleagues, resolver teams and project teams all have different perspectives on the same piece of work.\nYou have to be able to work with all of them.\nThe Army didn\u0026rsquo;t teach me how to do IT # I think that\u0026rsquo;s probably the most important distinction.\nThe Army didn\u0026rsquo;t prepare me to troubleshoot Microsoft 365.\nIt didn\u0026rsquo;t teach me how Entra ID works, how to investigate an Intune compliance issue or how to understand a Conditional Access result.\nThose are things I\u0026rsquo;ve had to learn since moving into IT.\nWhat the Army did give me was a way of approaching work.\nTake responsibility for what is in front of you.\nPrepare properly.\nKeep accurate information.\nLook after the people around you.\nStay calm when something changes.\nAsk questions when you don\u0026rsquo;t know.\nAnd when something isn\u0026rsquo;t working, don\u0026rsquo;t just keep doing the same thing without trying to understand why.\nLooking back, those habits have been useful # When I first moved into IT, I was obviously focused on learning the technology.\nI had a lot to learn, and I still do.\nBut as I\u0026rsquo;ve gained more experience, I\u0026rsquo;ve realised that knowing the technology is only part of being good at the job.\nHow you investigate something matters.\nHow you communicate matters.\nHow you document something matters.\nHow you work with other people matters.\nWhether you take responsibility for an issue matters.\nThose aren\u0026rsquo;t necessarily IT skills, but they\u0026rsquo;re skills that have helped me while I\u0026rsquo;ve been learning IT.\nMy career has changed quite a lot since I left the Army.\nThe environment is different, the problems are different and the technology is completely different.\nBut when I look at how I work today, I can still recognise quite a lot of the person who was there before I moved into IT.\nThe Army didn\u0026rsquo;t teach me IT.\nIt taught me a lot about how I approach the work.\nThe technology is different.\nThe way I approach the work isn\u0026rsquo;t quite so different.\nAnd I think that\u0026rsquo;s been useful.\n","date":"3 March 2026","externalUrl":null,"permalink":"/blog/what13yearsinthearmytaughtmeaboutit/","section":"Field Notes","summary":"What my Army career taught me about responsibility, preparation, leadership and working in IT.","title":"What 13 Years in the Army Taught Me About IT","type":"blog"},{"content":" That Bearded IT Guy. I\u0026rsquo;m Liam.\nI work in IT, I like figuring out how things work, and I have a habit of starting projects just to see if I can make them work.\nThat Bearded IT Guy started as a simple idea: somewhere to put all of that stuff - the things I learn, the things I build, the problems I run into, the things I find interesting, and probably a few things that seemed like a good idea at the time.\nIt\u0026rsquo;s grown into a place where I can document the practical side of IT and the things I\u0026rsquo;m learning along the way.\nHow I think about IT I\u0026rsquo;ve always been more interested in understanding something than just making it work.\nIf something breaks, the first question isn\u0026rsquo;t always \u0026ldquo;how do I fix it?\u0026rdquo; Sometimes it\u0026rsquo;s why did it break? And if it keeps happening, why are we still seeing it?\nThat doesn\u0026rsquo;t mean everything needs a complicated solution - quite the opposite. Sometimes the best answer is a really simple one. But I like understanding what\u0026rsquo;s happening before changing things, keeping a record of what I\u0026rsquo;ve done, and looking at whether there\u0026rsquo;s a better way of doing it next time.\nThat\u0026rsquo;s probably why I find things like troubleshooting, documentation, process improvement and service management interesting.\nWhy TBITG exists There\u0026rsquo;s a lot of technical information out there. Some of it is brilliant. Some of it assumes you already know half the terminology.\nWhat I want TBITG to be is a bit different - a place where I can share things from my own experience and projects in a way that makes sense. If I\u0026rsquo;ve solved a problem, I\u0026rsquo;ll write about it. If I\u0026rsquo;ve built something, I\u0026rsquo;ll show how I built it. If I\u0026rsquo;ve learned something useful, I\u0026rsquo;ll share it. And if I get something completely wrong, there\u0026rsquo;s a good chance I\u0026rsquo;ll write about that too.\nThe point isn\u0026rsquo;t to have all the answers. It\u0026rsquo;s to keep learning and share what I find along the way.\nBuilt, broken, fixed. That\u0026rsquo;s basically how I learn. I like getting hands-on with things, which is one of the reasons I have a homelab - a place to experiment, test ideas, build things and occasionally discover that the thing I changed five minutes ago has broken something else.\nIt\u0026rsquo;s also a good place to try things I don\u0026rsquo;t necessarily get to work with every day: Proxmox, Docker, Linux, Raspberry Pi, self-hosted services, scripting, networking, and whatever else I happen to be interested in at the time.\nSome projects are useful. Some are just experiments. Either way, I usually learn something.\nOutside the screen I\u0026rsquo;m not always thinking about IT. I spend plenty of time outdoors, especially paddleboarding, getting out with the dogs and generally finding reasons to put the laptop down for a while.\nI think that\u0026rsquo;s important. Technology is a big part of what I do, but it doesn\u0026rsquo;t have to be everything.\nWhat you\u0026rsquo;ll find here Field Notes Things I\u0026rsquo;ve learned, noticed or found interesting.\nProjects Things I\u0026rsquo;m building, testing and experimenting with.\nExperience A look at the work and experience behind what I do.\nOne last thing I\u0026rsquo;m still learning. There are plenty of things I know reasonably well, plenty of things I\u0026rsquo;m still getting better at, and plenty of things I haven\u0026rsquo;t learned yet. I\u0026rsquo;m quite happy with that - IT changes too quickly to ever really be finished learning anyway.\nSo that\u0026rsquo;s what TBITG is about.\nBuild something. Break something. Figure out why. Fix it. Learn something.\nThen probably do it all again.\nGet in touch If you want to follow along, the best place to find me is LinkedIn.\nConnect with me on LinkedIn\n","externalUrl":null,"permalink":"/about/","section":"That Bearded IT Guy","summary":"That Bearded IT Guy. I’m Liam.\nI work in IT, I like figuring out how things work, and I have a habit of starting projects just to see if I can make them work.\nThat Bearded IT Guy started as a simple idea: somewhere to put all of that stuff - the things I learn, the things I build, the problems I run into, the things I find interesting, and probably a few things that seemed like a good idea at the time.\n","title":"About","type":"page"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":" A different route into IT My route into IT wasn\u0026rsquo;t exactly straightforward. Before moving into technology I spent more than 13 years in the British Army, working across Infantry and Logistics. Since then I\u0026rsquo;ve built my career in an MSP environment, supporting a broad range of customers, technologies and environments.\nAlong the way I\u0026rsquo;ve become just as interested in what sits around the technical problem as the problem itself - how services are delivered, how teams work together, whether documentation actually helps people, and what changes when something isn\u0026rsquo;t working as well as it should.\nAt a glance Role Organisation Dates IT Support Engineer Managed Service Provider 2022 - Present Logistics British Army 2018 - 2022 Infantry British Army 2009 - 2018 IT Support Engineer, MSP Working in an MSP has given me experience across a broad range of customer environments, technologies and support requirements. My day-to-day covers triage, investigation, resolution, escalation and closure across multiple customer environments, plus taking ownership of the more complex issues, supporting colleagues, and looking for ways to improve how the service operates.\nTechnical areas Area Includes Identity \u0026amp; Access Active Directory, Microsoft Entra ID, Azure AD Connect, Conditional Access, MFA, sign-in and audit logs Endpoint Management Windows 10/11, Microsoft Intune, enrolment, compliance and configuration profiles, application deployment, device builds Microsoft 365 Exchange Online, Outlook, Teams, OneDrive, SharePoint, shared mailboxes, licensing Troubleshooting \u0026amp; Diagnostics Event Viewer, HAR/application/audit/sign-in logs, PowerShell, VPN, DNS, DHCP, Wi-Fi and Ethernet I also work with printers, business applications, RemoteApp environments and other customer-specific systems.\nOn customer sites A significant part of my role is supporting customers on-site, often as the sole engineer, taking responsibility for the support activity and coordinating what needs to happen. That covers:\nTriaging issues and floor-walking Supporting users and gathering evidence Device provisioning and asset validation Printer and network checks Coordinating escalations and keeping customer contacts updated Being on-site gives a different view of the environment - you see how people are actually using the technology, and often find information that isn\u0026rsquo;t obvious from the original ticket. I\u0026rsquo;ve also acted as on-site support lead for larger change activity, including a migration covering more than 200 users.\nWorking with the wider team My role isn\u0026rsquo;t limited to my own workload. I support colleagues with more technical investigations, take ownership of complex tickets when required, and try to make sure any handover to another team includes what actually matters - what happened, what\u0026rsquo;s been tested, and the logs, screenshots and configuration details needed to pick it up without starting over.\nI\u0026rsquo;ve also identified documentation gaps and written knowledge articles to improve consistency, and raised wider service concerns where an issue looks like it\u0026rsquo;s recurring rather than one-off. Sometimes the useful question isn\u0026rsquo;t why did this happen, it\u0026rsquo;s why are we still seeing this.\nHow I approach the work Start with the evidence - find out what\u0026rsquo;s actually happening before deciding what the problem is Work through it properly - establish impact, gather information, test causes, don\u0026rsquo;t guess Take ownership - even when another team makes the change, make sure the investigation is useful Keep people informed - the technical fix is only part of the job Look beyond the individual problem - if something keeps happening, understand why Keep learning - there\u0026rsquo;s always another technology, process or framework worth understanding Before IT: 13+ years in the British Army A lot of how I work today came from those years - taking responsibility, planning properly, keeping track of things, and staying calm when something doesn\u0026rsquo;t go to plan.\nInfantry (2009 - 2018) - working as part of structured teams, training and mentoring people, and maintaining equipment. I led and coordinated teams of up to 12, including delivering training to less experienced colleagues, and held responsibility for high-value equipment: its accountability, readiness and records. If something was your responsibility, you needed to know where it was and what condition it was in.\nLogistics (2018 - 2022) - more focus on planning, operational readiness and coordination. I led teams of up to 12 across equipment readiness, asset tracking, maintenance schedules, resource allocation and liaising with external organisations and international partners. Most of it came down to having accurate information: what you have, where it is, and who\u0026rsquo;s responsible for it.\nAfter leaving the Army I spent a short period in recruitment before moving into technology, which gave me a different perspective on communication and working in a commercial environment before I started building the technical side of my career.\nQualifications \u0026amp; learning I want my learning to connect back to the work I actually do, not just sit as a certificate.\nStatus Qualification Completed ITIL v5 Foundation, Strategy \u0026amp; Product Completed Microsoft Azure Fundamentals (AZ-900) Completed CompTIA A+ In progress ISO 27001 ITIL has helped me connect the day-to-day work - incident and request management, prioritisation, escalation, continual improvement - to the bigger picture of how a service actually fits together. ISO 27001 is a natural next step, given how much I\u0026rsquo;m drawn to the relationship between people, process, technology and risk.\nOutside of work Most of what\u0026rsquo;s left goes into my homelab - Proxmox, Docker, Linux, and enough self-hosted projects to keep learning without a client on the other end if I get something wrong. Full write-ups live on the Projects page.\n","externalUrl":null,"permalink":"/experience/","section":"That Bearded IT Guy","summary":"A different route into IT My route into IT wasn’t exactly straightforward. Before moving into technology I spent more than 13 years in the British Army, working across Infantry and Logistics. Since then I’ve built my career in an MSP environment, supporting a broad range of customers, technologies and environments.\nAlong the way I’ve become just as interested in what sits around the technical problem as the problem itself - how services are delivered, how teams work together, whether documentation actually helps people, and what changes when something isn’t working as well as it should.\n","title":"Experience","type":"page"}]