The Career That Was Always Waiting: A Journey to Product Leadership
Or: How staying true to your nature leads you exactly where you need to be
The blog post below is one I wrote in 2011, three years into my career and one year into my first and only full-time software engineering role. Reading it now, I’m hit by a strange gratitude–not just for having documented my thoughts, but for the proof it provides of a journey I didn’t know I was on.
That confused engineer knew he didn’t fit in the role. He was seeking understanding of systems. He was creating quality equations and lamenting his “curiosity of a flock of kittens,” fearful for what that meant for a career in tech.
What I see now is my non-linear career path toward product management and the value of a habit of self reflection.
When Theory Meets Reality: My Quality Equation
In 2011, I wrote:
It struck me that this week marks just over a year since I transitioned from CSS Tech Support to USD Engineering. I have so many questions worth asking as I reflect: What have I learned? What do I hope to continue to learn? Why do I still call myself an outsider?
There is too much to know for any individual. Below is just a simplified example of just one portion of the [product] design concepts. Every single section in there is owned… and quite likely by different people in different teams. Often even different locations. Let alone different countries.
We [, the engineering organization,] aim to distribute responsibility. It is the only way to make something so complex in a reasonable amount of time. As an equation:
Quality = Time * (Testing / Complexity)That is, the quality of the build is the time spent testing its complexity. But it inevitably discovers bugs that must make it into the Release but also need to be tested. So the actual equation is recursive:
Quality = Time * ( Testing / Complexity ) + [ Time * (Fix) * Time * ( Testing / Complexity) ]This behavior continues ad infinitum.
There is always a great deal of complexity.
There is always more testing could be done.
There is never enough time.
The organization is build on a landscape of interdependent silos.
I am not an Engineer. I enjoy technology - knowing it deeply and intimately. But I am no Engineer like my peers in USD are Engineers.
I have the curiosity of a flock of kittens. That is my strength as well as my weakness. Its the reason I can get a handle on the diversity and complexity of work in the department in less than a year. It’s also what keeps me from buckling down to a specific specialty.
Reflecting On My 15 Year Journey
Reading back through this is illuminating. I was trying to capture why pride in my work felt impossible–why our releases were always late, why quality felt impossible, why the system felt broken despite everyone’s best efforts. It continued:
The post included a sketch of waterfall handoffs between interconnected teams across countries and codebases that was more than a diagram–it was a checklist of all the theories I was learning through practice. It wouldn’t be until years later that I learned to model what I was experiencing.
Long after we shipped our product and it was end-of-lifed within two years, I appreciate the experience. I remember picking up The Phoenix Project and feeling seen. I went through the pile of what I was told were “softer” topics like The Innovator’s Dilemma, The Lean Startup, Crossing the Chasm followed by Inspired and I saw how what we built wasn’t positioned to succeed. Years later, Team Topologies would give me the language for why our org structure–those interconnected boxes I sketched–was creating the very friction I felt daily.
Revisiting it now, I recognize how those writers were describing in theory what I’d already felt in practice.
From Weakness to Superpower
What strikes me most is how I ended that 2011 post: apologizing for not being “an Engineer like my peers.” I saw my systems-level curiosity as a failure to specialize, a character flaw that prevented me from buckling down.
15 years later, I apply that same systems thinking daily as a product leader. Those weaknesses I documented? They’re the exact strengths I lean on when I’m:
- Mapping out how teams successfully implement an operating model
- Translating between technical constraints and business objectives
- Seeing patterns across our entire product ecosystem rather than optimizing for a feature
- Applying Team Topologies patterns to reduce cognitive load on teams
The journey from that post to here wasn’t about changing who I was–it was about finding where what I already was could create the most value.
Blogging as Career Wayfinding
Past blog posts are messy, uncertain, and full of questions I couldn’t answer. But I published them anyway. This practice of learning in public–of documenting confusion as readily as clarity–has been my career’s GPS system. But more importantly, blogging gave me a way to be honest with myself. When something didn’t fit me–like pure engineering–I couldn’t hide it. The words on the page reflected back what I knew I needed to think about to find my path.
Today, I wake up and do exactly what that past version of me was trying to do: understand complex systems, find the constraints, and figure out creative ways to deliver value within them. The difference is that now it’s not a bug–it’s the type of product leader I am.
Books didn’t teach me to be a product leader; they gave me language for what I’d always been drawn to. The theories–from the Agile Manifesto to Conway’s Law to Team Topologies’ principles–aren’t academic pursuits to me. They’re tools I use daily, applied with the hard-won context of someone who’s felt their impact firsthand.
Looking back, every role was teaching me something I’d need:
- Support taught me how a cost center runs and drains on customer loyalty
- Engineering taught me how software actually gets built (and why it breaks)
- Marketing taught me the customer lifecycle and showed metrics that determine who gets funded and who doesn’t
- DevRel showed me how to bridge technical and human systems
- Product refined my mapping of value streams and iterative tradeoffs
Each detour was actually the main road–the nonlinear path I just couldn’t see led me to good things in the long run. That’s the gift of learning in public throughout a career: it’s proof that who you are was always enough. You just needed to find where that particular shape fits.