Adam Gonnerman

More than a decade ago, sitting across from a Brazilian consultant who was reviewing my resume for a potential project management opportunity, I received a verdict I was not expecting. He looked up from the page and said, matter-of-factly: "You're a theologian." He was not wrong about my degree. I hold a Bachelor of Ministry, earned through an accelerated program at Harding University that covered nearly four years of biblical, counseling, and ministry education in two. But in the standard Brazilian professional framework, you are what your degree says you are. My PMP certification, my years of project management experience, my track record of delivering complex initiatives meant very little in that moment. I had graduated into theology. Therefore I was a theologian. I thought about that conversation years later when I enrolled in a Master of Arts program in management with a concentration in project management, made possible through Viacom's employee education bene...

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