Ways to Avoid Dependencies: Tips for Product Engineering Teams

Dependencies cause chaos on delivery and destroy predictability. Use the "independent executor" model. These are weightless conditions that can increase your plans.

Independent Executor Model

We need things from other teams because they are the owners of the area we need to do work in. And it is natural when there is a temptation to depend on them and wait for them to provide something for you. For example, there is a need to find a team to add a field into the API or to build a new one. Sometimes, you can’t show what you require without these changes. 

This organizational trap leads to distress and pain.

Independent Executor Teams: Useful Rules

You shouldn't expect other teams to do work for you. To avoid this pit of despair, you can ask them for advice, but never shift your responsibilities onto others. Here are some rules. Follow them:

• Communication is vital here. Make sure that the other team understands what you want and how important it is.
• Make plans for other teams. Ask them to do work for you.
• Never expect that someone will do work for you.
• Be convincing. The client must believe in your experience.
• If you depend on other teams - have backup plans. If their priorities don’t align with your own, the backup plan will help to show your value.

How Should Product Engineering Work With Dependencies?

Tracking is the first way that some organizations use when they try to solve dependencies. This method doesn’t work. It can't solve the problem. Adding a method to track needs in Jira will not help because the problem is dependencies. The background of that is that each team has competing priorities. We can't rely on them because they shift all the time.

If you are developing an ambitious project, you will have dependencies and go into the danger zone. Your plans are being built in the air if you have dependencies. The more you have, the greater your risk.

But let's look at a model where you're always having a plan, where you don’t rely on other teams. This plan will always deliver value and maximize value for the entire company. You only need to follow the plan and communicate your needs to the other teams. Stay in your zone of control and deliver the most value you can.

This way is the one that can help you stay balanced in product engineering.

Some will think that the trouble is weak project management. They try to avoid this trap by using knowledgeable project managers. But that's not the difficulty at all. You will have unacceptable risks no matter how you manage the project. Even if you manage risks and dependencies. Plans with dependencies are high risk. Having a fallback, you guarantee your team and the company that you can give a standard of value.

Time to Use This Model

• Make it a habit. Do it the default for product engineering teams. There is a higher risk of project failure. But operating in this way minimizes that.
• You can use the basic principle for all engineering teams.

Useful Tips When Using This Model

• Assess the cost of migrations and hacks. Often you have to be messy while working around other teams' priorities. Your solutions can be less elegant when you don’t do the work in the right place. First, check your team. Do they do the work in the right place or not? Use the away team model that you can see below.
• Don’t ignore the cost of using a hack. The costs will comprise the hack creation, maintenance, and migration to the new solution. It may seem the cost isn't worth it. But don't go to work on something else. The team you're requesting should know these costs. Let them know about it. The costs you incur and the value you deliver will show you whether it is worth it.
• Don’t forget the power of influence. You have no power to control the other team's actions and doings, but you can influence them. Communicate with the team. Tell them about your needs and explain why it's important. This helps them to evaluate the global priorities.
• Organizational structure needs to be under your control. The incorrectness of the org structure can lead to excessive dependencies. The back-end and front-end engineering team is the most common example. Every front-end project relies on the back-end team. These teams aren't ideal, even if they try to avoid the dependencies. It's better to work together and agree to an API contract without missing things.
• Your org design is usually incorrect when you see the dependencies. (You will find another article later, about the front-end and back-end team pattern - there are lots of thoughts in my head about that issue).

• Think about system-level prioritization. You require product management (or Integrator) prioritizing and listening for comprehensive needs. Strengthen your Integrators and make it a priority to work not only on local needs but also on global.

Independent Executor or Other Coordination Models 

The independent executor model helps to reduce unneeded coordination. When you need increased coordination, find other regulating forms. Looking for work from other teams, think over:

Program managers managing epic begins

A program manager is ideal to coordinate a large initiative if it is a priority. Soon you will find another big article about decentralized/centralized prioritization. The information in the post will describe the way to prioritize rationally. That will make the program manager help get other teams to do work for you.

Integrators prioritize and listen

Communication is vital for integrators. They listen to people’s needs and proposes. They are ready to prioritize based on ideas they hear. Product managers usually fill this function. But if you move to an Independent Executor model, you require integrators. Without integrators, your product would be a bunch of messy engineering, and a platform that isn’t working as you need.

The away team model is a good way to do it yourself

The better way is to do the work yourself rather than having another team do it. The Amazon company has an approach - the Away Team model. The essence of the method is that you do not rely on other teams, but you can do work in their area of responsibility. One or more people from your teamwork in another team for some time. They do the work in their codebase for a limited time. They have a flexible way of interacting with the other team. They can have someone from that team that helps or be completely independent.

Develop norms and standards for this in your organization. These norms will help The Away Team to flourish. You will see that it is helpful when you have people from the other partners who guide the Away Team members. But this might not be necessary if you have strong standards and norms.

• Combine your goals with the other teams' goals. To get things done, you need to talk to the team. If the other team does not have the bandwidth for these conversations, you may be out of luck.
• Later you will find another post on this model that would be more detailed and longer.

Make meetings for a task force for vital tasks

Create a task force, if the project is critical. Here you assemble a part-time team. Use them in urgent situations and do the work across a few teams. Note that task forces don’t help you get your work, other teams will do instead of you.

Persuade a tiger team to do the work for you

Sometimes there is a chance to convince a tiger team to do the work for you. This messy way can work sometimes.

Enlist the community of practice

Sometimes you can enlist the communities of practice, who develop ways to drive work. Take advantage of that if you can convince them.

Coordination Models

There is more than just one coordination model. The Independent Executor is the one that gives you different ways to solve your inter-team coordination issues.

Feedback

If you have something to add that I have missed, or you disagree with my point of view, please don't hesitate and write it in the comment section you can find below!