In (agile) software development, the role of a lead, scrum master and/or CTO often includes “protecting” the team from various external “threats” or “distractions”. A development team often needs some help to maintain focus and efficiency in their work, but it is very, very, very easy to overstep the mark and end up (inadvertently) doing damage to the team.

In the past, I have ventured into each territory mentioned in the headline. Sometimes willingly, sometimes without even realizing it until much later in life.

Raising a shield and building a dome

In one company, leadership was so heavily involved in the product development process, that as the development manager/CTO, I had to act and start filtering all feedback, ideas and straight-up demands that were directed toward the developers in my team.

Is it worth it to deprive your developers of direct communication feedback?

So I became a human shield — soaking up all the bullets aimed at my overworked developer colleagues. Things got so hectic that I could barely do any actual constructive planning or proper team leading. This was not a happy place to be in.

After things had settled down a bit, I was still protecting my team from distractions — this time by forming a soothing, protective bubble around them. I was the one who was in all the meetings with clients, leadership, and partners… the list goes on and on. 

Yes, my team was busy, but they were also missing out on every bit of vital information about how to take their work further. Direct discussions and feedback from several different sources, especially from clients and end users, are extremely useful operational information.

You don’t have to carry the burden alone.

After doing this for some time, it became clear that things had to change. Luckily, the team was interested in trying out a new approach to doing things, but there was still a lot of work to do in order to deconstruct all the meetings and other process monstrosities I had helped to create in the past. 

I have seen this happen in several other places. Team leaders “carry the cross” in order to give their teams hope of clarity (and time), instead of having them all attend endless meetings. Yet, keeping them out of meetings can also be an efficient way of preventing knowledge-sharing, collaboration, and communication. 

A bridge over troubled waters

In one of my later roles, I was helping internal product owners get up to speed with their outsourced development teams, cope with the bureaucracy of a giant centralized ICT organization, and find a comfortable way to do development work in these awkward circumstances.

This forced a shift in my role, as well as my ways of working and thinking. I needed to be much more collaborative, communicative, and proactive. Most of all, I had to be a kind, knowledgeable, and approachable enabler who provides:

• Smiles and empathy

• Swift service

• Very concrete help with current problems, and

• Guidance to the next steps along the path.

Ultimately, I had to become a helpful and wise companion for the adventure of software development. I had to guide around and, if necessary, fight the perils lurking along the way.

In large organizations, it’s crucial to have enabler roles.

The first teams had to start pretty much from scratch, since there were very little processes or documentation in place. We had to bridge the gaps by first stumbling into them, and then just resiliently working to find a solution. And of course, find the people connected to those gaps.

As this had never been done before in the organization, it was a huge task with hundreds, or even thousands, of subtasks, but in the end, it paid off massively! Teams that had had no previous access to necessary documentation or people to help them suddenly found teams of specialists and their thought-out processes at their service. These could enable them to succeed by creating better services, and continuously improve their own methods of working.

This change of mentality and action made it possible to shift our ways of working on a larger scale into adopting more beneficial methods. Instead of one team at a time being in the onboarding process (spending months worth of development time and money in an endless search for the correct people to request access rights, petitioning for resources and development environments), there was a new, better way to do things. Suddenly, there were several dozen teams getting things set up smoothly and blazing through development with working processes and centralized templates instead of that old, endless and futile onboarding “process.”

While there’s always room for improvement — nothing is perfect — now, a constantly improving entity can both change and handle that change at a reasonably rapid pace. A much happier place, wouldn’t you agree?

Words of wisdom, or experience…

There are different situations and different types of people. At times it may seem necessary to wear a suit of armor, like Iron Man or some other superhero, and save the world, or at least your team. At other times, you may feel the need to shield your team, Under the Dome style. However, I advise you to think very hard about it and proceed with caution.

Encouraging your team, creating ownership, building bridges and enabling multiple ways to collaborate at a very low level of effort will take all of you a lot further. And with less personal workload in the long run. Yes, it can be difficult to start and pull through, but you can do it!

We are here to help you with every part of the journey, so you don’t have to figure out everything and reinvent the wheel, so to speak. :)

The words poured into this post came from my experiences and my heart.

Jukka Paldanius
DevOps Advisor

If you want to start your journey towards this DevOps euphoria, please be in touch! 

Let’s start with a DevOps Assessment and then continue the journey according to the findings from your assessment with a better understanding of all of your needs. 

Whether your organization needs advisory, coaching, training, or hands-on consulting services, we can work with you all the way and enable your organization to do more meaningful work!

Polar Squad — The Best DevOps Company*

*according to us