An autobiographical reflection on software, leadership, and why I’m more excited about what comes next.
11 min read
Three things happened within a short span of time in late September and the past week that made me stop and think.
In my current work, I had been digging into a familiar problem: how much confidence an organization can have in its technology team’s ability to consistently deliver within expectations. I had started using delivery confidence to describe much of the work around forecasting, commitments, capacity, and communication, and was already writing about what I was experiencing. Then I discovered that a colleague in the industry had independently been working on much the same problem and using the same language.
It reminded me of something similar a few years earlier. As my focus shifted from improving software delivery flow and efficiency toward understanding outcomes and realized value, that thinking became the foundation for my first book on leadership, change, and outcomes. About 11 months into writing it, I found myself at an industry conference talking with an acquaintance who was already an established, bestselling author in the field. He was working on a follow-up to his very successful previous book, and much of it touched on the same ideas I had been developing in my own work.
I have to admit, my heart sank a little.
For a moment, I wondered whether I was too late or whether I still had a reason to keep writing. Then I realized something important: the overlap did not diminish what I was doing. In many ways, it validated it. We were seeing some of the same changes in the industry and asking similar questions, each through our own experiences and perspective.
I did not need to compete with his book. I just needed to keep telling my story, share what I had learned, and contribute my own experience to the conversation.
Today, the conversation around outcomes over output is everywhere.
Then, in an interview this past week, I was asked a question I have heard more than once: Why do you keep doing this? Why do you keep working in this industry?
Those three moments brought me back to a phrase I had on my personal website for years:
The art of the possible.
I recently changed the site, but the phrase has stayed with me. Looking back across my career, I think I understand even better why.
——
Software has never stopped evolving, and neither has the conversation around how we build it. I have worked through many of the shifts that shaped modern software delivery: Agile and Scrum, test-driven development, continuous integration and delivery, DevOps, microservices, cloud architecture, shifting security left, observability, platform engineering, and plenty of others.
I’ve also been shaped by changes in how we lead people. Earlier in my career, command-and-control and Taylor-style management were still common influences. Over time, I became much more influenced by autonomy, servant leadership, empowered teams, trust, psychological safety, blameless learning, and the idea that leaders create the environment in which people can do their best work.
That evolution in leadership has probably affected me as much as any technical practice. Over the years, people I have led have occasionally told me about an opportunity, conversation, or working environment that influenced their careers. Those comments stay with me. You rarely know all the thumbprints you leave on people while you are doing the work, but every so often someone tells you. Seeing people I once worked with grow into stronger engineers, leaders, executives, and mentors has been one of the more meaningful parts of staying in this industry.
“You rarely know all the thumbprints you leave on people while you are doing the work, but every so often someone tells you.”
Experience has also taught me how much leadership and the surrounding organization affect whether change actually works.
We have all heard declarations that Agile failed, Scrum does not work, DevOps is dead, SAFe failed, or microservices created more problems than they solved. Sometimes the criticism is deserved. Practices get overapplied, implemented mechanically, or introduced where they do not fit.
I have also watched organizations introduce a new way of working while much of the surrounding system stays the same. Decision-making remains slow. Priorities shift constantly. Commitments remain rigid. Organizational boundaries stay in place. Teams are told they are empowered while meaningful decisions still travel upward.
Over time, I learned to look beyond the name of the practice and pay more attention to the environment around it. Conway’s Law reminds us that the way we organize ourselves tends to show up in the systems we build. Incentives and measures influence behavior. Previous success shapes the assumptions leaders bring into the next problem.
Our own thinking is part of that system too.
One of the harder lessons I wrote about in Profitable Engineering is the importance of looking in the mirror. The behaviors and instincts that helped us succeed in one environment may fit differently in another. Experience gives us useful pattern recognition, while continuing to learn exposes how much complexity we may have missed before.
——
That realization has changed the kinds of questions I ask.
Earlier in my career, I focused much of my attention on improving software delivery mechanics. As we got better at those mechanics, I became more interested in what surrounded them: leadership expectations, prioritization and funding, the relationship between Product and Engineering, capacity decisions, and ultimately the connection between technology and business results.
That became especially clear to me in early 2023.
We had become significantly more efficient at delivering software. Flow had improved, releases had become routine, and many of the delivery problems we had spent years working through were in a much better place. That progress led me to ask a question that changed the direction of my thinking:
Were we getting better at delivering software, and were we equally good at making sure we were delivering what actually mattered?
That question eventually became Profitable Engineering. My focus expanded from flow efficiency into outcomes and realized value. I became much more interested in connecting the work teams were doing to what happened after delivery.
Since then, I have noticed more of the industry conversation moving toward outcomes, value, and the limits of looking at software productivity primarily through output.
AI created another progression for me. Early on, I focused on adoption and how engineering organizations could use these tools responsibly and productively. As adoption accelerated, I became increasingly interested in economics, governance, cost visibility, usage, and ROI. It reminded me of the evolution of cloud computing, where harder questions about architecture, consumption, governance, optimization, and economics eventually followed early excitement about what suddenly became possible.
——
More recently, my work has taken me deeper into forecasting, commitments, capacity, and what I call delivery confidence.
I touched on many of these ideas at a high level in Profitable Engineering. Software development contains uncertainty. Estimates reflect what we understand at a point in time, and that understanding changes as the work progresses. Dependencies emerge, complexity is discovered, priorities change, and there will always be things we could not know at the beginning.
My current fractional work has allowed me to go much deeper. I have been looking more closely at engineering capacity and where it actually goes, how competing priorities affect delivery, the role of probabilistic forecasting in planning, and how teams communicate as their confidence changes.
The tension is familiar. Businesses need to plan, coordinate, invest, and make commitments. Software development rarely provides the certainty traditional planning systems prefer. I have become increasingly interested in how forecasting, capacity visibility, and better communication can help those worlds work together more effectively.
In September, I started writing an article about what I was experiencing. I even began sketching the foundation for a possible second book, written as a fictional business story in the spirit of The Goal or The Phoenix Project, before deciding to set it aside and stay focused on the work in front of me.
Soon afterward, something interesting happened.
A colleague, Marnus Marx, and I realized we were independently working on much the same problem. He had been developing a new services approach around delivery confidence and published his thinking on October 2 in It Has A Name Now.
Then I came across a new and timely book by Nicholas Brown, published a few days ago, that addresses the same underlying challenge. From what I have read so far, it handles the problem thoughtfully and aligns remarkably closely with practices and ideas I have been developing or applying through my own work.
The timing caught my attention.
I am careful about what I read into that. My progression is my progression. Experienced practitioners have been discussing many of these problems for years, often in different sequences and using different language. When something becomes central to your own work, you also become much more aware of other people studying it.
Still, I enjoy those moments. People working on similar problems often start asking similar questions. They compare experiences, try different approaches, talk about what worked and what failed, and gradually improve the language and practices around the problem.
——
That is one of the things I value most about this industry.
My path has let me meet and collaborate with some genuinely brilliant and inspiring people, from junior engineers early in their careers to many of the people whose ideas and writing have shaped how we work today. I cannot count the number of times my wife has walked into my office and found me on a video call with someone in another part of the country or the world, talking through an idea, comparing experiences, or learning from each other. Those relationships and conversations have been one of the unexpected gifts of this career.
Some of the best conversations have been with people willing to talk honestly about the hard things. What worked? What failed? What are we still struggling with? What did experience cause us to reconsider? What are we learning now that might help someone else?
Improvement rarely follows a straight line. We introduce an idea with the best understanding we have at the time, discover where our assumptions were incomplete, adjust, and learn more about the larger system around the problem.
That is also a big part of why I write.
I mostly write to share what I have learned from experience, including approaches I genuinely believe give teams a better chance to succeed, and to invite other people into the conversation. I learn from the response. Someone challenges an assumption, shares a different experience, or adds evidence I had not considered. The thinking gets better.
There is some irony in all of this. I came from an engineering background, gravitated toward math and science, and for a long time did not particularly enjoy writing. I remember some of my earliest articles as being pretty rough. Somewhere along the way, writing became one way I work through what I am seeing and make sense of what experience has taught me.
Now I write regularly, and looking back through that writing, I can see how the questions I happened to be working through changed over time: flow, outcomes, AI adoption, AI economics, and now forecasting, uncertainty, and delivery confidence.
What interests me is how those questions have gradually moved higher in the system. They started much closer to how teams build and deliver software. Over time, I became more interested in organizational value, leadership decisions, investment priorities, the economics of emerging technology, and how stakeholders and technology teams work together when certainty is limited.
I think some of the most interesting opportunities in software delivery today sit in that space.
We have spent decades improving how we build software, and we are still learning how leadership and the surrounding organization need to evolve with those practices. Better data, probabilistic forecasting, clearer visibility into capacity and tradeoffs, stronger collaboration, and more open-minded leadership are giving us better ways to work through problems that have frustrated teams and stakeholders for years.
AI adds another chapter. I know some people look at what is happening and wonder what it means for their careers or whether parts of their work will disappear. I tend to see another period of reinvention and another opportunity to learn.
——
Sometimes I think back to 1999, when I was an entry-level software engineer learning the software development lifecycle on my first project. The way we designed, built, tested, released, operated, and learned from software then is remarkably different from what teams can do today. I have had the benefit of watching that progression firsthand through changes in technology, architecture, automation, delivery practices, leadership, and now AI.
It was not a smooth progression. I have been through heated debates, failed approaches, big-bang changes, difficult transformations, reorganizations, reductions in force, and decisions that looked far clearer in hindsight than they did at the time. We learned through experimentation, disagreement, disruption, and sometimes painful consequences.
What makes that history especially meaningful to me is knowing I contributed to some of that progress alongside countless engineers, leaders, practitioners, and teams who kept trying to improve how we work. I have seen ideas become practices, practices become capabilities, and those capabilities produce real results for teams, customers, and businesses. There is something deeply satisfying about looking back and seeing how that collective effort changed what software organizations can do.
I remember what many of these things used to require, how long they took, and the problems we accepted as part of building software. I have also seen what happens when people keep questioning those assumptions and improving the system. Today, teams routinely do things that would have seemed extraordinary earlier in my career, and we are still learning how to work better.
That is why I have said for several years that I have never been more passionate about delivering software than I am today.
“I have never been more passionate about delivering software than I am today.”
So why, after all these years, do I stay in this industry and keep working?
I think it has a lot to do with a recurring theme throughout my career: being willing to unlearn what no longer serves us, relearn what experience is showing us, and keep rethinking how software, organizations, and leadership can work better. Every time we think we understand something, the environment changes, experience exposes another layer of the problem, or someone offers a perspective that makes us look at it differently. I still find that incredibly energizing.
That brings me back to the phrase that sat on my website for so long.
The art of the possible.
The technology continues to change. Our understanding of how to build software keeps improving. Our ideas about leadership have evolved enormously. Along the way, I have been fortunate to keep learning, share what I have learned, collaborate with people I never would have imagined meeting earlier in my career, and leave a few thumbprints on people and organizations that mattered to me.
I have always been a glass-half-full person. When I encounter a difficult situation, my instinct is usually to understand it, learn from it, and look for the path forward. Experience has made me more aware of complexity and more comfortable acknowledging what I do not know. That has made the learning more interesting.
After all these years in software, that has not changed.
There is still so much left to learn, improve, share, contribute, and make possible. I want to keep being part of that for as long as I can.
AI helped edit this article. The ideas, experiences, and initial base writing and perspectives are mine, drawn from industry resources, collaboration, and more than 25 years in software and technology leadership.
References
- Phil Clark – Profitable Engineering: Transforming Technology Teams Into Strategic Business Partners (2026). The ideas around Flow + Realization, leadership, organizational change, and connecting technology work to business outcomes provide background for many of the experiences discussed in this article. Profitable Engineering
- Marnus Marx – “It Has a Name Now” (LinkedIn, October 2, 2026). Marnus independently explores the idea of delivery confidence and the challenges organizations face around commitments, forecasting, and predictability. Read on LinkedIn
- Nicolas Brown = Beyond Burnups: The Different Ways to Forecast Delivery (and When to Use Them) (2026). A practical exploration of forecasting, uncertainty, Monte Carlo simulation, feature WIP, and multi-team dependencies. Beyond Burnups on Leanpub