Mixing leadership, delegation, and accountability
When we start growing and moving through the laddering of promotions or switching teams, we start experiencing different types of leadership from diverse perspectives.
When referring to leadership, every company or I dare to say even teams within the same company, defines a level of accountability and delegation, that suits them better.
Rarely appreciated, this plays an important role when defining responsibilities. And, I believe it’s quite important to define and draw a line between accountability and delegation.
What’s what
Wait! Before we get immersed in the topic, let me try to clarify things a bit.
In my appreciation the one in the leadership team is the one accountable, responsible, and who owns the problem (or whatever other subjects), meaning that if something unexpected happens, although it’s a team responsibility, it will be mostly on that person's back.
Once that’s defined, in bigger groups where responsibility is shared, we would have some level of delegation depending on how flat the company/team is, just to name one possibility. This means that, for example, in flatter companies, responsibility for decision-making, the team is expected to get more involved.
But where do we draw the limit between delegation and accountability? Who should be the one making the decisions? Do I trust the team to leave the freedom to make decisions to something that I am accountable for? Is it only a matter of trust and experience? is it just a reflection of the sense of having control? If we go to the other extreme does it mean we are gatekeeping information?
As you can see, things are starting to get mixed up, that’s what I regularly see on teams when responsibility is shared, and this definition is not discussed or clarified beforehand, in some sort of team agreement or even an informal discussion.
So let’s rephrase and put it in one sentence, although the responsibility is shared, there will be always someone accountable in the laddering of management and leads if something happens, even if that needs to bubble up to the CEO.
Management has changed
If we go back in time and think about the old days, we might probably end up in situations where the hierarchy was defined in stone and hardly challenged by others.
Times when speaking out to managers, or being called “bosses” back then, were regularly seen as a lack of professionalism. Or maybe, we just thought it was impolite, as I, at least, tended to believe they were not interested in knowing about my feelings or opinions.
Fortunately, management has evolved into something different, and we now can find places to follow other ideas. Yet not ideal, but better than the old days.
What I am referring to as the new management is where team members feel more engaged and empowered, and take responsibility for success as a group effort. In a team where suggestions matter, responsibilities fluctuate across the team and communication flows up and down with not much restriction or friction.
There are, of course, levels of interpretation, on how deep we want to go with delegation. We can ask for feedback and then the leaders will decide, or just let the team decide and the leader just agrees on it, just to name two extremes. That is exactly the level of delegation that for me needs to be stated somewhere, whether it's implicit or explicit, to avoid misunderstandings in the responsibilities scheme.
Usually, failures are probably the biggest trigger that forces us to think and set up a balance in the delegation levels we have during post-mortem analysis.
Situations that by setting and preparing ourselves in advance could be avoided.
From another angle, the premise "we are in this together", is easy to break, and can fall apart when recognition comes into the picture. Who’s going to take the credit? Ideally, this shouldn't be the most important matter, but it can break the trust and commitment of the team if only the one accountable takes the prize.
Things are not always that simple, another problem I have seen with delegation is that leaders or managers, put pressure on the team, with the excuse of “we are flexible and modern”, just to prevent them from making decisions and being exposed or finger-pointed by others. Which slowly turns into a lack of alignment, trust, commitment, etc.
Eventually, when you become a leader or manager (you name it), what took you there should be your mantra, not suddenly changing your spectrum and becoming what you normally hate.
As a side note, I have noticed that in the IT world, most managers come from engineering backgrounds. I am not saying that they don’t have the skills but it’s funny how they can change career paths and become a senior manager in 1 year, and in most cases, that change is based on wishes over the skill set, myself included.
To highlight this topic, I sometimes use the word meritocracy to define that path we have to discover, but as it’s currently misused, especially in politics, I heard a replacement in a song that says that smooth seas never made a good captain which seems to emphasize how I experience things more elegantly.
The confusion between accountability and delegation
Within that transformation, certain misunderstandings can cause a team to fight for the wrong problems or get lost in the processes.
We can all agree that there are different types of managers. But just making one segmentation between the ones who like to have everything under control and the ones who like to delegate most of their work, there is a balance that needs to be defined.
Ownership in the sense that I take responsibility, I trust you to move this forward, but I can't expose or blame you if in the end this never gets done.
It’s the manager/leader's responsibility to make that happen, so that is exactly the point where I see the gap between accountability and ownership. I do agree that managing and measuring success as a manager is difficult. But as it’s a matter of delegation, it doesn’t mean it’s your responsibility now, and I (as manager) am out of the picture.
What have I learned?
Enough about exposing the issues, what can we do?
If I were to become an engineering manager now, I think I just know what I wouldn’t do. I only have a little experience as a Product Manager, but back then although there was a lot of stakeholder management, I had no reporting lines coming to me.
Even considering that I just came back to coding, I do see myself in people management over something purely technical. Or at least that is what I have been told by former colleagues and my vision and preference.
Having said that, what would I do if I got into this situation?
- Build an environment where there’s no such thing as pressure or rush. I know that's difficult but If I can absorb that and abstract it from the team, I will.
- No room for egos. A place where people feel comfortable sharing experiences and opinions. Where introverts are not afraid to share, and the ones with imposter syndrome can open up.
- Transparency overall. When I know what to do or not, whether I am lost or not, the team will know about my feelings, and if I ever feel overwhelmed or incapable of playing the role, I will be the first one to admit it.
- Not playing the blaming game, whether we win or lose, we are a unit, but if something goes wrong or expectations are not met, I will be the one to blame and take action to make things better.
- If I ever have a strong opinion about someone’s career path I would ask in advance if they are looking for ideas or a piece of advice from me.
- I would define expectations, and responsibilities by roles together with the team, and reflect on them from time to time.
Unfortunately, as with most of the human problems in industry organizations’ schemes, there’s no such guide we can follow. I based my recommendation on my experience from the other side of the fence.
But, just asking ourselves and clarifying the questions I have shared across the article, could lead to a better understanding of scoping the responsibilities accordingly within our environment.
Written by Manu
I am a product-driven JavaScript developer, passionate about sharing experiences in the IT world, from a human-centric perspective.