“Would you follow a Navy Commander on troubled waters if all of his experience was only based on books or painting boat decks combined with his lack of empathy? Probably he would be better off painting boats” – Ricardo Moreira

The above applies to technical Teams, where it is very usual having Leadership without any hands-on experience, lack of empathy, and use of “power” (they imagine having) over respect, inciting “fear” rather than providing a safe environment to the team.

Usually, these kinds of leadership are the ones that try to keep the spotlight over themselves rather than to the Team that actually does the work, or in less than ideal scenarios they will be the first ones pointing the finger at the Team if there is a problem. The outcome of this can be catastrophic not only to the Team but to the company itself as it tends to be toxic. Team members don’t feel enough motivation to innovate or to raise the working standards, rather feel they are there just temporarily until they manage to find something else “better”.

You can say, but aren’t there HR, evaluations, and procedures in order to prevent this from happening? So, my answer will be, is HR ready to understand the mindset of techie Teams? In some companies yes, others not really, and others are just trying.

Shifting left is not something exclusive from Operational and Development Teams, it’s something that should be a priority to all the Teams involved in a given project, that applies to HR, Security, Business, Architecture, Testing, Development, and Operations… when this happens you can say you correctly shifted left!

Shifted left done. So now how can we continuously measure/assess the performance of the team in order to know if we really are a high performant Team? Shall we pick the right KPIs then?

Does it really exist, the magic formula of one fits all KPIs? Shall I blindly apply what I learned from any given Agile framework, or any other framework and transpose “ipsis verbis” to any Team? – No and No!

Experience,  Teamwork, and proper collaboration within the Team will guide you through the process of defining and deciding the right KPIs for your team, as a team.

Don’t mix KPIs with SLAs or metrics! Use KPIs as an affirmation of the Team’s performance against the value that the Team is delivering, assuring that everyone from the Team knows and accepts those KPIs as their own. Do avoid at all cost KPIs being defined by someone else apart from the Team that is actually working on the solution, there is no such thing as X, Y, or Z being the owner of the KPIs because the owner of those KPIs need to stay with the team.

But then you rightly ask, what about KPIs that are chosen to be the standard on a Corporate level? Of course, we need to track those, as they are the perspective or the point of view across business, but don’t solely rely on those to be the identifier of your Team. The Team itself should add the most relevant ones that can capture their performance and quality of the value deliverable.

Shift left, check! KPIs, check! Team composition?

Another very common topic that can jeopardize a high-performing Team, is having the wrong people doing the right jobs. For instance, how often do you hear the following:  You don’t need a Scrum Master; Why is the Product Owner choosing and deciding technical implementations? The architect team/person doesn’t know more than drawing a few boxes; RTE is speaking with the Team as a “big boss” or even deciding KPIs on behalf of the Team…

There is a big difference between wannabe and honesty, skill set, and transparency. What I mean is everyone has talent but don’t try to pretend you have experience on something you clearly don’t have, the outcome can be disastrous. The Team feels it, as inappropriate, even if no one will tell you on your face or complain to the management. But without any doubt, it will reflect on your KPIs if you set it properly as described previously.

If it doesn’t reflect on your KPIs, inevitable, you will end up with the blaming culture, rather than the “we can do” mentality in collaboration. Topping up, if you don’t stop it in time it will push your best Team members to find something else to do somewhere else, ultimately leading to the perpetuation of failure.

Having the right people doing the right job is important, assume that everyone has a talent just waiting to be potentialized on the right role!

Last but not least, remember the Team that everyone is important and there is no such thing as Scrum Master, RTE or whoever, having more important or that they are “the managing positions” of the Team, that is so wrong in so many ways!!

The Team is a Team, all together, all accountable for the success and the failures as a unit. No one is special and everyone is special at the same time, and there needs to be zero tolerance for any kind of abuse or assumptions of power (this last one it’s a very common pitfall that should be avoided at all cost).

My suggestion here to anyone that really has the role of managing people in anyways would be Respect: you don’t need to befriend everyone, but treat all with respect, learn your limits and accept that you can fail as well. Recognize your own mistakes with the Team and show/lead the way of improvement.

Now that everything is set and running as expected we should take attention and monitor close the following less positive signs:

• Lack of Transparency, Team not being completely honest about a given subject
• The team not accepting or taking well external inputs from other Teams
• The use of “I” too many times, rather than “we”
• Team living in their own bubble
• Team or anyone part of the Team that thinks they are the guardian of a special segment of information
• Making excuses rather than proposing solutions
• Blame someone else

Now that I summed up and demonstrated in a very, very simplistic way the complex world of High-Performance Teams around people first, followed by process, let’s sum up the tools.

So, what are the right tools for the job then?

To start with, there is no such thing as an ideal tool for the job! And have in mind that every day a new tool is launched into the market. With several options to choose from, where usually what is “free” has its own limitation when we try to scale up to our Enterprise level requirements.

It is important to assess the real added value to the overall solution for any tool and technology. Assess the innovation risk factor and the effort that any team will need to expend in order to learn or improve their knowledge in any given Tool.

For example, we have a small project, is it worth it to go to a full-blown CI/CD tool out of the shelf? What is the value to the overall project? What is the future impact in order to avoid any technology legacy dependency? How much will the support and maintenance overhead cost? Do we have the right skillset?

All the above questions must be addressed inside of the Team with all the stakeholders, as any decisions from it will definitely make a huge impact on the overall success of the project, therefore everyone needs to understand the choices and be committed to the Team selection.

No matter the choice the Team does, never forget to forecast maintenance or underlying infrastructure that will give support to any chosen tools. The mindset of any successful team lays on good communication with everyone and the right mindset to automate everything, even if that means automating emails (who never?) and be flexible.

These are the principles that I use in any Team under my management, where I make myself part of the solution and creative process alongside the Team, and not relying on being just another backlog manager.

Article written by Ricardo Moreira, DevOps Manager, Vodafone