Build a leader habit: Empower people around you.

A good leader has an impact on the team they join.

They don't bring anyone down, they don't lower standard but they make the effort to show the way, possibly the better way. I've seen over and over again engineers clinging onto their knowledge convinced that's how they remain valuable to the team or the company. I have news for you, it only works short term, it harms your career development AND damages team dynamics.

Although we might feel better about ourselves being the "go-to" person for specific things within the office, we might risk to become the only person available for it, at all times. This means that you get stuck or pidgeon-holed into that role. This has two major drawbacks:

1. Eventually you might get tired of always being the go-to person for the same issues/tasks. It feels great in the beginning but it becomes tiring in the long run.
2. It can hamper your career development. If you're the only one able to solve a specific issue/task, why would the manager want to move you to a different team/role/project ?

How not to get stuck

There is a quite simple solution to this.

There's a theme you'll see across many of my posts. And it's the answer to a simple question which varies based on the context you apply it to.

What can YOU do to improve the current state of things ?

How can you change the situation without relying on external factors ? While some of you might be lucky enough to have a supporting team and a great manager, we are engineers at heart so we need to consider the WCS (Worst Case Scenario). Although we hear this mostly when it comes to solving algorithmic problems, it definitely applies to many real life situations.

Here are a few things you can do to "get unstuck":

1. Write incredibly good docs

I wrote about this in the past here, it definitely applies to the situation discussed as well. Some of the best engineers I had the pleasure to work with, were absolutely great at writing detailed-enough docs.

This means solid Readmes where all you had to do was follow a few steps. Explanations of the whys more than the what. Any team member should be able to be up and running by simply reading the docs and without any further need for communication. This liberates you from being the sole reference for a project and empowers other engineers to use or contribute to your work.

Writing docs is always a good idea, even just for your future self. So you have a dual benefit:

• You empower your future self enabling them to pick up where you left off
• You empower junior employees by showing them how things work passively (with docs).

Passive mentorship is a good starting point, but that's all it is. A starting point. So keep that in mind.

2. Automate what you can

Especially in 2020 I'm all for automation. There's so much out there to help you out, it's quite incredible. Even posting on my personal blog is now automated with a scheduler.

This can be quite useful for repetitive tasks. Instead of manually running a database query every 2 or 3 days a week to generate a report, automate it! Generate a report every day and save it somewhere where others can analyze it easily. On top of that, apply (1) again and document it all. With this you solve two problems at once: reports are automated so nobody needs to come ask, the automation is documented so other people can help fix any future issue.

• You empower any other engineer by allowing them to pick up and possibly fix a task you bootstrapped.
• You empower members of other teams by making sure they have the data they need at all times.

3. Teach and spread the knowledge

If you become the only source of truth for a specific piece of knowledge, you'll always be the point of reference. This ties well with my other post (Learn how to let go), where I suggest that a good leader knows when to let go.

That precious piece of knowledge can grow even more if you let other people nurture it.

Share what you learned. You are a lead so you don't need to be afraid that some specific information is what keeps you in that position. I have NEVER seen a leader lose their credibility or position by sharing most of their knowledge with their peers.

• Empower people around you by showing them the ropes. Help them acquire some knowledge faster. It'll enable them to contribute sooner and become an integral part of the team.
• Teach as much as you can about projects, company past failures or what you learned in the past/present.

I always found the last one extremely valuable. My goal has always been to elevate juniors as fast as I could by sharing everything I know about specific topics. My intent is to bring them up to speed so that we can have a 1:1 conversation about any technical topic.

I remember spending quite some time explaining how state management works in React in great depth. Then showing the good and bad of Redux and how to use it effectively. Within a few weeks I was able to discuss with other junior devs how we should go about handling a complex feature, letting now them tell me how they would do it. This was only possible because I filled the gap in their knowledge by sharing and teaching them what I knew.

Conclusion

There is no reason why you, as a lead, should keep your knowledge secret. We've seen how beneficial sharing and empowering team members can be. From a more self-centered perspective, it unlocks your growth. From a self-less perspective you allow the team to grow. That sounds absolutely great on all levels!

Be the type of leader who brings the best out of people. Their growth is your growth!

👋 Hi, I’m Gabri! I love innovation and lead R&D at Hutch. I also love React, Javascript and Machine Learning (among a million other things). You can follow me on twitter @gabrielecimato and on GitHub @Gabri3l. Leave a comment if you have any questions, or send a DM on Twitter to say hi!