[MUSIC PLAYING]
JAY STEELE: Hello.
Good morning.
My name is Jay Steele.
And I'm a software engineer manager at Google.
Today I'm going to be talking about working
with technical teams abroad.
So I'll kick this off with a little background on me.
Here's a couple of the companies I've
worked for in the past, including a couple of startups
in the left--
Plazmic and Viigo, and larger companies
on the right, BlackBerry and now Google.
All of these involved working with engineering teams
all across North America and around the world.
And you'll see listed on the bottom of each
some of the regions involved, some of the cities and areas
and how it involves working across large geographic
divides.
I've seen some things go really well.
And when it does, it's really rewarding.
And I've also been involved with some pretty challenging
environments.
Working with decentralized, remote, and international teams
is very hard.
And this presentation will walk you
through some of my own experiences
and hopefully give you some tools
to inspire you as you go through your own experiences.
There are a lot of challenges working with distributed
technical teams.
And I'm going to walk you through eight
best practices, all of which can be distributed
into three major themes.
The first one is minimizing social distance,
then providing the power to communicate
and creating a success framework.
All of these have foundations in communication.
For example, the reason you want to minimize
social distance between people is
so you can give them the comfort and confidence to communicate.
The reason you give people infrastructure and tools
so they have the means to communicate.
And the reason you build interaction frameworks
is to ensure that the communication has guardrails
and purpose.
So let's drill into eight best practices for working
with technical teams abroad.
All of these best practices follow to those three themes
that I described previously.
And I should note, these best practices
aren't unique to distributed teams.
You should do this with any team.
They're just especially important when
working with teams abroad.
So let's kick off our eight best practices.
Number eight, know your team.
This one seems obvious.
But in the bustle of running a small company,
this is really easy to overlook.
You'll be busy.
They'll be busy.
And everything will work out if you just go to the meetings
and spend time with them, right?
Well, it's not quite so easy.
You really need to invest in connecting with individuals,
learning about what they like, what drives them, what they
hate, what they love, learning about what they want to get out
of their role in your organization
and learn about how they see their career evolving.
Why is this important?
Well, number one, it helps build trust.
And it helps open channels of communication
between you and them.
Number two, it gives you important information
about how to model and structure your team based on what
really drives people over time.
For example, if you learned that a junior member of the team
really wanted to become a technical lead,
you could provide opportunities for them
to learn and grow and provide a great future for your company
down the road.
Number seven, structure your team.
This one seems obvious, right?
But boy, can this get tricky when
you're adding the dynamics of a highly-distributed team.
There are some important things to consider here.
So first of all, seniority and experience--
your team will have junior members.
It'll have senior members.
And how you divide those people around the team
will play a key factor.
There's also domain expertise and roles.
So some members of the team will be
specialists in a specific technical vertical.
And some will be experts in UX or project management.
And you're going to want to distribute those people
amongst the team appropriately.
Where everyone is located and what time zone they're in
is going to play a key, key role, especially
with distributed teams.
And you're going to want to structure your teams
to optimize for that.
And then finally, how products and services are designed
plays a key role as well.
For example, you might have an application
that has two separate tabs where the technology is completely
independent of each other in those two tabs.
You could design teams to focus independently
on those two tabs.
Or you might decide if your product is a client server
model, one team can focus on the front end,
one team can focus on the back end.
All of this has to be factored into team structure.
And you need to optimize it for the problems you need to solve.
However, there is one core, one thing that's very important.
You have to be very deliberate and clear about the structure.
You have to identify clear roles for various team members
within that structure.
And you have to communicate it all to the team.
Number six, managing technical experience-- engineers
typically fall into four levels of experience
as they navigate their careers.
Junior engineers are typically just getting started.
They're very eager.
They just want to pump out code.
Intermediate engineers have been around for a year or more.
And they're still writing code, but they're
starting to dabble in software design debates.
And they're starting to develop opinions
about how products and features and designs should go.
Senior engineers are normally three to five years
into their careers.
They're typically driving designs, providing leadership
on small projects.
And finally, leads are typically five plus years
into their career.
And they can drive complex projects or even
multiple projects.
And they can even have reports.
The best teams manage the ratios of these levels appropriately.
For example, a team with all junior engineers
is likely going to struggle to steer
the projects appropriately.
They can maybe go fast, but they're not going
to go in the right direction.
A team of senior engineers risk overthinking and debating
direction and not making enough progress on the little things.
Or worse, you could have people in roles
that they are under or overqualified to do.
And that's not great for morale and just team
cohesion in the long term.
You also need to factor in career growth and hiring.
So, for example, junior engineers
won't stay junior forever.
They're going to become intermediate and senior
engineers eventually.
And you're going to have to figure out an appropriate way
to backfill them for the future of the company.
Managing this across distances is pretty important.
For example, you may need to have a local lead
in a remote office to ensure more junior team members have
appropriate leadership.
Number five, invest in great tools.
So this is really important for highly-distributed teams.
And I highly recommend investing in getting the best
tools for your team if you can.
Don't just think about the obvious ones,
like email and chat.
Consider collaboration tools like video conferencing,
calendaring, project management, planning tools, task and defect
tracking support, and even more.
Consider asset creation tools like dev environments,
release management, UX tools, office tools.
Furthermore, focus on how these tools
can interop with each other to ensure that they all
work seamlessly together.
For example, can a support system automatically
generate a bug ticket and notify people on email and chat rooms?
There's nothing more frustrating to have a whole bunch of tools
that you can't make work together.
Finally, make sure you're investing
in training so that team members know how to use these tools.
There's nothing worse than spending a lot of money
on a tool and then only using 1% of it
or maybe even not even using it properly.
Last thing actually is--
and this is often overlooked-- invest in best practices
and ensure people are using the tools appropriately.
We'll get into that a little bit more later.
Number four, invest in process.
Some people don't like the word "process."
It makes it feel a little too big company.
But you really need them.
Processes are the train tracks of productivity.
I've been there.
I've been in environments where people just try to wing it.
And it just does not work.
It's also important to ensure that process are lightweight
not burdensome.
You want to create repeatable, well-understood steps
for achieving goals.
You want people understanding what
they need to be steering toward every day.
You want to build a culture that values
having effective processes.
And that's probably your biggest role in all of this.
And you want to let the team actually build and evolve them
over time.
That way they're bought in.
All of this is especially true when working
across time zones or comments.
The processes should factor in into the challenges presented
in the separation that's created here.
This makes it more concrete.
For example, you want processes for project planning,
agile execution, product release, UX research, testing,
and QA.
All of these things are really important to develop processes
for.
Number three, build a team roadmap.
So this is an internal roadmap.
And the number one goal here is to be aspirational and ensure
everyone on the team is pointed in the right direction.
This is not a roadmap that you share with customers.
It's only kind of a planning tool.
And it doesn't even have to be 100% accurate.
This is a tool to inspire the team about the future.
It's like a beacon or a lighthouse.
You don't want a team that is completely oblivious to what
the next year will bring.
To me, that doesn't sound like a happy team.
In addition, this provides agency to distributed teams
to make decisions.
And that's why this is so important.
It helps alleviate confusion or ambiguity
in what they need to do.
You often only have a couple of hours a day
in some cases where you're able to directly communicate.
So making sure they can make decisions quickly
is absolutely important.
Number two, document things.
The importance of this one is amplified tremendously
in teams that are distributed across time zones
or internationally.
Don't rely on storing information in people's brains.
For example, if you know someone on the team
is the only person who knows how to operate the software release
tools, this is a major red flag.
What if they were to leave the company?
Plan for attrition.
Plan for worst-case scenario.
And your job is to build a culture and behavior
on the team that values this and helps solve the problem.
And proper tools here, which we talked about before,
are really key to making this work.
Number one, create and adopt team norms.
This one is really important.
Create a charter of expectations for everyone on the team
and let the team define it.
Establish norms for mutual respect,
the rules for resolving conflicts.
Create expectations for how everyone on the team
expects to be treated and spoken to.
If your organization is bridging different cultures,
be really meaningful here.
Here's a great opportunity to include everyone
while defining this.
And this will help facilitate areas
where cultural differences could introduce
confusion or frustration.
Include expectation around meetings, tardiness,
respectfulness, and conversation and delivering feedback.
Include some norms around how to communicate
via email, chat rooms, code reviews, and other processes.
So I don't think anything here should be tremendously
surprising or revolutionary.
Most of it should be common sense.
But hopefully it will inspire you to work effectively
with your distributed teams.
All of these things are best practices
for even running simpler co-located engineering teams.
It's just that the impact of not doing them
becomes amplified exponentially when
dealing with engineering teams bridging long distances
and cultures.
It's a very challenging problem.
But working proactively to get it right
can pay huge dividends.
So with that, I will wrap.
Hopefully my presentation has been valuable for you.
And thank you for having me.
[MUSIC PLAYING]