← Back

Developers as Product Engineers; less ceremony, more shipping

As Senior engineers working on often high impact, important services in a large organisation we can easily become detached; sidetracked and blinded from the real user outcomes we really want to create, carried along with the ceremony and performance that surrounds us as engineers. It threatens to hi-jack our sense of value as engineers - doers, solvers - and our primary asset and means of producing valuable output; our focus.

Process-heavy methods of agile, implemented as scrum, are optimised for predictability and visibility. It traps engineers in the performative culture it promotes, frustrates teams reaching flow - working to build the right things using an understanding of the product, user feedback and data, and then as professionals, exercising autonomy to spec and build the right thing.

Agile frameworks seem antithetical to the egalitarian spirit of the original concept. They instead impose significant controls, artificial deadlines (leading to burnout and poor quality) and distraction from the discovering and delivering on the real drivers of value. Doing what is valuable and not do what is... not.

‘Scrum’ masquerades as agility; it distracts engineers and normalises obedience; all-too-easily handing-over not just their life-hours, but energetic brain cycles and attention, we can otherwise spend on building.

It brings with it a well-documented group-think that prioritises the appearance of success over real outcomes. Scrum enables a narrative-driven version of value, where success or failure is shaped by the way we frame it. This is more favourable and easier to quantify than actual value, which is then reported and sold to stakeholders via outputs: charters, definitions, up-front planning documents, risk assessment, long-range planning, collaborative boards and a packed calendar full of ceremonies.

Don’t like the story the map tells? Just redraw the map.

Process-heavy scrum at the team level within a larger organizational structure, diminishes the direct connection to market signals and users, leading to under-utilisation of engineers.

I feel because such direct connection is a more conveniently nebulous but critical measure of what the market - our users - respond to as valuable.

This leverages a troubling cognitive dissonance on developers who are intrinsically motivated to create meaningful work for users, rather than backlogs, predictability, and processes which attempts to reduce an emergent, creative process of discovery-by-doing to a waterfall structure. Yet engineers know we are learning what makes sense but can only know by starting.

We need only consider the practice of estimating and refining technical features when we know least, as we don’t start learning until we start building. Yet now, a team finds themselves on the hook for promises they were coerced int,o on shaky understanding. Over time, we get burnout, attrition, less optionality in our code for future changes, and a poor user experience.

Product Engineers #

My observations aside, and amid the general emergence of this movement in the industry I feel there’s an answer; a reckoning. Leaner teams, comprising empowered, product and user-focused engineers who care about discovering, building and shipping valuable outcomes frequently. but our orgs need to enable it.

Product Engineering is about full-life-cycle involvement in the iteration of a product, based on user feedback and data to know what problems to solve.

Jordan Cutlers’ Substack High Growth Engineer - Becoming a Product Engineer and Posthog.io have an awesome description of the role and why it matters to companies moving from project to product mindsets.

John and PostHog's commentary of Product Engineering gives a model which I feel represents a vision for the necessary organisational shift toward small, focused, empowered product engineers.

Engineers here take initiative and are implicitly enabled and unlocked by the organisation and product strategy to have ownership of the end-to-end lifecycle; from identifying the user and business needs with highest ROI, to development and iteration through Continuous Discovery.

What makes them unique is their focus on creating a product for users. They care about building a solution to problems that provides value to users. They must be empathetic to users, and this means caring about user feedback and usage data.

Instead of perpetuating the traditional software lifecycle in a ‘project-oriented’ paradigm full of ceremony, we might as aspiring PEs, ask:

1. “What is the user’s actual problem?”

2. “What is the best solution for the user?”

3. How soon can we get something that looks like this built and shipped to find out?

As such, Product Engineers are heavily invested in market and user feedback. They are ‘customer obsessed’ and are opinionated about the roadmap for the product, building a deep understanding of the problem space, and then self-organise to build and iterate solutions.

"As a product engineer, writing code is just one part of [the] job. Product Engineers also talk to users, get involved with design, and develop an opinion on what needs to exist in the world. Then you'll move with urgency to make it happen.

The primary goal of the Product Engineer then - is in a more direct way than typically mandated in feature teams - about building a great user experience and code we write as mere means.

With the increasing efficiency in software development possible, market competition and lean startups without legacy structures, the role of the Product Engineer seems a natural step in the evolution of the role of Software Engineers; a way in which Engineers can have more impact; leveraging their technical and product knowledge, with market feedback and crucially, enablement at the strategic level of our organisations.

This is exciting to me, as many like me as Senior Engineers will have developed the commercial skills necessary to be successful in what could be a new frontier of software delivery; an alternative to the parallel tracks of Tech or Management the industry has standardised.

No longer feature teams #

While start-ups and product-led companies are adopting this approach, we may soon witness a fast-following among established product companies wishing to build a strong Product culture.

The question is whether larger orgs can be honest with themselves; not paying lip service to true engineer-empowerment and strong product-market fit, but structuring in such a way as to separate these teams from the legacy funding model and make it possible; to unlock small *Product Engineering teams, empowered* to progressively own more of the product and ship frequently.

To facilitate PEs, the goal is to minimise the centralised processes that stifle Scrum feature-teams in larger orgs and empower teams to make decisions, prototype, test frequently and build what matters.

I feel companies adopting and hiring accordingly for this mindset would see a significant strategic advantage in product quality, market-fit and engineering engagement.

Where we are… #

Let’s be real though. Many of us are maintainers; working with functioning processes, entrenched incentive structures, and mature codebases with a long list of project features to implement.

But there’s much we can take and aspire to even as individual contributors. We can stand out as acting Product Engineers in our feature teams as far as we’re able.

We are product experts, with the technical background. We are then, uniquely positioned - obliged even - to communicate technical trade-offs, advocate for users and doing the right things in light of user feedback and data.

But surely they need direction; to keep the product roadmap coherent.

In a recent episode of Lenny’s podcast, Dylan Field, co-founder of Figma, discussed the role of Product Management, especially within Figma:

...effective PMs communicate and define the strategic framework; scoping the range of options for PEs to work within, to which they can bring their own deep technical and product knowledge to deliver the outcomes that are valuable.

In an organisation entrenched in large-scale ‘agile’, small teams must protect their goal of delivering autonomously from the surrounding process-oriented environment.

I took some great inspiration and assurance in the value of what I can bring to a product’s direction; a benchmark for how I’m still able to impact a product as an individual contributor, and encourage others in my team to think beyond where engineers might feel they can have influence.

As Engineers we must communicate and protect our principles and standards as it’s our responsibility to educate stakeholders of their importance for product quality and team health.

If we establish trust we don’t need _permission_ to do the right things*

The Product Engineering lens of Software engineering, I believe represents the future of what Product companies will need to enable, in order to remain competitive; leveraging the user-focus and ability to ship quickly; the thing which motivates us: Solving problems, building things that matter and are a joy to use, making users into advocates.