You have 1 article left to read this month before you need to register a free LeadDev.com account.
Hi Maria,
I’m an engineering manager. I’ve made sure everyone in my team is clear on their roles and responsibilities. However, things still go wrong when issues lie outside of those roles.
For example, a backend engineer noticed an issue on frontend but didn’t report it because it was not part of their job description. I’m sure there’s always a good reason, maybe they were not proactive, or stressed and couldn’t handle yet another thing.
Here’s my question: how can I foster an accountability culture where people would flag issues like this? I believe this shows up more at a team level than with individuals. I’ve seen people with a high level of personal accountability, but on a team level that doesn’t happen. What are your thoughts on this?
Thanks,
Sam
Hi Sam,
You have a dual challenge in front of you. On the one hand, balancing clarity with flexibility when defining roles, and a classic case of changing the culture of a team. This is really just a fancy word for describing the habits and usual ways a team does things. The bad news is you might face some inertia at the start. The good news is once you’ve built a new habit for your team, this inertia becomes momentum towards that new way of working.
Set clear expectations, keep space for flexibility
Creating clarity is always a good call. There’s a chance that role definitions have gone past clarity and into rigidity. This is where role boundaries are so fixed that folks on the team may not feel comfortable going outside of them, or even know that it’s expected of them. A common symptom of this is when the team feels like a group of independent consultants more so than a team of people working towards a common goal.
One way you could create clarity in this situation is similar to how you’d offer feedback to an individual. Explicitly say what you see, what the impact is, and what you’d like changed. Ask for feedback and input on how this happens. In your next team meeting you might observe that while execution on the projects is good overall, the team seems unwilling to identify bugs or issues outside of the direct track of work. Then explain why this is impacting the overall quality of the work, and finally, ask for ideas on how things could change.
Surface it in 1:1s
More like this
Alongside proposing it to the team, it could be helpful to bring this up as a topic in 1:1s. This is a good opportunity to dig into the reasons why it’s not happening in a psychologically safe environment.
I think your hunch is right that it’s not rooted in a lack of care. Typical reasons for not doing stuff includes not knowing it’s expected of you, or not seeing improvement after taking that action.
Some of the inaction you’re observing might be rooted in not resonating with the “why”. This would be a good opportunity to reiterate the good that can come out of your team keeping an eye on work outside their own sphere. They’ll help their teammates ship higher quality code, get feedback faster than a user noticing an issue, and also get the chance to see the bigger picture of what their team is working on.
This is also a good opportunity to set, or reiterate, clear expectations. It sounds like role clarity has been an effective tool in your team, so you could use it here too. Explain that it is an expectation to look for opportunities for improvement outside one’s main domain, especially of more senior folks, who are generally expected to raise the bar for everyone.
It’s your role as a leader to ensure you act on whatever input comes up, both in a group and in individual settings. If you hear that the team didn’t know where to raise these issues, make sure there is a place where they can, in a low-friction way. If the feedback is that issues aren’t prioritized when they are raised, ensure there’s at least a discussion about these issues in the future, so that people see that the time they spent on raising something was not totally wasted.
Model and recognize it
Depending on how committed your team is to changing at the start, you might see some change pretty soon. Make sure to recognize and reinforce it when it does. Make a point of thanking people, and make sure it’s included in any feedback or performance reviews.
Think of ways to also model the behavior, especially at the start, or if you sense there’s confusion remaining on the specifics. In cases where you yourself spot a bug – or something that needs doing that doesn’t neatly fall within your responsibilities – show that you took the time to log , and include it in a prioritization discussion.
It might take a while
We’re all creatures of habit, and some changes are harder than others. Both as individuals and as teams, we fall into patterns that can be hard to shake. Stay patient and gently but firmly keep nudging the team towards how you want them to work. Remember to always include the why, make it a conversation rather than an announcement, and constantly remove blockers to it happening.
Do you have a work challenge that you’d like some additional perspective on? Submit it here, and it might feature in a future column. All submissions are edited for anonymity.
