Joy in Aligning With Product

An optimal team is a team where every skill needed to deliver the product or service the team owns is on that same team reporting to the same manager. That team has four to ten members.  That team owns everything from feature definition to running their systems in production. That ensures that the team has no hard schedule dependencies on other teams.

Unfortunately, that optimal structure is exceedingly rare, so it's unlikely your organization functions that way. Your organization is probably a matrixed organization with skill verticles reporting through management that only manages that skill verticle. Your organization has Product people reporting up through a Product organization, Program people reporting through a Program organization, Test people reporting through a test organization, etc. That nineteenth-century industrial model envisions an assembly line of work that flows through each skill vertical and eventually pops out a finished product. That model made good sense if you built Model T's in 1913, but doesn't make sense for software development.  Among other problems, it creates deep organizational divides in individuals that should work together. It harms ownership and accountability. That inevitably leads to cultural toxicity and poor delivery.

One of the better examples of the organizational challenges that this outdated approach creates is the rift between the Product and Engineering organizations. Product is held accountable for defining features. Engineering is held accountable for delivering those features to production. This division of labor sounds intuitive. One team does the first part, and the second team does the second part. It's like an assembly line, and things should move smoothly down the assembly line.  Unfortunately, its not an assembly line. Its a fully connected graph of interdependent actions. The mandate to Product is to build out the roadmap for the Engineering teams. Unfortunately, that doesn't work, because a coherent roadmap is a balancing act between lots of competing concerns. No single skill vertical has enough information to manage that balancing act well. Product features can't be defined and scheduled without significant engineering input, and engineering can't deliver without significant product input. Delivery is a dynamic balancing act, so it's ineffective to do those things ahead of time. An optimal team structure sets up the team to solve those problems, but you don't have that.

Fortunately, this isn't a zero-sum game. While the difference between an optimal and sub-optimal model is vast, the closer you move to the optimal model, the better off. Even incremental movement can have a significant impact on delivery efficiency.

Aligning Models

Restructuring the teams give us a magic wand for laying the foundation for alignment and incentive. Without that, we have to work much harder for a less effective result.

First Understand The Pain

Let's start by clearing the air. The Product/Engineering divide has probably already caused a lot of finger-pointing and resentment across both skill verticals. That is not useful and its also based on inaccurate information.  Both Product and Engineering are in a bad situation. Both are being held accountable for an overlapping piece of a whole. Neither skill verticle can deliver, and both are frustrated. Both feel strong ownership, but they don't have any ownership. Neither skill verticle can move forward with input and support from the other.  The next outcry will be 'they can just work together' or 'Why don't they just talk to each other.' They can't do that effectively because they are two separate organizations. Each organization has its own management chain, their own alignments, and its own incentives. That means that it is almost impossible to align their models. It also means that any communication across those models is costly. Your intuition may be that this should be easy, but your intuition is wrong. So how do you do patch over these structural problems? How do you improve alignment?

First, know that while you may be frustrated with the Product organization. They are almost always good people. Its the structure of your organization that is causing the tension, not the quality of the people involved. Start with the assumption that your partners in Product want to do the right thing.

Second, realize that you have a 'The Emperor Has No Clothes' situation here. Everyone gives lip service to the idea that all these matrixed skill verticals are on the same team, but they aren't. They are a different organization, and so incur all the usual costs of communication and coordination across organizational boundaries. That defines the relationship you have with your Product people. Once you realize that, you can stop trying to treat Product as a part of a team and start treating them as stakeholders. That new relationship is much closer to reality and will result in much less friction between you and Product.

Addressing Specific Points of Friction

There are a few traditional points of friction between Product and Engineering that you need to address. Those points are, from an engineering perspective:

1. Product's roadmap isn't realistic.
2. Product isn't clear on what they are trying to accomplish. They are not telling us the goal, just the steps.
3. Product likes to change things that are already in flight.

The Product Roadmap Isn't Realistic

Product is coming to you with a complete feature roadmap. The nexus of that conversation is, 'Here is your feature roadmap for the next quarter.'  It is a monolithic block, and that you have to workaround. They had conversations with you to define that roadmap. They are trying to be collaborative, but the structure isn't there to allow collaboration. You take that roadmap, as a monolithic block, and try to build around it.

That is not the right conversation to have. You must change the conversation. You change the conversation, as you always do, by changing *your* actions. It's never useful to ask someone else to change to make your life easier. What do you need to do?

Start by keeping a complete engineering roadmap in a public place. Lay out the primary goals on a calendar with delivery dates. Yes, its a Gantt chart. That roadmap should cover the next two or three months.  It should include all of your feature and reinvestment (tech debt) work. I recommend using a tool that does this for you,  like Jira Portfolio or Liquid Planner. If you can't do that, then use what you have. It doesn't matter if its Airtable, a Wiki Page, or an Excell spreadsheet as long as people can get to it.

Be religious about keeping that roadmap up to date. When something e changes that affect a delivery timeline, update that roadmap. It is going to become the tool that every timeline conversation revolves around. It's going to become the focus of discussions because it's accurate, available, and you refer to it frequently. Yes, its a lot of work, but you still have to take the time to do it.

Finally, when Product comes to you with a roadmap. You will sit with them and discuss how to integrate that roadmap with your roadmap. Framing the conversation around integrating roadmaps naturally changes it.  The conversation becomes about trade-offs and prioritization. These conversations also inform your mental model of Product.  It lets you build rapport with Product and allows you to educate Product on the engineering realities of delivery. The conversation is essential. Don't try to replace those integration conversations with a process.

Product Isn't Clear on What They Are Trying to Accomplish

Many people fall into a common trap of talking through the steps to accomplish a goal instead of stating the goal and letting the team figure out the steps. It is an easy trap to fall into and something you commonly see in features described by Product. The solution is straightforward. Ask what the goal is. A simple 'What are you trying to accomplish here?'. Don't do it in email, do it face to face (or via Zoom in the current world). Ask with humility. Ask with a genuine interest in accomplishing the goal in the best way possible. Once you understand the goal, open up a conversation about the best path to reach that goal and metrics to measure progress. With the support of Product, roll that information back into the story or epic. The feature will be better for, and Product won't have a problem partnering with you.

Product Likes to Change Things That Are In-Flight

Product wants to change things in-flight because that is when they realize that Engineering didn't understand what they actually wanted. Engineering and Product didn't align well enough before work started on that particular deliverable. Product and Engineering have different mental models and think about things differently. They have access to different information, and they have different incentives. That reality means that it takes a lot of work to align their models.

In many cases, Product doesn't do a great job of describing their desired outcome. Engineering then makes inaccurate assumptions about what they think that Product wants. When Engineering starts work on a feature, they start asking questions, and Product starts to see the result of Engineering's work. That is when Product realizes that you were building the wrong thing, which is far too late.

Alignment is the challenge here. The things I have recommended in this post will improve alignment tremendously so that these problems won't pop up as often. They are still going to happen, though. When it does happen, you can offer two options to Product. These are the same two options that you would provide to anyone that wants to change in-flight work.

1. Continue with the work and iterate on it in the future.
2. Cancel the work, but it goes into replanning, and the team continues with the work already scheduled.

Those are the only two options that work. Trying to replan in-flight is too costly. It disrupts your delivery schedule and everything around it. Changing work in flight also increases delivery risk. It's a much better option to deliver something that is not quite right then to deliver nothing at all or deliver the perfect thing at a much greater cost than anticipated.

Keep in mind the fact that the Product team is one of your stakeholders. You should enable them, not block them. It's also essential that you retain the Political Capital with them that lubricates discussion and allows you to work together. So give them the option to step back, replan and reprioritize. It won't be in the current Sprint (if you are doing Sprints), but it could be in the next Sprint if it continues to be necessary.

Finally

It's Not My Job

You may be thinking to yourself, 'this is Product's job. Why am I spending my time doing this?'. That 'It's not my job' think has no place in your repertoire. You do it because it is critical for success, and no one else is doing it. In a matrixed organization, no one is accountable for delivering the product. If everyone provides what they are accountable for, everyone is successful, but nothing useful gets into production. You are holding yourself accountable for delivering something useful to production, and with that extra accountability comes extra work.

Mentoring and Delegation

In the best case, this work with Product happens in your team. Once you set the model, it's time to start delegating the work. Include members of your team in these conversations with Product. Before you meet with Product, explain your approach for the meeting and what you expect to accomplish. Afterward, explain how you think it went, what you could have done better, and what you expect the outcome to be. Over time, shift control of the conversation to them so that they can drive. In the end, these good conversations will happen without you in the room.

This Approach Works at All Levels

This approach works regardless of your level. From a manager of individual contributors to a Vice President of Engineering or CTO this approach works. The details change, and the higher up in the organization you are, the more you will focus on mentoring your direct reports. However, the approach consistently works.