The Product-Native Engineer
Thoughts on the continued evolution of the software engineering role
Introduction
Software engineering is a modern day frontier profession. Frontier professions are those that are focused on innovation and pushing the boundary forward, unlocking new capabilities for humans. The new capabilities shift behaviors and create cultural change, sometimes for better, sometimes for worse. Throughout history frontier professions have shared a similar arc:
Craft phase - deep individual mastery, at the cost of scale
Industrial phase - specialization, efficiency, role fragmentation
Optimization phase - tools and processes improve to the point where tedious work is automated, freeing humans to orchestrate and direct
Judgment phase - the “how” becomes simple and value shifts from execution to decision-making
Frontier professions are constantly transforming and every profession at the frontier of innovation eventually experiences the same shift. When tools get powerful enough, knowing how to do the work matters less than knowing which work is worth doing. This is the advent of the judgment phase. Software development is behaving like every frontier profession before it and making the shift into the judgement phase. Let’s once again ground these changes in history through the analogy of sailing (like I’ve done in the past with the Leadership Odyssey, parts 1 and 2).
In the craft phase of sailing, early explorers used a combination of intuition, the stars, and experience to guide the ship along its journey. Over time, specialized roles emerged, such as cartographers and meteorologists. As time progressed, and technology continued to improve, specialization continued to be centralized and abstracted away. Modern day ships don’t need cartographers or meteorologists, they need people that can make decisions, given the information the tools provide. Ultimately, conversations have shifted from how we get there, to where we want to go.
Let’s briefly review how the software engineering role has evolved over time and see how it compares.
The Evolution of the Software Engineer Role
We’ll cover the first 3 phases in this section and leave the judgement phase; the advent of the product-native engineer, until later, since it deserves its own section.
The craft phase
In its earliest days, software engineering was a craft. Programs were written by small groups, or sometimes single individuals, who understood the system end to end. There were few abstractions, little tooling, and almost no separation of roles. Engineers reasoned directly about hardware constraints, memory, performance, and behavior, often learning through trial, error, and lived experience. Quality emerged from personal discipline rather than process, and progress depended heavily on tacit knowledge that was difficult to transfer or scale. Early software was powerful when built by experts, but inconsistent and slow to reproduce. As demand for software grew, the limitations of this craft model became clear, not because it lacked skill, but because it could not scale without externalizing knowledge and fragmenting responsibility.
In the craft phase, responsibilities existed, but they hadn’t been formalized yet and the roles we recognize today had not yet been defined. The clear roles and responsibilities that demand specialization only emerge alongside the need to scale.
The industrial phase
The industrial phase is about scale. A critical part of the scaling journey is role specialization. This is the core idea behind assembly lines.
When I first started my career, roles were highly specialized. Developers were responsible for execution; translating functional and non-functional requirements into code. And that’s where the responsibilities ended in most companies. Once code was complete (with basic testing), it was handed off to the quality assurance experts for validation. If any issues were found, tickets were created and the code was sent back to the engineers for bug fixes. This process repeated until the release was approved and forwarded on to the operations team for deployment. Once deployed, if any issues arose, tickets were created, bug fixes were made by the developers, and the cycle repeated.
The specialization model had some benefits:
Local efficiency - each function had deep expertise and was efficient at their specific role.
Clear roles and responsibilities
And some challenges:
Coordination costs - context is lost with each hand-off between functions
Global inefficiency - feedback loops were long and expensive. There were many bottlenecks as work traveled across functions.
Specialization unlocks scale, but in a rapidly changing world where the ability to adapt and stay nimble is key, optimizations become critical. Optimizing the software engineering role meant solving for the aforementioned challenges. The result was the introduction of the Full Cycle Engineer. We’ll dive deeper in the next section.
The optimization phase
The optimization phase leads to tools that accelerate existing responsibilities. This in turn drives two things. First, a shift in the existing set of responsibilities across specialized roles. Second, the development of new skills. For example, with modern tools, engineers are able to deploy code in a distributed microservices environment with high confidence, which promotes strong ownership and the development of new operational skills. This tooling is the result of a shift towards centralizing deployment and operations expertise into the abstraction layers (i.e., platforms) that provide the tools.
In the optimization phase, specialization shifts from the individual to centralized abstraction layers that expose tools and processes. This tends to happen across functions, enabling each function to effectively export functional expertise that can be consumed by customers. This transformation is what gave rise to the Full Cycle Engineer.
The Full Cycle Engineer
The Full Cycle Engineer model collapses aspects of the design, test, deploy, operate, and support functions into the developer function. This phase transition is made possible by better tools, processes, and standardization, exported by centralized abstraction layers. You can do a deep dive on the Full Cycle Engineer here if you’re curious.
The shift to the Full Cycle Engineer model resulted in several new benefits and challenges:
Benefits:
Tight feedback loops - A single individual is responsible for designing, implementing, testing, deploying, operating, and supporting what they build. This results in rapid iteration, with no context loss, across several aspects of previously specialized roles.
Aligned incentives - when engineers are responsible for what they build, they are incentivized to build things that are easy to support and maintain.
Challenges:
Higher cognitive load - engineers now have to learn a broader set of skills. Naturally, this means attention is split across many different tasks, each with different cognitive demands and context.
Steep learning curve - onboarding takes much longer and involves learning a broader set of tools and techniques.
The Full Cycle Engineer model has proven to be quite successful and has led to well-rounded engineers that have a much deeper understanding of the product as a result of being directly responsible for outcomes. The advent of GenAI has lead to the amplification of tooling Full Cycle Engineers. Let’s briefly touch on this recent evolution that leads us, more or less, to the current state of affairs; the AI-Enabled Full Cycle Engineer.
The AI-Enabled Full Cycle Engineer
The AI-enabled Full Cycle Engineer model is effectively the same as the Full Cycle Engineer model, but with a toolset that enables even more rapid iteration. As I wrote about earlier, I see GenAI, in its current form, as an abstraction layer. This abstraction layer increases efficiency by further shrinking feedback loops, accelerating learning, and acting as an incredibly powerful tool in the developer’s arsenal. Beyond toolset improvements, developers have to learn new skills like prompt engineering to get the most of the new tools.
It’s worth calling out the AI-Enabled Full Cycle Engineer model because the new toolsets are a step change in terms of how much they enable optimization of existing activities. My sense is that this is the model most engineers are currently operating with. However, it’s also important to recognize that this is a transient state, one that will not persist for long. The AI-Enabled Full Cycle Engineer only exists temporarily while the next phase transition takes shape. I believe the next phase transition is the judgment phase, where Full Cycle Engineers become Product-Native Engineers. The phase change is in process right now.
The Judgment Phase - The Rise of the Product-Native Engineer
The product-native engineer emerges in what might best be described as the judgment phase of software engineering. In this phase, execution is no longer the primary constraint. Tools, platforms, and AI systems have absorbed much of the mechanical work that once consumed engineering time and attention. What remains scarce is not the ability to build, but the ability to make good decisions about what should be built, why, and at what cost. A product-native engineer is an engineer who is equipped, and expected, to exercise judgment across the full arc of value creation: framing problems, weighing trade-offs, shaping solutions, and owning outcomes. In the judgment phase, engineering advantage no longer comes from doing more work, but from choosing better work.
This is not a rejection of specialization or product management. It’s a recognition that as execution becomes easier, responsibility concentrates around the decisions that shape everything downstream. Earlier phases of software development asked engineers to integrate inputs from others, requirements from product, designs from UX, constraints from operations. In the judgment phase, engineers increasingly hold those concerns together themselves. They are responsible for identifying the right problem, choosing an appropriate solution, and understanding the long-term consequences of that choice as a single act of judgment.
The product-native engineer operates with high autonomy not because they possess every skill, but because many of those skills now live in the tools they direct. Their work shifts from primarily executing solutions to deciding which solutions are worth executing in the first place.
In practice, this may look like a product-native engineer directing multiple AI agents in parallel, each handling aspects of research, implementation, testing, or analysis. Some of those agents may themselves coordinate other agents, collectively solving the “how”. You can see this world taking shape with multi-agent systems and Gas Town.
This leads to a couple interesting realizations. First, the judgement phase resembles the craft phase in that it’s centered on the individual and their ability to generate outcomes with a high degree of autonomy. However, in the craft phase, expertise was centralized in individuals, whereas in the product-native engineer phase, expertise is spread across AI agents, each working in parallel, being orchestrated and directed by an individual. Second, product-native engineers are effectively becoming managers. Not of people, but of AI systems. The product-native engineer will effectively be managing project teams comprised of AI agents. The engineer’s role won’t be to micromanage each step, but to set intent, evaluate trade-offs, and guide the system toward the right outcome, freeing human attention to focus where judgment matters most.
The product-native engineer blurs even more lines between existing roles. On the one hand, the role now demands that product-native engineers can think like a product manager, exercising good judgment, and having a deep sense of the business and how outcomes will affect it. It requires them to be managers of systems that are able to perform execution. It requires them to understand and measure the impact of their changes. All of this, in addition to the role they are already filling.
Conclusion
Change is constant and just like all roles of the past, since the inception of organized work, the role of the software engineer is evolving as well. In many ways, the role, and many roles across many industries, will need to be reimagined over the coming years. As leaders, our job will be to set these product-native engineers up for success. Collaboration needs to evolve. Onboarding processes need to evolve. Expectations need to evolve. We need to help develop judgment earlier in the career journey. In some ways, the judgment phase leads to the next craft phase, kicking off the next cycle of evolution. Beyond the next craft phase, new specialized roles will emerge and existing roles will evolve. The future holds a lot of excitement for those that choose to stay at the frontier.