From Forming to Performing — High-Performance Teams

At the end of 2019, as usual, I thought about what happened during the year, and about the lessons we learned, no doubt the most valuable and intense was the formation of new teams. I’m being obvious here, but it’s important to point out that those new teams were created to deliver bold and urgent matters, in other words, the pressure and the expectations were high.

The Necessity to deliver new features and the teams’ formation are almost opposite forces, because there are some steps to create a team before it starts to perform.

The opportunity to create new teams with specific goals is really valuable, because usually, the team acts to pursue their goals. At the same time, it is very difficult and scary because they don’t know each other, what they like or dislike and how they will react when bad times come….

Based on that, I’ve written about how 2 teams formed by fourteen people have come about(Designers, PM’s, Dev’s and Me), and how we hit the stage of Performing.

A little briefing of what I consider Performing for a Software Development Team:

Quick interactions delivering small features to customers, learning with these deliveries, adjusting the bad outcomes and celebrating the good results week by week, also having good numbers of throughput and lead time, finishing with good feedback given by users. Adding to this, the teams’ maturity in a pro-active mode instead of reacting to the problems and dealing well with conflicts.

First of all, I’d like to suggest a content source to introduce the subject. There are some steps a team has to follow in this journey, and these steps take time to happen, we must respect and understand the time each one takes to go through it.

You can learn more about The Steps with Tuckman’s Model (Forming, Storming, Norming, Performing). You can also read Google’s research and article about what are the keys to create successful teams (Psychological Safety, Dependability, Structure e Clarity, Meaning and Impact here:https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/.

Stage #1 — Ready to Go

Before hiring team members, the PM and the Designer worked in the features that the team would work on. This kind of study has helped us to define the profile and how many people would be necessary to handle the work.

RD has a special onboarding, in the first two weeks of work RDoers start working on a project to better understand the concepts of Marketing and also to learn about the MKT platform. For 2 weeks, newcomers have access to an intensive Digital Marketing course where they are not divided by areas. Everyone works and studies together.

After that, the Area onboarding (Product and Engineering) begins, that’s the moment the leaders present the team objectives so that everyone is on the same page. Everyone knows what we are going to do, How, and most importantly, Why.

Once the onboarding process is finished, the next phase — the most important in my opinion — is Team Building, and it’s not so easy for us, because a great part of our team works remotely. Therefore, meeting and talking to coworkers face to face is fundamental to create empathy. (You can read more about it here https://medium.com/rd-shipit/6-hacks-de-performance-para-times-remotos-tdc-s%C3%A3o-paulo-2019-903f0318349),.

“The first Team Building was the most important because it’s when the team recognizes their power as individuals and as a group, working together, sharing their vulnerabilities and creating a strong connection between themselves. Besides, the mission gets out of the paper, the integrants define the execution, what are the responsibilities and the roles of everyone, what is expected of each role, what behaviors are not accepted and the main goals to the next releases. It’s the moment of understanding the impact for our users.”

Note that in this phase we have already gone through all the steps cited at Google’s article LINK. Now the real work starts and day by day we make alignments to keep the team focused on what has been agreed.

Stage #2 — Getting things DONE

Finally, the most important phase starts, when we put our knowledge and abilities in practice and release the first tasks. It’s also the moment to perhaps make some process and metrics adjustments.

We are using Kanban at RD to guide our software development practices, so every Monday we do a replenishment and alignment of the tasks we want to release that week, taking a look at the backlog if we need to dedicate some time to discover new items or to do a POC, to reduce the risks of a not well-known feature.

We have learned here, that we should respect the moment of learning because it’s when the teams get acquainted when the metrics are refined when we learn how to deal with our mistakes, how to brake and divide tasks; so the releasing result is less important than creating a sense of group, trust, and ownership.

Each new thing learned and each task done is a victory, and we celebrate it!. It’s important to look at the bigger picture and adjust the route every week, the whole team must be aligned and know exactly what we want to deliver.

Trust and clarity are the pillars to have velocity and productivity. It is paramount to have a motivated team, delivering frequently and quickly.

Trust takes time. Clarity is based on good communication every day, respecting the moment without pressure, but with bold metrics and process, and also a bold and SMART goal. Each member of the team needs to know their responsibility in all of this.

Stage #3 — Facing the first big challenges

Just like when you learn how to ride a bike or to drive, now that we are more confident, we take more risks, we accelerate, take hands off the wheel and sometimes we fall.

Some features have bugs, some are more difficult to finish.

People are now more confident, they try new things, innovate and contribute more.This is really exciting! When individual abilities emerge, when everyone wants to contribute, to participate, to decide, and to help do things in a better way, we get the motivation and power to do a lot of good stuff.

First of all, nobody should curtail this kind of initiative, because by doing this, you block innovation and possibly break people’s trust, they may be afraid to talk or act in the future.

It’s important to guarantee that everyone feels comfortable to make mistakes and to learn from these. Therefore, every week we talk about the goals and realign the main objectives and little by little we keep on track.

During the weekly 1–1 and at the retrospectives, individuals and groups are encouraged to give positive feedback to one another. The responsibility of leadership is to create space, to think about tools and activities to help this process happen, and leading everyone to make a good decision.

The result of this is that the individual grows and the group gets stronger. Obviously, sometimes, the whole group realizes that some members don’t have the fit for the team, so it’s important to map this scenario and take action.

Conflicts are normal, people want to deliver, to show results and to grow, there’s a lot of energy in one direction, a lot of knowledge is put into practice, but sometimes different opinions emerge, and high-performance teams need to deal with this and define a strategy to follow, otherwise it will be energy wasted.

A good point here, that I consider a Keypoint is that each individual has acted as a leader and made the discovery about a feature, therefore everyone has experienced a moment of glory working with other people to find a solution, and also have acted influencing the team with his or her ideas and dealing with different opinions.

Thereby the empathy created by the team, makes the process of team formation and development process much easier in giving directions and defining goals.

After that, we started to look intensively to our software development metrics and indicators and to notice some pattern deviation of what we consider good flow to delivering software constantly organizing ideas about what the best way to improve our deliveries would be.

We agreed that the best way is to put one Software Engineer to start with the PM and the designer to discover new Epic(features) separated from the delivery board. After he finishes the work, he presents this documentation to the team and comes back to deliver the tasks of development and also creating the new tasks on the backlog.

It is important to have a pattern of the size of the tasks in order to keep the previsibility. Also to put the whole team to work in every kind of task, to improve knowledge about the software legacy, close to customers and support.

Stage #4 — Evolving to next levels

Ok, we got to a point that the team starts to perform recurrently, positive results are more apparent and frequent. Everyone is happy and trustful, the customer feedback is very good. Paying attention to this moment, because the environment and the challenges start to change.

Changes are constant about product and process, new tickets arriving at the support, new customer needs, our satisfaction survey shows us that our customers need more and different things sometimes, also some people need to go on holiday and so on.

At this point, we come to a temporary halt and with these new variables, we rearrange on what, why and how we are going to solve this equation.

We created a mechanism where we can quickly react to changes, less fragile, but that encourages us to innovate, to define our boundaries and responsibilities.

At this point, the team manages itself, making decisions and being productive. Considering all that was aligned and also all of the things that happened to the team the previous year.

The feedback to one another starts to be more constructive and transparent because it is clear for everyone. The needs, the goals, the deadlines and why obviously the most important; what behavior is expected and what behaviors are not.

It is important to prepare and support the environment of trust and help the team to understand that feedback is a necessary thing to grow.

Stage #5 — Self Control

Here we are at the highest stage of a team, in my opinion, self-control. At this stage the team is connected with the soul of the company, they interact with other teams, with customers, ask questions about the strategy and try to define the roadmap together with the PM. They start to influence the future and become much more data-driven.

The team defines the product strategy, the process, the technology that we are going to use based on indicators, benchmark, the use of our solution and feedback (qualitative and quantitative) of our customers.

Each new situation is discussed and included as new learning to use at the next decision making.

At this moment the team starts to look for new challenges and initiatives, mostly cross with other teams, and also opportunities to improve performance, clarity, focus, and visibility.

As a leader I understood that what I needed to do is clearing the path, helping at the decision making, bringing more information about strategy and market as possible, helping to communicate and involve other teams and also participate in retrospectives with good questions to assure the way.

The second thing, momentum is more important than spikes, so when I talk about improving performance is to sustain the rhythm with little growth at the flow.