login


Google Sign inLinkedIn Sign in

Don't have an account? 

Engineering Teams Run as a Product Organization

Collaboration
Internal Communication
Prioritization
Productivity
Team processes

14 May, 2019

Alex Bello describes the challenges his internal platform teams faced, as well as why and how he transitioned them into product teams.

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.

Related stories

Skip-Level One-On-Ones: Skip Them of Keep Them?
2 August

Peter Fedorocko, Director of Engineering at Workday, discusses if a manager should keep his skip-level one-on-ones and describes how he introduced the Open Doors instead.

Large Number of Reports
Leadership
Micromanagement
Internal Communication
Peter Fedoročko

Peter Fedoročko

Director of Engineering at Workday

The Power of Documentation Seen Through the Lens of a Manager
2 August

Lloyd Holman, Head of Engineering at By Miles, explains why documentation is essential for any company to achieve excellence, particularly underlining its importance in onboarding new engineers.

Onboarding
Internal Communication
Collaboration
Lloyd Holman

Lloyd Holman

Head Of Engineering at By Miles

How to Prevent a Single Point of Failure
28 July

Arun Krishnaswamy, Director of Data Science at Workday, elaborates on how he approached a single point of failure problem while sharing three key tips (or guardrails) on how to prevent it.

Different Skillsets
Legitimacy
Firing
Internal Communication
Ownership
Arun Krishnaswamy

Arun Krishnaswamy

Director at Workday

Visualizing Your Team’s Engineering Quality
26 July

Alex Litvak, Engineering Manager II at Uber, explains how he adjusted Spotify’s squad health check to enhance his team’s engineering quality.

Productivity
Alex Litvak

Alex Litvak

Engineering Manager II at Uber

Ways to Reduce Your Cloud Costs
26 July

Andrew First, Co-Founder and Chief Technologist at Leanplum, shares how with a focused effort his company succeeded in reducing cloud costs by more than 60 percent in only six months.

Productivity
Impact
Andrew First

Andrew First

Co-founder & Chief Technologist at Leanplum

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.