Great post from our friends at Source link
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
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.
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.
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!
#Ways #Avoid #Dependencies #Tips #Product #Engineering #Teams