[U30M] How to improve working with remote teams?

For a software engineering product team, there are two kinds of ownership:

1. Product ownership: The domain that is part of vision/mission/charter. It talks about the ‘What’ the customer ultimately experiences.?
2. Engineering ownership: The systems, services, DBs and pipelines, which define the ‘How’ the customer is impacted.

It’s near impossible, in any medium or large company, where there is no mix-up of these two areas. Meaning, a software engineering team will always have product domain, which is defined by engineering artifacts not owned by the team and vice versa.

<<Venn diagram to show different overlaps.>>

An important responsibility of a team leader is to understand (over simplifying), and accordingly do the expectation settings with leadership.

1. Does my team have ‘little mix’ or ‘tonnes of dependency’?
2. The large chunks of dependency (ignoring the smaller ones) are of the kind we ‘we depend upon’ or ‘we are depended upon’?

Now assuming that you have done that, and you find yourself in a situation where your product ownership is vast, and you actually own a very small, sometimes none, code to which you have unfettered edit/deploy access then you can try the following few things that I have tried and mostly have worked.

For sake of discussion, let’s define team Y (which is your team) and team O (which is the other team). The assumption here is, team Y owns OKRs which requires it to make a lot of <<characterize a lot>> in artifacts that are owned by team O. Now if you are lucky then Y and O are in the same timezone, otherwise, the friction to get the work done is an order of magnitude more, all else being same. Also, every additional skip-level separation somehow introduces more friction.

1. Ambassador engineers (Trusted?bridges)

Have one or two persons from your team “onboard” onto team O. This onboarding should be equivalent to a new engineer joining the team O. Now these ambassador engineers should be good enough that the team O people respect them and trust them to hold their bar for the reviews and possibly for deploys.

Remember, it is a win-win if team O can find someone who can offload their external dependencies code review for projects, which most likely will not be on its radar.

This is the fastest solution to implement, if you are facing delays or friction in code/design reviews.

2. Re-define the ecosystem

If the team O and Y have two different domains, ideally their code should also reflect that. It should be possible to decouple the code base where team O only refers to choices and pointers from team Y, instead of fully corrupting the domain separation.?

Usually, things could be architected such that the dependency between two domains is parameterized instead of hard-coded. Of course, it requires expertise in both the domains to a. understand b. propose (sell) c. execute these changes. Lack of capable and motivated engineers and ability to fund these initiatives makes them difficult to execute.

3. Share the?wins

Now this option will almost sound like cheating, but hold on to your beers, and imagine if you could befriend the product manager and engineering manager of team Y, and help them find OKRs for their team, which will be the result of your “asks” and prioritize them.

If you can do that, then the following things will happen:

1. You have created an ally on the other side who is as much motivated as you to get things done
2. You have doubled the number of people who care about the same customer-problem that you were solving
3. You don’t have to track, check or push any project

In some companies, this may require you to share your wins (e.g. partially count the GB win for the team) but the Customers don’t care about it, and you shouldn’t either. A wise man said you can achieve a lot more, if you are willing to take off your name from the credits.

4. Move the?teams

If leadership finds great dependency between two teams, one planning cycle after another, then they could move the team ownership to reduce the skip level separation. This assumes doing so overall reduces total dependencies, and not just shift them from one team to another.

In Uber Delivery, we had started a Payment Experience team as part of delivery org, which worked very closely with the rest of the delivery organization.?

For this to happen, a great many people have to be convinced that this is the right thing for the company. That makes it the slowest of the solution.

Note: I really wanted to start writing these suggestions in written format, but I wasn’t able to spend more than 30 mins on one writing session, so I have decided to put meta tags for whatever I can’t jot down in 30 minutes and publish whatever I have written at the end of 30 minutes session. After all, 1 published is better than 10 drafts, but at the same time, there is zero proofreading of the stuff I have written, to meet timeline.