[{"content":"","date":"16 October 2026","externalUrl":null,"permalink":"/posts/","section":"Articles","summary":"","title":"Articles","type":"posts"},{"content":"","date":"16 October 2026","externalUrl":null,"permalink":"/","section":"Shanti Korporaal","summary":"","title":"Shanti Korporaal","type":"page"},{"content":"I have a confession to make.\nI committed a stakeholder management offence.\nThe consequences have lasted four months.\nAnd I still can\u0026rsquo;t access half my wardrobe. 😂\n1. Requirements gathering: Excellent # A few months ago, my partner and I moved back in with my parents to help support my dad as his health is declining.\nWhich meant we needed somewhere to store our belongings.\nWe\u0026rsquo;d both used storage units before, so we knew what we needed.\nSomething larger than a single-car garage.\nWe have quite a lot of stuff. We\u0026rsquo;re not particularly small people, and we wanted to be able to move around and access our belongings.\nNot just fit everything in.\nActually get things back out.\nRequirements discussed. Parameters agreed. Both key stakeholders aligned.\nWhat could possibly go wrong?\n2. Stakeholder consultation: Unexpected development # My partner was working when I went to inspect the storage units.\nSo I went with my mum.\nThe woman at the facility showed us the different sizes.\nMum looked at the units.\nThen at the prices.\nThen at me.\nAnd made a very compelling case for a smaller, cheaper unit.\nMum hadn\u0026rsquo;t used storage units before, but her cost considerations were extremely appealing.\nAnd despite knowing better, I agreed.\nWe booked the smaller unit.\nA new stakeholder had successfully influenced a major project decision.\nUnfortunately, the other key stakeholder hadn\u0026rsquo;t been consulted.\n3. Change control: Non-existent # When I told my partner, she immediately knew I\u0026rsquo;d made a mistake.\nIt\u0026rsquo;s not going to be big enough.\nAnd even if everything fitted, she pointed out, we\u0026rsquo;d never be able to access anything.\nWhich was one of the exact reasons we\u0026rsquo;d agreed on a larger unit in the first place.\nBut we had to move quickly, and the booking was already made.\nSo we proceeded.\nAgainst the very reasonable advice of the stakeholder whose requirements had been discussed, agreed upon, and then completely disregarded by the project manager.\nWho was me.\nExcellent work. 😂\n4. Project delivery: Technically successful # Moving day arrived.\nAnd somehow, we managed to fit everything into the storage unit.\nEverything!\nThere was just one small problem.\nWe couldn\u0026rsquo;t move around inside it.\nThe walkway didn\u0026rsquo;t exist.\nAnd accessing anything at the back would require a significant excavation project.\nMy partner looked at me.\nI looked at my partner.\nThere was some eye-rolling.\nNo argument. No drama.\nThe storage unit was doing an excellent job of making her point for her.\n5. Post-implementation review: Four months later # Four months later, the unit is still packed.\nThe walkway still doesn\u0026rsquo;t exist.\nAnd half my wardrobe remains inaccessible.\nAnd while we were laughing about this whole situation, something rather important came up.\nThere\u0026rsquo;s a difference between finding a cheaper way to meet the agreed requirements and changing the requirements to make something cheaper.\nWe hadn\u0026rsquo;t found a more economical way to achieve what we wanted.\nWe\u0026rsquo;d simply bought less space.\nAnd I\u0026rsquo;d known perfectly well why we needed more.\nMum wasn\u0026rsquo;t wrong to suggest a cheaper option. She was considering the cost with the information she had.\nMy partner wasn\u0026rsquo;t wrong to question it. She understood the practical requirements.\nAnd I wasn\u0026rsquo;t wrong to consider an alternative.\nI was wrong to change an agreed decision without consulting the person who would also have to live with the consequences.\nIt\u0026rsquo;s a mistake that\u0026rsquo;s remarkably easy to make in projects, too.\nA cheaper option appears, everyone gets excited about the savings, and somewhere along the way an important requirement gets lost.\nNew information is a good reason to revisit an agreement.\nIt\u0026rsquo;s not permission to quietly replace it.\nAnd four months later, I have a rather excellent reminder of that distinction.\nThe storage shed was within budget. Unfortunately, I can\u0026rsquo;t reach my clothes.\n😂\nOriginally published on LinkedIn.\n","date":"16 October 2026","externalUrl":null,"permalink":"/posts/what-a-storage-shed-taught-me-about-stakeholder-agreements/","section":"Articles","summary":"","title":"What a Storage Shed Taught Me About Stakeholder Agreements","type":"posts"},{"content":"My mum and I have a classification system for people.\nThere are Bread Rippers.\nAnd there are Bread Slicers.\nIt\u0026rsquo;s not scientifically validated.\nIt has absolutely no supporting research.\nAnd I wouldn\u0026rsquo;t recommend including it in your organisation\u0026rsquo;s recruitment framework.\nBut we\u0026rsquo;ve been using it for years, and we find it remarkably useful.\nMostly because we both really like bread. 😂\nAllow me to explain # Imagine someone puts a beautiful, fresh loaf of bread on the table.\nA Bread Ripper looks at it and thinks:\nExcellent. Bread!\nThey tear off a piece, pass the loaf around, and everyone gets stuck in.\nA Bread Slicer looks at the same loaf and thinks:\nExcellent. Bread!\nThey get the breadboard, find a suitable knife, slice it neatly, and arrange it for everyone.\nPossibly on matching plates.\nWith matching mugs.\nMum and I are definitely Bread Rippers.\nWe\u0026rsquo;re not particularly concerned about whether the bread is presented beautifully.\nWe just want to eat the bread.\nAnd share it, obviously.\nWe\u0026rsquo;re not monsters. 😂\nIt\u0026rsquo;s not really about bread # Although, to be fair, it is a little bit about bread.\nIt\u0026rsquo;s about how people approach getting things done.\nBread Rippers tend to jump in, work with what they\u0026rsquo;ve got, and make progress without needing everything perfectly arranged first.\nBread Slicers prefer a little more preparation. They like things considered, organised and done in the right order.\nNeither approach is inherently better.\nAnd neither is necessarily right for every situation.\nWhich brings me to project management.\nBecause apparently I can\u0026rsquo;t even talk about bread without finding a project analogy.\nThe project has been approved. Now what? # Imagine we\u0026rsquo;ve just been given a new project.\nThe Bread Ripper is thinking:\nRight. We know what needs to happen. We\u0026rsquo;ve got enough to get started. Let\u0026rsquo;s go!\nThe Bread Slicer is thinking:\nRight. Before we begin, let\u0026rsquo;s confirm the scope, responsibilities, dependencies, approvals, and documentation.\nAnd here\u0026rsquo;s the thing.\nThey might both be exactly right.\nIf we\u0026rsquo;re dealing with an urgent problem and have enough information to act safely, spending another three days making everything look lovely probably isn\u0026rsquo;t helping.\nBut if we\u0026rsquo;re about to begin something complex, expensive, or difficult to reverse, taking time to establish the right controls could save us an enormous amount of trouble later.\nThe trick is knowing how much preparation the situation actually needs.\nAnd sometimes the best project team is the one where someone says, \u0026ldquo;Let\u0026rsquo;s get moving,\u0026rdquo; and someone else says, \u0026ldquo;Absolutely, but first we need to check this.\u0026rdquo;\nEven if one of them is quietly wondering why we\u0026rsquo;re still talking about the bread. 😂\nActivating our Bread Slicer brains # Now, here\u0026rsquo;s the important bit.\nMum and I don\u0026rsquo;t actually believe people are permanently one type or the other.\nMost of us can approach things differently depending on what the situation needs.\nWe just have natural preferences.\nAnd ours happen to involve ripping bread.\nSometimes we\u0026rsquo;ll be talking about someone or something and realise:\nOh. This is going to require Bread Slicer mode.\nWhich means we\u0026rsquo;ll need to slow down, be more methodical, explain things in a particular order, or pay closer attention to presentation.\nAnd sometimes there is a little eye-rolling.\nNot at the person!\nAt ourselves.\nBecause activating our Bread Slicer brains requires a bit more effort than simply doing what comes naturally.\nBut we do it.\nBecause the way I naturally approach something isn\u0026rsquo;t necessarily the way it needs to be approached.\nA Bread Ripper might help a Bread Slicer get started before every possible detail has been resolved.\nA Bread Slicer might help a Bread Ripper notice something important before it becomes a problem.\nNeither needs to become the other person.\nWe just need to recognise what the situation requires.\nAnd occasionally pick up the bread knife.\nPass the bread # So there you have it.\nYears of informal research conducted by two women who really like bread.\nNo peer-reviewed studies.\nNo psychometric testing.\nAbsolutely no intention of turning this into a corporate personality assessment.\nJust a funny little framework that reminds us our natural preferences aren\u0026rsquo;t always the best tool for every situation.\nSometimes you need a beautifully sliced loaf.\nSometimes everyone is hungry, and someone just needs to rip the bloody bread.\n😂\nOriginally published on LinkedIn.\n","date":"15 October 2026","externalUrl":null,"permalink":"/posts/bread-rippers-and-bread-slicers/","section":"Articles","summary":"","title":"Bread Rippers and Bread Slicers","type":"posts"},{"content":"Give me a blank page and unlimited possibilities, and I can spend an extraordinary amount of time achieving absolutely nothing.\nNot because I can\u0026rsquo;t think of anything.\nQuite the opposite.\nI can think of far too many things.\nThis is why I\u0026rsquo;ve discovered that one of the best things I can do for my creativity is give it some rules.\nWhich sounds completely backwards.\nBut hear me out.\nWhat do you make when you can make anything? # One of my hobbies is making jewellery.\nAnd the wonderful thing about making jewellery is that, within reason, I can make pretty much whatever I want.\nThe possibilities are enormous.\nWhich is lovely, until my brain starts exploring all of them.\nI could make earrings. Or necklaces. Or something with wire. Or beads. Or maybe I should learn an entirely new technique. Actually, what if I combined two techniques?\nYou get the idea.\nAt some point, I realised that having absolutely no boundaries wasn\u0026rsquo;t necessarily helping me create anything.\nSo I started making collections.\nOne was based on requests from family and friends. They told me what they wanted, and I worked out how to make it.\nAnother was inspired by nature.\nAnd another used old computer components I\u0026rsquo;d taken apart.\nSuddenly, I had somewhere to begin.\nThe funny thing about looking for something # The nature-inspired collection was particularly interesting.\nI started noticing things on my walks that I would previously have walked straight past.\nThe shape of a leaf. The details in plants and trees. Colours appearing together in combinations I would never have thought of myself.\nThey were already there.\nI just hadn\u0026rsquo;t been looking at them that way.\nThe framework didn\u0026rsquo;t tell me what to create. It gave me something to be curious about.\nThe computer-parts collection worked the same way. Instead of wondering what I could make from anything, I was exploring what I could make from the pieces in front of me.\nI wasn\u0026rsquo;t being less creative because I had fewer options.\nI was actually making things.\nA rather important distinction. 😂\nApparently, I do this at work too # I\u0026rsquo;ve noticed the same thing in projects.\nGive me a project with no clear scope, no agreed outcome, and no boundaries, and my brain can come up with possibilities forever.\nWe could do this.\nBut what if we also did that?\nAnd while we\u0026rsquo;re here, wouldn\u0026rsquo;t it make sense to improve this other thing?\nBefore long, we\u0026rsquo;ve got an absolutely magnificent collection of ideas.\nAnd potentially no finished project.\nScope creep would be having the time of its life.\nBut give me a clear objective, some constraints, and an understanding of what success looks like, and suddenly I have a problem I can really get my teeth into.\nI can explore approaches, test ideas, ask questions, and look for opportunities.\nAnd I have a way to decide which ideas actually belong in this piece of work.\nThe boundaries don\u0026rsquo;t tell me how to solve the problem.\nThey help me understand which problem I\u0026rsquo;m solving.\nA little structure goes a long way # I\u0026rsquo;ve noticed it in everyday life, too. When everything I need to do is floating around in my head, part of my attention is always occupied trying to remember what\u0026rsquo;s next.\nHaving those things organised gives me the freedom to concentrate on what I\u0026rsquo;m actually doing.\nIncluding absolutely nothing, if that\u0026rsquo;s what I\u0026rsquo;ve decided to do.\nWhich is a perfectly respectable use of free time, thank you very much. 😂\nOf course, too much structure can be just as unhelpful as too little.\nA framework that dictates every decision doesn\u0026rsquo;t leave much room for creativity or judgment.\nAnd I certainly don\u0026rsquo;t think every hobby needs a project initiation document.\nAlthough I am now slightly tempted to prepare one for my next pair of earrings.\nA place to begin # I used to think freedom meant having as many options as possible.\nAnd sometimes it does.\nBut I\u0026rsquo;ve discovered that a little structure gives my ideas somewhere to go.\nAnd sometimes, as I discovered while looking for jewellery inspiration on my walks, it helps me see things I might never have noticed otherwise.\nFor me, structure doesn\u0026rsquo;t take away my freedom to be creative.\nIt gives that creativity somewhere to begin.\nOriginally published on LinkedIn.\n","date":"14 October 2026","externalUrl":null,"permalink":"/posts/the-freedom-created-by-structure/","section":"Articles","summary":"","title":"The Freedom Created by Structure","type":"posts"},{"content":"","date":"13 October 2026","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","date":"13 October 2026","externalUrl":null,"permalink":"/series/troy/","section":"Series","summary":"","title":"TROY: An Enterprise Transformation Program","type":"series"},{"content":" Part 6 — The Withdrawal of a Critical Resource # We\u0026rsquo;ve got a problem.\nOur most important resource has withdrawn from the project.\nHe\u0026rsquo;s still on site.\nHe\u0026rsquo;s just not doing the work.\nUnfortunately, the rest of the project appears to have been designed around the assumption that he would.\nWelcome back to Troy.\nWe have a critical resource dependency problem.\nAnd, as of Book 9, we also have a resource retention problem.\nExcellent.\nSo, how\u0026rsquo;s the project going? # Not brilliantly.\nThe Trojans are gaining ground, the Greeks are struggling, and the absence of Achilles is becoming increasingly difficult to ignore.\nNow, we\u0026rsquo;ve already covered the spectacular breakdown in stakeholder relations between Achilles and Agamemnon.\nI\u0026rsquo;m not going to revisit that whole argument.\nSuffice to say, the executive sponsor has managed to alienate one of the project\u0026rsquo;s most valuable contributors, and that contributor has decided he\u0026rsquo;s had quite enough.\nWhich is unfortunate, because Achilles isn\u0026rsquo;t just another soldier.\nHe\u0026rsquo;s an exceptionally capable warrior whose contribution has become enormously important to the Greek campaign.\nAnd now he\u0026rsquo;s sitting out.\nThe Greeks still have plenty of talented people. Odysseus, Ajax and Diomedes haven\u0026rsquo;t suddenly forgotten how to fight.\nBut losing Achilles has exposed something rather uncomfortable.\nThe project was far more dependent on one person than anyone seems to have adequately planned for.\nThe risk has become an issue # Achilles withdrawing isn\u0026rsquo;t the underlying risk.\nThe risk was that the Greek army had become so dependent on his participation that losing him could seriously compromise their ability to deliver.\nHis withdrawal is the event that exposed it.\nAnd now the Greeks are dealing with the consequences.\nWhich brings us to a question I would very much like to ask whoever was maintaining the project risk register:\nDid nobody consider what would happen if Achilles became unavailable?\nNot necessarily because he was angry.\nWhat if he was injured?\nWhat if he decided to leave?\nWhat if he simply wasn\u0026rsquo;t available when the army needed him?\nHaving someone exceptionally capable on your team is wonderful.\nBuilding a delivery strategy that only works while that person remains available is rather less wonderful.\nAnd it isn\u0026rsquo;t necessarily that person\u0026rsquo;s fault.\nThe retention strategy # By Book 9, Agamemnon has realised that things are going badly enough to warrant an intervention.\nSo he assembles a truly extraordinary retention package.\nTreasure. Horses. Women. Marriage arrangements. Future rewards.\nIt\u0026rsquo;s quite a lot.\nThen he sends Odysseus, Phoenix and Ajax to negotiate Achilles\u0026rsquo; return.\nWhich, in modern corporate terms, is a fairly senior delegation for a performance and retention conversation.\nThey arrive.\nAchilles welcomes them.\nThey talk.\nThey explain the offer.\nAnd Achilles says no.\nOh.\nResource retention strategy: unsuccessful.\nNow, to be fair, Achilles has a genuine grievance.\nHe was publicly dishonoured by Agamemnon, and the damage wasn\u0026rsquo;t simply financial.\nThis is about respect, status, trust, and how he\u0026rsquo;s been treated.\nAgamemnon is offering an enormous amount of compensation.\nBut compensation isn\u0026rsquo;t necessarily reconciliation.\nAnd Achilles doesn\u0026rsquo;t appear particularly interested in pretending otherwise.\nThere\u0026rsquo;s something very familiar about an organisation discovering that a valuable person is unhappy and responding with a bigger offer, without quite resolving the reason they became unhappy in the first place.\nSometimes the problem isn\u0026rsquo;t what you\u0026rsquo;re offering.\nIt\u0026rsquo;s what happened before the offer.\nMeanwhile, the rest of the team\u0026hellip; # This is where I started getting a bit frustrated with Achilles.\nBecause I understand why he\u0026rsquo;s angry.\nI really do.\nAgamemnon behaved appallingly.\nAnd I don\u0026rsquo;t think Achilles should be expected to simply forget it because someone has arrived with a spectacular pile of presents.\nBUT MATE. PEOPLE ARE DYING.\nYour colleagues are fighting for their lives.\nThe situation is deteriorating.\nAnd at some point, I found myself wanting to climb into the book, walk into Achilles\u0026rsquo; tent and say:\n“BRO. WHEN WILL ENOUGH BE ENOUGH?”\nI appreciate that this is not a particularly sophisticated diplomatic intervention.\nBut neither, apparently, is offering someone an enormous pile of treasure and hoping the underlying problem goes away.\nAnd this is the part I find genuinely difficult.\nI can understand Achilles\u0026rsquo; reasons without necessarily agreeing with what he\u0026rsquo;s doing.\nI can recognise that Agamemnon caused the breakdown without believing Achilles\u0026rsquo; decisions have no consequences for anyone else.\nBoth things can be true.\nThe person who caused the problem isn\u0026rsquo;t automatically the only person with choices left to make.\nAnd the people suffering the consequences aren\u0026rsquo;t necessarily the people who caused the dispute.\nTwo problems, not one # The Greeks have a dependency problem and a relationship problem.\nEven if Achilles returns, the army is still vulnerable if it can\u0026rsquo;t function effectively without him.\nAnd even if the Greeks develop better contingency arrangements, that won\u0026rsquo;t magically repair the damage between Achilles and Agamemnon.\nThese problems are connected.\nBut they aren\u0026rsquo;t the same problem.\nWhich means they probably need different solutions.\nThe project continues # So here we are.\nThe critical resource remains unavailable.\nThe executive sponsor has made an offer.\nThe retention delegation has returned without securing the desired outcome.\nAnd the remaining team is still expected to deliver.\nI imagine the project status meeting is going to be an absolute delight.\nBecause if your entire project depends on one person coming back, you don\u0026rsquo;t just have a resource retention problem.\nYou\u0026rsquo;ve got a project problem.\nAnd in Troy\u0026rsquo;s case, quite a lot of people would probably appreciate someone doing something about it.\nPreferably before the next battle.\nOriginally published on LinkedIn.\n","date":"13 October 2026","externalUrl":null,"permalink":"/posts/troy-an-enterprise-transformation-program-part-6/","section":"Articles","summary":"","title":"TROY: An Enterprise Transformation Program: Part 6","type":"posts"},{"content":"When I was about ten years old, I found myself sitting on a chair in a classroom at an orphanage in rural India.\nIn front of me was a room full of children, most a little younger than me, sitting on the floor.\nBeside me was an interpreter.\nAnd I was reading them a children\u0026rsquo;s Bible story.\nMy parents were pastors and missionaries, so growing up, I spent quite a bit of time in places like rural India and the Philippines. I was used to meeting people whose lives looked very different from mine.\nBut this particular moment has stayed with me.\nBecause I was becoming increasingly uncomfortable.\nThere I was, this rather large little white girl, sitting on a chair while a room full of children looked up at me with wide eyes.\nThey didn\u0026rsquo;t speak my language. I didn\u0026rsquo;t speak theirs.\nAnd I felt like some sort of visiting alien who\u0026rsquo;d been placed at the front of the room to say something terribly important.\nExcept I wasn\u0026rsquo;t terribly important.\nI was just another kid.\nAnd I didn\u0026rsquo;t like feeling as though I belonged above everyone else.\nSo I got off the chair # I turned to the interpreter and asked for a moment.\nThen I climbed down, sat on the floor in front of one of the girls, and smiled at her.\nI gently took her hand and brought her finger up to my nose.\nShe pushed it.\nThen I reached over and pushed hers.\nFor a second, she looked completely stunned.\nThen she smiled.\nThen she laughed.\nAnd suddenly the whole room was laughing.\nNo interpreter required.\nJust two kids being a bit silly.\nI remember asking everyone what sport they thought Jesus played.\nThe answer was apparently obvious.\nCricket.\nOf course it was cricket. 😂\nSo we went outside and played cricket.\nA sport I didn\u0026rsquo;t even particularly like.\nBut that wasn\u0026rsquo;t really the point.\nFor a little while, we weren\u0026rsquo;t a visiting child and a room full of children being visited.\nWe were just kids playing together.\nAnd that was what I\u0026rsquo;d wanted.\nFinding somewhere to begin # I wasn\u0026rsquo;t pretending our lives were the same.\nThey weren\u0026rsquo;t.\nWe came from different cultures, spoke different languages, and had very different experiences.\nThose differences mattered.\nBut I didn\u0026rsquo;t want them to be the only things that mattered.\nAt ten, I didn\u0026rsquo;t have particularly sophisticated language for any of this.\nI just knew I wanted to find something we could both recognise.\nApparently, my solution was to get someone to push my nose.\nWhich, to be fair, worked remarkably well.\nI still do this # I\u0026rsquo;ve carried that instinct into every industry I\u0026rsquo;ve worked in.\nWhether I\u0026rsquo;m talking to a specialist about something technical, working with a small business owner, or meeting someone whose experiences are completely different from mine, I tend to begin the same way.\nI look for something familiar.\nNot to prove that we\u0026rsquo;re the same, but to give us somewhere to start talking.\nWhen I worked with small businesses in rural Cambodia, helping people understand bookkeeping, I sometimes found that people were surprised to hear about the cleaning and manual work I\u0026rsquo;d done myself.\nIt gave us something else to talk about beyond the fact that I was there to explain bookkeeping.\nThese days, I might notice that a tradesperson uses MYOB and start asking how they use it.\nAnd before long, we\u0026rsquo;re having a conversation.\nNot because I know everything about their work.\nQuite the opposite.\nFinding something familiar gives me a starting point to become curious about what\u0026rsquo;s different.\nWhat do they do differently?\nWhy does their approach work for them?\nWhat do they know that I don\u0026rsquo;t?\nWhat have I assumed that might be completely wrong?\nI genuinely enjoy those conversations.\nThe differences are the interesting bit # I think sometimes we approach unfamiliar people or situations by noticing all the ways they\u0026rsquo;re different from us.\nAnd of course we notice differences. They\u0026rsquo;re interesting!\nBut I\u0026rsquo;ve always found it easier to begin with something I recognise.\nIt gives me a place to stand while I explore everything I don\u0026rsquo;t yet understand.\nThat doesn\u0026rsquo;t mean assuming someone else\u0026rsquo;s experiences are the same as mine.\nIt simply means I don\u0026rsquo;t have to begin with the distance between us.\nI can begin with a connection.\nLooking back, I think that\u0026rsquo;s what ten-year-old me was trying to do in that classroom.\nI couldn\u0026rsquo;t change the differences between our lives.\nI couldn\u0026rsquo;t speak their language.\nAnd I definitely couldn\u0026rsquo;t convince anyone that I was good at cricket.\nBut I could sit on the floor.\nI could be silly.\nAnd we could laugh together.\nStart with what\u0026rsquo;s the same. Get curious about what\u0026rsquo;s different.\nOriginally published on LinkedIn.\n","date":"12 October 2026","externalUrl":null,"permalink":"/posts/start-with-whats-the-same/","section":"Articles","summary":"","title":"Start With What's the Same","type":"posts"},{"content":"It\u0026rsquo;s Monday morning.\nSomething is urgent.\nEveryone wants an answer.\nAnd the pressure to do something is arriving considerably faster than the information needed to decide what.\nSound familiar?\nI work in urgent maintenance. Which means a significant part of my day involves things that have gone wrong, people who need answers, and problems that generally can\u0026rsquo;t wait until everyone has finished their coffee.\nSometimes the urgency is a genuine safety issue. Sometimes it\u0026rsquo;s a deadline. And occasionally, something is urgent because the person asking is several levels above you on the organisational chart.\nDifferent kinds of urgency. Remarkably similar feelings when they land in your inbox.\nFirst, I need a moment # Recently, I received information about a recurring maintenance issue that needed immediate attention at 4:30 on a Friday afternoon.\nMy first reaction was not particularly profound.\n“Oh, you\u0026rsquo;ve got to be kidding me.”\nWhich is fair enough. I\u0026rsquo;m human.\nUnfortunately, being annoyed hasn\u0026rsquo;t yet solved an emergency for me.\nSo I took a breath.\nNot a particularly long breath. Nobody had time for a wellness retreat. There was an actual problem that needed dealing with.\nBut I needed that moment to accept that this was happening, whether I liked it or not, and work out what needed to happen first.\nThe specialist needed the information so they could respond. My managers needed to know what was happening. The client needed an update. The paperwork needed completing. And because the issue had happened before, the underlying cause still needed investigating.\nAll important.\nBut not all first.\nA bit of triage in the brain # That\u0026rsquo;s what the breath gives me.\nA little bit of triage in the brain.\nIn this case, the first priority was getting the information directly to the person who could act on it.\nThe paperwork could follow, within the necessary requirements. My managers could be updated on what had already been actioned. The client could be given an accurate picture of what was happening and what would happen next.\nAnd the underlying problem could be investigated alongside the response.\nBecause sometimes dealing with an emergency and understanding why it happened are two different jobs.\nThe immediate issue needs attention, but if you never get around to understanding the cause, there\u0026rsquo;s a good chance you\u0026rsquo;ll be dealing with it again.\nAnd again.\nAsk me how I know. 😂\nUrgency doesn\u0026rsquo;t make everything equally immediate # When something urgent happens, it\u0026rsquo;s easy to feel as though everything needs to happen at once.\nBut some actions prevent further harm, some get the right people moving, and others provide information or accountability.\nThey all matter. The trick is working out what comes first.\nI don\u0026rsquo;t take a breath because emergencies don\u0026rsquo;t affect me # I take a breath because they do.\nI\u0026rsquo;m not immune to pressure, frustration, or the occasional desire to put my head on my desk.\nWhen several things need attention at once, my brain can get rather noisy.\nAnd if I let that noise dictate my next action, I\u0026rsquo;m much more likely to lose track of what I\u0026rsquo;m trying to achieve.\nSo I give myself a moment.\nSometimes I\u0026rsquo;m following a familiar sequence. Sometimes I\u0026rsquo;m building a new one.\nWhat\u0026rsquo;s happening? What\u0026rsquo;s the immediate risk? Who needs to know? What can wait?\nIt doesn\u0026rsquo;t guarantee I\u0026rsquo;ll get everything right.\nI\u0026rsquo;ve made mistakes. I\u0026rsquo;ll make more.\nAnd when the moment is right, I try to ask for feedback. Was there something I missed? Could I have communicated better? Is there a step I should add for next time?\nBecause there will absolutely be a next time.\nPreferably not at 4:30 on a Friday afternoon, but apparently emergencies don\u0026rsquo;t consult my calendar.\nFirst things first # Sometimes you have to act immediately with incomplete information. That\u0026rsquo;s the nature of urgent work.\nBut taking a breath doesn\u0026rsquo;t mean ignoring the urgency. For me, it\u0026rsquo;s how I find a way through it.\nI can\u0026rsquo;t always make an urgent situation less urgent. But a little bit of triage in the brain helps me work out what comes next.\nOriginally published on LinkedIn.\n","date":"11 October 2026","externalUrl":null,"permalink":"/posts/urgency-is-not-permission-to-stop-thinking/","section":"Articles","summary":"","title":"Urgency Is Not Permission to Stop Thinking","type":"posts"},{"content":" Part 5 — The Bloody Wall # Hang on.\nThere\u0026rsquo;s a wall?\nSince when do we have a wall?\nI was reading the Iliad when I suddenly realised the Greeks had a substantial defensive wall protecting their ships.\nA wall.\nWith towers.\nAnd gates.\nAnd a ditch.\nExcuse me. WHAT?\nI had to go back and find the bit where they\u0026rsquo;d built it.\nAnd there it was, in Book 7.\nNestor suggests building a defensive wall to protect the ships. The Greeks agree. They construct a wall, complete with towers, gates, and a substantial ditch reinforced with stakes.\nAnd by sunset, it\u0026rsquo;s done.\nAN ENTIRE DEFENSIVE INFRASTRUCTURE PROJECT.\nApparently completed in a day.\nHomer gives it a handful of lines and moves on.\nI, however, have questions.\nFirst of all, where did the materials come from? # Seriously.\nYou\u0026rsquo;ve got an army that\u0026rsquo;s been camped outside Troy for nearly ten years.\nThey\u0026rsquo;re fighting a war.\nAnd suddenly somebody says, essentially, \u0026ldquo;Right, let\u0026rsquo;s build a wall.\u0026rdquo;\nOkay.\nWith what?\nWhere are we sourcing the materials?\nWhat are we building it out of?\nHow much do we need?\nWho\u0026rsquo;s transporting it?\nAnd where are we storing everything while construction is underway?\nThen there\u0026rsquo;s the workforce.\nThese are soldiers.\nNow, I\u0026rsquo;m sure plenty of them had practical skills before joining the war effort, but were there stonemasons? Carpenters? People who knew how to construct defensive fortifications?\nWho was supervising?\nWho decided where the towers went?\nWho designed the gates?\nAnd how exactly did they coordinate all of this around an existing camp full of ships, soldiers, equipment, and supplies?\nWHO WAS RUNNING THIS PROJECT?\nI would genuinely like to know.\nImagine the modern version # If somebody proposed a substantial defensive structure today, we\u0026rsquo;d probably start with a scope of works, drawings, specifications, a budget and a construction program.\nThen, naturally, we\u0026rsquo;d put it out to tender.\nWe\u0026rsquo;d need at least three competitive bids.\nOne contractor would price the wall but exclude the gates.\nAnother would include the gates but make the ditch a provisional sum.\nThe third would submit a beautifully presented proposal that somehow didn\u0026rsquo;t specify what the wall was made of.\nThen we\u0026rsquo;d have several committees to review everything.\nEventually we\u0026rsquo;d appoint a contractor, organise a pre-start meeting and discover that the Greeks had parked an entire fleet of ships in the construction zone.\nThere would be discussions about access, deliveries and where to store materials.\nAnd at least one meeting about the gates.\nAt which point someone would ask whether the gates were wide enough for chariots.\nMeanwhile, Homer gives us:\nWall. Towers. Gates. Ditch.\nCompleted.\nNext.\nI understand that the Iliad isn\u0026rsquo;t a construction management manual.\nI really do.\nAnd I\u0026rsquo;m not suggesting the Greeks didn\u0026rsquo;t plan or coordinate the work. Homer simply doesn\u0026rsquo;t tell us how they did it.\nBut my project manager brain cannot accept that an entire wall has appeared without at least a few follow-up questions.\nEspecially when the whole thing seems to have been completed between breakfast and dinner.\nThe word \u0026ldquo;completed\u0026rdquo; is doing an enormous amount of work here # Actually, there\u0026rsquo;s something about this that I recognise from modern projects.\nI\u0026rsquo;ve worked on projects where months of coordination, troubleshooting, problem-solving and chasing dependencies eventually became four slides in a PowerPoint presentation.\nAnd those four slides were perfectly adequate for the project meeting.\nThe decision-makers needed to know what had been delivered, what remained outstanding, and what decisions were required.\nThey didn\u0026rsquo;t need a documentary about everything we\u0026rsquo;d done to get there.\nI understand that.\nCompletely.\nBut occasionally, when months of painstaking work get summarised as \u0026ldquo;Completed\u0026rdquo;, a small part of me thinks:\nExcuse me. Where is the parade?\nBecause there\u0026rsquo;s a tremendous amount of work that can sit behind one very ordinary word.\nAnd I think that\u0026rsquo;s partly why Homer\u0026rsquo;s wall caught my attention.\nHe tells us what was built.\nMy brain immediately starts trying to reconstruct everything that must have happened between deciding to build it and having an actual functioning defensive structure.\nThe logistics don\u0026rsquo;t disappear just because the story skips over them.\nAlthough apparently my questions are not important enough to interrupt the Trojan War.\nFine.\nAnd then Poseidon gets involved # Because, naturally, completing the wall isn\u0026rsquo;t the end of the story.\nPoseidon notices what the Greeks have built.\nAnd he\u0026rsquo;s not happy.\nApparently, the Greeks have constructed this substantial defensive wall without making the appropriate sacrifices to the gods.\nHe\u0026rsquo;s also concerned that the wall\u0026rsquo;s reputation might overshadow the famous walls of Troy, which he and Apollo had built.\nSo he complains to Zeus.\nAnd Zeus effectively tells him he can destroy the Greek wall after the Greeks have gone home.\nExcuse me.\nYOU\u0026rsquo;VE JUST COMPLETED THE PROJECT, AND THE GODS ARE ALREADY DISCUSSING DEMOLITION?\nImagine putting that in the project close-out report.\nInfrastructure completed successfully.\nStakeholder feedback received.\nA major stakeholder has expressed dissatisfaction and indicated an intention to remove the asset.\nExcellent.\nThe Greeks built the wall in a day, and their first stakeholder complaint came from the god of earthquakes.\nWhich raises one final question.\nDid anyone think to check whether the god responsible for shaking the ground was comfortable with their new infrastructure project?\nBecause I feel like that\u0026rsquo;s a stakeholder you probably want onside.\nOriginally published on LinkedIn.\n","date":"9 October 2026","externalUrl":null,"permalink":"/posts/troy-an-enterprise-transformation-program-part-5/","section":"Articles","summary":"","title":"TROY: An Enterprise Transformation Program: Part 5","type":"posts"},{"content":"I recently asked a contractor to amend an invoice.\nBased on the information they\u0026rsquo;d provided, I couldn\u0026rsquo;t justify everything they were claiming.\nSome of the items looked like duplicates.\nSo I worked out what I could support, started preparing the paperwork, and let them know what needed to change.\nSimple enough.\nExcept the contractor came back and said, essentially:\n“Hang on. That\u0026rsquo;s not quite what happened.”\nAnd then they explained the work in more detail.\nOh.\nRight.\nThat makes sense now.\nTurns out the work was legitimate. The original explanation just hadn\u0026rsquo;t made that particularly clear.\nUnfortunately, I\u0026rsquo;d already spent quite a bit of time preparing the reduced claim.\nWhich meant I now got to spend another twenty minutes undoing what I\u0026rsquo;d just done and putting everything back together properly.\nExcellent.\nBut the new information changed my understanding of the work.\nSo it needed to change my decision.\nIt\u0026rsquo;s not about saying yes or no # A significant part of my work involves reviewing scopes, invoices, and supporting evidence.\nSometimes a contractor has used the wrong code.\nSometimes they\u0026rsquo;ve included two items that can\u0026rsquo;t legitimately be claimed together.\nSometimes there\u0026rsquo;s additional work or labour that needs better justification.\nAnd sometimes everything is perfectly reasonable, but the paperwork doesn\u0026rsquo;t explain why.\nSo I ask questions.\nI request amendments.\nI explain what I can\u0026rsquo;t support and why.\nBut I also do the opposite.\nSometimes a contractor has used a code that doesn\u0026rsquo;t accurately reflect the work they performed, and correcting it works in their favour.\nSometimes additional information justifies something I initially questioned.\nSometimes I can see that the work is legitimate, but the client needs a clearer explanation before they can make a decision.\nIn those situations, I\u0026rsquo;ll work with the contractor to get the information right.\nI\u0026rsquo;m not trying to make every claim smaller.\nI\u0026rsquo;m trying to make every claim defensible.\nFairness has to work in both directions # I think this is where professional credibility starts to build.\nIf I challenge everything, regardless of whether there\u0026rsquo;s a legitimate reason, eventually my objections stop meaning very much.\nBut if I only challenge things when I have a reason, and I can explain that reason, the conversation becomes quite different.\nA contractor can disagree with me.\nThey can explain what I\u0026rsquo;ve misunderstood.\nThey can provide additional evidence.\nAnd sometimes they\u0026rsquo;re right.\nThat\u0026rsquo;s fine.\nI\u0026rsquo;d rather correct my assessment than defend an incorrect decision simply because I made it first.\nConsistency doesn\u0026rsquo;t mean reaching the same decision regardless of new information. It means applying the same standard to the new information.\nAnd over time, people start to recognise how you operate.\nNot that you\u0026rsquo;ll always say yes.\nNot that you\u0026rsquo;ll always say no.\nBut that you\u0026rsquo;ll have a reason for whichever answer you give.\nAnd that you\u0026rsquo;re prepared to explain it.\nWe\u0026rsquo;re working together # I work with contractors regularly, often over long periods of time.\nWe have different responsibilities, and sometimes we disagree about what\u0026rsquo;s reasonable or supportable.\nBut I don\u0026rsquo;t see those conversations as me versus them.\nWe\u0026rsquo;re part of the same delivery team, even when we don\u0026rsquo;t agree on every decision.\nAnd if we\u0026rsquo;re going to keep working together, we need to be able to have those conversations without turning every disagreement into a fight.\nI think that\u0026rsquo;s especially important when you work within a contract that involves multiple organisations, systems and approval processes.\nEach claim needs to stand on its own evidence.\nBut the working relationship continues long after any individual claim is finalised.\nEach claim needs to be defensible on its own. Trust is built across all the claims you\u0026rsquo;ve handled together.\nYour no has credibility # Over time, I\u0026rsquo;ve found that being straightforward with contractors makes these conversations easier.\nIf I can support something, I will.\nIf I can\u0026rsquo;t, I\u0026rsquo;ll explain why.\nIf there\u0026rsquo;s another legitimate option, we\u0026rsquo;ll talk about it.\nAnd if somebody gives me information that changes my understanding, I\u0026rsquo;ll reconsider.\nThat doesn\u0026rsquo;t mean everyone always agrees.\nIt doesn\u0026rsquo;t mean every claim gets approved.\nAnd it certainly doesn\u0026rsquo;t mean the paperwork suddenly becomes less complicated.\nUnfortunately.\nBut it does mean that when I question something, there\u0026rsquo;s a reason.\nAnd the contractor has somewhere useful to go from there.\nSometimes they\u0026rsquo;ll amend the invoice.\nSometimes they\u0026rsquo;ll give me more evidence.\nSometimes they\u0026rsquo;ll explain something I hadn\u0026rsquo;t understood.\nAnd sometimes I\u0026rsquo;ll spend another twenty minutes undoing the paperwork I\u0026rsquo;d just finished.\nBecause the point was never to win the disagreement.\nThe point was to get the decision right.\nYour no doesn\u0026rsquo;t become credible simply by saying it firmly.\nIt becomes credible when people have seen what your yes looks like.\nOriginally published on LinkedIn.\n","date":"8 October 2026","externalUrl":null,"permalink":"/posts/your-no-has-credibility/","section":"Articles","summary":"","title":"Your No Has Credibility","type":"posts"},{"content":"I work with a plumber who has joked more than once about coming to work for him.\nApparently, I do excellent scopes.\nWhich is lovely.\nBut also slightly unfair.\nBecause he gives me half the answer.\nHe knows the plumbing. I know the system.\nA quality scope happens in between.\nWhat actually happened? # On some of the more complicated jobs we work on together, we\u0026rsquo;ll spend a surprisingly long time on the phone reconstructing exactly what happened.\nNot because I know more about plumbing than he does.\nI absolutely do not.\nHe understands the physical system. He knows what he found, what failed, what had to be exposed, what he repaired and why.\nI understand the system that information has to travel through.\nThe reporting requirements. The scope. The codes. The evidence. What the client needs to see to understand what happened and make a decision.\nSo I ask questions.\nWhere exactly was the problem?\nWhat did you expect to find?\nWhat did you actually find once you opened it up?\nWhere did the existing pipework run?\nWhat had to be removed to access it?\nWhat did you replace?\nWhere does the new pipework run?\nWhat could you see before you started, and what only became apparent once the work was underway?\nSometimes we\u0026rsquo;re on the phone for quite a while.\nBut eventually I can see it.\nNot in the way he can see it. I\u0026rsquo;m still not a plumber.\nBut well enough in my mental model to understand what actually happened.\nAnd that\u0026rsquo;s the point where I can start translating.\nSometimes you don\u0026rsquo;t know until you open it up # I think this is an important distinction.\nSometimes the scope changes because somebody got something wrong.\nBut sometimes the scope changes because new information became available.\nYou can only scope what you can reasonably understand from the information available at the time.\nAnd buildings are particularly good at hiding information inside walls, underneath floors, and behind things nobody can see until somebody starts taking them apart.\nOnce the work begins, reality occasionally has some additional comments.\nOn one recent job, the original scope significantly underrepresented the work that ultimately had to be completed.\nThat didn\u0026rsquo;t necessarily mean the original scope was bad.\nSome of the information simply wasn\u0026rsquo;t available yet.\nThe plumbers started the work.\nThey uncovered the problem.\nThey learned more.\nThey adapted the repair to what was actually there.\nAnd now that new information had to make its way back through the rest of the system.\nThat\u0026rsquo;s where I came in.\nYou can\u0026rsquo;t translate what you don\u0026rsquo;t understand # My job wasn\u0026rsquo;t to find a clever way to make the scope bigger.\nIt was to understand what had actually happened well enough to represent it accurately.\nSo we reconstructed the work.\nThe plumber explained the physical reality.\nI asked increasingly specific questions.\nI mapped where the pipework ran, where the issue had been found and where the repair had occurred.\nI made sure the reports clearly showed what had been discovered, including the things that couldn\u0026rsquo;t have been known until the problem was physically uncovered.\nThen I could translate all of that into the system I work within.\nAnd importantly, I could explain it to the client.\nNot:\n“The plumber says we need this. Please approve.”\nBut:\nThis is what we originally understood.\nThis is what was uncovered once the work began.\nThis is where the issue was.\nThis is what was required to fix it.\nAnd this is the evidence showing what happened.\nThe client could see what they were being asked to approve.\nI could stand behind what I was submitting.\nAnd the plumber could be paid fairly for legitimate work that had actually been completed.\nThe work didn\u0026rsquo;t become worth more because I found better codes.\nThe work had already happened. The original scope just didn\u0026rsquo;t capture all of it.\nNeither of us had the whole answer # This is the bit I love.\nThe plumber couldn\u0026rsquo;t produce my half of the answer without understanding the system I work within.\nI couldn\u0026rsquo;t produce his half without understanding what had physically happened.\nNeither of us needed to become an expert in the other\u0026rsquo;s field.\nWe needed enough shared understanding to connect the two.\nAnd when we did, we produced something neither of us could have produced as well alone.\nThe plumber brought deep specialist knowledge.\nI brought knowledge of the contractual, reporting, and approval system that his work had to move through.\nThe client brought another perspective again: they needed enough clear, defensible information to understand what they were approving.\nThe answer existed at the interface.\nI think this is why I keep ending up here # I\u0026rsquo;ve worked across some very different industries.\nAnd I\u0026rsquo;ve realised that a surprising amount of the work I enjoy most happens in these spaces.\nBetween the technical specialist and the client.\nBetween the physical problem and the system used to record it.\nBetween what happened and how we explain what happened.\nBetween one person\u0026rsquo;s expertise and another person\u0026rsquo;s decision.\nI like learning enough about one side to translate it properly to the other.\nNot pretending to be the specialist.\nNot stripping out so much complexity that the meaning disappears.\nJust understanding enough to ask useful questions, identify what matters, and carry the information across without distorting it.\nBecause sometimes the specialist doesn\u0026rsquo;t need to learn your entire system.\nAnd the client doesn\u0026rsquo;t need to become a specialist.\nThey need someone who understands enough of both to help them understand each other.\nThat\u0026rsquo;s the work I love.\nThe bit in between.\nThe work that happens at the interface.\nOriginally published on LinkedIn.\n","date":"7 October 2026","externalUrl":null,"permalink":"/posts/i-love-the-work-that-happens-at-the-interface/","section":"Articles","summary":"","title":"I Love the Work That Happens at the Interface","type":"posts"},{"content":" Part 4: Even Projects Need Space to Breathe # Reading The Iliad, the fighting often feels incredibly fast to me.\nPeople are everywhere.\nThings are happening constantly.\nI\u0026rsquo;m trying to remember who everyone is, which god has intervened now, who just got stabbed, and whose dad I\u0026rsquo;m apparently also supposed to remember.\nAnd then occasionally everything slows down.\nThose quiet moments feel different.\nAnd strangely, they\u0026rsquo;re some of the moments I remember most clearly.\nThere\u0026rsquo;s one in Book 6 that I particularly love.\nHector has returned to Troy and finds his wife, Andromache, and their young son.\nIt\u0026rsquo;s not exactly a carefree family reunion.\nThere\u0026rsquo;s a war happening outside.\nAndromache is frightened about what will happen to Hector.\nHector knows perfectly well that Troy may fall.\nThen, in the middle of all of that, Hector reaches for his son.\nAnd his son takes one look at his father\u0026rsquo;s enormous horsehair-crested helmet and is terrified.\nHector and Andromache laugh.\nSo Hector takes the helmet off, puts it on the ground, picks up his son and holds him.\nFor a moment, everything feels very small.\nNot armies.\nNot gods.\nNot kings.\nJust a mum and dad laughing because their baby is scared of Dad\u0026rsquo;s ridiculous helmet.\nAnd I think it\u0026rsquo;s one of my favourite moments in The Iliad so far.\nWe are very good at filling the space # Which got me thinking about projects.\nBecause modern project language contains a lot of words about getting things done.\nSprints.\nVelocity.\nUtilisation.\nOptimisation.\nDeliverables.\nMilestones.\nThroughput.\nCapacity.\nAll useful concepts.\nBut spend enough time talking this way, and it\u0026rsquo;s remarkably easy to start describing human beings as though they\u0026rsquo;re processing units.\nHow much capacity do we have?\nAre we fully utilised?\nCan we increase throughput?\nCan we optimise this?\nWhat\u0026rsquo;s going into the next sprint?\nAnd there\u0026rsquo;s nothing inherently wrong with those questions.\nThe problem comes when we start trying to optimise every visible minute of human activity.\nBecause some of the apparently unproductive space is where people think.\nIt\u0026rsquo;s where they connect.\nIt\u0026rsquo;s where they process.\nIt\u0026rsquo;s where creativity has enough room to happen.\nSometimes somebody says something over coffee that solves the problem everyone has been staring at for two days.\nSometimes your brain makes a connection precisely because you\u0026rsquo;ve stopped demanding that it make one.\nSometimes two people talk about something completely unrelated to the project and understand each other a little better afterward.\nSometimes somebody finally has enough room to realise we\u0026rsquo;ve been solving the wrong problem.\nAnd sometimes absolutely nothing professionally useful happens.\nAnd that\u0026rsquo;s allowed too.\nPlease don\u0026rsquo;t optimise the break # I don\u0026rsquo;t mean that we should now add MANDATORY CREATIVITY DOWNTIME to the project plan.\nThat feels like exactly the sort of thing we\u0026rsquo;d do.\n9:00–9:15 — Stand-up\n9:15–10:00 — Focused delivery\n10:00–10:17 — Unstructured spontaneous human connection and innovation\nExcellent.\nWe\u0026rsquo;ve optimised the unoptimised time.\nNor do I think every quiet moment needs to justify itself by eventually producing a better deliverable.\nRest doesn\u0026rsquo;t have to earn its place by increasing productivity.\nPeople aren\u0026rsquo;t project resources every minute of their existence.\nThey\u0026rsquo;re people.\nSometimes we need space simply because human brains cannot sprint indefinitely.\nSometimes we need to laugh.\nSometimes we need to talk.\nSometimes we need to stare at absolutely nothing for a while.\nSometimes we need to go home and be somebody\u0026rsquo;s partner, parent, or friend.\nAnd yes, sometimes something genuinely useful or creative comes out of that space.\nBut that can\u0026rsquo;t be the admission price.\nThe quiet moments matter too # I think that\u0026rsquo;s partly why that little scene in The Iliad stayed with me.\nThe war hasn\u0026rsquo;t gone anywhere.\nHector still has responsibilities.\nAndromache is still frightened.\nNothing about their situation has been solved.\nBut for this tiny moment, the pace changes.\nHector takes off the helmet.\nTheir baby does something funny.\nThey laugh.\nAnd then Hector picks the helmet back up.\nThe fighting continues.\nThe work always continues.\nBut the quiet moment mattered anyway.\nAnd I think projects need those moments too.\nNot because we\u0026rsquo;ve calculated the optimum amount of rest required to maximise human output.\nNot because every coffee needs to produce an innovative solution.\nNot because downtime needs a business case.\nBecause the people doing the project are still people.\nAnd sometimes those moments are the most memorable part of the whole project because we are people, not sprint machines.\nThousands of years later, among all the battles, warriors, kings, and gods, one of the moments I remember most clearly is a little boy being frightened by his dad\u0026rsquo;s helmet.\nThe project will still be there.\nThe next sprint will still be there.\nThe milestone will still be there.\nSometimes people need enough space to take off the helmet.\nOriginally published on LinkedIn.\n","date":"6 October 2026","externalUrl":null,"permalink":"/posts/troy-an-enterprise-transformation-program-part-4/","section":"Articles","summary":"","title":"TROY: An Enterprise Transformation Program: Part 4","type":"posts"},{"content":" Part 3: When the Gods Are on the Steering Committee # By this point in The Iliad, I had started getting reasonably comfortable with the project structure.\nThere are Greeks.\nThere are Trojans.\nThere are various kings, warriors, and other critical resources.\nAnd above all of them are the gods.\nGreat.\nGovernance.\nExcept then I started paying attention to what the gods were actually doing.\nAnd I have some concerns about the governance model.\nZeus has made a side agreement # Back in Book 1, after Agamemnon takes Briseis and Achilles withdraws from the fighting, Achilles asks his mother, Thetis, to speak to Zeus.\nThetis does.\nShe asks Zeus to give the Trojans the advantage until the Greeks realise how much they need Achilles and restore his honour.\nZeus agrees.\nHe also knows Hera isn\u0026rsquo;t going to be happy about it.\nSo our ultimate authority over the project has now made a commitment to the mother of a critical resource, which will affect the direction of the entire war, while knowing that another member of governance has very different ideas about the desired outcome.\nExcellent.\nThis project continues to go extremely well.\nBut Zeus isn\u0026rsquo;t the only complication.\nThe gods aren\u0026rsquo;t sitting somewhere above the war, impartially observing what happens below them.\nThey have favourites.\nThey have relationships.\nThey have history.\nThey have grudges.\nAnd, most importantly, they have their own objectives.\nDifferent gods support different sides and different people.\nAnd they don\u0026rsquo;t restrict themselves to providing strategic oversight.\nThey intervene directly in delivery.\nWhich raises a fairly significant governance question.\nWhat does authority actually mean when the people inside the governance structure have competing interests of their own?\nZeus is still in charge # The strange thing is that Zeus\u0026rsquo;s authority is real.\nWhen Zeus decides the gods are not to interfere in the fighting, he can establish that rule.\nAnd for a while, it works.\nMostly.\nUntil the gods watching events unfold become unhappy enough with the consequences that they start considering intervention again.\nHera and Athena, in particular, are not delighted with how things are progressing.\nThey prepare to intervene.\nZeus notices.\nThey are stopped.\nAnd Olympus requires what I have decided to classify as another progress and disciplinary meeting.\nThis seems to happen quite a lot.\nZeus makes a decision.\nThe gods follow it.\nSomeone becomes unhappy with the consequences.\nSomeone starts interfering.\nZeus discovers the interference.\nEverybody returns to Olympus for another conversation about what we\u0026rsquo;re all supposed to be doing.\nApparently, one of Zeus\u0026rsquo;s recurring responsibilities is governing the governance.\nThis looks nothing like modern governance # On the surface, obviously, it doesn\u0026rsquo;t.\nMost steering committees I\u0026rsquo;ve encountered contain considerably fewer immortal beings personally entering the battlefield.\nWe would also probably have some questions about conflicts of interest if members of the same governance body were actively supporting two organisations trying to destroy each other.\nModern governance generally tries to avoid that.\nBut once I stopped looking at the gods and started looking at the structure underneath them, something became surprisingly familiar.\nBecause modern governance doesn\u0026rsquo;t make competing priorities disappear either.\nPutting decision-makers around a table doesn\u0026rsquo;t mean everyone suddenly wants exactly the same thing.\nThe different priorities come into the room with them.\nAnd that\u0026rsquo;s not necessarily a problem.\nIn many cases, that\u0026rsquo;s exactly why those people are there.\nDifferent priorities are part of the point # A technical lead might be focused on feasibility and technical risk.\nFinance might be focused on cost.\nOperations might be thinking about what can actually be supported once the project is delivered.\nSomeone representing the customer or the business might be focused on whether the thing we\u0026rsquo;re building actually solves the problem it was supposed to solve.\nThey can all be looking at exactly the same project and legitimately care about different things.\nDifferent responsibilities.\nDifferent risks.\nDifferent priorities.\nDifferent values.\nDifferent opinions about what matters most.\nThe governance mechanism exists partly so those competing considerations can be made visible and a decision can be reached.\nThat doesn\u0026rsquo;t mean everybody splits the difference.\nSometimes one priority legitimately wins.\nSometimes there\u0026rsquo;s a compromise.\nSometimes somebody produces another option.\nSometimes the committee decides:\nWe understand the risk. We\u0026rsquo;re accepting it because another objective matters more.\nThe point isn\u0026rsquo;t that everybody walks out wanting exactly the same thing.\nThe point is that there is a mechanism for reaching a decision and clarity about who has the authority to make it.\nWhich brings me, back to Zeus.\nSomeone still has to decide # Olympus has competing priorities in abundance.\nThe difference is that the gods aren\u0026rsquo;t simply bringing different professional perspectives to the same project objective.\nThey\u0026rsquo;re supporting different sides of the war.\nWhich does make the governance model somewhat harder to recommend.\nBut when Zeus makes a decision and chooses to enforce it, there is an ultimate decision-maker.\nThat doesn\u0026rsquo;t make Hera agree with him.\nIt doesn\u0026rsquo;t remove Athena\u0026rsquo;s interests.\nIt doesn\u0026rsquo;t stop the other gods having favourites, relationships, grievances, or opinions.\nIt establishes what happens next.\nAt least until the next intervention.\nAnd the next escalation.\nAnd presumably another meeting.\nGovernance is still part of the system # At first, the governance of the Trojan War looked completely alien.\nGods supporting opposing armies.\nPersonal grudges.\nFamily relationships.\nSide agreements.\nDirect intervention in delivery.\nThe occasional disciplinary meeting on Olympus.\nAnd yes, I think we\u0026rsquo;d identify a few conflicts of interest.\nBut underneath all of that, something much more familiar is happening.\nGovernance doesn\u0026rsquo;t sit outside the system. It\u0026rsquo;s part of the system.\nThe people making decisions bring their own expertise, responsibilities, priorities, relationships, and opinions with them.\nDifferent priorities inside governance aren\u0026rsquo;t necessarily a problem.\nSometimes that\u0026rsquo;s exactly why those people are there.\nThe challenge is having a way to make those competing considerations visible, reach a decision, and establish who has the authority to decide what happens next.\nIn The Iliad, ultimately, that\u0026rsquo;s Zeus.\nWhich means that alongside thunderbolts, fate, family disputes, and managing an unusually interventionist group of gods, Zeus appears to have acquired another recurring responsibility:\nGoverning the governance.\nWelcome to the steering committee.\nOriginally published on LinkedIn.\n","date":"5 October 2026","externalUrl":null,"permalink":"/posts/troy-an-enterprise-transformation-program-part-3/","section":"Articles","summary":"","title":"TROY: An Enterprise Transformation Program: Part 3","type":"posts"},{"content":"I\u0026rsquo;ve noticed something slightly strange about the word understand.\nSometimes when I tell someone,\n“I understand.”\nthey seem to hear,\n“I agree with you.”\nAnd that\u0026rsquo;s usually not what I mean.\nWhat I mean is:\nI can see how you got there.\nI can follow the information you started with, the assumptions you made, the things you were trying to protect or achieve, and the reasoning that led you to your conclusion.\nI might still think you\u0026rsquo;re wrong.\nIn fact, sometimes disagreements are the most interesting conversations.\nBecause once I understand how someone got to a conclusion I don\u0026rsquo;t share, we have somewhere useful to go next.\nWhere did we actually disagree? # If all we have are our conclusions, a disagreement can look pretty simple.\nYou think A.\nI think B.\nExcellent.\nWe\u0026rsquo;ve established that we disagree.\nNow what?\nBut if I understand how you got to A, we can start comparing the path rather than arguing about the destination.\nMaybe you have information I don\u0026rsquo;t have.\nMaybe I have information you don\u0026rsquo;t have.\nMaybe one of us has made an assumption the other hasn\u0026rsquo;t.\nMaybe we\u0026rsquo;re looking at exactly the same information, but we value different things.\nOr maybe we\u0026rsquo;re starting from different values altogether, and those values are shaping how each of us reasons about the same situation.\nMaybe we agree about almost everything, but we weigh one particular risk differently.\nOr maybe one of us is just wrong.\nThat\u0026rsquo;s useful too.\nBecause now we\u0026rsquo;ve located the disagreement.\nAnd once you know where two people\u0026rsquo;s reasoning diverges, you can actually do something with it.\nUnderstanding also gives me the opportunity to change my mind # This part matters.\nTrying to understand someone isn\u0026rsquo;t just a more sophisticated way of explaining to them why I\u0026rsquo;m right.\nSometimes I follow somebody else\u0026rsquo;s reasoning and discover that they have a point.\nThey knew something I didn\u0026rsquo;t.\nThey spotted a consequence I hadn\u0026rsquo;t considered.\nOr I discover that one of the premises I was confidently building my position on isn\u0026rsquo;t actually true.\nGreat.\nI\u0026rsquo;d rather find that out.\nIf someone gives me information I didn\u0026rsquo;t have before, and it changes how I understand the situation, why wouldn\u0026rsquo;t I change my mind?\nThat\u0026rsquo;s what the information was for.\nBut sometimes we go through the whole thing and still disagree.\nThat\u0026rsquo;s okay too.\nUnderstanding isn\u0026rsquo;t agreement.\nIt just means I can see the model you\u0026rsquo;re working from.\nThis matters enormously on projects # Projects bring together people who know different things, care about different things, and are responsible for different things.\nThe technical specialist sees one set of risks.\nOperations sees another.\nThe client has priorities.\nFinance has constraints.\nDelivery has dependencies.\nThe person actually using whatever we\u0026rsquo;re building, changing, or maintaining may have an entirely different perspective again.\nWe\u0026rsquo;re not always going to agree.\nAnd I\u0026rsquo;m not sure agreement should even be the goal.\nIf every stakeholder has to get 100% of what they originally wanted before we can move forward, we\u0026rsquo;re going to have some very long meetings.\nBut people do need to be heard.\nAnd I don\u0026rsquo;t mean the performative version of consultation where everybody gets five minutes to speak before we proceed with the decision we already made.\nI mean genuinely trying to understand:\nWhat do you know that I don\u0026rsquo;t?\nWhat are you concerned about?\nWhat outcome are you trying to protect?\nWhat constraints are you working within?\nHow did you get to your position?\nBecause sometimes that information changes the decision.\nSometimes it doesn\u0026rsquo;t.\nBeing heard isn\u0026rsquo;t the same as getting your way # I think we sometimes confuse these too.\nA stakeholder can disagree with the final decision and still understand why it was made.\nThey can see what information was considered.\nThey can see where their concerns fit into the decision.\nThey can understand the constraints.\nThey can disagree with the weighting.\nThey can even walk away thinking they would have made a different call.\n“That isn\u0026rsquo;t the decision I wanted, but I understand why we\u0026rsquo;re doing it.”\nis a very different project environment from:\n“Nobody listened to me.”\nThe outcome might be exactly the same.\nThe process wasn\u0026rsquo;t.\nAnd that matters because projects don\u0026rsquo;t happen between boxes on an organisational chart.\nThey happen between people who need to keep working together after this particular disagreement is finished.\nCuriosity comes before agreement # Maybe that\u0026rsquo;s the bit I\u0026rsquo;ve been getting at when I say I understand someone.\nI\u0026rsquo;m not awarding them points for being right.\nI\u0026rsquo;m curious about how their model works.\nAnd I think I\u0026rsquo;ve realised that my natural order is:\nCuriosity → Understanding → Agreement or Disagreement\nNot:\nAgreement → Permission to Understand\nUnderstanding isn\u0026rsquo;t the reward we give people for being right.\nIt\u0026rsquo;s the reward we get for being curious.\nAnd sometimes understanding will change my mind.\nSometimes it will change yours.\nSometimes neither of us is going anywhere.\nThat\u0026rsquo;s fine.\nAgreement isn\u0026rsquo;t the goal of every conversation.\nSometimes understanding is progress.\nBecause understanding doesn\u0026rsquo;t require agreement.\nIt gives us somewhere useful to disagree from.\nOriginally published on LinkedIn.\n","date":"4 October 2026","externalUrl":null,"permalink":"/posts/understanding-isnt-agreement/","section":"Articles","summary":"","title":"Understanding Isn’t Agreement","type":"posts"},{"content":" When Two Critical Stakeholders Want Different Things # Before I could even get onto solid ground about who everyone was in The Iliad, Achilles and Agamemnon were already deep into what I think we can safely describe as a fairly significant stakeholder disagreement.\nWhich is fine, I suppose.\nWe are still on a beach.\nAgamemnon is forced to give up Chryseis after Apollo sends a plague through the Greek camp. He agrees to return her, but he isn\u0026rsquo;t prepared to be the only leader left without a prize.\nSo he takes Briseis from Achilles.\nAchilles is furious.\nAnd he doesn\u0026rsquo;t just get angry with Agamemnon.\nHe withdraws from the fighting.\nSuddenly, a disagreement between two people has consequences for an entire army.\nThat got my attention.\nAnd my first reaction was basically:\nYeah. I can see why.\nBut I couldn\u0026rsquo;t quite get all the way onto Team Achilles.\nBecause while I could understand why he was angry, there was another thought sitting in the back of my project-manager brain:\nThere are a lot of people depending on you.\nIt wasn\u0026rsquo;t really about one woman # One of the things I have always struggled to understand about the Trojan War is the idea of going to war over one person.\nHelen.\nThen I started The Iliad and almost immediately found myself in another enormous argument involving Chryseis and Briseis.\nI had questions.\nBut the more I started understanding the world these people were operating in, the more I realised I was looking at the argument too literally.\nThis isn\u0026rsquo;t simply an argument about who gets Briseis.\nHonour and status matter enormously in the world of The Iliad.\nThe prizes awarded to warriors aren\u0026rsquo;t just possessions. They are public recognition of honour and standing.\nSo when Agamemnon takes Briseis from Achilles, Achilles doesn\u0026rsquo;t experience it simply as losing something he wants.\nHe experiences it as an attack on his honour.\nAnd Agamemnon\u0026rsquo;s position in the dispute is bound up with status and authority too.\nHe is the leader of the Greek expedition, and he isn\u0026rsquo;t prepared to be the only leader left without a prize.\nSuddenly, the argument looked very different to me.\nThese aren\u0026rsquo;t just two powerful men wanting different things.\nThey both care deeply about how they are recognised and treated.\nThey have different perspectives on what their positions mean, what they are entitled to, and what respect looks like.\nAnd now we have a stakeholder problem.\nProjects are manifestations of things people care about # Nobody allocates money, labour, time, expertise, attention, and reputation to an outcome that absolutely nobody values.\nProjects are manifestations of things people care about.\nAnd that means projects are emotional before the first spreadsheet ever gets created.\nWe make them look rational because that\u0026rsquo;s useful.\nWe give them objectives, schedules, budgets, resources, milestones, risks, dependencies, and governance structures.\nSometimes the spreadsheet leads us to forget that.\nUnderneath all projects are people.\nAnd those people care about things.\nThey care about the outcome.\nBut they also care about their expertise being respected. Their contribution being recognised. Their authority. Their autonomy. Their reputation. Their relationships.\nThey care about whether they\u0026rsquo;ve been consulted.\nWhether somebody kept their word.\nWhether they\u0026rsquo;ve been treated fairly.\nDifferent people will care about different combinations of those things.\nAnd that\u0026rsquo;s why stakeholder disagreements can derail even the best-intended projects.\nNot necessarily because someone is irrational.\nNot necessarily because somebody is the “difficult stakeholder.”\nNot necessarily because one of them is wrong.\nSometimes two people can both be behaving in ways that make complete sense from where they\u0026rsquo;re standing, and the wider system still has to absorb the consequences.\nUnderstanding someone isn\u0026rsquo;t the same as agreeing with them # I think that\u0026rsquo;s why I couldn\u0026rsquo;t completely agree with Achilles.\nI could understand him.\nFrom where he was standing, something deeply important had happened.\nHis honour had been publicly challenged by someone he was already in conflict with.\nHis anger made much more sense once I understood that.\nBut understanding someone\u0026rsquo;s position doesn\u0026rsquo;t make the consequences of their response disappear.\nAchilles withdraws.\nThe disagreement might be between Achilles and Agamemnon, but the consequences aren\u0026rsquo;t contained to Achilles and Agamemnon.\nThere are a lot of other people on that beach.\nThat\u0026rsquo;s a very familiar project problem.\nA disagreement between two people can look interpersonal right up until you discover that the rest of the project depends on those two people continuing to work together.\nThen their relationship becomes part of the project environment.\nAnd you don\u0026rsquo;t necessarily get the luxury of deciding who is right before you have to deal with what happens next.\nThe spreadsheet isn\u0026rsquo;t the project # I like project-management frameworks.\nI like systems.\nThey help us take complicated things and make them visible.\nBut there\u0026rsquo;s a danger in making a project look so orderly on paper that we forget what we\u0026rsquo;re actually trying to organise.\nPeople.\nPeople who care about things.\nPeople with history.\nPeople with expertise.\nPeople with competing priorities.\nPeople who want to be respected.\nPeople who occasionally become furious with each other.\nThe plan might say that one workstream depends on another.\nThe org chart might tell you who has authority.\nThe stakeholder register might tell you who needs to be consulted.\nNone of those things can completely capture what happens when two critical people look at the same situation and experience it very differently.\nI\u0026rsquo;m still not sure whose side I\u0026rsquo;m on in the Achilles–Agamemnon argument.\nI\u0026rsquo;m not sure I need to be on a side.\nWhat interests me more is that I can understand why both of them believe something important is at stake.\nAnd once two critical stakeholders believe that, their disagreement doesn\u0026rsquo;t stay between them.\nThe wider system has to absorb the consequences.\nWe put projects into spreadsheets because we need somewhere to keep the plan.\nBut the project still happens between people.\nOriginally published on LinkedIn.\n","date":"3 October 2026","externalUrl":null,"permalink":"/posts/troy-an-enterprise-transformation-program-part-2/","section":"Articles","summary":"","title":"TROY: An Enterprise Transformation Program: Part 2","type":"posts"},{"content":" Part 1: Welcome to the Project # I\u0026rsquo;ve been reading The Iliad.\nI\u0026rsquo;m partway through it now, and honestly, it\u0026rsquo;s been a mission.\nIt\u0026rsquo;s been sitting on my “I really should read that someday” list for years, and I finally made it a priority.\nI’m just going to state the obvious here:\nI am not a Homer scholar.\nI\u0026rsquo;m a project manager.\nWhich means that somewhere during the reading, my brain started doing what it always does when I encounter something unfamiliar:\nWhat are the similar aspects here?\nAnd unfortunately for everyone involved, I started looking at the Trojan War like a project.\nNow I can\u0026rsquo;t stop.\nSo this is apparently going to be a series.\nWelcome to Year Ten # When I started The Iliad, I had absolutely no idea what was going on.\nI didn\u0026rsquo;t grow up on the ancient Greek stories. I knew Zeus. I knew the names of a couple of the other gods. I\u0026rsquo;d even tried watching the movie Troy years ago and only made it about halfway through because, at the time, it made absolutely no sense to me.\nNow I’ve started reading The Iliad and realised I\u0026rsquo;d basically been dropped into a project ten years into delivery.\nOf course I had no idea what was going on.\nEveryone else already has context.\nThere are kings, warriors, gods, alliances, grudges, families and relationships everywhere.\nPeople have history with each other that I don\u0026rsquo;t know about.\nThe gods have history with each other that I definitely don\u0026rsquo;t know about.\nEveryone already seems to know why we\u0026rsquo;re here.\nAnd we\u0026rsquo;re all living on a beach.\nI had questions.\nWhat is this project actually about?\nWhy are we here?\nWhat have we already done?\nWhat was the original objective?\nIs that still the objective?\nWhat resources do we have?\nWho\u0026rsquo;s actually making the decisions?\nWho are all these stakeholders?\nDoes this project have a plan?\nWhy are we on a beach?\nAnd somewhere in all of that confusion, I realised:\nOh. I know this feeling.\nI\u0026rsquo;ve been dropped into a messy project that\u0026rsquo;s already well underway.\nEverybody else already has the context # There\u0026rsquo;s a particular kind of confusion that comes with joining an established project.\nEveryone who\u0026rsquo;s been there for a while knows why things are the way they are.\nThey know the history.\nThey know which decisions have already been made.\nThey know who technically owns something and who actually makes the decision.\nThey know which workaround exists because of something that happened six months ago.\nThey know which two stakeholders have history.\nYou don\u0026rsquo;t.\nSo before I can start making sense of a messy project, I usually need to build myself a mental model.\nWhere are we now?\nHow did we get here?\nWho are the people involved?\nWhat does each of them want?\nWhat depends on what?\nWhat am I missing?\nIt turns out this is also how my brain decided to read Homer.\nI wasn\u0026rsquo;t analysing The Iliad.\nI was trying to orient myself inside it.\nAnd slowly, as the people and relationships started making more sense, the giant cloud of WHO IS EVERYONE? started turning into something resembling a system.\nWhich meant my brain was finally free to ask the next annoying project-management question:\nWhy are we still doing this?\nIs the project still viable? # One of the things I like about modern project-management frameworks is the idea that approving a project once doesn\u0026rsquo;t mean you should keep doing it forever.\nPRINCE2 calls this continued business justification.\nEssentially, throughout a project, you keep checking whether it still makes sense to continue.\nIs it still worthwhile?\nIs it still viable?\nIs it still achievable?\nHave the circumstances changed?\nDoes the original justification still hold?\nIf it doesn\u0026rsquo;t, the answer isn\u0026rsquo;t necessarily to keep going because we\u0026rsquo;ve already come this far. The project may need to change or stop.\nWhich is an extremely entertaining concept to have rattling around in your head while reading about a war entering its tenth year.\nI am absolutely not qualified to assess the business case for the Trojan War.\nI\u0026rsquo;m still trying to remember everyone\u0026rsquo;s names.\nBut I do want to ask:\nWhat are we trying to achieve now?\nIs it the same thing we were trying to achieve when this started?\nWhat does done look like?\nAnd how did we get all the way to Year Ten?\nBecause by the time The Iliad begins, there is quite a lot going on.\nWe\u0026rsquo;ve got major stakeholder disagreements.\nOne particularly important resource is extremely unhappy.\nThere are some interesting questions about who actually holds authority.\nAnd governance is heavily involved, except governance consists partly of gods who don\u0026rsquo;t necessarily agree with each other.\nI have thoughts.\nBut those are problems for another article.\nFor now, I\u0026rsquo;m still getting my head around the project.\nCurrent status: Year Ten\nOriginal objective: We should probably check\nContinued business justification: I have questions\nStakeholder alignment: We\u0026rsquo;ll get to that\nGovernance: Complicated by gods\nWelcome to the project.\nOriginally published on LinkedIn.\n","date":"2 October 2026","externalUrl":null,"permalink":"/posts/troy-an-enterprise-transformation-program-part-1/","section":"Articles","summary":"","title":"TROY: An Enterprise Transformation Program: Part 1","type":"posts"},{"content":"When I was about thirteen, I decided I needed a more lucrative skill.\nI\u0026rsquo;d already asked my parents what I could do to earn some extra money, and they\u0026rsquo;d given me a perfectly reasonable answer:\nClean the office.\nSo I did.\nI got paid for it. I\u0026rsquo;m fairly sure my mother had to redo a fair amount of my work in the beginning.\nEventually, though, I was over cleaning.\nI wanted to learn something else.\nSo I asked Mum to teach me something I could actually use to make money.\nShe decided to teach me bookkeeping.\nThis was probably a fairly unusual response to a then thirteen-year-old asking for more pocket money, but it worked out surprisingly well.\nEverything is basically a database # Mum had spent years working with business systems and databases, so when she started teaching me MYOB, she didn\u0026rsquo;t begin with a thrilling lecture about debits and credits.\nThank God.\nShe explained the system.\nMYOB was basically a database.\nFileMaker, which they also used, was basically a database.\nDifferent front ends. Different purposes. But underneath, you\u0026rsquo;re putting information into a structured system so you can do something useful with it later.\nAnd Mum had a phrase for this:\nEverything is basically a database.\nThat made sense to me.\nIf you put good information in, you could get useful information out.\nIf you put rubbish in, well\u0026hellip;\nThe database wasn\u0026rsquo;t going to magically fix it for you.\nSo I learned MYOB.\nThen I learned bookkeeping.\nEventually I started doing my parents\u0026rsquo; bookkeeping, then bookkeeping for some of their clients, and eventually I had my own little bookkeeping business while I was still at school.\nAnd that\u0026rsquo;s where I discovered something else.\nBookkeeping is surprisingly good detective training # A database is only useful if the information inside it bears some resemblance to what actually happened.\nAnd sometimes figuring out what actually happened takes considerably more work than typing numbers into MYOB.\nWhere did this payment come from?\nWhat was this purchase actually for?\nWhich customer does this relate to?\nWhy doesn\u0026rsquo;t this reconcile?\nWhat the hell happened here?\nSuddenly bookkeeping wasn\u0026rsquo;t just data entry.\nIt was detective work.\nYou had to establish what had actually happened, classify it correctly, put the right information in the right place, and make sure the relationships between things made sense.\nBecause eventually somebody was going to ask the system a question.\nHow much did we spend?\nWhat do we owe?\nWho owes us money?\nHow is the business actually doing?\nAnd the quality of the answer depended on the quality and structure of the information we\u0026rsquo;d put in.\nThat idea stuck.\nThen MYOB became Xero # Later, I started working with clients who used Xero.\nDifferent software.\nDifferent interface.\nDifferent buttons.\nBut underneath?\nBasically a database.\nSo instead of treating Xero as an entirely new universe, I could ask:\nWhere does this information go?\nHow do I enter the same thing here?\nHow does this system categorise it?\nWhat connects to what?\nHow do I get the reporting I need back out?\nOnce I understood the underlying structure, I could learn the differences.\nAnd then the same thing kept happening.\nFileMaker.\nExcel.\nBusiness systems.\nProject management systems.\nDifferent interfaces. Different terminology. Different purposes.\nBut I kept asking variations of the same questions.\nWhat information is going in?\nHow is it being organised?\nWhat connects to what?\nAnd what do we need to get back out?\nMore data isn\u0026rsquo;t necessarily better data # Eventually I learned another part of the lesson.\nTechnically, you can capture everything.\nYou can create another field.\nAnd another one.\nAnd another one.\nYou can record every conceivable piece of information just in case someone, somewhere, someday decides they might like to know it.\nYou can also spend an unreasonable amount of everyone\u0026rsquo;s life entering data nobody ever uses.\nSo the question changed.\nInstead of:\nWhat information can we capture?\nI started asking:\nWhat do we actually need this system to tell us?\nIf we need a particular report, decision, trigger, or outcome at the end, what information needs to exist at the beginning?\nStart with the question you want the system to answer.\nThen work backwards to the information it needs.\nBecause good data isn\u0026rsquo;t just accurate.\nIt also has to be useful.\nSomewhere along the way, the idea got bigger # Over time, “everything is basically a database” became “everything is basically a system.”\nNot because I suddenly discovered some grand theory of how the world works.\nI think Mum had just given me language for something my brain was already doing.\nWhen something was unfamiliar, I looked for the familiar structure underneath it.\nOnce I recognised the structure, I had somewhere to put the unfamiliar bits.\nA new piece of software didn\u0026rsquo;t have to be completely new.\nA new industry didn\u0026rsquo;t have to be completely new.\nA new project didn\u0026rsquo;t have to be completely new.\nThere was usually something underneath it that I already understood.\nThen I could learn what was different.\nI\u0026rsquo;m 37 now, and Mum and I still joke about it.\nI\u0026rsquo;ll be telling her about some completely different industry, project, or system I\u0026rsquo;ve wandered into, and somehow we\u0026rsquo;ll end up back at the same conclusion.\nEverything is basically a database.\nWhich, somewhere along the way, became:\nEverything is basically a system.\nAnd eventually, in my own slightly less elegant terminology:\nIt\u0026rsquo;s all the bloody same.\nOriginally published on LinkedIn.\n","date":"1 October 2026","externalUrl":null,"permalink":"/posts/everything-is-basically-a-database/","section":"Articles","summary":"","title":"Everything Is Basically a Database","type":"posts"},{"content":"I really like people who know an extraordinary amount about one specific thing.\nGive me someone who has spent twenty years understanding fibre networks, air-conditioning systems, finance, software architecture, industrial equipment, plumbing, trees, or some tiny piece of infrastructure most of us never think about, and I\u0026rsquo;m probably going to start asking them questions.\nFortunately, I\u0026rsquo;ve somehow built a career where sticking my nose into other people\u0026rsquo;s areas of expertise and asking them how things work is often part of my job.\nIt\u0026rsquo;s brilliant.\nI started in bookkeeping and business services, which meant getting little windows into completely different businesses.\nCafés. Air-conditioning businesses. Churches. Nonprofits. Small businesses and organisations where one person seemed to know how absolutely everything worked.\nEvery business had its own little ecosystem, and I had the privilege of learning a bit about each one.\nThen I moved into telecommunications and technology and discovered an entirely new collection of people who knew extraordinary amounts about very specific things.\nNetwork engineers. Fibre specialists. VoIP specialists. Developers. Security people. Finance people. Commercial people.\nPeople who could happily spend an hour discussing some tiny technical detail I hadn\u0026rsquo;t known existed that morning.\nI loved it.\nAnd project work gave me a perfectly legitimate reason to ask:\nWait. What\u0026rsquo;s that?\nWhy does it work like that?\nWhat happens if that bit fails?\nWhy can\u0026rsquo;t we just do this?\nAnd, my personal favourite:\nCan you explain that to me again, but assume I know absolutely nothing about it?\nThe dad bods of industrial equipment # Years ago, I was involved in a series of events around Australia with a company that made specialised technical equipment for industrial environments.\nThink small but critical components within much larger industrial systems. The sort of equipment most of us would probably never notice, but which has a very important job to do.\nI was chatting to one of their sales guys, and he was explaining some of their products to me.\nWhat fascinated me was the expected lifespan.\nSome of this equipment had to be installed into pretty unforgiving industrial environments — heat, cold, vibration, and all the other things machinery generally doesn\u0026rsquo;t appreciate — and then essentially just\u0026hellip;\nwork.\nFor years.\nPotentially decades.\nHe\u0026rsquo;d been explaining this to me when he said something along the lines of:\n“Yeah, it\u0026rsquo;s pretty boring.”\nBoring?!\nI was genuinely blown away.\nYou\u0026rsquo;re telling me you can manufacture a technical component, put it into a harsh industrial environment, and potentially have the bloody thing still sitting there doing its job twenty years later?\nThat\u0026rsquo;s incredible.\nAnd then, because apparently this is how I communicate admiration in professional settings, I told him:\n“You guys make the dad bods of industrial equipment.”\nThere was a very brief moment after the words left my mouth where I wondered whether I\u0026rsquo;d just said something deeply inappropriate at a professional event.\nFortunately, he laughed.\nI explained what I meant.\nNot flashy. Not trying to be sexy. Dependable.\nBuilt for the long haul.\nThe Toyota of industrial equipment.\nPut it in. Leave it alone. It does its bloody job.\nHe worked with these products every day. Of course they\u0026rsquo;d become ordinary to him.\nI\u0026rsquo;d known about them for about twenty minutes.\nI still had the privilege of being impressed.\nThat\u0026rsquo;s one of my favourite things about working with SMEs # Subject-matter experts get to lend me their eyes for a little while.\nThey show me a part of the world I might never otherwise have thought to explore.\nAnd I genuinely consider that a privilege.\nSomeone has spent years — sometimes decades — learning this thing.\nThey\u0026rsquo;ve made mistakes in it. Solved problems in it. Learned all its strange little rules and exceptions. They know the difference between something that looks straightforward to me and something that makes them immediately go, “Oh, that\u0026rsquo;s a problem.”\nAnd for a time, they\u0026rsquo;re willing to let me into that world.\nI don\u0026rsquo;t need to become an expert in it.\nI just get to ask questions.\nAnd because I haven\u0026rsquo;t been looking at the same thing every day for ten or twenty years, sometimes I get to give them something back:\nfresh eyes.\nThe thing that\u0026rsquo;s become completely ordinary to them can still be fascinating to me.\nSometimes you can actually see the moment someone realises you\u0026rsquo;re genuinely interested in their weird little corner of the world.\nI love that moment.\nIt\u0026rsquo;s like a tiny professional inside hug:\nYour thing is interesting. I want to understand it.\nCuriosity isn\u0026rsquo;t a substitute for expertise # It\u0026rsquo;s one of the ways I learn to work with expertise.\nOver the years, the SMEs around me have changed.\nBusiness services gave me access to people who understood completely different businesses and operating models.\nTelecommunications and technology introduced me to network engineers, fibre specialists, VoIP people, developers, security specialists, finance people and commercial teams.\nThese days, I spend a lot of time talking to electricians, plumbers, roofers, arborists and other construction specialists.\nI don\u0026rsquo;t leave those conversations thinking I can do their jobs.\nI can\u0026rsquo;t.\nThat\u0026rsquo;s rather the point of having the SME.\nBut I can leave understanding their world a little better than I did before.\nAnd that matters in project management.\nA project manager doesn\u0026rsquo;t need to know more about fibre than the fibre specialist.\nOr more about finance than the CFO.\nOr more about software than the developer.\nOr more about electrical systems than the electrician.\nFrankly, if I\u0026rsquo;m the deepest expert on everything in the room, we\u0026rsquo;ve probably assembled the wrong room.\nWhat I do need is enough curiosity to ask useful questions.\nWhy do you want to do it that way?\nWhat happens if we don\u0026rsquo;t?\nWhat does your part depend on?\nWhat do you need from somebody else?\nWhat\u0026rsquo;s essential, and what\u0026rsquo;s just really bloody cool?\nBecause specialists can all be completely correct from within their own area of expertise and still disagree about what the project should do.\nThe engineer can see what would make the best technical system.\nThe finance person can see what the organisation can actually afford.\nOperations can see what they\u0026rsquo;ll have to support when everybody else has gone home.\nThe customer knows what problem they actually need solved.\nNone of those perspectives becomes unnecessary because another one exists.\nMy job is to be curious enough to understand them, find the connections between them, and help turn all that expertise into something that actually works.\nI think that\u0026rsquo;s why I\u0026rsquo;ve always liked sitting somewhere in the middle.\nI get to borrow everybody\u0026rsquo;s expertise without pretending it\u0026rsquo;s mine.\nI don\u0026rsquo;t need to leave every project knowing how to do everybody\u0026rsquo;s job.\nUsually I leave knowing something much more useful:\nwho I\u0026rsquo;d call if I ever needed to understand that problem again.\nAnd I don\u0026rsquo;t think I\u0026rsquo;d enjoy a career where I eventually knew everything I needed to know.\nOne of the things I love about project work is knowing that somewhere in my future is another person who knows an extraordinary amount about something I\u0026rsquo;ve never thought about before.\nEventually we\u0026rsquo;ll end up in the same room.\nThey\u0026rsquo;ll use a word I\u0026rsquo;ve never heard before.\nAnd I\u0026rsquo;ll have the privilege of saying:\n“Wait. What\u0026rsquo;s that? Show me how it works.”\nOriginally published on LinkedIn.\n","date":"30 September 2026","externalUrl":null,"permalink":"/posts/project-management-is-a-great-job-for-a-curious-person/","section":"Articles","summary":"","title":"Project Management Is a Great Job for a Curious Person","type":"posts"},{"content":"A reported electrical infrastructure risk was initially assessed through the electrical trade pathway, resulting in a recommendation for escalation to a higher-level specialist. Review of the available evidence identified an external physical obstruction as the likely underlying cause, allowing the issue to be redirected to an alternative specialist workstream and resolved without unnecessary escalation.\nOr, what actually happened was:\nThere was a tree in the way.\nRecently, a work order landed on my desk reporting that the power lines to a tenant\u0026rsquo;s property were too low.\nI sent out one of my regular electricians.\nAt that point, I wasn\u0026rsquo;t looking for a solution. I wanted information.\nAre the lines actually too low? Is there anything wrong with them? Are they damaged? Are they dangerous? And please, for the love of all things useful, send me good photos.\nThe email came back with a long technical report that, boiled down, basically said:\nThese power lines are a problem. Send a Level 2 electrician.\nOh dear.\nA Level 2 job can get complicated quickly. Depending on what they find, we could be looking at a more complex electrical scope, coordination with the electricity network, potentially other trades, and an outage for the tenant while the work is completed.\nSo my brain had already started heading down that path.\nThen I stopped and looked at the photos.\nAnd the photos told a slightly different story.\nTo my admittedly non-electrician eyes, the cables themselves looked pretty good.\nThere was, however, a bloody great tree growing through the space they needed to occupy.\nSo I called the electrician.\n“Hey mate. Is there actually anything wrong with the cables? Are they dangerous?”\nNo. The cables themselves looked okay.\n“Okay\u0026hellip; what happens if I just cut back the tree?”\n“Oh yeah. You could just cut the tree.”\nRight.\nExcellent.\nI\u0026rsquo;d sent an electrician to assess an electrical problem, so unsurprisingly, I\u0026rsquo;d received an electrical recommendation.\nBut before escalating up the electrical chain to a Level 2 electrician, there was another option:\nGo sideways.\nEnter the arborist # I still wasn\u0026rsquo;t going to diagnose a tree from my desk based on some electrician\u0026rsquo;s photos.\nI\u0026rsquo;m not an arborist either.\nSo I sent the photos to my arborist.\nHe had a look and essentially said:\nYeah, that should be fine. I can lop the tree — but I\u0026rsquo;ll go out and confirm.\nPerfect.\nThe arborist attended, sent back much clearer photos, and provided a quote to cut the tree back.\nThe scope was straightforward.\nIt was approved.\nThe tree was lopped.\nDone.\nThe work order came in on Monday and by Wednesday morning, the arborist had finished.\nWhat could potentially have progressed into a much larger electrical project — involving a Level 2 electrician, potentially a roofer and other trades, coordination with the electricity network and disruption to the tenant\u0026rsquo;s power — had turned out to be a much simpler problem.\nThere was a tree in the way.\nThe electrician wasn\u0026rsquo;t wrong # This is the important bit.\nI work with subject-matter experts because they know things I don\u0026rsquo;t.\nI am not going to look at a photograph of electrical infrastructure, declare myself an electrician, and start overruling the person who actually knows what they\u0026rsquo;re looking at.\nThat would be insane.\nBut the electrician and I have different jobs.\nThe electrician\u0026rsquo;s expertise helps me understand the electrical system and the risks within it.\nMy job is to understand enough of the whole problem to coordinate the right people towards the outcome.\nAnd sometimes that means asking the SME one more question.\nIn this case:\nIs there actually anything wrong with the cables?\nThat one question changed the direction of the work order.\nRecommendations and root causes answer different questions # A recommendation usually answers:\nWhat should we do next?\nRoot-cause thinking asks:\nWhy is this happening in the first place?\nThose questions can lead to exactly the same answer.\nBut they don\u0026rsquo;t always.\nAnd that\u0026rsquo;s why I try not to process recommendations automatically.\nI look at the report.\nI look at the evidence.\nI ask what we actually know.\nI ask what outcome we\u0026rsquo;re trying to achieve.\nAnd then I think about which expertise bank I need next.\nSometimes the answer really is to escalate vertically: electrician → Level 2 electrician → network provider.\nBut sometimes the better move is sideways:\nElectrician → arborist.\nThat\u0026rsquo;s one of the things I find most interesting about project coordination.\nYou don\u0026rsquo;t need to personally hold all the expertise.\nYou need to know where the expertise lives, when you need it, and how the different pieces fit together.\nOr, if we\u0026rsquo;d like to turn the tree back into project-management language:\nEffective issue resolution requires distinguishing recommended corrective actions from underlying causal factors, and selecting the appropriate specialist pathway based on evidence rather than default escalation.\nWhich is accurate.\nBut I think the tree explained it better:\nA recommendation tells you where someone thinks you should go next. It doesn\u0026rsquo;t necessarily tell you why you\u0026rsquo;re there.\nSometimes you don\u0026rsquo;t need to escalate.\nSometimes you need to sidestep.\nOriginally published on LinkedIn.\n","date":"29 September 2026","externalUrl":null,"permalink":"/posts/a-recommendation-isnt-a-root-cause/","section":"Articles","summary":"","title":"A Recommendation Isn’t a Root Cause","type":"posts"},{"content":"A downstream work package was progressed based on reported completion of a critical predecessor activity without sufficiently defined acceptance criteria or objective verification. The resulting dependency failure caused rework and demonstrated the need for stronger hold points at trade interfaces.\nOr, what actually happened was:\nBack in the early days of my urgent property maintenance coordination role, I made a real blunder of a work order.\nI was within my first month of managing urgent work orders. I had around 40 running at the same time, a ridiculous number of little procedures still to learn, and nowhere near enough time to stop and deeply understand every technical detail coming across my desk.\nThen this work order came in:\nThe shower is leaking through the base of the shower tiles.\nOkay. Send the plumber.\nThe plumber attended, tested the shower, and reported that they needed to replace the breech piece behind the tiles.\nOkay.\nI didn\u0026rsquo;t actually know what a breech piece was, but I knew what needed to happen next: get the additional work approved.\nApproval received.\nSent it to the plumber.\nThe next day I got an email back with photos:\nDone.\nPlumbing complete. Send the tiler to repair the wall.\nThe tiler went to the site and had been working for quite a while. He was about halfway finished and found something wasn’t quite right.\nThen my phone rang.\n“Shanti, it\u0026rsquo;s still leaking. You need to send the plumber back.”\nOh, no! “Can you just do what you can do?”\n“No. You really need to send the plumber back.”\nRight. Okay.\nThe tiler sent me videos showing the leak. I sent those back to the plumber and arranged another attendance.\nThe plumber went back to site.\nTheir report came back:\nWe need to replace the breech piece.\nWait.\nWHAT?\nI\u0026rsquo;d already had the breech piece approved.\nAnd that was the moment I realised something slightly important:\nI had absolutely no idea what a breech piece was.\nSo I Googled it.\nOhhhhh! That\u0026rsquo;s a breech piece!\nA beautiful, shiny copper plumbing fitting behind the wall, connecting the hot and cold water supplies to the taps.\nAnd now that I knew what I was actually looking for, I went back through the photos attached to the original “done” email.\nSure enough:\nNo new breech piece.\nIt hadn\u0026rsquo;t been replaced.\nThe plumber had reported the work as complete.\nI had accepted that report as verification.\nAnd because I didn\u0026rsquo;t understand the specific subject matter well enough to know what evidence I should have been looking for, I\u0026rsquo;d sent the next trade.\nThat bit was mine.\nThe plumber said it was done.\nI didn\u0026rsquo;t understand the work well enough to know what I needed to see to prove it was done.\nSo I sent the tiler.\nThe wall was still leaking.\nAnd now we had another plumber attendance, another tiler attendance, rework, delays, and additional cost.\nIt was an expensive lesson relative to the responsibility I had at the time.\nBut I have never made that mistake again.\nI don\u0026rsquo;t need to know how to replace a breech piece # This is the important distinction.\nThe lesson wasn\u0026rsquo;t:\nProject coordinators should become plumbers.\nAbsolutely not.\nI work with specialists because they know things I don\u0026rsquo;t.\nWhat changed was my understanding of how much technical knowledge I need in order to coordinate specialist work effectively.\nI don\u0026rsquo;t need to know how to replace a breech piece.\nBut if replacing one is a critical predecessor to the next stage of my work, I need to understand:\nWhat is it?\nWhat outcome are we expecting?\nWhat evidence should exist when it\u0026rsquo;s finished?\nAnd what needs to be true before I send the next person?\nThat work order permanently changed one of my habits.\nIf a trade gives me a term I don\u0026rsquo;t understand, I look it up.\nIf I still don\u0026rsquo;t understand it, I ask.\nAnd when the work comes back as completed, I don\u0026rsquo;t just look for the word “done.”\nI look for the evidence that the thing we approved is the thing that actually happened.\nBecause reported completion and verified completion are not the same thing.\nThat\u0026rsquo;s the bit I learned from a leaking shower, an increasingly exasperated tiler and one very educational Google search.\nBefore progressing to the next stage, make sure you understand the prerequisite well enough to verify that it has actually been completed.\nOr, to translate the whole story back into project-management language:\nEffective dependency management requires sufficiently defined acceptance criteria to verify predecessor completion before downstream activities are released.\nWhich is accurate.\nBut the version permanently burned into my brain is much simpler:\nYou can\u0026rsquo;t verify what you don\u0026rsquo;t understand.\nAnd I will never forget what a breech piece looks like.\nOriginally published on LinkedIn.\n","date":"28 September 2026","externalUrl":null,"permalink":"/posts/you-cant-verify-what-you-dont-understand/","section":"Articles","summary":"","title":"You Can’t Verify What You Don’t Understand","type":"posts"},{"content":"Leveraged cross-domain abstraction and analogical systems modelling to establish a shared conceptual framework, enabling collaborative interrogation of system dependencies, identification of the failure point, and development of a targeted remediation pathway.\nOr, alternatively:\nA coder was stuck, so we talked about a postal system until he wasn\u0026rsquo;t.\nBack in the day, I had a role I affectionately describe as “den mother to the coders.” My job was to keep everyone fed, hydrated, vaguely on track, and moving towards whatever we were trying to build.\nOne day, one of the coders came to me completely stuck. He\u0026rsquo;d been going around in circles trying to solve a problem and was getting increasingly frustrated.\nI asked if I could help.\nHe gave me a look that very clearly said: How exactly are you going to help me with my highly technical coding problem?\nFair question.\nI wasn\u0026rsquo;t a coder. I\u0026rsquo;d seen code and understood some of the broad strokes, but I wasn\u0026rsquo;t going to solve his technical problem for him.\n“Just tell me what\u0026rsquo;s happening. Maybe I can help.”\nSo he did.\nI listened while he explained the problem in all its technical detail. I understood some of it, definitely didn\u0026rsquo;t understand all of it, and slowly built a picture in my head.\nAnd something about that picture looked familiar.\nWe\u0026rsquo;d recently worked on an R\u0026amp;D project involving a postal system, and the problem he was describing reminded me of the way parcels moved through that network.\n“Hang on. This sounds a bit like a postal network…”\nSo I started talking about parcels.\nAbout two minutes in, I noticed he\u0026rsquo;d stopped listening to me.\nHis eyes had gone somewhere else.\nSo I stopped talking.\nWe stood there in silence for maybe ten seconds.\nThen I saw it.\nLightbulb.\n“I think I know what the problem is.”\nAnd off he went.\nHe solved it.\nI wasn\u0026rsquo;t his technical lead. I wasn\u0026rsquo;t standing over his shoulder waiting for him to finish, and I wasn\u0026rsquo;t interrogating him about why he hadn\u0026rsquo;t solved it yet.\nMore importantly, I wasn\u0026rsquo;t pretending I knew how to solve it.\nHe was the SME. The solution ultimately had to come from him.\nFor a few minutes, we were simply two people being curious about the same problem from different angles.\nAnd now, fifteen-odd years of professional vocabulary later, I can describe what happened much more impressively:\nI leveraged cross-domain abstraction and analogical systems modelling to establish a shared conceptual framework, enabling collaborative interrogation of system dependencies and identification of the failure point.\nWhich is technically true.\nBut look what I just did to a perfectly lovely human story.\nThat\u0026rsquo;s not to say jargon is useless.\nIn fact, I like jargon.\nProfessional terminology can be incredibly efficient. When everyone understands the underlying concept, one phrase can replace an entire paragraph.\nInstead of:\n“You know how we worked out who was actually doing the work, who had final responsibility, who we needed input from, and who just needed to know what was happening?”\nWe can say:\n“RACI.”\nFantastic. That\u0026rsquo;s jargon doing exactly what it should do.\nOnce we share the underlying understanding, we don\u0026rsquo;t need to explain the whole concept every time. A good term can turn a paragraph into a word.\nStories can help us build understanding. Jargon can help us compress it.\nBut if I\u0026rsquo;ve never encountered RACI before and you simply tell me:\n“We need to establish the RACI.”\n…you haven\u0026rsquo;t actually explained anything. You\u0026rsquo;ve handed me a label for a model I don\u0026rsquo;t yet possess.\nI think professional language sometimes gets this backwards.\nYou can understand a concept without knowing its official term, and knowing the official term doesn\u0026rsquo;t necessarily mean you understand the concept.\nI\u0026rsquo;m not anti-jargon.\nI quite like discovering that something I\u0026rsquo;ve been doing for years has a name.\nBut the term isn\u0026rsquo;t the understanding.\nThe coder didn\u0026rsquo;t need to know he was participating in cross-domain analogical reasoning.\nI didn\u0026rsquo;t know I was doing it either.\nThe concept worked before either of us knew the label.\nProblems start when we confuse the compression for the thing itself.\nOr when knowing the password becomes more important than understanding the person standing in front of us.\nSometimes you need “cross-domain analogical systems modelling.”\nAnd sometimes you just need to ask where the parcel got stuck.\nOriginally published on LinkedIn.\n","date":"26 September 2026","externalUrl":null,"permalink":"/posts/how-jargon-ruins-a-perfectly-lovely-human-story/","section":"Articles","summary":"","title":"How Jargon Ruins a Perfectly Lovely Human Story","type":"posts"},{"content":"One of my mum’s favourite sayings when I was growing up was:\n**“You have to pick your battles.” **\nIt made me so mad.\nUntil, about ten years later, I had to admit how right she was.\nLet’s go way back in time to 15-year-old Shanti: full of rage, full of opinions I was very attached to, and absolutely certain I was right about all of them.\nI remember watching my mum have yet another conversation where, in my opinion, she didn’t stand up for herself. She was correct. The other person was wrong. My mum was the smartest person I knew! Obviously she was right! But she would let the louder, more emotional person talk as though they were correct, then get herself out of the conversation and move on with her life.\nThis was completely unacceptable to 15-year-old me. I would go up to her in all my teenage bluster:\n“Why didn’t you stand up for yourself?! Why are you being a doormat?! You’re right! They’re wrong! You have to fight for yourself!”\n(Before you think it: I know. If I were my mum, I would have wanted to slap me too.)\nShe would take a breath and calmly say:\n**“You have to pick your battles.” **\nAt this point you can picture 15-year-old me with steam coming out of my ears. And we\u0026rsquo;d usually have a couple more rounds of me arguing and Mum repeating the same sentence.\nAt the time, I didn’t understand what she was really trying to teach me:\n**Your time and energy are finite resources. You have to use them wisely. **\nThe irony, completely lost on 15-year-old me, was that Mum was a financial management consultant. Managing finite resources was quite literally her day job.\nWhen I was about 25, I remember going back to Mum, hat in hand, and telling her I was sorry. She was right. By then, I had learned that fighting every battle was expensive. Not just in my own time and energy, but in relationships.\nThen, at around 35, I realised there was another layer to it:\nSometimes a battle still needs to be fought, **but I don’t necessarily *need *to be the person fighting it. **Sometimes my job is to establish the facts, gather the evidence, and give the person upstream of me what they need to put the case forward.\nThat\u0026rsquo;s something project management has taught me particularly well.\nKnowing where a decision sits matters. So does knowing the extent of your own authority. Good escalation isn\u0026rsquo;t throwing every difficult problem up the chain and asking someone else to deal with it.\nIt\u0026rsquo;s handling what sits within your responsibility, and when something genuinely requires authority you don\u0026rsquo;t have, giving the right person enough information to make the next decision.\nYou don\u0026rsquo;t need to fight a battle that isn\u0026rsquo;t yours to fight.\nThe cruel irony of all this external growth is that I still have the big internal reaction.\nThat\u0026rsquo;s wrong.\nThat\u0026rsquo;s unfair.\nThat doesn\u0026rsquo;t make sense.\nSomeone should do something about that.\nTHIS ISN’T RIGHT!\nApparently 15-year-old Shanti is alive and well. I\u0026rsquo;ve just learned to create some space between the internal reaction and the external response.\nBecause no matter the internal reaction, sometimes the appropriate response is:\nTo wait,\nTo gather further information,\nTo calmly put forward an alternative solution,\nTo reframe the problem,\nTo escalate to the appropriate authority,\nTo do absolutely nothing,\nAnd yes, sometimes I still need to fight.\nI still get this wrong occasionally. I still overreact. But it\u0026rsquo;s rare now, and thankfully it doesn\u0026rsquo;t come with quite the same gusto as 15-year-old me.\nThe longer time goes on, the more I realise that most things aren\u0026rsquo;t worth fighting about. And when something is worth fighting about, there\u0026rsquo;s another question:\n**Who is actually in the best position to get the outcome this project needs?\nThe older I get, the less attached I am to being seen to be right. I\u0026rsquo;d rather get the outcome that works for the mission. I\u0026rsquo;d rather be part of a team that gets quality things done.\nAnd, like a lot of things I\u0026rsquo;m learning and relearning now, somehow I keep arriving back at the same conclusion:\nSorry, Mum. You were right.\nOriginally published on LinkedIn.\n","date":"25 September 2026","externalUrl":null,"permalink":"/posts/my-mum-told-me-to-pick-my-battles-it-took-me-ten-years-to-admit-she-was-right/","section":"Articles","summary":"","title":"My Mum Told Me to Pick My Battles. It Took Me Ten Years to Admit She Was Right.","type":"posts"},{"content":"Different industries have genuinely different domain knowledge. But underneath that expertise, organisations repeatedly encounter the same systems problems: information has to move, decisions have to be made, dependencies have to be managed, specialists have to be coordinated, resources are constrained, circumstances change, and humans remain inconveniently human.\nAbout three years ago, I moved into construction because I was over the tech industry and wanted to do something completely different.\nA couple of months into my new role as a construction project coordinator, I had a slightly annoying realisation:\nEven this is the same.\nWe’re moving different widgets around different systems, but beneath the terminology and technical detail, many of the underlying structures are remarkably similar.\nPlumbing, electrical and telco systems obviously aren\u0026rsquo;t the same. Each has its own technical requirements, risks, regulations, and specialists who know far more about their field than I ever will.\nBut zoom out far enough, and they start to look surprisingly familiar.\nSomething needs to move from here to there. It passes through different parts of a system with dependencies and constraints. Something interrupts the flow. We need to figure out where the problem is, who understands that part of the system, what needs to change, and how we\u0026rsquo;ll get it working again.\nAt my core, I\u0026rsquo;m a project manager and a relationship builder. I tend to understand something new by asking:\nWhat is this similar to that I already understand?\nThen I build the differences back in.\nIt\u0026rsquo;s how I went from knowing virtually nothing about routers and switches to effectively supporting network engineers. It\u0026rsquo;s also how I can now talk with a plumber about where a drainage line has collapsed, what needs to happen next, and how we explain the proposed solution to the people approving the work.\nI don\u0026rsquo;t need to become the plumber or the network engineer.\nI need to understand enough of their world so we can work effectively together.\nThat brings me to something I\u0026rsquo;ve noticed in project management job advertisements. Many place significant emphasis on years of experience within one particular industry or technology. Sometimes that makes perfect sense. Some projects genuinely need a PM with deep domain knowledge and existing relationships.\nBut we also need project managers who are simply great at project management.\nA PM needs to build relationships with SMEs, ask good questions, identify dependencies and sticking points, translate information between people, maintain visibility across the project, and keep everyone moving towards the same outcome.\nThe PM shouldn\u0026rsquo;t necessarily be the person disappearing deepest into every technical rabbit hole. Often, a better use of their time is getting SMEs the information, people or decisions they need, removing blockers, and letting them do what they\u0026rsquo;re actually very good at.\nThe project manager\u0026rsquo;s job isn\u0026rsquo;t to become every SME. It\u0026rsquo;s to get the best out of the collective expertise already in the project.\nThis diagram is deliberately simplistic, but at a high enough level it can describe an extraordinary number of systems: plumbing, electricity, telecommunications, logistics, information flows and even some organisational structures.\nThe details are different.\nThe basic questions often aren\u0026rsquo;t.\n**Where are we now? **\n**Where are we trying to get to? **\n**What\u0026rsquo;s stopping the flow? **\n**Who understands that part of the system? **\n**What do they need from everyone else? **\nWhat needs to happen next?\nWhen something breaks, reality hits, and the project suddenly feels like an end-of-the-world scenario, it\u0026rsquo;s then down to the PM: establish the current state, understand how it differs from the plan, identify what\u0026rsquo;s actually preventing progress, and coordinate the people who can get it moving again.\nSometimes it\u0026rsquo;s easier to see that when you\u0026rsquo;re not the person deepest in the technical detail.\nAnd there\u0026rsquo;s another benefit to this approach that gets underestimated: relationships.\nI\u0026rsquo;ve found most SMEs are incredibly generous with their knowledge when you ask good questions and genuinely respect their expertise. Let them explain what they can see. Build enough of their model in your own head to ask the next useful question.\nStripping a system back to its essential parts, understanding the relationships between them, and then adding the domain-specific detail back in helps me understand unfamiliar problems.\nMore importantly, it helps me understand the people I\u0026rsquo;m working with.\nBecause when the plan inevitably meets reality, it\u0026rsquo;s rarely one person with all the answers who gets a project through.\nIt\u0026rsquo;s the relationships between people who know different parts of the system.\nThe widgets change. The domain changes. The method transfers.\nAnd increasingly, I find myself looking at supposedly completely different industries and thinking:\nIt’s all the bloody same.\nOriginally published on LinkedIn.\n","date":"24 September 2026","externalUrl":null,"permalink":"/posts/its-all-the-bloody-same-notes-from-twenty-years-of-moving-different-widgets-around/","section":"Articles","summary":"","title":"It’s All the Bloody Same: Notes From Twenty Years of Moving Different Widgets Around","type":"posts"},{"content":"Coming soon.\n","externalUrl":null,"permalink":"/about/","section":"Shanti Korporaal","summary":"","title":"About","type":"page"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"The best way to get in touch is on LinkedIn.\nConnect on LinkedIn ","externalUrl":null,"permalink":"/contact/","section":"Shanti Korporaal","summary":"","title":"Contact","type":"page"},{"content":"Coming soon: projects, writing and career highlights, added over time.\n","externalUrl":null,"permalink":"/portfolio/","section":"Shanti Korporaal","summary":"","title":"Portfolio","type":"page"},{"content":"","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"}]