Product Engineering as a Discipline
originally written October 15, 2015
Traditional product development role interactions trend toward a local maximum of isolated contextual ownership. A global maximum & virtuous cycle can be achieved when a team sets up a reliable way to share & grow contextual ownership with full-stack engineers.
How do we build a team of engineers who can find, create, and dominate markets with world-class product development?
Posing this question to oneself is inevitable at some point in a career after seeing enough team formations and their various trade-offs. I suppose this inevitability is somewhat accelerated at a rocketship startup that is lucky enough to iterate formations at a higher frequency.
No matter the formation, tech companies these days generally espouse core principles that sound nice to engineers but are really hard to achieve in reality. At its worst, leadership preaches these principles but is incapable of practicing them or baking them into the culture.
Some pillars of great, happy product teams
- distribution of decision-making, structured autonomy
- long-term operational context, growth of business & personnel
- iteration speed commensurate with risk involved
Easy to say, harder to do.
Okay so we’re taking a lot for granted by implying these are self-evident. The intent is to capture the essence of the magical “Google/Facebook Culture” that so many companies aspire to emulate.
How do we make this a reality and prevent it from declining into mere managerial sloganeering?
As the quarters go by and Hired’s insane growth affords us further iteration, we are becoming increasingly convinced that there are some core principles we can encapsulate & discuss to inform team decisions at all layers of the product organization and all stages of product & company lifecycles.
Disclaimer: This is a living, collaborative thesis.
It should take years and the contributions of many talented individuals to really codify this. I’m merely sharing my perspective from my time working with software companies thus far.
As always, future experience will undoubtedly influence, hopefully evolve this living thesis.
Intro to Product Engineering as a Discipline
Traditional product development role interactions trend toward a local maximum of isolated contextual ownership. A global maximum, virtuous cycle can be achieved when a team sets up a reliable way to share & grow contextual ownership.
Let’s rephrase that around a more familiar perspective:
Full-stack Engineers are happiest and most impactful when they are gaining & exercising context around business & product development.
A Product Engineer’s Contextual Domain:
What does this mean for the functions traditionally served by engineering?
Functional Specialists benefit from:
- having a fresher set of eyes provide feedback to their operations & context
- having a “junior” person in that context to help with more familiar work
- a chance to train & educate smart, motivated aspirants
- in some functions (ex- design), a lot of work can be handed over to engineers with the right framework in place
Full-stack Engineers benefit from:
- re-incorporating contextual learnings into development decisions
- tighter relationships outside of the engineering team, larger social network to leverage over time
- eventually gaining more autonomy operating in that context (after trust is established)
Product Engineering Foundation
We seek to create a virtuous cycle that allows generalists to go forth and ship with as little friction as possible. So far, we’ve found three key pieces are needed for a team to achieve this.
Low-friction Tooling
When your code framework allows anyone to ship new forms and interfaces quickly (because of a strong CSS & visual framework and a strong backend framework), there is ample time for individuals to tackle new contexts. At Hired our team has a healthy mix of tool makers and tool users and they have collaborated to evolve a surprisingly low-friction environment for shipping product. (And not without some pain, like we had to learn the hard way that Angular just increased friction and wasn’t worth the tradeoffs against having simpler designs.)
We rely heavily on the ubiquity and conventions of rails and our living style guide to achieve this high-liquidity build framework
Operational Constraints
We don’t want to throw people into the deep end and set them up for failure. Providing strong boundaries is critical for reducing risk and increasing chances of success (and happiness by proxy). These boundaries should be set with the engineer involved, of course, and act as a phase-gate between stages of gaining more trust & autonomy in a given context.
Is this concept going to touch 90% of our best customers? Sounds like there may be a little more risk involved so it’s worth reducing scope to have a slightly higher “senior check-in” frequency.
Team Support
Everyone on the team has to be bought into this mode of operation. If someone doesn’t go in knowing to expect some mistakes and some calibration, they’re at a higher likelihood of having a negative response to a non-traditional scenario, and that might be all it takes to prevent the team from getting over the local optimizations of traditional product development role interactions.
Longterm Pathway to Trust & Empathy
Enabling every role to support growing product engineers cuts cross-functionally and requires a non-traditional operational contract between the traditional roles in a product development team. Instead of handing specs and work over, the relationship between functions is much more fluid. Adopting this contract, however, can immediately alleviate tensions that invariably form between roles as a deeper level of mutual respect & empathy should be the natural conclusion.
Here’s are some quick examples addressing specific functions, but really each function deserves its own blog post and a deeper dialog from this perspective.
- Product Managers - Build a project framework. Work your way out of project management. Focus on educating engineers about the market, product vision, user feedback, and how our project framework can enable them to run their own projects.
- Designers - Build a design framework. Teach engineers how to design & build in your sandbox. This will free up your time to focus on other things, such as moonshots or deeper design iterations on specific components.
- Engineering Managers - Build a personal growth framework. Truly the stewards of this harmony between functions, your job is to ask help map engineers’ interests to cross-functional project opportunities and coach every through the process.
Then, when “engineer X didn’t do function Y correctly” crops up in conversation for the first time, and it always will, it’s less about “they’re not right for this” and more about “how did the operational framework make it harder for them to gravitate toward the right decision naturally and how can we evolve the framework accordingly?” and “how can we share what has been learned with the organization as a whole?”.
Respect the Learning Curve
Nobody starts as a product engineer. Nobody will master all of the contexts.
- Everyone is at a different strength for different aspects of product development.
- No one is expected to master this in a year. Try 5-10.
- It’s a journey of breadth, aimed at excellence in generalism.
Mistakes will be made. They are learning opportunities. If too many mistakes are being made, the contextual framework & rules of engagement between parties are probably not ripe for a generalist. It take some effort to scope things correctly and reach a cadence between parties, but after the initial hump… that’s where the payoff lies. And the more natural this modus operandi becomes for your team, the smaller the upfront cost will become.
But this sounds like a lot of work for everyone involved.
Smart people basically get off on creating & learning. At least at Hired, we’ll argue that we’re just going with the flow of brilliance rather than letting our managerial fears get in the way.
What are some examples of this working in real life?
- Lih wants to learn more about paid advertising and how we introduce our brand efficiently, so he’s spending Q4 iterating on our attribution infrastructure while working closely with our director of user acquisition.
- Aaron wants to learn more about email marketing and how we deliver value to users’ inboxes to keep them engaged, so he’s spending Q4 extending our email infrastructure while shipping critical engagement & growth experiments with our email marketing manager.
Now these two will be contextual leaders on the engineering team and can help other engineers navigate these waters as well. And these things never would have gotten done if we had waited ‘to hire the perfect candidate to build this for us’ or ‘for the functional expert to get free time to spec everything out for an engineer’.
What do you think?
Hey, thanks for reading this in its raw state! I’d love to hear your thoughts.
If you have a few more minutes, I do have some questions for you. =)
- What do you think could use more clarification?
- What about this doesn’t fit with your understanding of “the ideal way to work in tech”?
- What seems naive about this?
- Is this just a bunch of useless wankery?
I look forward to sparking any kind of dialog aspiring to make working in tech more awesome.