Generally speaking engineering and product teams tend to organize themselves in two different ways: Code-centric or Product-centric. There is no perfect org structure as there are pros and cons to each of these approaches. One big con to product-centric orgs usually is a decline in code quality and engineering productivity over time. Today, I want to focus on how teams can ensure code-quality and engineering productivity in product-centric organizations.

Code-centric

Code-centric teams organize themselves around their code/technology stack or architecture. Code centric teams tend to have the names of the platform they own and maintain. For example: the ui team, the api team, the data platform team or the mobile team. Startups tend to start with this model because there are usually one or two people who end up focusing on one area of the tech stack. Code-centric teams have a strong sense of ownership because of clear boundaries and full control over how their code evolves. There might be ups and downs but one can expect improved code quality and engineering efficiency over time from code-centric teams. Code-centric organizations can be challenging for product teams though. Product managers often need to work with  multiple teams to build a product feature. Due to the short-lived nature of teams who work on product features, a sense of product ownership may not be as strong as it needs to be.

Product-centric

Product-centric teams organize themselves around customer-facing services or product features, such as supply integration, clearing, or creative management. Product-centric teams are driven by product metrics sometimes referred to as north star metrics. Product-centric teams have clear product owners and a team of engineers that can build features using different tech stacks. Long-lived product-centric teams not only build what they believe are the most important features for their customers but also own and drive business metrics to achieve business goals. A sense of customer and product feature ownership is very strong on these teams.

One con to a product-centric organization's approach is reduced code quality and engineering efficiency over time. Product-centric teams are made up of a group of engineers who are incentivized to drive business metrics. They are not as specialized as code-centric teams in particular areas. Engineers might find themselves taking shortcuts, acquiring technical debt overtime, and not investing in tools and frameworks to simplify repeated asks. Such an approach might help to get a product feature out the door faster in the short term, but it is guaranteed to slow down the team and cause unhappiness over time. How can we create product-centric teams that have a strong sense of both product and code ownership so we have code quality and engineering efficiency?

Ensuring Code Quality and Engineering Efficiency

A product-centric team needs metrics that track code quality and efficiency just as much as it needs metrics to track business/north star goals.  Customer sign-ups, monthly active users, customer engagements, and mean time to resolve customer support tickets are examples of business metrics. These metrics help product-centric teams make the right decisions on where to invest their precious time in order to make the most impact. Business metrics are tracked and reviewed by product-centric teams and management continuously. In order for the team's code quality and efficiency guardrail metrics to do what they intend they need to be treated just like business metrics.

What quality and efficiency guardrail metrics should product-centric teams use to ensure code quality and engineering efficiency?

• Frequency of deployments: How often and how quickly can the product-centric team put new features in-front of its customers? Frequent and quick deployments are preferred to rare and slow ones. Frequent deployments push a small set of changes which are easier to debug in case of an issue. Quick deployments mean less time is required for a team to babysit a deployment. Hopefully it is not hard to see that the ability to deploy frequently and quickly is not only beneficial for quality and efficiency but it is also a good thing for customers.
• Rollback Rate: How often does the team end up rolling back a deployment? This metric can shed light on a few areas: Has the team tested new features thoroughly enough? Has the team run into any issues which could not be replicated locally or in test environments? Are there particular integration points that are hard to test?
• Time to Recovery: How quickly can the team recover from a production issue? How quickly can the team identify and fix the issue via pushing a fix, a rollback a release or a feature?
• On-Call Volume:  This is a tricky one as there are many ways to look at on-call rotation health. By on-call I mean that a designated team member is the first line of defense for ensuring important services are operating within the SLAs/SLOs of the team's expectations. I think it is important to track on and off hour pager volumes. How many times has the on-call responded to a page during business hours and non-business hours? I also suggest tracking how many times an on-call person was actually woken up to deal with a page. Managing on-call is a complex topic that deserves its own post. Briefly, you should track on-call volume and make sure it is acceptable.

Achieving frequent and quick deployments, and reducing rollback rate, time to recovery from failures and on-call volume requires investment for on-call teams. The list of guardrail metrics mentioned here are not comprehensive but should be helpful for product-centric teams who want to ensure that code-quality and  efficiency does not suffer over time.

I briefly touched on this earlier, but product-centric teams cannot just introduce these guardrail metrics and expect success in achieving engineering efficiency and code reliability. They need their management's support. In order for these guardrail metrics to help product-centric teams they must be taken seriously just like the business metrics. Guardrail metrics should be reviewed and graded regularly by the team and management. The goal is to build product-centric teams with a strong sense of product and customer ownership that tracks its guardrail metrics for quality and efficiency.