The most valuable trait of great software engineers
A mindset shift that changed the way I approach software development
Engineer’s Codex is a newsletter about lessons from real-world engineering.
John Carmack, previous CTO of Oculus and creator of id Software (Doom, Quake, etc), was asked how AI will affect software developer jobs in the future.
He had only one piece of advice: “build full product skills.”
In fact, he’s beat the drum about this trait over and over, in tweets, podcasts, and his writing: being product-minded makes you an extremely valuable engineer.
The best engineers I know are not only extremely sharp technically, but also are able to apply their technical skills in a way that provides the most impact to move their product forward.
Some companies have formalized this mindset into the role of “product engineers,” where they are responsible for the overall direction of the product, not just the engineering. This is surprisingly not common in a lot of tech companies today.
In this article, I’ll refer to “stack engineers” as basically all software engineers.
When I was doing research on product engineering, I found that PostHog has written a lot of blog posts about it, so I reached out to them to chat about:
What’s the main difference between “product engineers” and “stack engineers”?
What does “product engineering” look like in the real world?
Tips for engineers to build full product skills
Recommendations for engineers who prefer to be tech-oriented instead of product-oriented
What else does PostHog do uniquely?
What’s the main difference between “product engineers” and “stack engineers”?
Neil Kakkar, a product engineer at PostHog, writes:
“Probably the biggest shift becoming a product engineer was with thinking from the eyes of the user. What’s technically sound takes a back seat to what the user wants.
When I was a stack engineer, I’d approach problems from the lens of “what’s technically possible?” and choose a compromise that somewhat works, negotiating with the product manager.
Now, it’s more like: “Ok, what we ideally want is technically impossible. But we still need the user to have a good experience, so maybe we can relax some other constraints such that it sparks joy for the user, and becomes technically possible as well”.
I still don’t always do it, and sometimes fall into the default of thinking through the tech side, where my lovely team mates help prod me back on the right track.
Neil linked to an example of this from PostHog’s GitHub, which is public.
One thing I want to emphasize here is that being product-minded and code-oriented are not mutually exclusive.
In fact, they go together hand-in-hand.
What does “product engineering” look like in the real world?
Generally, product engineering is similar to how most projects are planned.
Neil wrote a detailed blog post about how he owns projects as a software engineer:
Gather Context: Understand the problem thoroughly, focusing on use cases.
Figure out a Solution: Start with ideal solutions and tease out first principles.
Build: Prioritize tasks effectively, set clear priorities, and avoid distractions.
Gather Feedback: Conduct user interviews to confirm principles and validate solutions.
Align Metrics with Feedback: Ensure that feedback aligns with actual product usage.
These steps are similar to a software project being planned in a “normal company.”
However, there are a few things that stand out to me:
Gathering context
Gathering context in a normal tech company generally means using data that’s already there or interfacing with product managers and UX teams.
In a product engineering role, gathering context means talking directly to the customer and having a more hands-on approach. This is rare!
Most engineers in companies are silo’d away from users and interface with product managers instead. This is usually done because having clear “roles” allows for higher focus.
On the other hand, product engineers get to wear many hats, doing engineering, product, and UX work. The interface of a product manager is removed.
Instead, a product manager goes deeper into aspects of the product when necessary, supplementing surface level insights and taking over investigations that product engineers don’t have the bandwidth for.
You can also see it in real life, since PostHog makes their sprint planning for each team public.
Feedback Loops
An interesting note mentioned was feedback loops.
There’s a huge focus on generating faster feedback loops, allowing engineers to make sure they’re going in the right direction. Checking for feedback often allows for micro-adjustments towards a better product.
A good question that Neil mentioned here was him asking himself “How can I verify my thinking?", actively forcing him to seek feedback.
Metrics are always user-focused
This seems obvious, but having worked in big tech, it’s not always the case.
At a startup like PostHog, it’s a necessity for metrics to be user focused. The name “product engineer” keeps this focus top of mind for all engineers.
On the other hand, results vary greatly at larger tech companies. Metrics often become another thing to game to show impact for promotions. Of course, there are many cases where metrics align with a better user experience, but this is much more common at a “product engineering” company.
For example, at Big Tech companies like Meta and Google, there are countless stories littered across the web where making a better user experience is often implicitly discouraged, leading engineers to simply work on “hard problems”, regardless of whether they bring user value or not. Engineers must often pick between doing what’s best for users or what’s best for their careers (though this is not always the case).
This is very obviously not the case for product engineering-focused companies.
I think that there is a non-engineering benefit here where working on things that have impact on the end-user leads to better outcomes for both engineers and the company. It leads to less burnout and less time wasted on company politics.
Software isn’t always the solution
Owning a project provides a holistic view from talking to customers to getting feedback.
This perspective helps in understanding the entire flow and when software might not be the right solution.
When the product comes first, this is more encouraged. Compare this to other tech companies, where volume of code and velocity of pull requests are common metrics tracked as a gauge for productivity, regardless of the real value provided.
Tips for engineers to build full-product skills
Most companies would like for engineers to be more product-minded. While it’s made waves on “engineering” social media, it’s not really that common for engineers to think about the product that deeply.
Work alongside data analysts, implementation specialists, and product managers more. Talk to them more.
Ask questions about the user experience. What metrics matter for the end result? What user experience is being aimed for?
This also means really paying attention during all-hands. It’s easy to breeze through this, but it can be important to try to come out of an all-hands or earning call with questions.
Pretend you’re leading your company and/or org.What would you focus on and what moves would you make for both the company and the org you’re in?
If your predictions align with what direction the org is going in, great!
But if they don’t. Why don’t they?
It’s actually quite common that they don’t. When visions differ enough and somebody feels strong enough to feel frustrated by leadership’s vision (or lack thereof), startups are created.
It’s very common for big tech companies to flounder through projects that took years and eventually shut down. I’ve seen it first hand! VPs and Directors will be assigned to projects that they have no business leading, and when those orgs get shut down due to failures a couple years later, it’s usually employees who suffer.
Build more prototypes. As Neil said, making an MVP is super valuable.
Try to get a good mix of 0-1 projects along with “improvement” projects. At companies, it’s common to work on feature improvements or changes to existing products. But, ideally, there are opportunities to work on projects that start from “ground-up.”
At startups, these opportunities might be easier to find.
At big tech, it’s definitely harder, but it’s possible.
What if I prefer being tech-oriented instead of product-first?
Being product-minded and code-oriented are not mutually exclusive.
Great engineers are able to steer both the product and technical direction the right way at the same time!
This isn’t easy, but it’s a skill that can be developed over time.
There are many engineers who prefer being deep in the weeds of code and don’t want to talk to users or be product-facing. I think that’s okay. In fact, I’d say this is actually encouraged in some Big Techs.
At Google, for example, it’s only at L6 (Staff Engineer) that one becomes responsible for the product direction. Before that, “you can be largely successful by building good technical solutions.” (Adam Bender, Principal Software Engineer at Google)
An easy way to work on the “tech-first” is to simply work on distributed systems and infrastructure. In these cases, your users are now other teams!
What does PostHog do uniquely?
I wanted to thank PostHog for being willing to reach out and chat about product engineering. It’s not everyday that a startup is willing to take time out to chat transparently about their processes.
However, this is something that PostHog does right - transparency. I read a lot of PostHog’s articles while writing this one, and I was impressed by the level of transparency they provide.
At the same time, I think it makes sense. It builds trust and works as a marketing tool. Furthermore, it is notoriously hard to market products to developers (versus sales, managers, etc). However, I do think PostHog’s transparent culture and open-source codebase is a mark of transparency that is to be appreciated.
They also have a key focus on product engineering and growth engineering. These are twists to the normal “stack engineers” we see - but I think simply having those titles sets the tone of the roles and company. Engineers come in knowing they are going to have to wear more hats. They aren’t here to just work on improving the backend or frontend - they are here to improve the product and grow it.
This seems like a small detail, but it’s really easy for people to lose sight of this a few months into the job.
Other great articles about product engineering
- has a great article about being product-minded.
Really good writeup on product-minded engineers vs. stack-minded engineers 🙌🏼
A lot of larger corporations tech to hire and organize around stack-minded engineers.
A lot of startups tend to hire and incentivize product-minded engineers.
Both have their strengths. Both could learn a bit from each other.
Personally, I prefer being a product-minded engineer.
It’s served me really well at several startups I’ve worked at, and large 0-1 projects I’ve worked on.
Product-engineers + Product manager vision + culture that gives space for this = amazing products
Is this useful? Different terms used but same sentiment https://medium.com/codex/developer-vs-engineer-373d4a4ba22a