content/posts/2016/2016-05-17-dealing-with-change-in-teams/index.md
---
title: "Dealing with change in teams"
cover: "https://picsum.photos/1600/800/?image=389"
date: 2016-05-17 21:44:49 +0200
category: "tech"
tags:
- Mindset
- Relationships
- Productivity
---
> It's sad when people leave because bonds are formed but we can't stay in the
> same environment and position forever.
I had a bad experience. I once joined a team that had pressure from all angles.
Fixed deadlines, unexpected and sometimes last minute scope changes,
responsible for numerous front-end websites integrating into a highly sensitive
service that we had to maintain and was audited regularly.
Mistakes in the entire flow could cost production companies millions and
people their jobs.
The biggest problem with this team was the high staff turnover. Within a few
months of joining, developers started leaving; one month after the other. When new
people joined the team, they were completely new to the company which made
ramp up time a nightmare.
It wasn't just the developers who left. People from all roles either left or
were rotated to other teams. Everyone was looking to me for answers to
questions I couldn't give. I struggled to keep up with all the changes as well
as ramping up.
This was hell for me. I thought I caused people to leave. It turned out that
the team always had a bad reputation for change but knowing that didn't help.
I needed a survival guide.
## Social change is inevitable
People come and go. Opportunities present themselves and people want to grow.
This could be to upskill in a different team or company.
Unfortunately many developers migrate within the first two years
at a company to explore different types of domains.
Learn what you can through team members and wish them the best when they
move along. Don't create the perception that you are the problem.
## You're not responsible for everything
Don't take on the responsibility of everyone who leaves. You will only stress
yourself out and end up with insomnia.
You could share the responsibility with the team for a short time while
someone is ramping up. Know that you should push back more. Get business and
line managers to figure things out together.
## Expectations need to be managed
As people leave the team you need to start
[managing expectations](/blog/manage-expectations) with your line manager and the
Product Owner. Offer trade-offs or alternatives. Explain in non-technical
terms why you can't achieve this now.
## Relationships are essential
If you are consuming data or features from other teams, or dependent on their
rendered services then it is essential to find out who they are and what they
do. Start talking to them. Building strong relationships with people help you
solve problems quicker and exposes your to different parts of the business.
## Ask when you need help
If you don't know what is cooking, put up your hand and say "Yo! I am clueless
here. Who can we talk to?". (_Maybe drop the "Yo!" if you want to be more
professional._) Get the right people together and talk. Figure out problems
together.
You might not always get the right people together but it gets better the
more you familiarize yourself with the people, products and business. This also
makes life easier when you rotate to a different team as those relationships are
already built.
## Communicate suggestions
If you find flaws or processes that hinder productivity in your team,
and you have suitable suggestions to improve, communicate it to the appropriate
channels - your team, line-manager, HR or head of division. This could be as
simple as how people are ramped up.
## My final thoughts
Change in a team will happen. Hopefully never as drastic as what I experienced.
It's sad when people leave because bonds are formed but we can't stay in the
same environment and position forever. We want new challenges and
new experiences.
Dealing with too much change at any given time is exhausting. Productivity will
be affected. Push back and manage expectations. Remember to breathe
and don't be afraid to ask for help.
### Side-note
That team has now been split into two. One for the front-ends and one for the
service. They have a separation of concerns and have split the workload and
level of responsibility. Both teams are more stable than before.