Engineering Teams Run as a Product Organization

Problem

Back in the day I created my own startup. I was working on a consumer web application where I actually got excited about building something end-to-end. There was no separation between engineering and product. Fast forward and I began working in enterprise software where I was heavily involved in building back-end platform-style services that were consumed by front-end teams. There was a clear separation between those who built the back-end services, engineers like myself, and those working with the customers. It became really hard to connect to the business value because priority was put on roadmaps that emphasized customer-facing features, while in platform-style services we were fighting to justify our roadmaps and prove to the rest of the company that what we were building was actually enabling the business.

Actions taken

What I realized was that a lot of our internal teams weren't putting value on the work that we were doing. They thought that because there was already a product to sell that my team was simply an enabler of the other teams to distribute that product. So what I did was retrain my mind to start thinking like a product organization. I decided that I would run my organization as if it were a product and therefore treat all of the engineers on my team as if they were customers.

I began by hiring a technical program manager. This person was brought on to create a proper release process around the work that the internal engineering teams were doing. They were tasked to start getting all of the platform teams to follow a product release cadence and other product processes. Then, because I had previous product knowledge, I began training this manager to be a product manager. I chose to hire a technical program manager instead of directly hiring a product manager because it was easier to attract a technical manager for this role. They are used to managing programs. And there is a gray area between program management and product management so I took advantage of that gray area. Additionally, these two domains are starting to morph together in larger enterprise organizations so there is an influx of potential program manager candidates in the pool. Lastly, the person I hired aspired to be a product manager, so it was a win-win situation.

Next, as I started to transition my internal platform teams into product teams, I put in place real product metrics. For example, one of the KPIs that I use for my team is adoption, just like in a real product. So how do you measure success? How is it getting adopted? And I made those objectives and key results valid for those teams. So it was no longer just build a feature and hope it gets used. Now they were being measured by adoption. Basically, the metrics were to guide prioritization.

Another key aspect that I implemented was using a framework for prioritizing feature requests. This meant it was no longer up to the platform engineers to decide what to work on. I used a RICE model which is a model for product feature prioritization. RICE stands for Reach- how many users does is this feature going to reach; Impact- how do you rate impact on a one to five scale (for example); Confidence- what confidence do you have in the previous two numbers; and Effort- what is the level of effort to actually build?

As I took all of these elements of product and applied them to platform engineering the outcome was that my engineering teams started building customer-facing products. This was because the teams were very successful in driving adoption with internal services. They enabled other teams and that built up confidence with the rest of the organization. They began leveraging and using all of their own tools and pipelines which made them fast and efficient. Consequently, they were in the best position to build customer-facing products and all of sudden became the highest performing team. In fact, they actually created, built, and shipped a whole new revenue-generating feature as I was leaving the company. And they were able to crank it out in less than a month.

Lessons learned

• I personally realized that I wanted to build more customer-facing products. I felt that the experience I had building my own product engineering organization prepared me for this transition. Thus, I ended up seeking a career path that was on the product side of a platform.
• Having now been a product leader and an engineering leader, I am a firm believer that they should both be under one organization. Product has a hard time understanding what engineers are doing until they start building customer-facing features, and I would rather avoid this ambiguity. Therefore having them in one organization ensures awareness and greater alignment.
• Another benefit to combining the two is that if you have a product minded engineering leader, you are actually going to build better products. This leader will understand both sides really well. They will understand the challenges. And they will know the best way to build the product.