# Teknologika — Full Content > Complete content index for LLM consumption > Generated: 2026-10-18 | Posts: 8 --- ## Articles URL: https://teknologika.com/articles/ Type: page Modified: 2026-10-18 Articles on the hard parts of the work. As I walk into the valley of death A conversation with a CEO reveals why operating models shape how businesses compete, where their blind spots sit, and when to play offence. You can’t put that on the wall Leadership asks teams for transparency. What happens when someone puts the budget on the wall and asks leaders to meet their own standard? Why Your Competitors Are Always One Step Ahead Why competitors keep moving faster, how operating models create the gap, and why shipping speed is a leadership problem as much as a technical one. Maybe it’s time to ban PowerPoint again. Amazon’s narrative documents made thinking visible. What happens when people learn to mimic the format, and AI makes the thinking optional? --- ## Home URL: https://teknologika.com/ Type: page Modified: 2026-10-18 I help people in tech lead from where they are. In my time at Amazon Web Services I learnt that true leadership is not inferred by role or title. It’s about your impact and influence on the people around you.Hi, I’m Bruce McLeod. I’ve spent more than 30 years delivering customer value through technology, at Amazon, ThoughtWorks, a vendor to Microsoft, Australia’s National Broadband Network, AMP and Macquarie Bank among others. While technology is the business, its also about the people and the day-to-day challenges of delivering for your customers and peers. AI changes the rules of the game AI is getting good at the work where the answer is clear. Writing a function, fixing a bug, creating a new test, filing the PR or drafting your document. What Artificial Intelligence lacks, where Human Intelligence thrives. Experience, context and judgement. AI can’t decide which task is more important. It can’t help people who disagree to commit to a plan that they didn’t create. It most certainty isn’t answering the call when the boss calls at 2am. Quickly, how you use AI in your role is becoming a core differentiator. If you use it to support high quality thinking you will get ahead of people just generating more slop. Where did I learn this? I was privileged to grow up as computers went from sci-fi to something small on our wrists, and on that journey there have been some key experiences that helped me on the way Microsoft I worked for years embedded at the Microsoft Solutions Delivery Centre. Developing and testing shippable value very day. Working alongside customers, using the tools and processes proven internally at Microsoft, solving their unique business challenges. ThoughtWorks My years as a ThoughtWorker provided a core foundation on enabling Australia’s largest businesses with Agile and Technology. Training teams in Agile, building and shipping applications, coaching teams and leaders on different ways to help customers. Amazon Web Services Working as an AWS Advisory Consultant and Customer Solutions Manager let me experience first hand what it means to be customer obsessed, data driven and what is needed to deliver results. Most leadership happens without a title. It’s the engineer who talks the team out of a bad architecture decision. The architect who gets two vendors to agree on an integration. The consultant who tells the client the timeline won’t hold, before it’s too late to fix. None of them manage anyone. They are still leading. I coach people in technology roles to handle those moments better: the meeting where the decision actually gets made, and the conversation that has gone sideways. Read my writing --- ## Privacy Policy URL: https://teknologika.com/privacy-policy/ Type: page Modified: 2026-10-18 Last updated: 17 October 2026. Teknologika is Bruce McLeod’s website. This policy explains how personal information is handled when you visit the site or contact us. Information you provide If you contact Bruce, your name, email address and the information in your message may be used to respond and manage the conversation. Please avoid sending sensitive personal information that is not needed for your enquiry. Website information and cookies Website infrastructure may record technical information such as your IP address, browser, requested pages and access times to operate the site and investigate errors or abuse. WordPress uses cookies for signed-in administration. Your browser lets you manage or block cookies. This site loads Libre Franklin fonts from Google Fonts. Your browser connects to Google to retrieve them, which sends technical information including your IP address. See Google’s privacy policy for details. Email subscriptions Email subscriptions are not currently available on this site. This policy will be updated before a subscription service is enabled to explain the information collected, the provider used and how to unsubscribe. Service providers and external links Hosting, email and other providers may process information as part of delivering their services. Providers may process information outside Australia. Links to other websites, including YouTube, take you to services with their own privacy policies. Keeping information Personal information should only be retained for as long as needed for the purpose it was provided, legitimate business records or legal obligations. No online service can guarantee absolute security. Access, correction and privacy concerns To ask about your information, request access or correction, or raise a privacy concern, email privacy@teknologika.com. Describe your request without including unnecessary sensitive information. Identity may need to be checked before information is released or changed. If a privacy concern is not resolved, you can contact the Office of the Australian Information Commissioner. Whether the Australian Privacy Act applies depends on the circumstances and your location. Updates This policy may change when the site’s services or information handling change. The update date above identifies the latest version. --- ## About URL: https://teknologika.com/about/ Type: page Modified: 2026-10-18 Hi, I’m Bruce McLeod. I was running an offsite with my AWS Practice, working through an example from my past of delivering business value, when something struck me. I hadn’t used that part of my brain since I joined Amazon. I’ve spent years in technology and consulting, helping people connect the work to the business decisions behind it. The experience was still there. My current role just hadn’t given me much reason to use it. A few weeks later, someone introduced me as one of the “tech guys”. Fair enough. I love getting hands-on and that is what they saw me doing. But it made me think about how much of our experience becomes invisible when people get to know us through one role. Over a career, you learn things that don’t fit neatly into your next job description. You can see where a decision will cause trouble, why teams are talking past each other, or what a customer actually needs. Yet people may never think to ask you. That’s part of why I decided to start coaching. I want to help people work on making breadth of experience useful in the role you have today, so people know what they can trust you to help with. What shaped my approach I’ve spent more than 30 years delivering customer value through technology, including roles at Amazon Web Services, a vendor to Microsoft, ThoughtWorks, Macquarie Bank, AMP and Australia’s National Broadband Network. Early in my career, at the Microsoft Solutions Delivery Centre, I learnt the discipline of building and shipping value every day. At ThoughtWorks, I helped teams and leaders adopt Agile, build applications and improve how they delivered for customers. At AWS, as an Advisory Consultant and Customer Solutions Manager, I saw how customer obsession, evidence, data and ownership shape everyday decisions. Leadership showed up in people’s impact and influence, whatever their title. What I write about I write about the situations where experience, judgement and influence matter: deciding what deserves attention, keeping promises, working across teams and learning from what happened. You can start with my articles. --- ## Maybe it’s time to ban PowerPoint again. URL: https://teknologika.com/maybe-its-time-to-ban-powerpoint-again/ Type: post Modified: 2026-10-18 A note before you read : I spent time working within Amazon and alongside its people. Amazon is a vast organisation and operates differently across its businesses, geographies, and teams. My personal experiences and observations do not reflect Amazon's position, nor should they be read as a comprehensive account of how the company operates in the past or today. Everything in this article is based on publicly cited references, listed at the bottom of this article. This is one practitioner's view, offered in the spirit of understanding what made something great, and what it takes to keep it that way.In June 2004, Jeff Bezos sent a short email to his senior leadership team. The subject line was blunt:"No PowerPoint presentations from now on at STeam."In its place, Amazon would use what became known as the doc read. A narratively structured document, written in full sentences with real arguments, read in silence at the start of every meeting. No slides. No bullet points. No presenter hiding behind a deck.Jeff explained his reasoning simply. “Writing a four-page document is harder than producing a twenty-page presentation because the narrative structure forces you to think. PowerPoint”, he wrote, "gives permission to gloss over ideas, flatten out any sense of relative importance, and ignore the interconnectedness of ideas."He later called it "probably the smartest thing we ever did."He was right. But not for the reasons most people repeat.What the doc read actually wasMost coverage of Amazon's document culture focuses on the format. Six pages. Narrative structure. No bullet points. Silent reading.That misses the point entirely.The doc read was an accountability mechanism. When you write in full sentences you cannot hide. The logic either holds or it does not. The argument either connects or it falls apart. There is no animation, no charisma, no seniority in the room to compensate for incomplete thinking. As Jeff wrote in his 2017 shareholder letter, the quality of memos varied widely. "Some have the clarity of angels singing. They are brilliant and thoughtful and set up the meeting for high-quality discussion." Others did not.Jeff admitted openly that the silent reading was not optional. If they skipped it, he said, "the executives, like high school kids, will try to bluff their way through a meeting."The doc read was also a democracy mechanism. Anyone in the organisation could write a document. A junior software engineer named Charlie Ward wrote the document that became Amazon Prime in 2004. He had an idea. He wrote it down. It reached Jeff. One hundred million Prime members later, that is not a footnote.The Working Backwards process worked the same way. Before AWS launched S3 and EC2, Andy Jassy and his team spent more than a year writing, revising, and debating the PR/FAQ documents that defined what AWS would be and why it would matter to customers. Thirty-one drafts of the initial press release. That is not bureaucracy. That is thinking made visible.Ideas moved on the quality of the argument. Not the title of the person making it.If you want to learn how to “Write like an Amazonian”, the free guide below will get you started.Then COVID happenedAmazon grew fast during the pandemic. Large numbers of new hires, including myself joined, most remotely, many of them experienced professionals from outside Amazon who were good at their jobs and highly motivated to prove it quickly.We never sat in a doc read.We learned about doc reads, saw the finished documents land in our inboxes. I asked colleagues how common they were. Very, they said, then they slowly started fading away. We read the outputs of the culture, alone, without ever being immersed in the practice of building it. For me, Amazon had an onboarding program called Embark, specifically designed to slow new hires down, to immerse them in how Amazon thinks before they were let loose. Remote onboarding made that transmission much harder to sustain at scale. It is one thing to read how something is supposed to be done, another to experience and practise it.I can only assume senior leadership kept writing and demanding narratives. The S-team and the leaders around them probably continued operating the way they always had. The doc read survived at the top.But in the middle of the organisation, a different pattern emerged. A group of well meaning people who knew enough of the rules to comply with them, but had never struggled through writing a real document. Never spent a weekend rewriting. Never had a colleague tear apart their argument at paragraph level. Never experienced the mechanism. Only seen the artefacts, and heard the fire side stories of how it used to be.Jeff had anticipated this risk. He borrowed the physics concept of entropy specifically because he understood that organisational cultures decay without deliberate, sustained effort to maintain them. "Day 2 is stasis," he wrote. "Followed by irrelevance. Followed by excruciating, painful decline."What COVID accelerated was exactly that entropy. Not through any deliberate decision. Through the compounding effect of broken transmission at scale.The middle layer problemHere is the dynamic that makes this worse.The people who kept writing real documents during COVID were mostly senior. They had been doing it for years. The doc read was second nature to them. I can only assume they continued to produce and consume documents because that is how they operate.Which meant that in the middle of the organisation, I saw a new skill emerge. Not writing. Compliance. Producing a document that satisfied the format requirement without using mechanism the format was designed to force. Following the letter of the law without understanding why the law existed.Call it the middle layer problem. People exposed to what senior leadership demanded, without the battle scars of being in a room and living the process that naturally produces it. They saw the outputs. They learned to mimic the form, and they became effective at generating documents that pass inspection.But the accountability mechanism, the democracy mechanism, the innovation mechanism, and the ideas that must serve an audience of one in a silent reading session. All that Jeff built, lost when the document is a compliance exercise rather than a thinking exercise.The ideas that survive are no longer the ideas that come from anywhere in the organisation. They come from the people who write the documents. Which, one must assume are mostly the people who were there before COVID, and the people senior enough to have been properly trained. The junior engineer with the next Prime-level idea is absent. Because the tool that would have carried their voice no longer works the way it was built to.Now add AIThis is where it gets serious.AI writing tools can produce a narratively structured document in minutes. Proper sentences. Topic sentences. Logical flow. Arguments that connect. It looks, on the surface, exactly like what Jeff was asking for.But Jeff’s insight was never about the document. It was about what producing the document forced you to do. "When you have to write your ideas out in complete sentences and complete paragraphs," he said in a 2012 interview with Charlie Rose, "it forces a deeper clarity of thinking."The difficulty was the point. The rewriting was the point. The setting aside and coming back with fresh eyes was the point. Great memos, Jeff wrote, "simply can't be done in a day or two."AI does it in twenty minutes.Which means the accountability mechanism is now completely bypassable. The leadership layer does not need to understand the argument. They need to write a prompt. The output looks right. The thinking never happened.And the democracy mechanism breaks in a different way. The junior engineer with the next great idea does not need to struggle through thirty-one drafts to find clarity. They generate a polished document instantly. Which sounds like an improvement. Except that the thirty-one drafts were not wasted effort. They were how Andy Jassy figured out what AWS actually was.So, maybe it is time to ban presentations again?In 2004, Jeff Bezos did not tinker around the edges. He made a hard call and enforced it from the top. The doc read did not emerge organically from the culture. It was mandated, practised, and transmitted deliberately until it became the culture.The conditions that threaten it now are different, but the response has the same shape.Someone with authority has to call it. Not as a policy memo about AI usage, not as a reminder that documents should be written in full sentences, but as a genuine reset on what counts as thinking in a meeting room. A document produced by AI and submitted without genuine engagement is not a doc read. It is a very polished bluff, which is precisely what Jeff designed the process to prevent.That reset has three parts. First, bring back the struggle: the re-drafts, the peer challenge, the setting aside and coming back with fresh eyes. These are not inefficiencies to be optimised away. They are the mechanism. Second, rebuild how the practice is transmitted to new people. Not by showing them what a good document looks like, but by putting them in rooms where documents get made, challenged, and improved in real time. Reading the artefact is not the same as earning the scar. Third, be honest about what AI actually bypasses. The tool is not the threat; the willingness to skip the thinking and submit the output is. Those are different problems and only one of them has a technological solution.Amazon built something worth understanding. A process that made thinking visible, let good ideas travel on their own merits, and held people accountable for their reasoning regardless of their title. Whether it survives the current pressure is an open question. Whether your organisation has anything equivalent, and whether you are willing to defend it with the same clarity Jeff brought to a short email in June 2004, is the more urgent one.ReferencesBezos, J. (2004). Email to the STeam: "No PowerPoint presentations from now on at STeam." June 9, 2004. Reproduced in: Charan, R. and Yang, J. (2019). The Amazon Management System. Ideapress Publishing.Bezos, J. (2017). Annual Letter to Shareholders. Amazon.com. Available at: https://www.aboutamazon.com/news/company-news/2017-letter-to-shareholdersBezos, J. (2012). Interview with Charlie Rose. CBS News. Referenced in: CNBC (2018). Jeff Bezos: This is the 'smartest thing we ever did' at Amazon. Available at: https://www.cnbc.com/2019/10/14/jeff-bezos-this-is-the-smartest-thing-we-ever-did-at-amazon.htmlBezos, J. Forum on Leadership. Referenced in: CNBC (2018). Why Jeff Bezos makes Amazon execs read 6-page memos at the start of each meeting. Available at: https://www.cnbc.com/2018/04/23/what-jeff-bezos-learned-from-requiring-6-page-memos-at-amazon.html https://www.youtube.com/watch?v=xu6vFIKAUxkBryar, C. and Carr, B. (2021). Working Backwards: Insights, Stories, and Secrets from Inside Amazon. St. Martin's Press.Charan, R. and Yang, J. (2019). The Amazon Management System. Ideapress Publishing.Stone, B. (2013). The Everything Store: Jeff Bezos and the Age of Amazon. Little, Brown and Company.Working Backwards (2024). Working Backwards PR/FAQ Process. Available at: https://workingbackwards.com/resources/working-backwards-pr-faq/Tufte, E. (2006). The Cognitive Style of PowerPoint: Pitching Out Corrupts Within. 2nd ed. Graphics Press.Columbia Accident Investigation Board (2003). Report of the Columbia Accident Investigation Board. Referenced in: Tufte, E. PowerPoint Does Rocket Science. Available at: https://www.edwardtufte.com/notebook/columbia-accident-investigation-board-the-boeing-powerpoint-slide/ --- ## Why Your Competitors Are Always One Step Ahead URL: https://teknologika.com/why-your-competitors-are-always-one-step-ahead/ Type: post Modified: 2026-10-18 The answer has nothing to do with their strategy, their budget, or their people.You have good people. A credible strategy. You are not standing still.And yet somehow, your competitors always seem to be one step ahead. You launch a feature, they already have it. You cut a price and they had already cut it. You announce an initiative and they are six months into delivery. The gap never closes. If anything, it widens.Most leaders in this position look for the problem in the wrong places. The strategy. The talent. The technology. But the organisations consistently winning shoot-outs are not winning because of superior ideas. They are winning because they can move those ideas to customers faster than anyone else, and they have been building that capability for decades.This is not a technology story. It is a story about how organisations are designed.Toyota figured this out firstNot just on the factory floor. In every process, every approval gate, every handoff, every decision sitting in a queue waiting for the right meeting. Toyota didn’t win by building better cars in isolation. They won by building an organisation that could respond to what customers actually wanted, faster than any competitor could react.The lesson Western manufacturing took decades to absorb, and most industries still have not absorbed, is that speed is not the output of a good strategy. Speed is the output of a well-designed operating model. You cannot will your way to faster. You have to build for it.Jim McCarthy understood this when he ran the Visual C++ team at Microsoft in the 1990s. His observation about competitive markets was blunt: when you are in a shoot-out, the organisation that ships faster wins. Not the one with the better roadmap or the bigger budget. The one that gets working product in front of customers more frequently learns faster, corrects faster, and compounds that advantage with every single release.No one ever asked Amazon to ship slower and charge moreAmazon understands something that most organisations pay lip service to but never fully operationalise: customers are never truly satisfied. Not because they are difficult, but because expectations only ever move in one direction. The experience that delights someone today becomes the minimum they expect tomorrow.When I was at AWS teaching customers about working backwards, I would share the “delightfully dissatisfied” customer analogy. No customer has ever called Amazon and asked for same day delivery to be slower and more expensive. Customer expectations only move in one direction, and Amazon designs its entire operating model around that reality.No customer has ever called Amazon asking them to slow down and charge more. That sounds obvious. But walk through your own organisation and ask honestly: how many of your internal processes, approval structures, and governance frameworks were designed around the assumption that speed matters as much as control? Or were they designed to manage risk at the expense of everything else?That orientation toward the customer is only sustainable if your operating model can actually respond. If it takes six months to change a product, three months to launch a feature, and four approval layers to move budget between teams, you cannot be customer-obsessed. You can only be intention-obsessed. Which is a very different thing, and it shows up in the results.Amazon had the same problem you haveHere is where I want to push back on the most common thing I hear from senior leaders: *we’re not Amazon, we can’t operate like that.*Let me tell you where Amazon actually started.In the early 2000s, Amazon.com ran on a single system called Obidos, a monolith that every engineer in the company was touching, and that every customer transaction ran through. Around a hundred engineers, all working on the same piece of code. A single mistake by one team could bring the entire site down. Their own internal research found it was taking an average of 16 days to get a change from idea to customer, with less than an hour of actual work involved. The remaining 14 days was pure organisational drag. Queues. Handoffs. Waiting for approvals. Coordination overhead between teams who all depended on each other.Sound familiar?Amazon fixed it, not by hiring better engineers, but by redesigning how the organisation worked. Smaller teams with genuine end-to-end ownership. No shared infrastructure that created invisible dependencies between groups. Every team accountable for its piece from concept to customer. The microservices architecture invented by James Lewis at ThoughtWorks and scaled by AWS was not primarily a technology decision. It was an operating model decision that happened to have technical consequences.The constraint was never the technology. It was always the organisation.The AI trap most leaders are about to walk intoRight now, every board in the country is asking the same question: how do we move faster on AI?And most organisations are answering it the same way they answered “how do we move faster on cloud” a decade ago, by buying tools, standing up a centre of excellence, and placing the initiative alongside the existing business rather than changing how the business actually operates.The organisations that will win the AI shoot-out are not the ones with the most sophisticated models. They are the ones that can get AI-driven improvements in front of customers the fastest, learn what works, and iterate before the competition has finished their business case.That requires the same operating model discipline that Toyota was teaching in the 1960s and that Amazon has been compounding ever since. AI does not change this equation. It accelerates it. The organisations that already had the discipline to move fast are now moving faster still. The ones that didn’t are watching competitors do in weeks what used to take them quarters, with the same headcount and a fraction of the drag.The DORA research, a decade of data across tens of thousands of organisations, led by Jez Humble, Nicole Forsgren, and Gene Kim, found a direct and measurable correlation between how frequently an organisation can ship and its financial performance. Revenue growth. Market share. Profitability. The top performers outperformed their peers on every business metric that mattered.Speed is not a nice-to-have. It is a compounding financial advantage. And it is almost entirely a leadership and organisational design problem.The question worth taking into your next leadership meetingIn March 2018, I sat in front of the board of AMBank in Kuala Lumpur and made a version of this argument. The response was the same one I see consistently when senior leaders genuinely engage with it: recognition, followed quickly by the uncomfortable realisation that the constraint is not somewhere else in the organisation.It is in the room.Shipping speed is not an engineering metric. It is a business performance metric. And it is almost entirely determined by how your leadership team has designed the organisation: how teams are structured, how decisions are made, how budgets are approved, how risk is managed, and how much of your best people’s energy goes into coordination rather than creation.If your most important strategic initiative needed to change course tomorrow based on what customers told you today, how long would it actually take?If the honest answer is months, the problem is not your technology. It is not your people. It is the operating model that has been quietly compounding the gap between you and the competitor who always seems to be one step ahead.Only your leadership team built that model. Only your leadership team can fix it.If this pattern sounds familiar, the Intention-Execution Gap Diagnostic will show you exactly where your organisation is losing ground. Twelve questions. Four dimensions. A clear picture of where the gap is widest.Bruce McLeod has spent 30 years inside the gap between how organisations say they work and how they actually do, from inside Microsoft, ThoughtWorks and Amazon Web Services. He advises senior leaders on operating model design, AI-augmented delivery, and the decisions that determine whether transformation actually sticks.Everything in this article is his personal opinion based on publicly cited references, listed below. This is one practitioner's view, offered in the spirit of understanding what makes something great, and what it takes to keep it that way.ReferencesJim McCarthy, Dynamics of Software Development (1995): https://www.amazon.com.au/Dynamics-Software-Development-Jim-McCarthy/dp/1556158238James Lewis and Martin Fowler, “Microservices” (March 2014): https://martinfowler.com/articles/microservices.htmlAmazon Builders Library, “Going Faster with Continuous Delivery”: https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate (2018), IT Revolution PressJeffrey Liker, The Toyota Way (2004), McGraw-Hill --- ## You can’t put that on the wall URL: https://teknologika.com/you-cant-put-that-on-the-wall/ Type: post Modified: 2026-10-18 There is a moment in almost every transformation program where the real problem reveals itself. It is rarely a technology problem. It is rarely a process problem. It is almost always a leadership problem. And it usually shows up when someone does exactly what the organisation said it wanted.In 2019, I was invited to train the executive leadership team of a large insurance company on how to transform to an agile organisation. My colleague who was supposed to be running the session with me wasn’t feeling well. So I went off script.I pulled up a chair at the front of the room and opened it up. “Ask me anything.”The questions were good. The kind you only get when the agenda disappears and the room relaxes. Where does transformation go wrong? What actually stops a company from being agile?My answer was straightforward.As leaders, you need to embody what you want the organisation to become. If you want your teams to move fast and deliver often, you need to do the same. If you want people to be frugal, you need to stop flying business class. If you want teams to use visual systems and information radiators to make their work visible, you need to do it too.They listened. That surprised me. Most rooms push back.But listening in a room and changing behaviour in the organisation are two different things.A colleague of mine, a fellow ThoughtWorker, was embedded in a different organisation doing exactly what I had described. She was building information radiators. Making the work visible. Putting numbers on the wall so the team could see where they stood, where the blockers were, and how the project was tracking.Then she put the budget on the wall.The response was swift.“You can’t put that on the wall.”“You can’t share the numbers.”She pushed back. Why not?This was an organisation that demanded full transparency from its staff. Teams were expected to show their work. Progress was tracked openly. Blockers were named in public forums. But when the budget appeared on the wall, the system rejected it immediately. Leadership wanted transparency flowing upward. They had no interest in it flowing in the other direction.This is exactly the situation I had warned that insurance room about. The organisation becomes what its leaders model, not what they mandate.Jim Collins spent five years studying what separated great companies from good ones. The pattern he found in every company that made the leap was a specific leadership behaviour he called the window and the mirror. When things go well, these leaders looked out the window, crediting their teams, their colleagues, external factors. When things went wrong, they looked in the mirror. The inverse — demanding accountability from others while exempting yourself — was the consistent pattern in the companies that didn’t make the leap.That budget on the wall quickly became an unintended mirror test. My colleague wasn’t asking leadership to be vulnerable. She was asking them to apply their own standard to themselves.Ray Dalio built Bridgewater Associates, the world’s largest hedge fund, on a principle he called radical transparency. Every meeting recorded. Every decision documented. Employees encouraged to challenge each other openly, including the founder. The idea was to create a true meritocracy of ideas, where hierarchy couldn’t protect bad thinking.It didn’t survive contact with human nature at scale. What started as intellectual honesty became, for many employees, a surveillance culture, with cameras throughout the offices and employees filing complaints about colleagues in an internal log. The principles are no longer mandatory for new hires. Dalio is no longer at the helm. The version of radical transparency that pointed outward, demanding honesty from everyone else, turned out to be easier to enforce than the version that pointed inward.Amazon approached the same problem differently. One of their leadership principles is Dive Deep: leaders stay connected to the details. They can drop into a problem, understand what is actually happening, and then come back to their operating level. The key word is “back.” A leader who gets lost in the detail has a different problem. But a leader who can’t explain their own team’s numbers, their own delivery cadence, their own blockers, has already failed.That budget on the wall wasn’t intended as a test. My colleague wasn’t doing anything radical. She was applying their own standard back to them.McKinsey’s research is unambiguous: roughly 70 percent of transformation efforts fail. The reasons McKinsey identifies are consistent across industries and geographies. Leaders fail to build genuine conviction within their teams. They don’t address the capability gaps. They don’t free up the right people to drive the change. What sits underneath all of it is the same thing my colleague ran into: leaders who set standards they don’t apply to themselves create organisations that quietly stop believing the standards mean anything.McKinsey’s research also found that organisations whose leadership clearly defined roles, took responsibility, and communicated progress openly were as much as eight times more likely to succeed than their peers. Eight times. Not from a better methodology. Not from a better technology platform. From leaders who were willing to be visible about what they were doing and how it was going.That is what the budget on the wall represents. Not a radical act. A leadership act.Most transformation programs focus relentlessly on changing the behaviour of the people below the leadership line. New ways of working. New ceremonies. New tools. New metrics. All of it directed at teams who are, in most cases, perfectly capable of changing if the environment allows it.The environment is set by the leaders.Flying business class when you’ve asked everyone else to cut costs. Running a cascade briefing when you’ve told teams to use visual communication. Hiding the budget when you’ve asked teams to make everything visible. Each of these is a signal. The organisation reads every one of them.Before your next transformation review, before you assess team velocity or delivery cadence or agile maturity scores, ask a simpler question.What are you putting on the wall?Your calendar. Your priorities. Your budget. Your blockers. The things you are accountable for and the current state of each of them.If the answer is nothing, you already know where the transformation is stuck.Bruce McLeod has spent 30 years inside the gap between how organisations say they work and how they actually do, from inside Microsoft, ThoughtWorks and Amazon Web Services. He advises senior leaders on operating model design, AI-augmented delivery, and the decisions that determine whether transformation actually sticks.Everything in this article is his personal opinion based on publicly cited references, listed below. This is one practitioner’s view, offered in the spirit of understanding what makes something great, and what it takes to keep it that way.References1. Collins, J. (2001). *Good to Great: Why Some Companies Make the Leap and Others Don’t.* HarperBusiness. The window and the mirror concept is developed in Chapter 2, on Level 5 Leadership https://www.jimcollins.com/concepts/level-five-leadership.html2. Dalio, R. (2017). *Principles: Life and Work.* Simon and Schuster. Radical transparency as a management philosophy is the central operating principle of Part III.3. Robinson, H. (2019). Why do most transformations fail? McKinsey and Company.4. AIM Business School. (2025). Why 70% of change management initiatives fail.5. Amazon Leadership Principles: Dive Deep.6. Westport Journal. (2023). Book scrutinises culture of radical transparency at Bridgewater. --- ## As I walk into the valley of death URL: https://teknologika.com/as-i-walk-into-the-valley-of-death/ Type: post Modified: 2026-10-18 Are You Playing Offence or Defence? (And Did You Choose?)I was meeting 1:1 with the CEO of a food delivery company. We were deep into discussing the re-platforming project I was leading, the kind that consumes budget, people, and patience in roughly equal measure.Then he referred to my project as the valley of death. Wait, what?He picked up a marker and drew a chart on the whiteboard. A curve that dropped before it climbed. This was the valley of death.The explanation was simple. While the platform was being replaced, the business could not add new features. Every engineering decision, every sprint, every dollar was pointed at the new foundation. The market kept moving. Competitors kept shipping. And we sat in the valley, unable to respond.But on the other side of that valley, if we made it through, everything changed. The new platform would let them move at a speed the old one never could. Features that took months would take days. The business would stop reacting and start attacking.He wasn’t describing a technology project. He was describing a choice about how to compete.And if my project failed, the company was dead. Not eventually. Soon.That conversation stayed with me. Because the valley of death isn’t unique to food delivery or re-platforming. Every organisation is navigating some version of it right now. Are they playing offence or defence? Did they choose deliberately? And is it still the right call for where their market is heading?Most leaders can’t answer all three. And in an AI-accelerated market, that gap is getting expensive.To understand why, it helps to look at seven operating models that answer the offence/defence question differently. Not as a history lesson. As a mirror.Amazon, Microsoft, Toys "R" Us, and Apple are four well-known examples. McDonald's and two other archetypes, the lifestyle business and food court, round out the set, because most of the leaders reading this aren't running a trillion-dollar platform. They're running something closer to the latter three.Amazon: Working Backwards, Not ForwardAmazon built its operating model around a single obsession: the customer. Working backwards from what the customer needs is a discipline baked into every meeting, every product decision, every new market entry.It works. Until it doesn’t.Working backwards from the customer means you don’t attack markets where the customer isn’t asking. Microsoft Office has dominated enterprise productivity for thirty years. It is expensive, bloated, and deeply unloved. Amazon has the engineering capability, the cloud infrastructure, and the distribution to build a serious open source competitor. It hasn’t. Because Office customers aren’t complaining to Amazon. They’re just paying the bill.Customer obsession is a profound strength. It is also a blind spot. If the customer isn’t asking, the model doesn’t move.Microsoft: The Eye of SauronMicrosoft doesn’t obsess over customers. It obsesses over competitors. Netscape. Java. Apple. Google. Each time a threat emerged, Microsoft turned its full attention toward it, leveraged its existing dominance, and attacked. Late, but overwhelming.Think of it as the Eye of Sauron. Total focus lands, the threat is neutralised, then the eye moves on.The problem is what happens in the silence between threats. Office sat largely untouched for years. Not because Microsoft couldn’t improve it. Because nothing was threatening it enough to deserve the eye’s attention.Now AI does. Copilot is the response. But a well-funded startup with no legacy codebase and a modern large language model could build something better in under a year. Microsoft’s own model created the conditions for its disruption.Toys "R" Us: Acquire and ExtractToys "R" Us didn't lose to Amazon. It lost to its own balance sheet.In 2005, a private equity consortium acquired the chain in a leveraged buyout, financed mostly with borrowed money, and pushed that debt straight onto the company's own books. From day one, hundreds of millions of dollars a year that should have funded better stores, a real e-commerce platform, or sharper pricing went to interest payments instead. The buyers then sold off the company's real estate and leased it back, booking a quick profit for themselves while saddling the business with rent it had never had to pay before.Acquire a dominant brand. Load it with debt it didn't choose. Extract value through fees, leasebacks, and financial restructuring. Defer reinvestment until competitors close the gap permanently. None of this is incompetence. It is the operating model working exactly as designed, just not in service of the business that's carrying it.It works for the buyers. The financials are exceptional, the fees are collected, the exit is timed well before the consequences land. But no one chooses to be the company carrying someone else's leverage. Toys "R" Us didn't lose on product, price, or brand. Every dollar that should have gone into competing was already spoken for the day the deal closed.Extraction is not a strategy. It is a countdown.Apple: The Platform is the MoatThe moat is real. The manufacturing advantage is extraordinary. No one comes close.But the moat doesn’t produce the next iPhone. It protects what exists. Vision Pro is the tell: breathtaking execution, unclear customer problem. The model optimises for defending the platform. It does not naturally generate the kind of disruptive offence that created the platform in the first place.Apple without Jobs is a different company running the same plays on accumulated momentum. So far, that has been enough.McDonald's: The FranchiseMcDonald's doesn't sell burgers. It sells a system so well specified that judgment becomes unnecessary. The fryer timing, the assembly sequence, the real estate model, the supplier contracts: all of it is designed to produce the same result whether the operator is a genius or a journeyman.That's the entire point. A franchise model optimises for replication, not innovation. It can scale to tens of thousands of locations precisely because it has engineered out the need for local judgment. The system is the product.The blind spot is the mirror image of the strength. A model built to remove judgment cannot easily ask for it back when the market shifts. McDonald's has spent years bolting on delivery, digital ordering, and menu localisation, each a genuine innovation, but each fighting against an operating model designed for sameness. The franchisee who built a business on not having to think is rarely the one who spots the next shift early.The other failure mode is closer to home. My local bubble tea shop is part of a franchise chain, and the moment it falls out of consistency, wrong ratio, slow service, a flat batch of tea, it's a fast path to one star reviews and instant decline. The whole value of the model is the promise that this location will be identical to every other location. Break that promise once and the system itself works against you, because the customer wasn't loyal to the shop. They were loyal to the standard.The Lifestyle BusinessNot every business is trying to get bigger. The lifestyle business is built deliberately around a ceiling: enough revenue to fund the life the owner wants, no more growth than that requires, and no appetite for the debt, hiring, or risk that scale demands.This is not a failure mode. A consultancy with three partners and a full book of work, a regional manufacturer happy supplying its existing customers, a single well-run restaurant: these can be excellent businesses on their own terms. The model optimises for control and lifestyle, not expansion.The blind spot is what happens when the owner's ambition and the business's stated trajectory quietly diverge. Leaders running lifestyle businesses often keep using the language of growth, scale plans, expansion strategy, while every actual decision protects the ceiling. The operating model is honest even when the leader isn't. Recognising which one you're actually running, rather than which one you're describing in the board pack, is the diagnostic moment.Retailers, in the Food CourtAnother Thai restaurant opens two doors down from the one that's already there. Same menu, same prices, same hours. Neither has a reason to win other than being slightly more convenient on a given night.That's the food court model: same product, same market, no differentiation, competing on proximity, price, or whoever shouts loudest this week. It's rarely chosen deliberately. It's what happens when a business enters a crowded market without first answering what it does differently, and then never goes back to ask the question.The blind spot is durability. Leaders running a food court business often believe the lack of differentiation is temporary, a problem they'll solve once things settle down. But the operating model locks it in. Without a deliberate point of difference built into pricing, product, or distribution, every decision defaults to matching the competitor next door rather than escaping the comparison. There is no version of this model that earns a premium. It only ever earns a marginThe Blind Spot Built Into Your ModelHere is the uncomfortable truth that connects all four.Every operating model creates a blind spot. Not by accident. By design. What you optimise for determines what you can see. And what you can’t.Amazon optimises for the customer. It can’t see markets where customers aren’t yet asking.Microsoft optimises for the competitor. It can’t see the slow erosion happening in markets nothing is threatening yet.Broadcom optimises for the balance sheet. It can’t see, or doesn’t care, what it’s destroying in the process.Apple optimises for the platform. It can’t see the problems that don’t fit inside it.The model that makes you successful is the same model that limits you. That’s not a flaw. It’s physics. You cannot optimise for everything simultaneously. Focus is a choice, and every choice has a cost.The problem isn’t having a blind spot. Every leader does. Every organisation does.The problem is not knowing where yours is.Because your competitors do.Are You Playing Offence or Defence?Most organisations default to defence. They protect existing revenue, existing customers, existing market position. They respond to threats rather than create them. They optimise for not losing rather than for winning.And they call it strategy.Defence feels responsible. It feels prudent. It feels like good stewardship of what has been built. In stable markets, it can be enough.But markets are not stable right now. And in an unstable market, defence is a slow loss. You are not protecting a position. You are watching it erode, one quarter at a time, while calling it discipline.Offence looks different. Offence means identifying the unloved dominant player in your market, the Microsoft Office, the VMware, the bloated incumbent that customers are paying for because switching feels too hard, and asking whether now is the moment to attack it. Offence means crossing the valley of death deliberately, eyes open, because you have decided the other side is worth the pain.These seven models mapped in this frame tell an interesting story.Amazon plays defence dressed as customer focus. Microsoft plays reactive offence, but only when threatened. Toys "R" Us didn't play either; the buyers who controlled it harvested value and left before the consequences landed. Apple plays defence and calls it premiumisation. McDonald's plays defence dressed as consistency, the system is built to protect the formula, not to attack anything. The lifestyle business has usually opted out of the game entirely, by design. Food court isn't playing either game; it hasn't chosen a position to defend or a target to attack, which is its own kind of answerNone of them are playing proactive offence right now. Not one of the most successful companies in the world is looking at an adjacent market and attacking it because the moment is right, not because a threat forced their hand.That is the gap. And it is sitting open in your market too.The question is whether you see it. And whether you have the model, and the nerve, to go after it.The AI Moment Changes the MathsThis has always been true. What’s different now is the speed.AI has collapsed the cost of building software. A startup with a small team, a modern large language model, and no legacy infrastructure can build in months what previously took years. The barriers that protected incumbent platforms, the switching costs, the integration complexity, the sheer engineering effort required to match feature parity, are eroding faster than most leaders realise.Every market has a Microsoft Office sitting in it. A dominant, expensive, deeply unloved product that customers use not because it’s good but because replacing it felt impossible. For twenty years, that feeling was largely correct. The cost and complexity of a credible alternative was prohibitive for anyone without Microsoft’s resources.That calculation has changed.The valley of death just got shorter. The other side just got closer. And the number of organisations with the capability to make the crossing just got dramatically larger.This is what makes the offence/defence question urgent right now, not just interesting. Twelve months ago your incumbent position was protected by complexity. Today it is protected by inertia. Those are not the same thing. Inertia breaks suddenly and without warning.The organisations that understand this are already moving. They are mapping their market for unloved dominants. They are asking which valley is worth crossing. They are building the offensive capability before the threat arrives, not in response to it.The ones that don’t are sitting in their own valley of death. They just haven’t drawn the chart yet.Three Questions Your Leadership Team Should Be Able to AnswerThis is not a theoretical problem. It is a diagnostic one.Most leadership teams cannot answer these three questions clearly. Not because they aren’t smart enough. Because the operating model they’re running doesn’t require them to.One. Which model are you running?Are you Amazon, working backwards from the customer? Microsoft, watching the competitive landscape for threats? Broadcom, extracting value from a captive base? Apple, defending a platform?Most organisations are running a hybrid, usually an unintentional one. Elements of customer focus mixed with competitive reaction, layered over a cost structure that looks a lot like extraction. Name it honestly before you try to change it.Two. Did you choose it?This is the harder question. Most operating models are inherited, not chosen. They emerged from the founder’s instincts, or the first big customer, or the competitive pressure of an earlier era. They calcified into process and culture before anyone stopped to ask whether they were still right.Inherited models are not automatically wrong. But running an inherited model without interrogating it is how organisations sleepwalk into irrelevance.Three. Is it still right for where your market is going?Not where your market has been. Where it is going.If AI is collapsing the cost of your competitors’ build, your defensive position is weaker than your balance sheet suggests. If the unloved dominant in your market is suddenly vulnerable, the window to attack it will not stay open indefinitely. If you are in the valley of death right now, the question is not how to avoid the pain. It is whether the other side justifies it.These are not technology questions. They are leadership questions. And they need to be answered at the table where strategy is set, not delegated to the team running the roadmap.The Chart on the WhiteboardI never forgot that conversation with the CEO. Not because of the valley of death. Because of what he understood that most leaders don’t.He knew exactly which game he was playing. He knew the cost of crossing. He knew what was waiting on the other side. And he made the call with his eyes open.That clarity is rarer than it should be.Most leaders are somewhere in the valley right now. Defending a position they didn’t choose, in a market that is moving faster than their model was designed for, with competitors who have already done the maths on what AI makes possible.The valley of death is not the problem. It is the moment of clarity.The question is not whether your organisation will face it. It will. The question is whether you will draw the chart before someone else draws it for you.Amazon, Microsoft, Apple, Broadcom. Four of the most successful companies ever built. Each running a model that made them great. Each carrying the blind spot that model created. None of them immune to the question.Neither are you.So. Are you playing offence or defence?Did you choose that?And is it still the right call?Get instant access to A Free 22 page diagnostic to run with your team to understand distance between stated intent and lived execution.Bruce McLeod has spent 30 years inside the gap between how organisations say they work and how they actually do, from inside Microsoft, ThoughtWorks and Amazon Web Services. He advises senior leaders on operating model design, AI-augmented delivery, and the decisions that determine whether transformation actually sticks.Everything in this article is his personal opinion based on publicly cited references, listed below. This is one practitioner's view, offered in the spirit of understanding what makes something great, and what it takes to keep it that way.ReferencesAmazon: Working BackwardsAmazon Leadership Principles: Customer Obsession. Amazon. https://www.aboutamazon.com/news/workplace/what-do-each-of-amazons-leadership-principles-really-meanHow Amazon defines and operationalises a Day 1 culture. AWS Executive Insights. https://aws.amazon.com/executive-insights/content/how-amazon-defines-and-operationalizes-a-day-1-culture/Bryar, C. and Carr, B. Working Backwards: Insights, Stories, and Secrets from Inside Amazon. St. Martin’s Press, 2021.Microsoft: Embrace, Extend, ExtinguishEmbrace, extend and extinguish. Wikipedia. https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguishThe inside story of the browser wars. TechRadar. https://www.techradar.com/news/the-story-of-the-browser-wars-told-from-the-frontlinesUnited States v. Microsoft Corporation. US Department of Justice, May 18, 1998. https://www.justice.gov/archive/atr/public/press_releases/1998/1764.htmMicrosoft antitrust case of 1998. The Silicon Underground. https://dfarq.homeip.net/microsoft-antitrust-case-of-1998/Sun, Microsoft settle Java lawsuit. InfoWorld, January 23, 2001. https://www.infoworld.com/article/2159673/sun-microsoft-settle-java-lawsuit.htmlMicrosoft and Sun Microsystems enter broad cooperation agreement; settle outstanding litigation. Microsoft News, April 2, 2004. https://news.microsoft.com/2004/04/02/microsoft-and-sun-microsystems-enter-broad-cooperation-agreement-settle-outstanding-litigation/Toys "R" Us: Acquire and ExtractHow private equity killed Toys "R" Us: the leveraged buyout, debt load, and bankruptcy. In These Times. https://inthesetimes.com/article/how-private-equity-killed-toys-r-usToys "R" Us collapse: how private equity loaded it with debt. Headcount Coffee. https://www.headcountcoffee.com/blogs/corporate-legends-lost-empires/how-private-equity-destroyed-toys-r-us-the-real-story-behind-the-bankruptcyWhen private equity gutted Toys "R" Us: leveraged buyouts and the sale-leaseback. Inequality Focus. When private equity gutted Toys "R" Us: leveraged buyouts and the sale-leaseback. Inequality Focus. https://inequalityfocus.substack.com/p/when-private-equity-gutted-toys-rApple: The Platform is the MoatApple Vision Pro sales plummet despite M5 chip upgrade. Gadget Hacks. https://apple.gadgethacks.com/news/apple-vision-pro-sales-plummet-despite-m5-chip-upgrade/Apple retreats on Vision Pro as consumer demand falls short. PYMNTS, January 2026. https://www.pymnts.com/apple/2026/apple-retreats-on-vision-pro-as-consumer-demand-falls-short/Apple Vision Pro production halted as sales collapse. Fintool News. https://fintool.com/newMcDonald's: The FranchiseMcDonald's franchise model: approximately 95 per cent of restaurants franchisee-operated, real estate and standardisation strategy. Arthnova. https://arthnova.com/mcdonalds-franchise-model-scaling-lessons/How McDonald's franchise model works: standardised recipes, training, and quality control systems. McDonald's Menu Guide. https://mcdo-menu-guide.com/franchise-model/Case study: the strategic franchising model of McDonald's. Smart Life Skills. https://smartlifeskills.co.uk/business-management-business-environment-case-study-franchising-of-mcdonalds/The Lifestyle BusinessLifestyle business. Wikipedia. https://en.wikipedia.org/wiki/Lifestyle_businessLifestyle business: definition, examples, and how it differs from a growth business. WallStreetMojo. https://www.wallstreetmojo.com/lifestyle-business/Small business is either a lifestyle or a scalable enterprise: which one are you? Cavitch Familo & Durkin. https://www.cavitch.com/blog/2023/09/small-business-is-either-a-lifestyle-or-a-scalable-enterprise-which-one-are-you/Food CourtCommoditization: business definition and characteristics, price-oriented competition and the race to the bottom. WallStreetPrep. https://www.wallstreetprep.com/knowledge/commoditization/Differentiating your business in a commodity market. Ntiva. https://www.ntiva.com/blog/differentiating-your-business-in-a-commodity-marketWhy do competitors open their stores next to one another? – Jac de Haan ---