This post was first published on CoderHood as 11 Top Responsibilities and 10 Common Mistakes of a Technical Leader. CoderHood is a blog dedicated to the human dimension of software engineering.
On Leadership
Leadership is an art; this is not only a statement that I genuinely believe to be true, but it is also the title of an excellent book written by Max Depree. In his book, Depree gives us the following description of the responsibilities of a leader:
The first responsibility of a leader is to define reality. The last is to say thank you. In between, the leader is a servant.
These words echo in my mind quite often during the day. They have guided me time and time again when I felt unsure of how to add value. They also hold a profound message that can easily be missed: Reality doesn't just "exist," it is something that needs to be defined.
Reality needs to be defined because there is rarely only one version of it. You often have to choose a point of view, and you have to make that choice with imperfect information. Defining reality is taking gambles, making bets, and guiding others to do the same with you. You will never have all the information you wish you had, but you must make decisions nonetheless. As a leader, you also must take responsibility for them.
Lack of Leadership Is Painful
You probably had the unfortunate experience of being part of discussions where decisions needed to be made but where nobody had or took a leadership role. Those conversations are painful. There is always a lot of talking --- too much of it --- but the group rarely reaches robust conclusions. In the end, regardless of how much discussion happens, there are no concrete decisions or substantial grounds to forge clear plans.
In those situations, everyone involved tends to hand-wave or ignore the trickiest aspects of the problem. The group often leaves the conversation feeling uncertain about what to do. "Reality" in those situations remains undefined. As a result, time passes without progress; people go back to their activities without being aligned with what reality is; confusion reigns.
Without technical leadership, a group of software engineers is also left to guess what is a good example of technical excellence. Senior engineers might have formed their opinion, but junior ones need to see it in action. If nobody takes the lead, guesses are made, and guesses are often wrong.
The Role of a Leader
A leader is somebody who drives a conversation and is trusted to choose between options, seeing past the fog of uncertainty. To be trusted a leader needs to be known as someone who is right --- or at least not wrong --- most of the time. Also, he or she must make choices without making people feel forced into directions they don't believe. In fact, a leader rarely forces decisions on anyone.
A leader guides a conversation and ensures that an explicit version of reality is defined before a discussion ends. Or, at least, he or she must determine what needs to happen to reach that point.Â
AÂ technical leader also has the responsibility to define reality by showing a team how to excel in the context of a project. Setting a golden standard to emulate is extremely important for the success of a group. Without that standard, a group of engineers often ends up going in disparate directions and clashing.
The Role of The Group
When Max Depree says that a leader's last responsibility is to say, "Thank you," he is explaining that followers must feel in control. Leaders say, "Thank you" because they don't impose choices on their people; instead, they guide them to a path, and then thank them for the privilege of being allowed to be their guide.
Guiding a team means that a leader needs to have a plan in mind, and then steers the group toward its general direction. As the discussion unfolds, a leader needs to be ready to change the course of action as required, adjusting and refining it on the fly. The process of adjusting and refining is where a leader invokes the collective wisdom, constructing a version of reality based on it.
Building Lego Towers
I imagine the process of leading a conversation as something similar to the process of building a Lego tower with a group of friends. As a leader, you start making the tower with a plan already sketched in your head. You share your vision with your friends, and they work with you to realize it. They check with you before making changes to the concept, or when necessary decisions are needed. Your original vision changes as you work guided by the team's suggestions, the pieces you have and how things are going.
Throughout the process you keep everyone informed of what the vision is so that the team can tailor suggestions to the shifting plan. You help your people to organize the work in a way that allows everyone to be most efficient. The construction is a team effort, but as a leader, you get to take the course of action that seems most beneficial based on your expertise and experience.
You incorporate good ideas, and gently redirect anything that looks like a bad one. Eventually, you get out of the group's way when you see that everyone is marching in the right direction and the vision and goal are clear. At that point, you can choose to keep working or merely keep an eye on things. The final result is going to look different from your original plan; most likely a better version of it, forged by the collective wisdom of the group.
During the entire process, you don't tell people what to do. You give suggestions and remind them of the overall vision. You also define reality for them and try to stay out of their way as much as possible, helping to resolve issues and answering their questions. When the team finished building the tower, you praise and thank them for their work. They did it. You, mostly, served them.
Technical Leadership
Similarly to building a Lego tower, building software requires making decisions from the beginning to the end. The first responsibility of a technical leader is to define the engineering reality: What needs to be built, the general technical direction, an example of the golden standard for productivity and technical excellence, the business and technological context and the time and resource constraints.
That initial definition of reality is a starting point, and it is subject to evolution. The development team is an active participant in the process of shaping it. During that process, the leader must be available to answers questions, resolve problems and coordinate and synchronize the activities. The leader is a servant, and their goal is to ensure that everyone is working on the same version of a shifting vision and that the project evolves in a self-consistent way.
A strong leader must understand the technical details of the overall project. They do not have to make all the decisions, but they have to be familiar with them in enough detail to catch inconsistencies. A technical leader must keep a lot of detail in mind and must be able to see the current state of the work and how it aligns with the vision.
A technical leader must also have the skills to understand the details of the work the team is doing, and cannot fall behind.
The 11 Top Responsibilities Of a Technical Leader
- Defining reality. That includes providing a clear example of technical excellence and productivity for the rest of the team. The team should be looking at the technical leader as somebody to emulate and follow. Leading by example is crucial in software engineering.
- Maintaining the project technical vision clear for everyone, from beginning to end. When the team has questions about a particular project or a technical direction, the leader needs to have answers or ways to get answers. A leader without answers is a bottleneck.
- Keeping in mind most engineering details of a project or system.Developers building parts of a project must keep a focus on what they are doing. It is up to the technical leader to keep in mind the big picture and most of the high-level engineering details. Without that view, the team risks making inconsistent or even incompatible choices.
- Answering the technical questions that team or stakeholders have.The technical leader needs to help the team to stay focus. One way of doing it is by answering most technical questions coming from team members or external stakeholders. Answering the questions not only provides the proper flow of information, it also informs the leader of what is important in the eyes of others.
- Helping the team resolve difficult engineering problems. When engineers are in the middle of a difficult problem, they often need a sounding board for technical brainstorming. The technical leader should be naturally seen as the ideal candidate for such discussions and should be able to provide suggestions on how to solve engineering challenges.
- **Reviewing the decisions the team makes to ensure consistency and alignment with the vision. **As the keeper of the overall high-level technical knowledge for a project or a system, a technical leader is in the best position to ensure a consistency of direction. Reviewing decisions and adjusting them using suggestions and direction is a key responsibility for a technical leader.
- **Translating engineering realities into simple terms for non-technical stakeholders. **Engineers are knee-deep in the details of the code and should not worry about translating details into non-technical language if that doesn't come naturally to them. A technical leader needs to be able to provide such translation, adjusting the level of detail depending on the audience.
- **Allow the team to make progress by staying out of their way and protecting them from distractions. **A technical leader needs to fulfill his or her responsibilities and, at the same time, stay out of the way of the team. He or she must allow other engineers to be as productive as they can be by limiting needless distractions. This is a tricky balance that takes time to master and can definitely swing too far in either direction.
- Knowing team members strengths and weaknesses. It is a technical leader responsibility to know his or her players and understand their technical strengths and weaknesses. With that knowledge, a lead is able to farm out the work appropriately to the right people.
- Mentoring team members. A technical leader needs to be seen as a mentor for team members; somebody that can help other engineers improve and move forward in their technical journey.Â
- **Saying, "Thank you" to the team. **A leader guides people to a path, and then let his or her people do the work. When the work gets done, the leader must thank them for their efforts and results achieved. A leader who does not show gratitude to the team is not going to be respected in the long term by the team.
10 Common Technical Leadership Mistakes
I have seen technical leaders falling into some common traps. Here is a short list:
- Forcing decisions on the team. Engineering leaders should not act like tyrants. I've seen it happen many times with junior leaders, and it is painful. Pushy leaders who want to make all decisions tend to alienate development teams. People grow tired of it and abandon projects or even the company. Instead, the team must be empowered to make independent decisions guided by a knowledgeable and trusted technical leader.
- Not listening to the team. The quickest way to become an ineffective leader is not to pay attention to the voice of the group. Remember that, as a leader, you are a servant to the team and you must listen to the people that are allowing you to lead. Leadership is not a title that grants you power over others. It is a role you must deserve that gives you a central position in the design and execution of a plan. Listening to the people doing most of the work is crucial for success. If you don't listen to the team, you quickly become the problem, and the team will stop listening to you.
- Falling behind. A technical leader must have answers, at least most of the time. If they don't know how things work, their role is compromised. Getting distracted from a project for a prolonged period is a death sentence for a technical leader. It causes becoming too distant from the details to maintain the ability to guide decisions and the technical vision.
- Losing the trust of the team. An engineering leader needs to gain and maintain the trust of the team. When the team loses confidence, being a leader becomes very difficult and loses its meaning. Trust must be earned by being right most of the time, and by being always available to the team. That means that a leader must have had the opportunity to prove themselves in front of the team. That is one of the reasons I am not a fan of hiring technical leaders and why I am, instead, a believer in growing them from within the trenches.
- Waiting to have all the data before making any decision. This is called "analysis paralysis," and it is another death sentence. A leader must be able to make decisions, most of the time, with the information available. Always needing more information to make decisions is a sign of weakness and poor leadership. Always waiting to have "more data" is a slippery slope that prevents a technical leader to fulfill their function. Being able to operate in the face of uncertainty is the reason why experience is so important for a technical leader. "Having done it before" enables a leader to make decisions based on imperfect, incomplete and even contradicting information. Experience and pattern matching is can easily trump possessions of data.
- Not being available to the team. A technical leader must work closely with the team. A detached leader risks to fall behind and lose track of the details of a project. A leader that is left behind loses the trust of the team quickly. If members of the group cannot get answers from the tech leader, they'll make their own decisions with the risk of moving in the wrong direction.
- Being Misaligned With Executive Management. A technical leader who takes a path misaligned from the executive management is ineffective. Technical leadership must operate within the constraints provided by the company, on the route established by the executive group. Misalignment of technical direction from business direction transforms leaders into problems instead of solutions. Again, I have seen this multiple times and it always ends poorly.
- Letting Pride, Ego, and Narcissism Guide Decisions. When pride, ego or narcissistic tendencies start driving decisions, a leader is walking on a dangerous path. People can see it a mile away and eventually grow tired of dealing with it. There is nothing wrong with being proud of your work, but you cannot allow that pride to guide your decisions. As a leader you are a servant to the team and the company you work for; as such you need to put your ego on the side. Decisions must be made with the business --- that is, your customers --- in mind, and not because of your ego. When you were wrong, admit it. When your team disagrees with you, cherish it and listen carefully.
- Not Knowing Your People. As a technical leader, you need to know your players. If you don't see your people's strengths and weaknesses you cannot lead them properly. Pay considerable attention to each person's technical skills, the type of decisions they make, their collaboration style, who they get along with and who they clash with, their habits and behaviors. Know your players.
-
Giving a bad example. A Technical Leader must provide the golden standard for the team to follow. He or she should not fall into bad habits or destructive patterns. Some examples of things to avoid:
- Being sloppy and writing bad code.
- Not following agreed upon standards.
- Coming late and leaving early.
- Not finishing committed work.
- Fighting or ignoring the process.
- Fighting organization standards.
- Being a poor collaborator.
- Engaging in non-benevolent friction.
- Etc...
Top comments (3)
Very interesting article. It really resonated with me.
Ultimately the cardinal sin, in my experience, of technical leadership is loving the code more than they love the team.
If you love the code and see where (say) some data-structure or some technique or some framework would be awesome to implement you have to smile, kiss that idea, and hand it to the report who's going to grow the most by doing that work.
If you're chasing the fun, engaging technical shiny-thing and your report comes and says, "Hey, can I talk to you about ..." and you don't happily shut your laptop, pull out a pen, and say, "How can I help?", you're not being a leader, you're being a selfish developer (ooh, here i can do shiny thing and I'm the boss so I can do it! muhahahahah).
So many developers and incentive structures are not set up to compensate the right behaviors in technical leadership and that's a damn shame: much turnover, systemic bias, and wasted cash result from not understanding the proper behaviors. You've done a great job at sharing how to get one's head into a "service mindset."
Thank you for the kind words, and thank you for sharing your views on this very important topic. I agree with you about the very real issue of focus on code vs. people. Leadership is about people, not code.
Lorenzo, this is great! The words "define the reality" deeply touched me reminding of a situation where in complete uncertainty, if not misery, I did exactly that for the team, guided by my intuition, and turns out it was a good choice.
You went much deeper into describing technical leadership and I really enjoyed the read. Will bookmark it. Thank you!