Adam Gonnerman

"The leader must own everything in his world. There is no one else to blame." — Jocko Willink, Extreme Ownership Having just been assigned to a cloud migration team, I was trying to get the lay of the land and understand where project work stood. What I gathered wasn't good. They hadn't had a project manager for about a year, and work had started to drift badly. That first week was when their manager called me into his office. He laid into me about how far behind everything was. His frustration directed at me felt like an accusation, as if I'd personally caused the delays. I could hardly get a word in edgewise as he vented. It became very clear to me that although I had no hand in creating the mess, it was mine now anyway.  This is part of inherited debt. When you step into a team, you don't just inherit a role. You inherit the technical shortcuts nobody documented, the cultural habits that formed before you arrived, and the strained relationships with stakeh...

There we were, on a Zoom call, sharing our quarterly roadmap with leadership. The visuals were clean with dates, themes, milestones, and color coding. I think it's safe to say that the emotional effect of such a roadmap is a sense of alignment, clarity, and reduced anxiety. That's where there may be a problem. Roadmaps create psychological safety, but that safety can become an illusion of control.  Visual order reduces anxiety. We humans are social beings, and stories are core to our way of thinking about life. We prefer structured narratives over ambiguity. A roadmap, high level though it may be compared to a detailed project plan, turns uncertainty into a sequence. Having dates implies predictability, and sequencing implies causality.  Executives, for their part, want forward visibility. They want to see into the near- and mid-term future to the extent possible. Sales wants commitments that can be communicated and kept. Finance wants forecasting. Engineers look at the roadma...

My title right now, were I employed, could be "program manager," "project manager," "technical program manager," or technical project manager. Fundamentally, a project manager thinks about planning, organizing, and guiding work so that a specific goal is achieved on time, within scope, and within budget. Unlike operations work, projects have a beginning, middle, and an end. They come and go. Now, I have held other titles. Once, at Scholastic, I held the title of Senior Technical Product Manager. This was a role that blended the fields of project and product management. Despite this experience, there came a time that I wanted a clearer and more current understanding of how strong product managers operate day to day. For this, I arranged to shadow a product manager where I worked. At the time, this was more about curiosity and personal growth, rather than role transition. Now, though, I could see a time coming in which I would want to transition into product...

Early in my career, I was invited to sit in on a meeting with enterprise architects and senior engineers to discuss an integration between a legacy content management system and a new distribution platform. I was there as the (fairly junior) project manager, not the technical authority in the room. The conversation quickly became highly specialized: API contracts, data schemas, caching layers, and system latency thresholds. It was clear I wasn’t the deepest technical expert at the table, and for the first part of the discussion, I mostly listened and felt a little lost. What I began to notice, however, was that while the technical details were sound, the group was implicitly optimizing for architectural elegance rather than delivery timing. No one was explicitly mapping the proposed solution against the external deadline tied to a partner launch. I asked a clarifying question that went something like this (I may have actually rambled a bit): “If we implemented the simpler, interim int...

Once when I was in a role supporting a multi-market digital release I was facilitating a meeting that had quickly become circular and unproductive. Engineering was discussing technical dependencies, product was focused on feature completeness, and regional stakeholders were raising compliance concerns. All of this was being discussed at the same time, with people occasionally talking over one another. Each group was using different terminology and optimizing for different risks, which made it difficult to determine what decision actually needed to be made. The conversation kept expanding instead of converging. What to do? I paused the discussion and reframed the session around three concrete questions: What decision are we making today? What constraints are non-negotiable? What options are truly on the table? I then captured each group’s concerns in plain language on a shared Google document, grouping them under timeline, compliance, and technical risk. This structure made overlaps a...

Several years back I was in a program role supporting high-visibility digital platform launches. As usual for such a role, I was responsible for driving an on-time release tied to contractual distribution milestones. Meanwhile, a senior engineer was focused on refactoring part of the integration layer to improve long-term maintainability. We were seemingly at cross-purposes, because my goal was to schedule adherence and certification readiness, and the senior engineer was technical sustainability and reducing future defects. These priorities seemed to be in tension, as deeper refactoring risked delaying launch. How could we move forward? Thinking it through, I decided that instead of forcing a trade-off, I would facilitate a working session to break the work into phases. That is, we would identify what refactoring was critical for launch stability versus what could be sequenced into a fast-follow release. Through this process we aligned on a minimal, high impact improvement set that re...