And mine?

For me, my best experience of working with a team wasn’t an easy one.

We went through a whole load of potentially very disruptive changes during the 18 months when I was tech lead on that team - I’ll tell you about just a few of them:

About 30 people worked on the team at various times - it seemed that every few weeks someone joined or left the team.
- At the end of that period only I and one other developer had been there since the start
- Almost all of the people who joined the team were entirely new to the organisation.
We had numerous requests coming in for new unrelated big pieces of work, from lots of other external organisations who we had a responsibility to
- We said no to a lot of them, but we had to take on some, including several simultaneously at one point.
- And that was on top of support and improvement work on the 10 different product areas we owned!
Demands of a big migration project that other teams were involved in meant that we had to switch the focus of the whole team’s work significantly at one point to work on that

Change is often a good thing!

I’d like to be clear at the start that change is often positive! It gives us opportunities and variety in our work, and we frequently make deliberate changes in how we’re working in our teams and what work we’re doing.

The kinds of changes that I’m talking about today are generally ones that you and your team aren’t fully in control of - you might be able to influence them to some extent, but often they come from decisions that are made with not just your team in mind.

They may be positive in the long run, but at the time they can feel like a distraction to your team, and they can unsettle people.

There’s almost always some uncertainty involved - which might get resolved quickly or it could go on for months.

It’s really hard for organisations to handle these situations well, and despite best intentions from everyone involved, people often still end up feeling unheard and unvalued, or they aren’t sure where they fit any more.

So I’m going to go to some dark places here - but stick with me, there is hope :)

We can prepare for change

If you’re leading a team at the moment, I’ll help you cultivate some practices in your team and in yourself which will help you manage the impact of those inevitable disruptions, and work in ways which you can sustain through them to help your team adapt and move forward - and those practices will also help your team function better even when things are a bit more stable.

And if you’re in a more senior role in your organisation, I’d like you to consider how you can better value and support the relationships that teams have worked hard to build together, and by doing that empower your whole organisation to flourish and evolve.

I’m focusing on preparing for change rather than how to react to it in the moment, because the details are going to be different in each case.

Often you have very limited time to react and take action in those situations, while you yourself are also dealing with the emotions that come with them - so me giving a conference talk is unlikely to help you much then!

Don’t do it all yourself (you can’t)

Especially if you’re new to leading a team, it’s easy to feel that you need to be on top of everything, have all the answers, review all the pull requests, and prove that you’ve got what it takes to do everything that’s expected in that role all at once.

After a few months leading my team, I realised that no one else expected that of me - I was putting that pressure on myself, and it wasn’t realistic or practicable to do all those things myself.

By trying to be involved in everything that the team was doing, I was actually acting as a gatekeeper - a blocker to the team being able to make their own decisions and take ownership of their work.

And sometimes it was inhibiting me from delegating and sharing information, or asking for advice and support.

Instead, I learned to let go of some of those details.

You don’t have to own everything. You don’t need to have this all figured out on your own.

Build your support network

Leadership can be a lonely place, especially when you need to lead your team through some diﬃcult times. You need to know who you can turn to for support, advice, or just to listen.

Maybe that’s your manager, or another mentor, or your peers.

If you’re working with people in other roles to lead your team (such as product and delivery managers) then building strong relationships with them is really valuable for this.

One of the things I’ve found most helpful was a support group, where every couple of weeks tech leads from around the organisation would get together to share the challenges they were dealing with in their teams and help each other find ways forward, come up with things to try out or get a different perspective on the problem.

Find an approach that works for you so that you have a support network you can turn to.

Define a single clear goal, because focus is invaluable

If you possibly can, focus on one goal - it can be big and hairy, with no clear path yet to get there, but have a goal that you can articulate clearly and briefly, which your whole team is working towards.

In my team we’d spent a long time jumping between different pieces of work which were important to other people, trying to spread ourselves too thinly.

That constant balancing act meant that it was hard for the team to understand where our priorities lay, and so they couldn’t take real ownership of any of the work.

Eventually we decided that we had to stop splitting our efforts and focus the team on one goal. The effect of that decision was magical: it cleared a path for the whole team to be able to take hold of that big challenge and figure out how to solve it together.

We were really clear about what we were trying to achieve overall, and everyone in the team understood that. We agreed as a team which parts of it were essential to get done by the deadline, what else we’d like to be able to do, and where the dependencies lay between those parts.

And having that shared understanding of the scope of the problem and how we’d prioritised different parts of it meant that the whole team was empowered to make decisions constantly within that scope, to get it done. And we did!

Seeing the team take ownership of that challenge and how they all learned and grew during that time brought me a huge amount of joy and pride… How much?

Communicate your goal over and over again

Once you’ve defined your goal, communicate it often, at every meeting with other teams, with your own team, maybe even every standup - every day.

It’ll feel like you’re just repeating yourself and surely everyone is bored of hearing it over and over again, but do it anyway.

It’s always worth reassuring people that the goal hasn’t changed, or if it is evolving then the way you phrase it will bring people along and help you develop your ideas together.

You may not be able to define all of your team’s work in terms of one single goal - in my team we were still supporting all the other products that we owned around the edges of that.

But communication is even more important in this case: work out how you’re going to divide your efforts clearly, whether that’s by time, or people, or story points - then make those priorities clear to your team, and iterate them openly if you need to.

Add context to user stories, Use story kickoffs, Run workshops

When you’re writing up a user story or ticket for someone to work on, document the context you have on it.   You could use techniques such as story kickoffs to help the team agree an approach to a problem before someone starts working on it so that they don’t get as far as opening a pull request before having that conversation.   For bigger changes of direction, you may need to go further.

A few months later, our team was asked to change direction to work on a big migration project which other teams had been working on for a while.

The team were a little apprehensive about that switch - they felt they didn’t know much about the migration (other than that those teams had been finding it tough).

So I organised some workshops at the start to get the team more familiar with what the migration involved, and to help them put their bits of existing knowledge together and learn from people who had already been working on it.

That meant that the team had a shared base of knowledge before we started working on the migration properly.

Embrace opportunities for positive change

My team took on 2 new junior developers just at the point when we had a big deadline a few months away, and although we were really keen to support them as well as we possibly could, we also had some concerns about the impact of that change to the team on our ability to meet that deadline.

But in fact the changes we had to make in the team in order to support them were hugely positive for all of us.

We transformed our ways of working by being more explicit about our intentions and assumptions, and making it clear that the whole team is learning together.

We achieved more than we thought was possible in an incredibly collaborative way, with the whole team able to take ownership of the problems we were grappling with and solve them proactively.

Recognise that everyone is always learning

We’d had lots of new people starting, so everyone was trying to absorb context and figure out how things worked.

That made it easier for us to be aware of the importance of learning continuously, but whatever the situation in your team you can encourage that yourself as well:

Model the behaviour you want to see:
- you can make it ok for other people to not have all the answers and feel able to ask questions themselves by saying when you don’t know something and asking for help yourself
Make it clear that you value learning as part of everyday work
- it isn’t something people should have to find extra time for around their normal work,
- everyone should have the opportunity to learn in some way from what they’re doing already.

Write great commit messages, Comment on tickets, Keep your docs updated, Document your decisions

Writing great commit messages, detailing the why as well as the what

Adding comments on support tickets and user stories, making your progress on them visible to everyone as you go

Keeping your documentation up to date as part of every piece of work

When the team makes a decision, document the context and reasons for it - architecture decision records are great for this

Working in this way makes it much easier for new people to understand what’s going on and what’s expected of them, and to pick up the context they need to be productive.

And when people leave, it reduces the amount of information you need to download from people’s brains before they go.

I’ve often seen teams which have trouble getting things done when particular people are off sick/on holiday/in meetings all day.

If you learn to share your context frequently, you’ll be more able to keep work flowing during disruptions - treat those smaller regular disruptions as practice for bigger ones.

Use every piece of work to help someone grow

Look for opportunities to develop members of your team in every piece of work your team does.

Helping people grow isn’t something you fit in around the edges - it should be the default way of working, a core part of what you do.

So use the work your team is doing anyway to give people the experiences they need to become better developers and be able to take on bigger challenges in the future.

If you’re doing this as part of your team’s everyday work, then it’s easier to continue doing it during times of uncertainty.

You may be under pressure to reduce the amount of time your team spend on their learning and development when things are hard, but if it’s built into the way your team gets work done then you’re not relying on people taking time out in order to learn.

Show the team how their work fits into the bigger picture

Relate your team's goals back to the wider organisation goals frequently.

Show your team where they fit in the bigger mission, and how other teams are working towards the same goal, and why it’s valuable.

One of the challenges we were facing as an organisation at the time was how to properly support all the many products we’d built, and we were defining technical standards with the aim of making our applications more consistent and easier for us to understand.

I’d often refer to that wider challenge in team discussions, as a guiding principle - so the team could make decisions in their day-to-day work which were consistent with those wider goals.

And knowing about that push enabled the team to find opportunities for contributing to the standards and working with other teams on them.

Don’t over-insulate your team

There is some value in shielding your team from all the other big questions and uncertainty flying around the organisation so that they can focus on your team’s goal, but over time I think it’s more effective to share some of that context with your team.

If your team is completely sheltered from all of those potential distractions or other priorities, they might get more done in the short term but when one of those things gets through your shield it’ll come as more of a shock to them, a bigger disruption.

And that isolation means they’ll be less prepared to work on something else if they need to.

So mention some of these things to your team occasionally - they might have heard rumours already and it’s better to be able to discuss them openly.

Tell them what you’re doing to handle the situation if it might affect your team.

And tell people sometimes when you’ve said no to someone who wants the team to take on other work - it’s an opportunity to show why the thing you are doing is important and valuable and worth prioritising over other things.

Communicate your team’s capacity for change

Make sure that your manager, and other people who are in a position to make these bigger decisions, understand how much work it takes from everyone to build a team that works well, and the time it takes for people to become familiar with the domain they’re working in.

Understand and communicate to those people what the impact of changing the direction of your team would be - what kinds of changes do you think your team could handle at the moment, and what might be possible in the next few months?

Talk those options through with them.

These techniques that I’ve talked about will help your team continue to be happy and productive in the face of disruptions, but teams are never infinitely flexible.

I’ve frequently had to argue for not restructuring teams wholesale, but I’ve also been able to agree ways to shift my team’s direction to meet bigger goals while bringing the team along on that journey.

Grow sustainable teams for a sustainable organisation

A team who share their knowledge openly and collaborate constantly can handle people leaving the team, and are in a great position to support new people who join.

A team who see new challenges as opportunities for learning together and are trusted and empowered to take ownership of problems can embrace new challenges, and can make progress during times of uncertainty.

A team who understand how they're contributing to the organisation's goals and where they fit in the overall strategy, can more easily accept changing the focus of their work to support that goal in a different way.

People who have experience of defining problems and leading work, and have seen what's involved in helping a team run smoothly over time, are ready to lead new teams and contribute effectively when they move.

Senior leaders who understand the effort involved from everyone in building a team like this can make more informed decisions about changing the direction of the organisation.

An organisation which supports everyone to learn and develop all their skills, and values and nurtures communities, is more capable of growing and changing direction sustainably.

It’s even more important to empower people during tough times

Maybe this all sounds too idealistic, or impossible to achieve.

It does take work from everyone to start working in this way, and continuing takes deliberate effort and attention too.

Even if you’re working well together during normal times, when stressful things happen it’s easy for a team to default back to not pairing or communicating.

It can be hard to prioritise learning or empowering people when you’re under pressure and you don’t know what the future holds.

But that’s when these things are even more important - they will see your team through the tough times if you hold onto them.

Embedding these practices now and committing to them will enable your team to adapt to change together.