Adam Gonnerman

I still cringe thinking about that executive briefing years ago. Our team was six months into rebuilding the customer portal, and I had prepared what I thought was a thorough status update. I walked into the conference room armed with architecture diagrams, database schemas, and a detailed explanation of our microservices approach. Twenty minutes in, our CTO held up his hand. "Adam, I need to stop you there. Are we on track to launch in Q3 or not?" The room went silent. I had spent the entire presentation talking about technical elegance while completely missing what he actually needed to know: timeline, budget, and business impact. That uncomfortable moment taught me everything about communicating tech status upward. I had fallen into the engineer's trap of leading with mechanics instead of impact. The CTO didn't care about our service mesh implementation. He cared about whether customers would have the new features before the holiday shopping season. Since then, I...

Three months into my first project management role at a software company, I watched a colleague destroy his credibility in thirty seconds. The engineering team was discussing a legacy system bug, and someone cracked a joke about Visual Basic. My fellow PM laughed loudly and nodded knowingly, clearly trying to signal that he was technically savvy enough to get it. The problem was obvious to everyone in the room: he had no idea what they were talking about. The engineers exchanged glances, and I could practically see his authority evaporate. That moment crystallized something I'd been sensing for weeks. Walking into a team of skeptical engineers as a new project manager feels like entering a room where everyone speaks a different language and you're holding a phrase book upside down. These developers had been burned before by PMs who talked a big game but delivered bureaucracy instead of value. Some had been working without any project management oversight and genuinely questione...

Ask someone outside the profession what a project manager does and you'll hear some version of the same answer: they run meetings, update Jira boards, track tasks, and produce status reports. Maybe they build a Gantt chart or two. It's not wrong, exactly. Those things happen. But describing project management that way is like describing an iceberg by what you can see from the deck of a ship. The visible tip is real. The work below the surface is where the job actually lives. Beneath every clean status update is someone who spent the previous 48 hours balancing three competing priorities against a resource pool that couldn't support all of them. Beneath every smooth stakeholder meeting is a PM who quietly diffused a conflict before it ever reached the conference room. The Gantt chart your executives see on Friday reflects decisions, trade-offs, and conversations that never make it into any report. That's not an accident. That's the job. What the profession actuall...

In the summer of 1995 I was part of a work crew operating under the Job Training and Partnership Act , traveling between two counties doing maintenance, painting, and lawn work. It was my second year with the program and I was looking forward to it. What I was not looking forward to was what the summer actually became. The team leader, whose name I will change to Mark for the purposes of this piece, was not much of a leader. Within the first two weeks it was clear that he had little interest in working. Off-color jokes were a regular feature of the day. So was sitting around while hours ticked by. I brought my concerns to the regional supervisor, a woman I will call Scarlet. Her response was simple and direct: if I did not like it, I could quit. I did not quit. I stayed because I did not have time to find something else on short notice, and I needed the work. What followed was a long summer of profanity, inappropriate humor, and minimal productivity. And then, predictably, things got...

"Innovation is saying no to a thousand things."  -  Steve Jobs There is a meeting to align on a proposal. Turnout is good, including some fairly senior people. Opinions differ. Time runs out. A follow-up is scheduled, a revised deck will be produced, a pre-read will be distributed before the next alignment meeting. Nothing is blocked. No one has said no. Yet nothing moves. This is what organizational stall actually looks like. Not conflict. Not resistance. Diligence. Leaders often equate consensus with alignment, but they are not the same thing. Consensus means everyone agrees. Alignment means everyone understands the direction and their role in it, even if they would have chosen differently. One is a state of unanimous opinion. The other is a condition for coordinated action. When consensus becomes the goal, progress slows while risk quietly compounds. Consensus optimizes for harmony. It is a room full of nodding heads, objections softened or withdrawn, everyone heard and id...

Not every career follows a straight line. Mine has not come close to one, and I have spent enough time now looking back at the path to say with confidence that nothing along the way was wasted, even the parts that looked like detours at the time. When my family moved to New Jersey in 2005, I was walking away from full-time ministry without a clear idea of what came next. I explored options that ranged from the practical to the improbable. Tree trimming was on the list at one point. What I landed on first was a job teaching English as a Second Language in Newark. The pay was low and there were no benefits, but it was work, and it was work that required me to communicate clearly across significant cultural and linguistic distance every single day. I did not think of it as professional development at the time. Looking back, it was exactly that. Having taken an introductory paralegal course while living in New Mexico, I got the idea of pursuing work at a law firm. Without credentials or ...

There are moments in a program manager's career when following the established process is exactly the right call, and moments when following it blindly leads to serious problems. Knowing the difference is not something any methodology teaches you. It comes from experience, and sometimes from a project that goes sideways before it gets right. I was once tasked with leading an ADA compliance initiative for a company's primary application, covering web, mobile, and Smart TV platforms. Accessibility work is not optional. It is a legal and ethical obligation, and the stakes of getting it wrong extend well beyond a missed deadline. When I assumed the project it had already passed through the hands of two product managers, both of whom had moved on to other opportunities. I was inheriting something that had already lost momentum and institutional memory. I did what any program manager would do in that situation: gathered what information I could, held a structured kickoff meeting, al...

Nobody puts missionary experience on a project management resume. I did not either, at least not explicitly. But after fifteen years delivering complex technology programs, I am convinced that two years of mission service in Brazil shaped my professional instincts more than any methodology certification ever has. Let me explain why. After a mission internship in Brazil in 1997, I committed to returning as a full-time missionary. That meant getting the right education first. I enrolled in Harding University's School of Biblical Studies, an accelerated program that compressed nearly four years of education into two. The pace was relentless. I studied beginning through advanced biblical Greek in 24 weeks. Along the way I went deep not just into Scripture but into counseling, fundraising, cross-cultural communication, and the practical realities of sustaining a mission. I was trained to enter unfamiliar territory and figure it out. That turns out to be an extraordinarily useful profess...

“The purpose of a system is what it does.” — Stafford Beer A team drowning in slow approvals decides the problem is speed, so they add AI. Leadership announces a new assistant to unlock productivity. A chatbot is rolled out to close knowledge gaps and reduce internal friction. Demos look promising. Early outputs feel impressive. But weeks later, nothing fundamental has changed. Decisions are still unclear. Ownership is still fuzzy. Data is still inconsistent. If anything, the noise level has increased. You can't use AI to repair broken systems. What it does in reality is accelerate their weaknesses. You see, AI multiplies what already exists. Unclear decision rights leads directly to faster confusion. If no one knows who owns decisions, AI generates more options. Further, more stakeholders weigh in, and decision latency increases. Think about it like this: AI increases surface area of disagreement. Poor data result in confidently wrong outputs. If your data are incomplete, incons...

"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...

“The essence of strategy is choosing what not to do.” - Michael Porter It's a familiar event to anyone who has worked with a tech team. You have work well along on a project when a stakeholder comes along asking for "just one more feature." If you are the project manager or product manager, people will look to you for guidance. You know that capacity is full, tradeoffs are real, the roadmap will bend, and something inevitably will break. Yet, the pressure is subtle (or non-so-subtle, depending on the stakeholder). There's an expectation, perhaps, that you'll say that the team can make it work, suggest that all are aligned, and acknowledge that this is an important feature. So, you say "yes." Six weeks or less later, you find that delivery slips, quality drops, morale dips, and trust is now eroded. Leadership is not only about what you drive forward. It’s about what you refuse to absorb. We need to be clear that saying "no" is not obstruction....

“By failing to prepare, you are preparing to fail.” - Benjamin Franklin In startup and tech culture, we celebrate the last-minute save. But heroics are often symptoms of earlier neglect. Hero Culture thrives on moments like this: it's Friday at 4:47pm, a ticket has been sitting in review for two weeks, the stakeholder is impatient, and the engineer has a flight to catch, so someone pushes the deployment button because it's a small change and it's always fine. By 9pm there's a Slack thread, by 10pm it's a call, the engineer is somewhere over Ohio in airplane mode, and the one person who knows that part of the codebase is stepping outside a birthday dinner every fifteen minutes to check their phone. The fix takes forty minutes, the post-mortem takes two weeks, and the person who stayed up to save the night gets praised on Monday morning while the person who warned against Friday deployments three sprints ago is quietly forgotten. That's the thing about Hero Cult...

“Only when the tide goes out do you discover who’s been swimming naked.” -  Warren Buffett One consistent truth I have observed in business is that leaders tend to reward what is visible, while some of the most essential work within organizations remains unseen. Consider a product launch. Slack channels fill with celebration, leadership offers public praise, and performance metrics are widely shared. Now contrast that with months of refactoring, quiet mentoring, and diligent risk mitigation that largely go unnoticed. Visibility distorts perception. This is visibility bias in action. It appears as: Shipping rewarded more than stabilizing. Roadmaps praised more than operational rigor. Deck-building valued over difficult conversations. Activity mistaken for impact. This connects directly to a post I previously wrote on shipping versus advancing , where I argued that organizations often conflate visible activity with meaningful progress. Shipping, with releases, tickets, a...

“You can't build a reputation on what you are going to do.” - Henry Ford Many years ago I told someone that my wife at the time and I were planning on adopting a child at some point in the future. To my dismay, the response was “congratulations!” As if I had already adopted a child. The person went on to say what good people we were. Receiving such praise did not feel gratifying. It felt misplaced. Almost like a “stolen valor” situation. After that I kept to myself our plans to adopt, and as it turned out the only child I ever adopted was my beloved step-daughter. The other day I wrote a blog post that I’d hesitated about quite a bit. It was regarding the DBA program at Edgewood University. On the one hand, I was excited to share a program that I’d found to be so affordable and complete, and from a good (albeit small) university. On the other, I dreaded the possibility of giving the appearance of one trying to take credit for what he has not yet done. There is an emotional tensio...

“ All change is not growth, as all movement is not forward .” — Ellen Glasgow One day I was at the neighbor's house, hanging out with friends, when I noticed a calendar with a quote for each month. Paging through it, I came across the one above. It impacted me deeply at the time, as it aligned with what I often felt I saw in the world. Movement without progress. As the years have passed the quote has stayed with me, and its meaning to me has evolved as I've progressed through my career. I can see that in today's business culture, we often confuse activity with achievement. Let's consider the differences between shipping and advancing. "Shipping" means delivering something, releasing a feature, completing a sprint, publishing a post, or closing a ticket. Shipping is visible. It feels productive. It checks a box. Advancing, on the other hand, means moving closer to a meaningful objective. It's creating durable value. Improving systems and not just outputs....

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...

Early in my career, I worked as a web producer at a startup, an experience I have written about before. It was a formative role that required wearing multiple hats and operating with a high degree of ownership. One of my primary responsibilities was receiving content from publishers and converting it into a format compatible with our online reader. The inputs varied widely. Investment newsletters arrived as emails, Word documents, PDFs, and in one case even by postal mail. Each format required a different workflow, and transforming them into publish-ready content demanded both technical adaptability and careful attention to detail. Although I could have managed most of the process from memory with minimal notes, I made a deliberate decision to fully document my work. I created step by step guides, including screenshots, and stored everything in Confluence. I also made sure my colleagues knew where to find it. My thinking was simple: if something unexpected happened, the business should...

While pursuing my Master’s degree at Salve Regina University , I collaborated with a fellow student on a class project to design a minimalist tabletop role-playing game. Role-playing games (RPGs) are collaborative storytelling games in which players take on fictional characters in a shared world. One participant—often called the Game Master—describes the setting and challenges, while the other players declare what their characters attempt to do. Outcomes are typically determined by simple rules and dice rolls, blending imagination, strategy, and chance. Our goal was to create a system simple enough for beginners but structured enough to feel meaningful. I initially sketched a rules framework built around four core attributes—Strength, Agility, Intelligence, and Charisma—using a single six-sided die to resolve actions. Players would choose streamlined classes like Warrior, Mage, Rogue, or Healer, each interacting differently with combat and problem-solving. The system emphasized fast e...

One of the most rewarding parts of my work as a project manager is leading cross-functional teams from design through execution to project close. These groups bring together diverse perspectives, and my role is often that of translator and coordinator, making sure everyone is aligned and moving in the same direction. If you think about it, each function approaches a project with a different lens. Product wants to deliver user value, engineering is focused on stability, and operations is concerned with predictability. When you add in design and other functions, the perspectives become even richer. The challenge, and the opportunity, is to bring these different priorities together in a way that results in an executable plan. What I enjoy most is seeing the impact of this collaboration. When cross-functional teams work well together, the outcome is stronger than any one group could achieve on its own. It is incredibly satisfying to watch product, engineering, operations, and design combin...

Sometimes a team has tight deadlines or a heavy workload. Or both! I've encountered this in nearly every position I have held, although it wasn't usually a constant but more of a phase. For example, I worked at a startup where the team was tasked with redesigning the website and refactoring the web app at the same time. They had trouble in the past delivering consistently, so I led them through an Agile transformation as well, and they became a scrum team. This allowed us to begin to get a notion of their capacity for work. However, pressure was on to the get a large amount of work done in a very short time period. Here's how I approach the situation. First, we acknowledge reality. It doesn't do any good to pretend that the pressure isn't there. Recognizing as a team that we have a lot to do and not a lot of time to do it makes the situation clear for everyone, and relieves some of that stress of feeling like the burden is unseen. Second, I work with the product own...