Technical leaders have a challenging job. We look to these leaders to make decisions, mentor developers, lead meetings, and tackle the most difficult problems on our projects. These leaders are often considered the “best” developers and are placed in leadership positions because of consistent performance in the face of challenge. However, while technical leaders have many roles and responsibilities, they also have an arguably more important responsibility to enable those they lead. I’m just not sure we know what that enablement looks like.

A “10x developer” is a developer that can do the work of ten other developers. In our community we’ve decided that having one person who can do a magnitude more work than others is great, but making another ten developers twice as effective is preferable. While highly skilled developers offer a lot of value, leveling up teams offers more to the organization. A team of developers is less likely to leave, performs more consistently, and is generally easier to work with than a savant.

Should we be looking at leaders the same way? When we think of leaders, they are the ones making decisions at almost every level. We drive these leaders to personally take on many of the problems that organizations face. Instead of bearing full responsibility, leaders should focus on enabling teams to be capable of making the right decisions.

Stages of Growth

As a college graduate, I was hired and placed on a small two-person team with my lead. We were responsible for a critical piece of our company’s system and a dozen other subsystems. I spent months learning each subsystem to the point that I could look in the right place when answering questions or debugging issues. This was a period of major growth for me.

I remember the stages of this growth. In the beginning, I would ask too many questions to the point that my lead gave me the 15-minute rule: “If you are trying to solve something or answer a question, spend 15 minutes looking for an answer before you ask me about it.” This was some great advice and it helped me to learn more than just getting an answer from him would have taught me.

Another growth point happened when a new member joined the team and the lead asked me to help mentor. I remember the feeling of elation realizing that my experiences had taught me enough to be able to explain our responsibilities. It was also around this point that I begin taking on night shifts and responsibility for responding to production issues that occurred during the evening when the office was empty.

The final stage of this growth occurred after my team lead transitioned to another team. Almost a year had passed and the team had grown to 5 members. It took him coming off for me to realize that, while he was providing a safe environment for me to perform, he was limiting my ability to finish growing within the team. Even though there were times that I had to work through problems and answer questions on my own, I was still working very closely with my team lead. When they transitioned off the team, I was finally able to finish my growth.

What is enablement?

Enablement is the act of providing a positive sense of empowerment.

My experience of growth came from my technical leader providing a consistent safe space to learn, fail and grow. Once I’d grown and learned enough, it was by giving me more of my own space outside of the shadow of their control that allowed me to accelerate my growth. By learning to answer my own questions and solve my own problems I gained experience, ownership, and agency. As my team lead transitioned to another team I was able to grow further and replace him as the technical leader of my team.

Junior developers lack this experience thus far and as they get more experience they can get stuck in a “junior” role because they haven’t been enabled to be anything else yet. They haven’t been given enough opportunities to work on difficult tasks, talk to stakeholders, or mentor others within a space they can grow. It then becomes difficult to continue to learn when leaders don’t enable those they lead by handing off responsibility. We all learn to confidently solve problems by developing a history of solving problems and having a history of growth builds on that confidence. That positive empowerment is enablement.

What can leaders do?

Leaders will understand when there is time for mentorship versus coaching. Sometimes the organization needs a time-critical feature and the best way to accomplish it, given someone with growing skills, is to coach them through it. When there isn’t as strong of a focus on expectation delivery and performance, it’s a good time to focus on mentorship. There’s a balance between the two that will both provide growth and help this person find confidence working within the team.

Occasionally leaders will say, “I think one of the best ways I can help enable the team is to do the uninteresting work no one else wants to do.” I agree with this, not because someone has to do the uninteresting (yet still important) work, but because developers need a space to innovate to be enabled to grow. It’s too often leaders are focused on solving hard problems rather than helping their teams solve those problems.

An easy way to get started building shared empathy is to schedule a regular one-on-one. In these meetings a leader and a developer can sit in a room and talk openly about what they need from each other. This type of candid conversation is really vital for building empathy and ensuring that neither party becomes overwhelmed.

Technical leaders are responsible for the growth of their teams because they’re often the only ones who can enable that growth. By reducing the transition cost between making decisions and being able to rely on their teams, leaders can not only be more effective but they can also spend more time making high quality decisions. It’s becomes somewhat easier for these leaders with teams helping out rather than trying to be a famed “10x leader” who can accomplish everything themselves.

What can developers do?

The individual is the only one who truly understands their own context. Because of the sheer number of things that are often involved in each new role in development it can be difficult to tell what it means to be ready for the next role. Comfort level is a good factor as well as how at ease the current role feels for a developer. If it’s too comfortable, then maybe it’s time to grow.

Establishing goals and communicating these goals helps to establish context and drives effort for both parties. A leader can act as a mentor to guide those who work under them toward the things they pursue. A level of transparency is important here so that the leader understands why these goals are important to the individual. The communication of these values from the leader will also inspire confidence in the developer that they are being led in the right direction that can enable them.

Volunteering and delivering on responsibilities is a clear sign that someone is capable in their role. This is a great way for a developer to get positive attention and show a willingness to grow their role and learn. Additionally, building tools and services that can communicate what the developer is capable of helps to highlight potential and interests.

Asking questions is extremely important. Quantity is not the goal, but asking good questions that get at fundamental understanding of an interest. Learning when to ask questions at appropriate times also helps. Questions can help communicate interests and help communicate where there might be misunderstandings or struggles. Understanding both of these can help leaders and teammates to best help the developer to accomplish goals and overcome difficulties.

Be aware that leaders are trying to do the best they can to juggle many responsibilities. Show respect and empathy for the responsibilities and position they hold. Someday, some of their developers will be put in leadership positions. Hopefully new leaders will be thankful for the lessons learned and prepared to enable others in the same way.