Great software speaks for itself.

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

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:

Full-stack Engineers benefit from:

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.

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.

  1. Everyone is at a different strength for different aspects of product development.
  2. No one is expected to master this in a year. Try 5-10.
  3. 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?

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. =)

I look forward to sparking any kind of dialog aspiring to make working in tech more awesome.

Originally presented at our weekly Tech Master’s talk at Hired: