In this episode, Dave and Jamison answer these questions:
\n\nOne and a half year ago, I joined my current team as a tech lead, in an organisation that uses \u2018Scaled Agile\u2019. This was my first time joining an organisation that employed dedicated Scrum masters. In previous organisations, the role of Scrum master would usually fall upon a team member that felt comfortable doing so, and the last couple of years that ended up being me. I feel this worked out well and I managed to create teams that were communicating well and constantly iterating and improving.
\n\nUpon joining the team, I noticed that despite having a dedicated Scrum master, the team was not doing sprint reviews or retrospectives, and it felt like every team member was on an island of their own. In the months that followed I tried to reinstate these and improve teamwork and communication, but often felt blocked by the Scrum master\u2019s inertia.
\n\nEventually, they were let go and a new Scrum master was hired. This new collaboration did also not work out. They didn\u2019t have enough of a technical background to engage with impediments, were trying to micromanage team members during Standups, and would continually try to skip or shorten retrospectives. If retrospectives were to occur at my insistence, they would try to determine actions without the team\u2019s input, only to not do them and never look back at the outcome.
\n\nTwo months ago the new Scrum master was let go and I was asked to take over their duties in the meantime. Ever since, it feels like the team finally owns their own Scrum process. Our collaboration is not perfect, but we\u2019re finally tracking measurements, evaluating retrospective actions, and iterating as a team. However, the organisation wants us to go back to having a dedicated Scrum master. I\u2019m not against this, but I\u2019m afraid the next Scrum master might undo our efforts. How do we as a team navigate this situation to get an optimal outcome?
\nA listener named Max asks,
\n\nI\u2019ve been working in a Data Engineering department at a mid-size product company for over 5 years. When I joined, we had a well-balanced team in terms of average proficiency - some juniors, some middles, and a few seniors. Over these years, we\u2019ve developed a great internal culture where people can grow to a senior level pretty easily. The company itself is wonderful to work for, and we have a pretty low \u201cchurn rate\u201d - most of my colleagues are highly motivated and don\u2019t want to leave.
\n\nAs a result, we now have only senior and staff engineers in the team. This is well-deserved - they all are great professionals, highly productive, and invaluable for the company, having domain knowledge and understanding of how all our systems work. Management wants them to take on only senior-plus-level tasks, which are usually larger projects and initiatives that involve a lot of collaboration with other departments, process changes or technical initiatives affecting our engineering practices. They have two reasons for this: 1) management doesn\u2019t want to waste the time of such skilled professionals on smaller tasks; 2) management cares a lot about people\u2019s morale, because losing them would be very harmful for the whole company, so they don\u2019t want people to take on small and boring tasks.
\n\nAt the same time, we have a HUGE backlog of tech debt, small improvements and refactoring initiatives. Ideally, we would hire 3-4 additional middle and junior engineers to share all backlogs with them, but we now have a hiring freeze. The amount of tech debt is starting to damage team morale on its own, and I feel like we have an unspoken deadline to deal with this problem, which could be someone\u2019s burnout and departure, or a major outage in some vital services we support caused by ignoring tech debt.
\n\nHow would you approach the problem of overseniority? I appreciate any advice, and thanks again for the show.
\n