There are many ways to classify engineers based on their skills and attitude.
One of the most interesting, to me, is the separation between those who tend to focus on technical excellence, and those who love to be engaged in user problems and UX as well.
The latter is more common with frontend devs because of the nature of their work, but I have learned over time that this is more a cultural separation than a technical one.
There are people who are more driven by impact, and others who care more about mastering their craft. Keep in mind, these are not rigid categories. It is a spectrum, and everyone falls somewhere on it.
Now, while there is a personal component to begin with, company culture has a strong impact on shaping this tradeoff and how people think about their work.
Startups and product-centric companies, for example, tend to embrace a culture of ownership where engineers have ample autonomy in designing solutions.
They fall more on the impact side of the spectrum.
Fostering an engineering culture driven by impact has many advantages:
↔️ Alignment — company goals are more easily aligned with teams’ and people’s goals.
↕️ Autonomy — alignment drives autonomy. You can trust people to take non-trivial decisions on their own.
👑 Ownership — autonomy turns people into owners of their work. This has a strong effect on their motivation and growth.
For this reason, more and more engineering roles are now identified by their area of impact (e.g. product engineer, customer success engineer), rather than their technical platform (e.g. frontend engineer, backend engineer).
Out of these, the product engineer role is probably the most representative of this shift and has become a staple in modern successful companies like Stripe, Intercom, Atlassian, and more.
For example, here is how Intercom defines it 👇
As a product engineer, you’ll be taking ownership of real customer problems by building smart, efficient solutions to both back-end and front-end systems. There are projects for you to own in multiple areas, such as our messenger, bots, rule matching, deliverability, security, app availability, machine learning, and more.
Does this work for every company, though?
This article demistyfies the product engineering mindset. It explains why we got here, what it looks like in practice, and whether it can be useful to you. We will talk about:
🤔 Why product engineers? — Let’s clear up the confusion between product managers, product owners, product engineers, and let’s figure out what each one really does.
⚖️ Does it work for you? — Design the best strategy based on your business, product stage, company size, and more.
🔀 How to turn engineers into product engineers? — Practical advice to steer your company towards a culture of autonomy and impact.
📚 Resources — real-world case studies taken from the Refactoring community, and the best readings to learn more.
Let’s dive in 👇