Dev Manager/Tech Lead - Is there a place for them in Agile teams?
Image from https://miro.medium.com
A situation and my strategies to address this
As more and more companies are starting their transition to “working Agile”, there are some important factors to consider. Most managers have to balance what they have learned about traditional organizational structures, with what enables good teams to become great in this new way of working. I find that even if organizations commit to being Agile, middle management somehow has not grasped the Agile Values and Principles. They happen to completely miss them in setting up their people and environments for success.
Before proceeding to read further, let’s remind ourselves of the below Value(s) and Principles of Agile, since these apply directly to the situation I discuss below.
Value: Individuals and interactions over processes and tools
Principle: The best architectures, requirements, and designs emerge from self-organizing teams.
Principle: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Principle: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
For one year, our team was independent, equal and relying on ourselves for architecture and technical decisions. The team was comprised of 100% independent contractors, save the Product Owner. We achieved great recognition for our quick decision making, resolving complexity with ease and being superstars while doing that. In 6 months’ time, this team had done 2 major releases, comprising of 1 pilot and 1 national rollout, of a self-serve business account open web application. We discussed everything as a team, and acted as one on executing our decisions, in our respective roles. We built 60 micro-services and integrations, 17 re-usable APIs, and a low resistance front end that only required 9-11 minutes for an application to be completed, when it used to take at least 30 minutes to fill out the required information. It was a thing of beauty. We did all of this without even once drawing a full solution architecture diagram. It was just white boards and a clear understanding of everything we were building. We did that with virtually no bugs, highly available system, with a complex set of rules that worked as expected and no solution architect or development manager of any sort embedded or dedicated to the team.
All of our managers didn’t get in the way, and supported us wherever we needed them, without hesitation. Isn’t that nice?
By the end of the calendar year, for various reasons, 85% of the team members were either no longer on this team or had left the company to work somewhere else.
On top of that, due to organizational changes, our product and team was moved to roll up into a Transformation program. Most leaders would say, the reason this, capital “T”, Transformation was funded, was because this team could accomplish such marvellous feats, and it showed confidence that this group within the technology was capable of delivering business value.
Since we were now part of this transformation, a reporting structure had been mobilized to put things in place. An Engineering Director was now assigned to us, who would help us to make strategic decisions and we could consult them on our solutions, if need be. We were jubilant, because one of the first things this person did was draw our solution diagram by extracting it from our memories. It was amazing to see what we had built in just six months and how complex it actually was.
Now, this Director was to support 4 teams (3 on the same product, 1 separate) of coders under him (say about 25 people). He felt that he could not possibly manage all the coders in these teams, especially the full-time ones, just by himself. The process and time it would take for year end reviews, career growth and other HR related things, would just be too large and he felt that he wouldn't get any time to work on the engineering strategy for these teams. So he hired Development Managers/Tech Leads for each one of his teams. In addition to Tech Leads, he also placed at least 1 full timer on each team along with independent contractors to complete the teams. Makes sense right?
At first, we thought this was really good, in terms of retention of knowledge and continuity of any product/application. The premise was, contractors could come and go, but the full time staff would still retain knowledge and become the experts in their respective products. Also, these tech leads would be fairly experienced and senior people, so they would help us improve our engineering practices and help surrounding Release and DevOps teams help us remove technical impediments faster. Sounds great right?
Turns out, this dynamic developed into every team member feeling like they now report to their Tech Lead, instead of just being a member of the team. It may have something to do with the way this person/role was introduced to the team members. Unfortunately, as the Scrum Master serving the team, I was not consulted or part of the positioning of the role within the team. Especially, since I too was a contractor. This completely changed the dynamic of the team by reducing individual engagement to problem solve and investigate more information for solutions. Additionally, it impacted how much direct communication/feedback they were having with each other, because it started to either go through me, the Scrum Master, or the Tech Lead. We both started to get involved in every small or large conflict there was in the team. We got along most of the time and were on the same page about most things. However, sometimes we happened to be at odds with each other and the confusion it caused for the coders really demoralized them.
My dear friends, this is a serious anti-pattern I happened to come across multiple times in my experience. Each time, it has been detrimental to the team’s autonomy, sense of ownership and responsibility. For 2 months (4 sprints), we were trying to recover our peak velocity, overall motivation, team engagement and focus with this new team. It took about 2 sprints and retrospectives to completely reverse this behaviour/dynamic in the team to create an environment of autonomy, fluid communication and ownership of the work within each individual.
My strategies for addressing this:
Deliberately and consciously involve and address the team for everything, instead of putting it on the Tech Lead to the have the answer for everything. This needs to be an internal commitment for the Scrum/Flow Master. We must bring in other relevant team members into discussions and not just consult with the Tech Lead.
Tip: In Sprint Plannings/ Backlog Grooming and other discussions - Always evenly distribute your eye contact among team members. Don’t just address the Tech Lead.
Tip: Ask questions like - “What do we think?”, “What other ideas do we have?” “Is this making sense to all of us?” - These questions invite other voices to be spoken
Share other questions and tips you can think of, in the comments below
Have a direct conversation with the Tech Lead about his/her role. They are the same as other team members, not above or below anyone else.
Tip: Ask if viewpoint conflicts with the direction they have been given. It’s very possible, as in this case, that the person themselves understand that the dynamic is harmful to the team, and that their managers put these expectations and defined the role in this manner.
Tip: Don't make it personal.
Have a conversation with the Engineering Director/ and managers above them about the impact of this structure. In some cases, they are also held responsible for the collective code quality, issues, successes and failures for the team. This is very harmful for that person and affects their behaviour in the team. Be cognizant of this and address it head on.
Tip: Work with them to consider re-defining the role for “tech leads”. Part of the problem is the mandate set out for the role.
This may be similar to some of your experiences. I thought of sharing mine, for the benefit of helping us identify these anti-patterns in the future and learn from each other. Agile practices focus on giving teams and individuals ownership of their work and accountability to the team and organization, so that you can care to make things better.
“Unless someone like you cares a whole awful lot, nothing is going to get better. It’s not.”– Dr. Seuss
