Great engineers will either get autonomy at your company, or they'll get it somewhere else. Our engineers are encouraged to think about the what and why of what they're building - not just the how.

At PostHog, new people are usually surprised by the lack of micromanagement, onerous KPIs, and death by meetings. Rather, we run two-week sprints where everyone decides what they’re going to work on for the next 14 days following a retrospective at the end of each sprint.

New problems are usually discovered and solved during each sprint that weren’t originally planned for, such as two of our main features - session recording and feature flags - which were ideated during one of our hackathons.

When you give engineers the freedom to play around with new ideas, magical things happen.

At PostHog, your speed of iteration is key - we’d rather you move fast and break things (and fix them just as quickly) than spend eons working on the perfect solution to a problem. Product thinking means accepting shipping small changes frequently will get you to the best result.

We also believe that the best way to learn is by doing. Hence we don’t give any special product training to new devs before they start. However, we have a generous budget for books, conferences, and outside training if someone wants further support.

Many companies harm their hiring prospects with their engineering job descriptions. Because autonomy is so critical, engineers are sensitive to certain keywords in job descriptions. For example, ‘close collaboration with product’ might give off the idea that product runs the show and that engineering merely exists to do the PM’s bidding. Calling the engineering team ‘IT’ is another red flag - no engineer wants to be treated like a second-rate citizen.

You can get a sense of project ownership during the hiring phase. At PostHog, we select for entrepreneurial candidates - people who’ve founded companies or worked on side projects in the past. Such people more likely to be intrapreneurs - out-of-the-box problem solvers who generate profitable solutions with the full backing of their company.

We also don't care whether they’ve worked at only one company or job-hopped - just that they learned new stuff, grew continuously, and built better products. Likewise, we don’t care whether you dropped out of college or attained a PhD - experience and entrepreneurship are not tied to qualifications. Most people underestimate the four-year head-start one gets by skipping college, especially for a field like computer science where everything you need to know is a Google search away.

Beyond iteration speed, risk-taking, and problem-solving, we’re also looking for curiosity - being willing to ask endless questions about the problem and the solution. For example, is there another way we could structure the dashboard? Do we really need three buttons here or is one enough? Do our users actually care about this feature? These are the types of questions we expect from product-minded engineers.

As of writing, we’ve got 12 engineers and are looking to double that number within a year. Expanding your engineering team introduces all sorts of interesting challenges, from the kind of work each person does to how we distribute ownership of output. We’ve introduced Small Teams at PostHog over the past few months and have enjoyed immense success with it. More work gets done faster and more problems are spotted early and fixed. Every Small Team has its own leader, and top management provides support and direction.

When you’re turning all your engineers into product people, it can be hard to justify hiring a VP of Product. But we’ve got a good reason for that. At the moment, our product is built for (and loved by) engineers, but we’ve only got shallow product/market fit - and that's actually pretty great for our current age.

We're young, aren't struggling for finance and we've the team needed to deepen our fit. The challenge we have today is that those less technical than an engineer (e.g., a product manager) often struggle to use our product fully. This hampers wider adoption within our client companies. Our new VP of Product will bring a sense of direction and long-term vision to the product in line with our current short term goal to delight five core customers (yes, even though we have thousands of users - we're focussing on just five key companies at a time, more on that in another post...). The VP Product will dig into what makes those Big Five tick, their Jobs To Be Done, and what new features they’d like to see added or nixed. They’ll also continue to turn our engineers into product people, providing training and coaching where needed.

Engineers are becoming increasingly mission-driven creators who want to understand what the user struggles with and how to alleviate those struggles. During our hiring process, many engineers reveal that they’re leaving their current companies because there’s simply no room to create stuff - either because they’re not given the autonomy to do so or because the product(s) they work on lack sufficient usage to track trends and test new features. Good engineers are scarce, and if you’re lucky enough to snag a few bright stars, give them the keys to the kingdom and watch what they build with it. You’ll be pleasantly surprised.

Further reading

• The difference between product engineers and software engineers