A Survival Guide to Leading Software Projects (When You Don't Code)
| I read an article by Sean Goedecke, a software engineer who writes quite a lot about technology, engineering, and software design. The title was already a small provocation: Software is slow because of bad design, not slow languages. In other words, software can be slow because of poor design, and the programming language may have very little to do with it. I found this interesting, especially because we are in 2026, when asking an artificial intelligence to rewrite thousands of lines of code in another language no longer sounds like such a crazy idea. Quite the opposite. It has become a very tempting possibility, and I wouldn’t be surprised to see someone proposing a complete rewrite of a system as the solution to a performance problem. The logic seems simple, right? If a program written in Python is slow, and C can execute certain operations dozens of times faster, why not ask an AI agent to rewrite everything in C? Or Rust? Or, for someone feeling particularly adventurous, assembly? Done. Problem solved. The company saves money, the system becomes fifty times faster, users are happy, and the project manager can finally turn that status report green. Wonderful! Except it doesn’t really work like that. Goedecke’s argument is that, in many systems, the real problem is somewhere else. And this is where I started thinking about something that, for me personally, has much more to do with project management than programming. How often do we discuss a technically sophisticated solution before we properly understand the problem we are trying to solve? A Ferrari won’t solve the traffic on the E6I’ll use a comparison that is quite close to my reality here in Sweden. For anyone who has to deal with traffic on the E6 towards Gothenburg, there is an important difference between having a fast car and getting to work faster. If half of your journey is spent in a line of cars that are barely moving, replacing your car with a Ferrari won’t change much. You might save a few minutes on the parts of the road where traffic is moving, of course, but the Ferrari will still be sitting behind the same truck, probably burning more fuel (and costing you a lot more money). I think you get the idea... Something similar happens in many software systems. A program can spend a considerable part of its time waiting for something to happen. Waiting for a database response, information from another system, communication over a network, or data being read from a disk. Software engineers call these systems I/O-bound, meaning their performance is mainly limited by input and output operations. The other case is CPU-bound, when the main limitation is the processing work itself. And this distinction changes the conversation quite a bit. Goedecke gives an example where 50% of an application’s response time is spent querying a database. If you somehow managed to make the entire remaining part of the program execute instantly (which would be a pretty impressive miracle), the total response time would be cut in half. So, in the best possible case, the system would become twice as fast. Nothing close to fifty times. And in practice, the improvement would probably be smaller. Back in 1967, computer engineer Gene Amdahl published a paper about the limits of speeding up computing systems, which became the foundation of the famous Amdahl’s Law. The basic idea, to simplify things quite a lot, is that you can make one part of a program incredibly fast, but the overall improvement will still be limited by everything you cannot speed up. And here I found an interesting connection with Eliyahu Goldratt’s Theory of Constraints, which became well known in management through his 1984 book The Goal. Goldratt explained how the performance of a process depends on its constraints, and why improving a step that is not the bottleneck may do absolutely nothing for the final result. They are different concepts, of course, but I like how both lead us to a similar question: what’s the point of making something much faster if the thing that really limits the system stays exactly the same? You can improve one part of a process by an incredible amount and still be limited by the time spent on everything that hasn’t changed. It seems obvious once someone explains it, doesn’t it? But this is where my mind started moving away from code, because this logic feels far too familiar to stay inside software engineering. Think about approval processes inside a company. We can automate documents, connect tools, remove manual tasks, use AI to prepare reports, and make dozens of small improvements. But if an important decision still depends on someone who takes two weeks to answer an email, much of that efficiency simply disappears while everyone waits. And this makes me think about how many projects are treated as execution problems when the real issue is that decisions are not being made. The team receives more tools, more meetings, more reports, perhaps more people, and the dependency that is causing the delay remains exactly where it was. Maybe software architecture and the way we design organizational processes have much more in common than we might think. Curiously, this reminded me of another discussion I recently brought up in an article about how to tell if your company’s next AI tool will end up costing more than it delivers. We have an impressive ability to discuss tools before investigating the work we want to improve. With AI, that temptation has become even stronger. But back to software, because there is another good story here. The engineer who expected to lose 20% and gained 30%In Goedecke’s article, I found a reference to a 2018 experience by Bryan Cantrill, an engineer with a great deal of experience in systems programming. Cantrill was rewriting a program in Rust that he had previously developed in C, a language well known for its high performance. The problem was that the original program’s carefully improved design didn’t fit very well with Rust’s rules. After trying to reproduce the same structure, he decided to write a simpler implementation, almost giving up on the original performance concerns. He expected the new version to be at least 20% slower. Instead, it was around 30% faster. Well, that was unexpected. The interesting part is that this improvement didn’t happen simply because Rust was a faster language than C. Cantrill investigated the results and found that a large part of the difference came from the data structures used by the two implementations. The C version used a binary search tree, and the Rust implementation used a B-tree, which in that particular case made better use of the processor’s memory cache. For those who have absolutely no obligation to know what a B-tree is, the way the program organized and accessed its data made a bigger difference than the language itself. And what I find curious is that this happened in the work of someone who knew very well how to write fast code. Of course, it would be a mistake to conclude that programming languages never matter. Sometimes they matter a lot, including for performance, security, and maintenance. Cantrill himself explains how Rust’s characteristics influenced the implementation and the structures he used. But the story shows something interesting: even a choice that might look small from the outside, such as the structure used to store data, can change a system’s performance considerably. I think this is a useful reminder for people who manage technology projects. After all, we discuss languages, infrastructure, tools, and architecture all the time, but do we really understand which of these decisions make a difference to the problem we have? So where does the project manager fit into all this?This is the part that interests me most. There is a very understandable insecurity among professionals who manage software projects but don’t come from a software development background. The feeling that, to participate in a discussion about architecture, you must know programming languages, frameworks, development patterns, and every technical concept that appears in the conversation (preferably without having to ask what each acronym means). And look, knowing technology helps a lot. I’m not going to try to convince anyone otherwise. But I think there is an important difference between understanding a technical decision and being qualified to make that decision. A project manager doesn’t need to choose which data structure an engineer should use. And certainly shouldn’t leave a meeting telling the team to abandon Python and start writing everything in Rust just because they read an interesting article about it. That would be, at the very least, a rather questionable contribution. On the other hand, our management responsibility doesn’t disappear just because the conversation becomes technical. If someone proposes a complete rewrite of a system, we are talking about time, investment, risks, dependencies, maintenance, quality, and, most importantly, a promise of results that needs to be understood. And the project manager needs to be able to participate in that conversation. This doesn’t mean questioning everything engineers say or thinking that every technical decision needs approval from someone in management. That would be a wonderful way to create yet another approval queue, exactly the kind I was complaining about a few paragraphs ago. What interests me is the ability to understand enough to ask good questions, follow the alternatives, and help connect technical decisions with the project’s objectives. Let’s go back to Goedecke’s article. When he describes the changes that brought real performance improvements in systems he worked on, we find things like storing the results of slow operations so they don’t need to run again (the famous cache), running slow tasks in the background, performing operations in parallel instead of one after another, improving database queries, and simply removing unnecessary work. Notice what these solutions have in common. They all start from understanding where the system spends its time and how that work could be organized differently. And a project manager can understand this logic without knowing how to implement any of these solutions. In fact, I think this is one of the most interesting contributions we can make in a technical conversation: helping turn a proposed solution into a decision that makes sense for the project as a whole. Because, let’s be fair, a proposal can be technically excellent and still be a poor decision for that particular moment in the project. The opposite can happen too. A less elegant technical solution may be perfectly good for what the business needs, considering the restrictions that exist. Goedecke published another interesting article called What requirements don’t you have?. I particularly liked his argument that, when designing a system, understanding the requirements you don’t need to meet can be just as important as knowing the ones you do. What can be slow? What information can stay a few minutes out of date? Where can we accept less flexibility in exchange for simplicity? Which unusual situations really need to be handled? Now, that is a good discussion to bring into a project scope conversation. We spend so much time trying to identify every requirement, every expectation, every possible future need, that sometimes we forget to ask about the things we can consciously leave out. And every piece of work we decide not to do, when that decision is properly understood, can reduce the complexity of what really matters. But there is a problem with my defense of asking good questions. You can’t just go around asking about everything without making any effort to understand the answers. That would be another wonderful way to drive engineers (even more) crazy. So maybe it’s worth talking a little about what a project manager should study... 13 technology topics that can make a huge difference in your next projectsWell, if you don’t need to become a programmer, what should you study? I think this is an interesting question, especially because there is an absurd amount of knowledge inside technology, and if you try to learn everything, you will probably end up knowing a little about many things without being able to connect them to the work you actually need to do. Thinking specifically about people who manage software projects, I would start with thirteen topics. I’m not suggesting that you study each one until you can discuss implementation details with an experienced engineer. I’m talking about developing enough knowledge to understand problems, follow decisions, and see their consequences for the project. And the difference can be enormous… Let’s see: 1. Software Architecture Understand how a system is organized, how its components connect, and why we have monolithic architectures, microservices, and so many other approaches. When someone proposes breaking a system into several services, you begin to understand what that decision might improve and the extra work it can create. It’s worth paying attention to coupling, which describes how much components depend on one another. Some dependencies can make it difficult to change one part of the system without affecting others. And this helps explain why an estimate that seems simple at first can grow quite a lot once the team starts investigating the work involved. 2. Cloud Computing and Cloud Services AWS, Azure, Google Cloud, infrastructure as a service, managed platforms, serverless. We already have a nice collection of names to start with. You don’t need to learn how to configure all of this, but you should understand what it means to run a system in the cloud, which responsibilities remain with the company, and how these choices affect costs, security, dependence on providers, and day-to-day operations. One thing I find particularly important is understanding that using the cloud doesn’t automatically mean saving money. It creates enormous possibilities, but someone still needs to design, configure, monitor, and pay for the infrastructure being used. And depending on the decisions, the bill can be quite a surprise. 3. APIs and System Integrations An API is, to simplify things quite a lot, a way for systems to communicate with one another. And that communication can fail, take time, or depend on third parties. Understanding the basics of APIs, authentication, integration contracts, and communication between services helps explain why something that looks small can become a major dependency in your project schedule. It’s useful to know the difference between synchronous communication, where one system waits for another to respond, and asynchronous communication, where the work can continue without waiting for an immediate answer. Remember the traffic jam on the E6? Yes, it appears here too, though some waiting is unavoidable. 4. Databases and Data Flow Where is the data stored? How is it accessed? What happens when information needs to move from one system to another? You don’t need to write a single line of SQL, but understanding relational databases, NoSQL, migrations, and data quality can help a lot in discussions about estimates, risks, and changes. This is especially true in projects involving older systems, because migrating data rarely means simply copying information from one place to another. There are different formats, business rules, relationships between records, and data quality problems that can make the job much more complicated. And, as we saw in Goedecke’s article, the way data is accessed can have an enormous impact on performance. 5. Development, Testing, and Production Environments A feature can work perfectly in a development environment and cause problems when it reaches production. Why? Because these environments can have different configurations, data volumes, integrations, permissions, and behavior. Understanding why different environments exist and which dependencies need to be checked can help avoid some very unpleasant surprises close to a launch date. It helps explain why a team can say that a feature has been developed but still needs time to check how it works in the environment where people will actually use it. 6. Git, CI/CD, and Software Delivery I know, this already sounds like an alphabet soup. But understanding how developers control versions, combine changes, automate checks, and release new versions of software can change quite a lot in the way you think about deliveries, release frequency, risks, and planning. CI/CD refers to continuous integration and continuous delivery or deployment practices, which can automate important parts of the development and release process. It’s useful to learn what a rollback means, returning to a previous version when something goes wrong. And to understand that going back is not always simple. Depending on the change, especially when data is involved, reversing it can require considerable preparation. 7. Software Testing and Quality Assurance Unit tests, integration tests, end-to-end tests, automated tests, and manual tests. Each helps answer different questions about the quality of a system. Knowing these differences helps you understand why a feature can be developed but still not be ready for delivery. It lets you participate more effectively in discussions about testing strategy, acceptance criteria, risks, and test coverage. After all, no collection of tests can prove that a piece of software is completely free of problems. And why can trying to recover a delayed schedule by simply cutting testing become so expensive? Well, I think that question deserves some attention before someone decides that quality is a good place to save time. 8. Performance and Bottlenecks Now we’re back to the discussion that started this article. Understanding latency, throughput, CPU usage, input and output operations, and how bottlenecks are identified helps you follow improvement proposals without depending only on someone saying that a certain technology is faster. Latency is the time it takes to get a response. Throughput is the amount of work a system can process during a given period. They seem like similar concepts, but they describe different things. A system can respond very quickly to one request and struggle when thousands of users start using it at the same time. Sometimes the problem is the language. Other times, it’s the way the system was designed. And what matters is knowing how to find out. 9. Scalability and Capacity A system that works perfectly with one hundred users may behave very differently with one hundred thousand. It’s worth studying vertical and horizontal scaling, how systems handle peaks in demand, and why adding more infrastructure doesn’t always solve a capacity problem. This discussion appears frequently in projects involving user growth, service expansion, or large volumes of information. It affects costs, requirements, and planning too. Preparing a system for demand that may never arrive can be just as problematic as ignoring demand that is already coming. 10. Availability, Resilience, and Recovery What happens when a service stops working? Is there any redundancy? How long can the system be unavailable? How much data could we lose without causing a serious problem? Understanding concepts such as availability, disaster recovery, RTO (Recovery Time Objective), and RPO (Recovery Point Objective, related to acceptable data loss) helps turn technical concerns into business decisions. These concepts can sound very specialized until the moment we need to decide how much money to invest in preventing an interruption. Because keeping a system available almost all the time usually requires different investments and technical choices from running a system that can be offline for a few hours without serious consequences. And the business needs to be part of that decision. 11. Information Security and Access Control Authentication, authorization, encryption, permissions, data protection, and vulnerabilities. I would give this topic particular attention, because security shouldn’t appear only during a review just before launch. Knowing how to ask questions about access, information exposure, vulnerabilities, and responsibilities can already help quite a lot, without requiring you to know the technical details of every solution. Security involves decisions about architecture, development, operations, and processes. There is little benefit in having very well-protected infrastructure if the permissions given to users are inappropriate, for example. 12. Monitoring and Observability How do we know a system is working correctly after it has been released to production? What can logs, metrics, and alerts tell us? How does a team find the source of a problem when several services are involved? Understanding the basics of monitoring and observability helps you see that delivering software is just one part of the story. Someone still needs to identify, investigate, and fix problems when they happen. And if the project hasn’t considered how the system will be monitored and operated, we might be delivering something that works but will be very difficult to keep working. 13. Technical Debt and Software Maintenance Perhaps one of the most important topics for people who manage projects, because it involves decisions that often look good in the short term. A quick solution can meet a need today and make future changes more difficult. Poor architectural choices, insufficient testing, old dependencies, or temporary decisions that were never reviewed can increase the effort required to continue developing a system. This doesn’t mean that every technical debt decision is a mistake. Sometimes consciously accepting a temporary solution makes perfect sense. The problem starts when nobody understands the cost of that decision or when something temporary is treated as if it were permanent. And here we return to that earlier discussion about the requirements we decide not to meet. Sometimes doing less today is the best decision. In other cases, we are simply pushing a problem into the future. The difference is not always obvious, and that is exactly why we should understand the consequences before making the choice. Okay, but do I really need to study all of this?Not necessarily. And definitely not all at once. Notice how almost all these topics connect to things a project manager needs to discuss? Estimates, risks, budgets, dependencies, scope, quality, schedules, decisions, and future consequences. And none of them requires you to know how to program before you start learning. Of course, depending on the type of project, some topics will be much more relevant than others. Someone working on a system migration will probably need to understand quite a lot about data, integrations, and cloud services. Someone managing the development of a digital product might find more value in studying architecture, quality, performance, and software delivery. And here I see a very interesting opportunity. Instead of studying these topics as if you were preparing for an exam, memorizing definitions and acronyms, why not learn by looking at the systems we already work with? Understand how they work, talk to the people building them, and try to connect each concept to a real decision. By the way, this discussion about learning technology reminded me of something I wrote about the ten minutes of internet access I had each week when I was younger. Ten minutes... That was the free internet time I had before my computer course, and I needed to use every second to download as much material as possible to study later, at home, without an internet connection. During the week, questions would come up, problems would appear, and I would try different things in my code. I wrote everything down, and by the time I finally had internet access again, many of those questions had already been answered through trial and error. Today, things are almost the opposite. We have immediate access to courses, documentation, videos, books, communities, and now artificial intelligence tools that can explain a technical concept in several ways, answer questions, and help us experiment with different solutions. I’m certainly not saying that having ten minutes of internet access was better, for God’s sake. I would have loved to have all these tools back then. But there is something about that learning process that still makes sense to me: the question came from a problem I was genuinely trying to solve. And maybe that is a very effective way to learn technology when we work with projects. You hear a concept in a meeting, realize you don’t fully understand it, study it, return to the subject, and start connecting the pieces. In the next conversation, you understand a little more. Then another concept appears. And your knowledge keeps growing around real problems, without the need to master an entire subject before you can start using what you have learned. Two books, a coffee, and a whiteboardFor anyone interested in studying a little more, there are two books I consider good starting points, though they approach the subject from different directions. The first is Accelerate, by Nicole Forsgren, Jez Humble, and Gene Kim. The book brings together research on software delivery performance and organizational practices associated with better results. I find it particularly interesting for managers because it helps connect technology, ways of working, and business results. The second is Fundamentals of Software Architecture, by Mark Richards and Neal Ford, which goes more directly into architectural decisions, different patterns, and the trade-offs that each choice requires. The second edition, published in 2025, covers topics including cloud, event-driven architecture, and generative AI. It’s a more technical read, but very useful for understanding how software engineers and architects think about systems. And, if I’m being practical, perhaps one of the easiest ways to start is one of the simplest. Invite an engineer from your team for a coffee and ask them to explain how the system you’re working on actually works, drawing it on a whiteboard. Where does the information enter the system? What happens after a user makes a request? Which systems communicate with each other? Where are the databases? What happens when a component becomes slow or stops responding? Of course, the first conversation will probably bring another twenty questions. And some answers will require more study, because complex systems are, well, complex. But I think that exercise would help you understand your project far more than memorizing a glossary of technical terms without knowing where those concepts appear in real work. And there is another benefit I find quite relevant. Understanding the system better can help you understand the people working on it, their concerns, their difficulties, and the reasons behind their decisions. Something that, for those of us working in management, has a lot of value. The question I couldn’t stop thinking aboutLet’s return to Goedecke’s article, because I think I’ve taken a sufficiently long detour into how project managers can learn technology. I started by reading about Rust and C, went through a Ferrari stuck on the E6, traveled back to 1967, returned to my old computer classes, and somehow ended up recommending coffee with an engineer. Not bad for an article about software performance. But there is a clear technical point in Goedecke’s argument: if the goal is to improve software performance, it makes sense to first measure what is happening and look for ways to improve the system’s design, before assuming that rewriting everything in a faster language will solve the problem. This doesn’t mean rewriting a system is always a bad idea. There are legitimate reasons to do it, including maintenance, security, portability, or limitations in the current architecture. And there are situations where the language itself really is a performance bottleneck. But we need to understand those reasons, because each one leads to a different conversation about costs, risks, and results. What stayed with me after reading the article, though, was something else. One of the insecurities of managing technical projects is knowing that you don’t know everything the people around you know. And that insecurity can lead us into two rather bad habits: giving opinions about subjects we don’t understand or staying out of discussions because we’re afraid of asking something basic. Maybe there is an important space between these two positions. A place for someone who understands their own role, respects the expertise of the people at the table, but still wants to understand the reasoning behind a decision. And that requires studying, of course. It requires curiosity and being comfortable admitting that we don’t know something. But it requires recognizing that our contribution to a technical discussion can come from a different kind of knowledge, from being able to connect a decision to the wider context of the project, its restrictions, and the results we are trying to achieve. After all, nobody should expect a project manager to know more about architecture than the architect, more about code than the developer, or more about security than the person responsible for security. But it would be rather strange to manage an entire project without having at least a basic understanding of what these people are building, which problems they are trying to solve, and why certain decisions matter. So, the next time someone suggests rewriting an entire system to make it faster, perhaps it’s worth starting with a very simple question: Okay, but where exactly are we losing time? If there is a good answer, great. We already have an interesting conversation ahead of us. If nobody knows the answer, I think we have just found a question that matters much more than which programming language we should use. And the Ferrari can stay at the dealership. At least for now. |
Posted on: November 04, 2026 09:00 AM
| Permalink |
Comments (1)
Why Volunteer Projects Build Stronger Project Leaders
| Most project managers build their leadership inside a single structure: one organization, one reporting line, and one set of incentives that makes people at least appear to follow the plan. That structure is useful for delivery, but it hides a question every project manager eventually faces, which is how much of their influence belongs to them and how much is borrowed from the org chart. Volunteering in professional communities, with PMI chapters as the most common entry point, is one of the few settings where that question gets an honest answer early in a career. It removes formal authority, reduces resources to almost nothing, and puts the project manager in front of people who owe them nothing except the time they chose to give. In a corporate project, part of the team's compliance is structural. People respond because the project manager shapes priorities, reports progress to their managers, or controls access to budget. (Sometimes...) Volunteer teams remove all of these levers, since contributors join because they believe in the goal and can leave at any moment without consequence. This is close to the condition Allan Cohen and David Bradford describe in Influence Without Authority, where influence depends on understanding what the other party values and offering something of equivalent worth in exchange. In a volunteer context those currencies are rarely money or status. They are purpose, learning, recognition, and the chance to work on something the contributor cares about, and a project manager who cannot identify them usually loses the team within a few weeks. The PMBOK Guide, Seventh Edition, lists "Demonstrate leadership behaviors" among its twelve principles and treats leadership as something any team member can exercise, independent of title. Volunteer work is a practical environment to test that principle without the safety net of positional power. Leadership developed where authority is absent tends to hold when authority is present, while the reverse is far less reliable. PMI's Talent Triangle groups the competencies of a project professional into Ways of Working, Power Skills, and Business Acumen. Certification preparation covers the first reasonably well. The second, which includes communication, collaborative leadership, and problem-solving, is much harder to develop in a classroom, and volunteer projects exercise it under realistic pressure. Adaptability under scarcity. Volunteer initiatives routinely combine firm deadlines with rotating contributors and free or improvised tools, and delivering under those conditions trains the habit of simplifying scope, reprioritizing quickly, and protecting the core outcome, which is what PMBOK 7 describes in its principle on adaptability and resiliency. Networks built on shared work. Mark Granovetter's 1973 paper on the strength of weak ties showed that connections outside a person's immediate circle carry a disproportionate share of new information and opportunities, and volunteer teams create exactly those ties across industries, seniority levels, and countries, with the added trust that comes from months of joint effort. Clarity for mixed audiences. A single volunteer initiative may require the same project manager to brief a chapter board, coordinate a student volunteer, and report progress to community members in the same week, so jargon fails with at least one audience and plain-language status updates become a constant discipline. The widely cited 70-20-10 model, associated with research at the Center for Creative Leadership, suggests that most leadership development comes from challenging experience, with relationships and formal coursework accounting for smaller shares. The exact proportions are debated in the literature, but the direction is consistent. Stretch assignments are where leadership capability grows, and early-career project managers rarely receive them inside their organizations, because stretch assignments tend to go to people who have already demonstrated the capability. Volunteering interrupts that loop. A second-year project manager can lead a chapter event, a mentoring program, or a content initiative with real stakeholders and real deadlines years before a comparable role would be offered at work. That was actually my case in my early years as a volunteer at PMI. The value, however, depends heavily on the role chosen. Passive membership (attending events and collecting professional development units) produces little of what is described above. The benefit comes from roles with delivery accountability, where there is a defined outcome, a team to coordinate, and a date that cannot move. The most accessible place to find those roles is usually the nearest PMI chapter. Chapters run events, mentoring programs, certification study groups, and community initiatives almost entirely through volunteers, and most of them have open roles at any given time that nobody has claimed. For an early-career project manager, the local chapter is a portfolio of real projects that requires no promotion to access, only the decision to ask for one. The practical step is small. Contact the chapter's volunteer lead or check its website, ask which initiatives currently need someone to own delivery, and choose one with a visible outcome within the next three to six months. That single commitment gives influence, adaptability, and communication a place to develop now, instead of waiting for a corporate role that may take years to offer the same exposure. Every project manager's career will eventually test whether their leadership depends on the org chart. A chapter role lets that test happen early, on a smaller scale, and on the project manager's own terms. |
Posted on: October 19, 2026 01:00 AM
| Permalink |
Comments (1)
Why Most Retrospectives Produce Documentation Instead of Learning
| Most project teams hold retrospectives. Far fewer can name a process change that originated in one and was still in place three months later. The gap is rarely a matter of attendance or goodwill. Teams show up, answer the three standard questions (what went well, what did not, what could improve), record the answers, and return to work. When the next cycle surfaces the same issues, the session has produced documentation without producing learning. The Agile Manifesto frames the purpose of the practice in its twelfth principle: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." The principle carries two actions of equal weight, reflecting and adjusting. Most retrospectives deliver the first and skip the second. Why retrospectives stay shallowDonald Schön, in The Reflective Practitioner (1983), distinguished reflection-in-action from reflection-on-action. The second, the deliberate interpretation of experience after the fact, is where professional learning takes place. Without it, teams accumulate events without drawing conclusions from them. Deliberate interpretation carries a psychological cost. Findings that threaten self-image, such as a flawed plan or a failed communication, trigger cognitive dissonance, the tendency described by Leon Festinger to resolve discomfort by rationalizing or attributing causes externally. In a group setting the result is predictable: discussion stays at the level of symptoms, and vendors, tools, or shifting priorities absorb the blame. The corrective is structure. A predictable, transparent process signals that the session is fair and that its target is the system. Psychological safety, in this sense, is partly a product of design. A structure that produces changeEsther Derby and Diana Larsen, in Agile Retrospectives: Making Good Teams Great (2006), propose a five-stage model that remains the most widely used reference for facilitation.
Two conditions determine whether this structure works. The first is safety. Amy Edmondson's research on psychological safety found that higher-performing teams reported more errors, because members felt able to discuss them openly. Facilitators reinforce this condition by stating Norm Kerth's Prime Directive at the start of each session: "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." When disagreement arises, the principle from Roger Fisher and William Ury's Getting to Yes applies directly: separate the people from the problem. A facilitator who names the dynamic ("there is a lot of frustration around this topic") without attributing it to an individual keeps the conversation on the system. The second condition is follow-through. Agreed actions belong in a visible improvement tracker, each with a single owner, and the next retrospective opens by reviewing their status before any new topic is raised. This mirrors the Plan-Do-Check-Act cycle from quality management, and a retrospective without that review step has no Check and no Act. Rotating formats such as Start-Stop-Continue, the 4Ls, or Mad-Sad-Glad helps sustain engagement over many cycles. These formats are secondary, and their value depends entirely on whether the underlying structure is in place. For early-career project managers, the practical implication is direct. The quality of a retrospective is measured by the actions still active a month later, and the facilitator's primary responsibility is protecting the two stages most often compressed: data gathering at the start and decision-making at the end. |
Posted on: October 12, 2026 01:00 AM
| Permalink |
Comments (2)
Why Projects Break During the Handoffs Nobody Owns
| Most project managers can produce a dependency list. Far fewer can say, for any line on that list, which person on their own team is watching it, and on what date that person will ask for written confirmation that the upstream work is still on schedule. That distance, between listing a dependency and managing one, is where a large share of late projects actually break. The schedule was not wrong. The estimates were not wrong. Something agreed in a hallway, or buried in an email thread from 3 months earlier, quietly stopped being true, and nobody found out until the week the dependent work was supposed to start. A dependency is any relationship where one piece of work cannot start, continue, or finish until something else happens first: another task, a decision, an approval, a vendor delivery, a person coming back from leave. Teams rarely miss them because they are hard to see during planning. They miss them because a dependency raised in a kickoff and assigned to nobody is a conversation, and conversations decay. There is a second reason, more cultural than technical. Dependency mapping carries the smell of governance theatre, the kind of artifact produced to satisfy a committee and then never opened again, so teams treat it as documentation rather than as an early warning instrument. Used properly it is closer to the wiring diagram of a house. Invisible while everything works, and the only thing worth having the moment something starts to smell like smoke. Four Relationships, Two AttributesThe precedence diagramming method, documented in PMI's scheduling practice and in earlier editions of the PMBOK Guide, describes four logical relationships between activities. The distinction is practical rather than academic, because each one fails in a different way and gives a different amount of warning.
The combination worth obsessing over is external and mandatory. Internal work is visible in a standup, a board, a hallway conversation. External work is visible only when somebody asks, and the answer arrives filtered through an account manager who has an incentive to sound calm. From Acknowledgement to MonitoringIn Normal Accidents (1984), the sociologist Charles Perrow described tightly coupled systems as those with no slack between components, where a small local failure propagates before anyone can intervene. Most project schedules are considerably more tightly coupled than the people who built them believe, because every compression of the timeline removes exactly the buffer that would have absorbed a late handoff. The collapse follows a predictable sequence. The dependency exists but is undocumented, then nobody is named as its owner, then no trigger date is set for confirming it, and by the time the delay announces itself the downstream work has already lost the time it needed to adapt. Human optimism accelerates all of this. Kahneman and Tversky named the planning fallacy in 1979, the systematic tendency to underestimate the time a task will take even with direct experience of the same task going long before. Optimistic estimates combined with untracked handoffs produce a project that looks healthy for months and then meets its accumulated delay during integration and testing, which is precisely the phase with the least remaining room to recover. Four practices convert acknowledgement into monitoring, and none of them require a tool purchase. Name an owner on your own side. For every external dependency, one person on the project team is responsible for tracking the other side's progress and raising the flag when it drifts. Nobody can own work performed by another organization, though anyone can own the monitoring of it, and that ownership is what most projects never assign. Set a proximity alarm at planning time. A proximity alarm is a date on the calendar, typically 2 to 3 weeks before the due date, when the owner obtains explicit confirmation that the commitment still holds. What counts is a confirmed status, since an assumption recorded as a fact is exactly what these alarms exist to catch. Anything short of a clear yes triggers the contingency plan immediately, while the runway to use it still exists. Keep a log with fields that force precision. A causal description ("because the vendor must complete the interface before integration testing can begin, our test start depends on delivery by 30 April") makes the risk legible to anyone skimming, where the phrase "API integration" hides it. The log needs the relationship type and attributes, the upstream owner and the dependency owner, the due date and the alarm date, a status limited to on track, at risk, blocked, or resolved, the impact expressed in days and in percentage of remaining buffer, and one sentence describing the contingency. Review weekly and look for concentration. A flat list of 50 dependencies hides the shape of the risk, while a sketch of deliverables as nodes and dependencies as arrows shows immediately which node has 6 arrows pointing into it. Those convergence points deserve the earliest alarms and the most developed fallback plans, because a slip there sets several workstreams on fire at the same moment. Escalation follows the same discipline. Reporting that a vendor is late produces anxiety and a request for more detail, while reporting that the delay is 8 days and consumes 35 percent of the remaining buffer to the integration milestone produces a decision, which is the actual point of escalating. None of this removes delays. It converts an unpleasant discovery 4 weeks before launch into a manageable decision taken much earlier, when options still cost less than apologies. For a project manager early in their career, the return on this practice is unusually high relative to its cost: one workshop that asks what must be finished first, what must run in parallel, and who outside the room holds a key, a named owner for every external link, and an alarm date written into the calendar before anyone feels nervous enough to need it. |
Posted on: October 05, 2026 01:00 AM
| Permalink |
Comments (3)
Why 31% of Complex Projects Fail to Deliver Their Benefits
| Complex stopped being a category and became the working condition. PMI's 2026 data on what that does to delivery, and to your record. In the 2024 Maximizing Project Success research, PMI measured how often projects fail to achieve the full scope of their originally intended benefits. The number was 12%. The 2026 Pulse of the Profession asked the same thing about complex projects specifically. The failure rate jumped to 31%. More than double. My first reaction was to distrust the number. Different studies, different questions, and different data slices usually have a methodology story sitting quietly behind them. Then I kept reading, and the report closes that escape route firmly. A massive 97% of project professionals say they managed at least one complex project in the past year. Over half classify those projects as significantly complex. Even more telling, 81% say projects have become more complex, and 37% describe the increase as significant. So the number that matters is not the failure rate... It is the population. Complex stopped being a category of project you get handed once every few years. It became the ordinary condition of our work. This means 31% is not describing some exotic subset of megaprojects in another industry. It is describing the environment where your delivery record is being written right now. After years of using the word in status meetings, what does PMI actually mean by complex? Complicated Is a Problem You Solve.Complex Is a Problem You Keep Answering.A complicated problem has many elements, and the relationships between those elements are knowable. You can map it out. Given enough expertise, effort, and the right resources, it resolves. A refinery turnaround with 4,000 activities is complicated. It is hard and exhausting, but knowable. A complex problem also has many elements, but the relationships between them are unpredictable. Complex systems evolve through their own interactions. Working through one calls for sensing, experimenting, and adjusting rather than just executing a fixed plan. PMI defines the difficulty not by effort or expertise, but by adaptation, emergence, and interdependence.
Complexity Is Not Risk, and This Confusion Is ExpensiveComplexity describes the conditions that make the project hard to predict, control, and stabilize in the first place. Complexity is a source of risk. Risks are the consequences that come out of it. They are not two names for the same discomfort. This explains something I have watched happen more than once, and have been on the wrong side of myself. You keep a genuinely good risk register. It is reviewed, owned, dated, and scored. And the project still gets taken apart by something that was never on it. In complex environments, risks are more interconnected and more likely to emerge over time. Organizational structures, human dynamics, and external forces interact in ways that amplify small issues into large ones. You cannot register a risk that does not exist yet as an identifiable event. You can only recognize the conditions that manufacture them. When the thing that hits you was never on the register, the conversation afterwards is almost never about the conditions. It is about your register. It is about whether you should have seen it coming. You lose that conversation every time, because you are defending an artifact that was built to answer a different question. Where the Friction Actually Comes FromOrganizational: The internal friction. Unclear decision-making authority, siloed teams, competing priorities, and misaligned objectives. Escalations take longer than they used to. Approvals stall in layers you did not know existed, and the question “who owns this?” keeps coming up. This scales with size. A large 91% of professionals in organizations of 100,000 or more report increasing complexity, against 78% in organizations under 500 people. Environmental: The external forces. Technology cycles, digital transformation, AI adoption, regulatory movement, geopolitical shifts, and supply chains. Requirements keep changing while everybody is still deciding. The world around the project simply moves faster than the plan does. Emerging technology resets what stakeholders consider reasonable on speed or cost, and a market event quietly changes what the word value means to your sponsor. Human: The social and cognitive layer. Competing incentives, politics, and relationship dynamics. Decision makers avoid committing. Teams second-guess a direction that was already given. Psychological safety becomes something you aspire to rather than something you have. This dimension requires emotional intelligence, influence, and coalition building (capabilities no methodology installs for you automatically). These dimensions interact. A regulatory shift (environmental) triggers new internal approvals (organizational), which increases anxiety and micromanagement (human). One force moves through three dimensions. By the time it reaches your team, it has stopped looking like regulation and started looking like a morale problem. Nearly half of project professionals name faster technology and tool cycles as a driver of complexity. But if you only treat the technology, you will keep treating the symptom three steps upstream from where your team is actually bleeding. The Finding That Should Change How You Spend Your WeekHigh performers (professionals whose complex projects perform above average) do not face less complexity. The report is explicit about this. They face the exact same conditions but respond to them differently, using intention and foresight. The difference is massive. A full 88% of projects were rated extremely or very successful when teams were highly effective at managing complexity. Compare that with just 14% when teams were only slightly effective or ineffective. Projects that handle complexity well are five times more likely to succeed. This is not a resourcing story. It is a capability story, and capability is the one variable you personally control. You do not need a new instrument to start. You need one simple discipline, and it costs you about 90 seconds. The next time something goes wrong on your project, before you write the escalation, classify it.
A complicated problem gets escalated with a solution attached and a request for resources or a decision. A complex one gets escalated with the conditions named and a request for a different operating agreement. You might need more frequent checkpoints, a decision right moved closer to the work, or a scope boundary that can flex on purpose instead of by accident. Most of the escalations I have seen fail happened because a complex condition was presented as a complicated problem. The sponsor gave a complicated answer: push harder, add a resource, tighten the plan. Nothing moved, because nothing in that answer touched the thing generating the trouble. You can name it now. That is real progress, and most people never get that far. What you still cannot do is measure it. That gap keeps this whole thing stuck at the level of a feeling. Feelings do not survive contact with a steering committee, but evidence does. In the next piece, I will hand you an actual diagnostic. It covers 15 items across the three dimensions. Each one is scored against something observable rather than against your mood on the day. You will be able to put a number and a profile in front of your sponsor and have a completely different conversation. |
Posted on: September 28, 2026 01:00 AM
| Permalink |
Comments (3)
