To make engineers more autonomous create a partnership

Paul Ortchanian
Bain Public
Published in
3 min readJan 7, 2018

It is 5:00PM in the office, and a member of the engineering team stops by the Product team desk and expresses they want to build everything at once. When discussed, the head of engineering states that excessive rework undermines motivation. That they prefer focusing on code without a lot of distraction. That continual change tends to corrupt the structure of the software and once something is “done” it should never be revisited. What is wrong with these people? Is there a subculture of haters holding back continuous integration so to prevent the validation of the evolving product?

It turns out the answer is no. Customer-centric rapid delivery can be perceived as a randomized environment. Rework could show problems in the requirements or the development processes. Yet all products need to start with a vision followed by an early delivery of subset capabilities . It’s ok to learn something new as you go. It’s ok to seek to understand the customer problem you’re going after. It’s ok to build small increments of value for your customers to frequently show progress. It’s not that engineers don’t want to be helpful, it’s a process issue. Enhancing and fixing existing capabilities is good. The surrounding business culture and philosophy about the product development process is misconceived.

It almost doesn’t matter what the product is

As a Product Manger you own the understanding of the product/market pair. It’s more about business than technology. Then making sure team members are all on the same page about goals. Engineers own the solutions. First establish a process where there is joint discovery, decision-making, and shared accountability. Have engineers join you in customer interviews so they understand the situation in which people encounter a problem to solve, understand the motivation for solving it, and understand what a great outcome looks like.

A partnership that values the customer as well as technical debt

Product and engineering are at the heart of the company. The cost of the partnership needs to balance against its benefits. It’s a combined effort where the PM’s process provides a large amount of autonomy to engineering. The product person test future work, figure out what customers need and manages the process. Engineering test current work, deals with the day to day while making what’s being coded transparent. The goal is to use a shared empathy for the customer needs to increase collaboration.

Start your product at the first step where you can add value. Work with engineering to understand the full workflow. Continuously integrate and validate the evolving product and you’re more likely to have happy customers.

I am a VP Product who has experienced different levels of product management positions and has learning’s to share. I thrive in middle market and scrappy startup environments, where everyone does a little of everything. I work closely with CSuite leadership teams towards product-market fit and operating at scale. Check me out on Reflektions.com and view my LinkedIn profile.

Thanks to Judy Wong, Ben Melchionno, and Sergio Escobar for reading drafts of this. Photo by Nik MacMillan on Unsplash. Also, if you have any feedback or criticism about this article then shoot me an email.

Originally published at reflektions.com on January 7, 2018.

--

--

Paul Ortchanian
Bain Public

I am a head of Product who has experienced different levels of product management positions and has learnings to share.