Imagine a well established development team in a product company. They have their issues but they have been good at reaching their goals for the last couple of years and are growing.
Their leader receives a new opportunity and moves on so the company fills the role after a long search. This is not a new problem that a company has to deal with and team leader transitions are very common in our industry.
How you approach this transition period is where the rubber meets the road and will make or break your new team.
Trust goes both ways
Trust is an incredibly powerful and fragile thing. Trust in a team is like a foundation of a house, built to last through natural settling of the environment surrounding it. If it's strong enough, it could last through disasters like earth quakes and flooding and still provide a level and secure structure for the house to stand on to provide warmth, comfort and safety.
When a new leader joins an established team, this foundation gets rocked. It's inevitable. A new person that fills a leadership role usually gets hit with a set of requirements that they have to fill at all costs. These costs are high.
I can imagine it being hard to balance the business requirements versus the established team processes and comfort. I can imagine it's a tough ask to keep on shipping value to customers and employees when such a fundamental change happens within a team. This presents an interesting set of problems. That is why, as a leader, it's your responsibility to ask the right questions.
Ask the right questions
"If scrum is the answer then you are asking the wrong questions" ~ @markkirschstein
Earlier in the week I saw this on Twitter and it resonated with me. I have worked in places and heard stories from other colleagues where this has been their truth almost every time. I am not prepared to comment on the usefulness of scrum or even the non-usefulness. There has been many a post on that topic.
In this context, when a Manager joins a team, there is a correlation between an over-the-top and bloated set of processes and a Manager's need to bring order and control to a system. A Leader would take the time to step back and observe this new system. This is the perfect time to observe a week or two in the lives of the team. How they work together, how they ship together, how they interact. By inserting yourself into their processes and asking the right type of probing questions you can immediately see where the pain points are and where stress is being generated unnecessarily. By this time you would have had a talk with the executive of the business and you would understand their pain points and sources of stress and you have context of the problems.
A Leader understands this and a Leader understands that both the business and it's developers want the same thing. It's your responsibility to balance these things by stepping away from the team first and acknowledging their work by speaking with the team about it. It's also your responsibility to reassure the business that their problems are heard and that a plan is being created and will work but only with their help. The developers are, in this case, the experts on their domain and you need to Trust that they know what they are talking about.
The first couple of days leading into weeks should be a context gathering and question asking exercise where the minimum amount of current working process disruption occurs. Pulling people into an open air (public area, around the coffee pot type of discussions) discussion about the work would make a great way to gather knowledge of how things work but more importantly, What is painful?.
The current working process, albeit painful or frustrating, is not going to change quickly. The faster everyone realizes that, the healthier the team will be and the better the adoption of changes will become in the end. Ship what can be shipped, Pair with stuck people to help them get Unstuck and try be as anti-hype as possible. There is nothing like hype to set the worst set of expectations and pile on a stupid amount of stress at the end of the day. Look at the video game industry for perfect examples of overhyped changes. You can't pre-order a collectors edition set of solutions for your team, so stop over-hyping it.
What is Painful?
"What is painful?" is a simple question to ask everyone on your new team. What comes after painful ... can vary from person to person. You should keep an open mind about what comes after the painful part because that is an incredibly vulnerable time for any person to talk about their pain points. Calling it a
one_on_one actually cheapens this opportunity to connect with a person and might stop them from opening up about the things that do bother them.
This is a good time to understand, with empathy!!, what the people on your team is going through and the type of hoops they have to jump through to get work shipped. You will also immediately see which people are introverts and which of them are extroverts. You will also get an understanding which of them prefer Depth vs Breadth type of work and who are the natural leaders. These are usually the first people you try to lean on when talking about the pain points because they will have a natural ability to see the problems people are experiencing in the team as well as the technical problems.
Now you have a list of things you can take to the business. You have a foundation to work from and a starting point to create a plan. Note that some of these problems might be perceived problems and some might be actual ones and it's your responsibility to distinguish between these. A Leader should have that skill because it underpins the essence of instilling emotional safety and trust in your team members and also satisfies the business anxiety over hitting their targets.
From what i've seen is that MOST misunderstandings and issues root from anxiety over not knowing what the outcome is or what to expect. ex:
- Business: We have no idea when stuff ships, and when it ships, it breaks and we have to fight fires.
- Leader: Send out a weekly email that distills the changes in a week and shares the priorities for the next.
A very simple email to all stakeholders that speaks about what shipped, what is being worked on and what is upcoming is sufficient enough to stem a large amount of anxiety. This is something you could implement in an afternoon without disrupting anyone. You do not have to be a rockstar and promise the world to be a super successful leader. Especially taking over the reigns of an established team, your vision should be to have the most boring transition ever because your only goals in the first few weeks are to:
- Build trust
- Reduce anxiety/stress
- Build context
- Get people unstuck
Notice how I am not saying aim for the low hanging fruits. I never liked that saying because it implies that you shouldn't reach for the juicy goals. There will be obvious initial wins that you can help with but a Leader knows that having patience will actually speed you up in the future.
Slowly introduce change
Do not steam roll your idea of a perfect system into your team. I cannot stress this enough. You undoubtably will have great ideas, especially after spending time with the team but the change needs to come from them, with your guidance. If anything, the pain points the team mentioned would also be the driver for change because they would be enabled to pick up the change they want to see. This moves you from actively Managing people to a Mentor/Coach role. Your hand would be in those projects and the business would be made aware of what they can expect but it's your responsibility as the Leader to make reasonably available whatever resources a person needs to accomplish their task.
The reason I touch on this point is to realize that inertia is a real risk and problem you have to actively be aware off. To get going is usually the hardest part. Something I see very few Manager's try is to build momentum. This means breaking new things up into shippable parts that add value. Also stopping on stuck things for a relook. A skill you should build as a Leader is to not fall into the sunken cost fallacy. It's okay to step away from something and start again. It is also okay to throw stuff away.
Momentum is the definition of slowly introducing change. This will build over time and you will realize that the types of conversations you have with the people in your team will change. Slowly changing gears also allows more people to become more confident in their abilities as they grow with the work they do. After a while you get to leave them alone to do their thing.
Share war stories
Make time to share your war stories. Stories drive imagination and a skill you should have as a Leader is storytelling. Sharing what happened "that time when you shipped a thing production and then it broke but we fixed it in this way" is an incredibly powerful way to share ideas with people.
War stories are not something you come by easily though and being in a team where you have the scope to make mistakes and not get fired for it is something that you should take note off. If you want your team to be able to perform under dire circumstances and use creativity and luck to get themselves out of something broken or bad then you as a Leader need to provide that environment.
Everyone talks about culture but no one can make a list of cultural things to put into place to ensure this happens. You can force people all you want by making cultural things mandatory, but no one will truly stand up and do the thing. No, this is a much more subtle shift in thinking. This happens without the need for it to happen and grows organically in a team, when you get out of the way.
When you get out of the way you are enabling your people to do the things they are hired to do but on their terms and with their capacity and creativity. If you as a Leader give someone the ownership to something, you will see some amazing things happen. When you get out of the way you start to have capacity to tell stories and nudge behavior. Sure there will be fires and times you have to jump in but if you give a person the opportunity to do the right thing, most of the time, if they care enough, they will.
Have you ever tried to build a house by yourself? Yes it sure is possible if time and money is not an issue but mostly in Product Development you do not have that amount of time or budget to do it by yourself. You have to rely on your team, specifically your more senior(established) people to come up with these solutions.
Your responsibility as a Leader is make sure everyone stays on the straight and narrow and by asking the right questions you can poke holes in proposed solutions.
It has to come from the team.
There is little that beats a cross functional team that flows on a problem together. It's a force to be reckoned with. If you let it, with enough presentness and listening, even a varsity graduate might come up with a multi million rand idea in cost savings because they felt safe to do so.
Your role becomes different here because you are not actively managing people. You are coaching them, you are mentoring them and you are training them on the spot. By being a pair-er, conceptually or hands on, you have an incredible view into what is actually happening.
You get to give a deep set of context to the people that are taking on a problem and you can help train their thought patterns, in small increments, while doing the thing they have taken ownership off. This does not remove the responsibility from you to make sure that what you put out there is good and working. In fact the buck does stop with you.
With this way of working, you are leveraging multiple brains instead of one and that is more powerful than you can imagine.
Shout if you need anything
I don't think there is a worse way of interacting with your team than saying this at the end of meetings or stand-ups. First of all there is no reason to shout. Manager's actively encourage people to stay quiet when they do this. A Leader's approach would be more subtle. Because of the regular time together with a person, you would have great insight into what their pain points are or what is getting them stuck.
Getting people Unstuck! is your day to day responsibility. It is really that simple. When a person is stuck, they are stuck because they do not know where to go next. By putting the responsibility ball into their court, you are actively aiding them to remain stuck if you pass the buck by saying:
Shout if you need anything...
The level of frustration and anxiety increases because you are not taking responsibility for their leadership or mentorship. Sometimes it's really just a simple thing to show them a utility class that already does a thing. It could also be a small part of the context that someone mentioned in a meeting once but never wrote down.
By actively spending time with people more than once a week, you could help them through or over obstacles by giving them something other than anxiety and fear. You can give them confidence. By giving a person confidence, they will pay it forward next time to someone else in the team.
Your goal should be to change the types of conversations in your team. Instead of asking where something is? or how long before it ships?, isn't it better to talk about what value it will bring? or if it's worth doing it? You do not need to actively manage to death every single thing. I believe that every consenting adult in a workplace, that they chose, should be allowed to self manage and choose the problems they solve.
It is your responsibility as a Leader to facilitate that regardless of role or level. It is your responsibility as a Leader to manage their energy and get out of their way. That is where motivation flows. That is where people wake up, come into the office/online and do their best to move the needle because they want to make a difference.
- (Youtube) The rarest commodity is leadership without ego: Bob Davids at TEDxESCP
- (YC) How to Be a Good Technical Lead?
- (Youtube) Why do so many incompetent men become leaders? | Tomas Chamorro-Premuzic | TEDxUniversityofNevada
- (Youtube) How To Be More Productive
- (qz.com) Now is the time to implement the flipped workplace at scale
Cover photo by Takanori Nishikawa