What is Technical Leadership

A Technical Lead has the responsibility to help the team move forward. The person assigned to the role, is someone who has sound technical experience and strong communication skills. He or she will be accountable for the technical direction of the project or product and serve as the go-to person for cross-team interactions.

What

When it comes to medium to large teams it is quite common to have a full-time Tech Lead present, responsible for important leadership activities such as

Guiding the project technical vision.

Eg. what technology are we going to use, how are we going to deliver the project, what patterns will we use, etc.

Analyzing risks and cross-functional requirements.

Analysing risk means mitigating risk: can we chose a certain approach or does it have too many unknowns.
What will the impact on the project be when taking a certain risk. Eg. introducing new technology you saw at a conference.

Coaching less experienced people.

You most likely will have mixed experience in your team. This makes a lot of sense when it comes to cost of a project, mixing and matching skills and experience; thus educating less experienced people.

Bridging communication between stakeholders and the team.

Business stakeholders are often less technical in nature then developers. They will use a different language and the Tech Lead will need to mitigate that.

Do we need a Technical Lead?

Some people argue against the role; claiming a team of well-functioning developers can make decisions and prioritise what is important to work on. Even when these perfect conditions would exist, during which team members talk to each other openly, discussing pros and cons before arriving at an agreed solution, it doesn’t take much to upset this delicate balance.

The Tech Lead role is just that – a role. Instead of focusing on whether the role should exist, it is better to focus on ensuring all Tech Lead responsibilities are met. As with every leadership position, a bad leader can make things worse. With these tips I would like to help you to make sure that doesn’t happen.

Two sides to a story

As the job title implies, Technical Lead is a job with mixed responsibilities: there is a technical and a leadership side to the story. I will share tips for both sides, although the distinction is not always clear. It is very unlikely these sides will be equally divided. More on this in Tip 4.

1. Advocate for Change

Change

Advocate for change, means installing a mindset of positive evolution. When a proces is slow or cumbersome … try to turn that around and make it better. One way of doing this, is by using OODA loops: Observe, Orient, Decide, Act. More information on OODA, can be found in this earlier blogpost.

In order to observe slow or cumbersome processes correctly, it is important to be part of the team and experience the same pain as everybody else on the team. You should adopt a state of mind that continuously wants to improve a certain situation. The Japanese call this “Kaizen”. In our case, the situation you want to improve is the efficiency and happiness of the team and the delivery of a software project.

Seek out the issues that prevent good teamwork.

2. Work through Failure and Success

Things will fail

Things will fail. Don’t worry too much about failure. Builds will fail. Deploys will fail. Schedules will be missed. Crashes will happen. If you prepare for failure, it will be easier to cope with it.

When things fail, don’t look for someone to blame. You are the Tech Lead. Take responsibility and use your energy to fix the problem at hand and learn from it. Of course, don’t fix the same bug twice. If you need to fix the same bug twice, then you made a wrong decision.

Learning from failure, will shape your orientation and make for better decision-making in the future.

Celebrate success

When the team has a sense of achievement, they will be happy and motivated, to be the best they can. It’s important to celebrate smaller achievements, like a successful sprint or a completed feature. I did a project once, where we delivered a system and the customer was really happy with it … Unfortunately, the vision of the customer changed, and the project never made it to production. If that’s the moment you’ve been waiting for …

When someone comes up with a new idea, maybe an approach or framework they saw at a conference, and if the idea delivers, it is important that whoever came with the new idea, should be credited. This is very rewarding and will lead to more cooperation, creativity and out-of-the-box thinking.

A drink on Friday evening, a small lunch, maybe a team building are all good ideas to get a happy and motivated team. Oh, and it’s fun.

3. Stay Technical

A Tech lead has a lot of non-coding responsibilities, but it is very important not to neglect the hands-on technical activities:

Write code, do proof-of-concepts, define interfaces, … Depending on the maturity of the team your involvement will be different.
Do code reviews and have your code reviewed. When new people arrive at the project, I tend to do most of their code reviews and I will be pretty strict: I will write tests that cause NullPointerExceptions, I will ask them to adhere to conventions, to use the Single Responsibility Principle, to be careful about packaging and naming, etc etc. I will also elaborate on the reasoning for these remarks and for the choices that were made. This might challenge existing ways of working and increase the maturity of the codebase. The number of changes they have to do (after a review) will quickly become less.
Insure a technical vision exists and is shared by the team. This vision needs to be in line with the customers needs. Customer needs will lead to important constraints, eg. regarding reuse (a throwaway project for marketing vs. a multiyear enterprise endeavour … but be aware that this type of constraint might also change). Sharing how you got to this vision with your team, will have theyhuge impact its adoption. Try to involve the team to arrive at the technical vision. And make sure they know how they contribute in reaching that vision.
Keep an eye on the evolution of the code: after a while, the amount of actual coding you do might be lower, but you need to stay up to date on the evolution of the code. You need te maintain awareness of the system and its technical constraints.

Most (if not all) developers will be happy to define frameworks, to advocate certain methodologies, etc. But some non-functional requirements (also called quality attributes) such as networking, security, deployment and consistency are often overlooked.

4. Always Available

Time Management

As a Tech Lead, you should always be available for your team; for questions, for support, for guidance or to make decisions. I started this blogpost by saying the technical leadership role has two important aspects and combining these is never easy. Something that makes a lot of sense (for me) is writing down the amount of effort you expect to put into certain tasks, eg.

Technical design: preparing work for the team (that includes you). Making sure it is clear what needs to be implemented and how. This will often take a lot of quality attributes like networking, security, … into consideration.
Business: talking to the customer, looking at their needs and goals and matching these with the technical vision of the project.
Project Management: defining user stories, estimating, follow-up.
Code: writing code, doing code reviews, etc.

The assigned percentages will obviously vary for everyone and for every project. It’s also important to look at the actuals, because these will help you understand on what you are spending time.

5. Be a mentor for your team

Mentor

Mediator: A Tech Lead should be a mediator, that facilitates discussion. When people have different opinions, you should embrace this. Because it means they care enough about something to discuss about it. In the end we work towards the same goal. Everybody can learn from the opinion of others. Get input from the team and try to reach a consensus. If reaching a consensus is really impossible and a decision is necessary, decide. Not deciding will always lead to more discussion.
Mentor: A technical lead should be a mentor for developers. Be a teacher. When you review code or when you explain certain conventions, be sure to clearly explain the reasoning why you are doing something in a particular manner.
Effective Delegation: After a while, your team will adopt certain best practices and less (strict) reviews will be necessary or more people will do reviews. That’s the point where you can also give ownership of user stories to more developers. By transferring ownership to developers, they will be highly motivated to do a great job. A tech lead should not try to own all of the responsibilities. The tech leads needs to make sure responsibilities are taken by someone.
Match goals: match the individual goals of the developers with the larger goals of the project and the organisation. This is specifically targeted dynamic coaching. Dynamic, because goals can change. Communication is very important when it comes to matching goals: it will make people feel valued.
Optimise for the group: Individuals in a team are extremely important, but when it is difficult to find consensus, it’s the team you should focus on. Teams that collaborate well, will perform better and members of a well-performing team are happy members.

A good Tech Lead

knows when to give input
knows when to make decisions
knows when to step back and allow the team to take more ownership.

Share responsibility, give ownership … but stay accountable.

6. Surround yourself with other Tech Leads

There are many reasons to surround yourself with other Tech Leads. On a personal level, it presents an opportunity to learn from your peers: how do they provide input for their team and how do they divide their time between the different responsibilities of the role. On an organisational level, you should verify if there is a clearly understood overarching goal. If this is the case, you might want to investigate whether cross-organisational coordination is required to meet objectives. It is important to keep track of architectural guidelines to make sure your product will play along nicely with other components and to make sure the larger system is consistent. Chances are there will be dependencies on the product of other teams or on the members of other teams. Make sure these are taken into account when composing a sprint.

This kind of coordination is a genuine problem at many (larger) organisations or customers. Investing time in networking, is necessary to avoid surprises beyond your control.

7. Think Big, Bias for Action.

Think Big and Bias for Action are two of the twelve leadership principles at Amazon. Thinking big, means creating and communicating a bold direction for the project or the product. This will inspire results, because people are working on something big. Something that makes a difference. Focus on the opportunities that might arrive in the future. Make decisions that are not limiting. An excellent book on this, is Liminal Thinking by Dave Gray.

A Bias for Action means acknowledging that many actions and decisions are reversible and don’t need extensive study. Getting things done … matters. When you put a flywheel in motion, it will keep rotating. Focus on simple things to get the flywheel to move. It will encourage people to deliver as initial hurdles have been taken.

8. Interviewing potential new team members

Know what you are interviewing for. Are you looking for someone for the longer term or are you looking for someone for a short assignment? When you look at a resume, look for patterns: eg. duration of an assignment. Does this match with your needs? If it doesn’t, make sure you ask the candidate if he or she has certain preferences. Some people like long-term projects, others don’t. This does not have to be a blocking issue. But it is something to talk about. Also look at used languages, libraries and frameworks. Do these match with your current choices? When you are looking for a long-term team member, experience with certain tools is less important than the will, ability and eagerness to learn. I always try to focus on the mindset of a developer: thinking logically, identifying multiple approaches to tackle a certain problem. Personally, I strongly discourage using Stack Overflow to find questions. It is more important to ask questions that are relevant for your project. My personal pattern for conducting an interview is as follows:

Comfort
Offer options
Build on the responses
Show interest
Bonus question

Of course, always, stay polite. If the candidate doesn’t match with your specific goals, don’t send them home with a bad feeling.

Beware: we still will need to get things done, even when we don’t have the time, resources or influence to fix the team composition.

9. Embrace cultural differences

Diversity is invaluable. All people are different and live different lives. This is incredibly valuable, because your users will also be different. Surround yourself with passionate people.

Nowadays most (if not all) teams use some kind of instant messaging. When working with teams in different time zones, this becomes even more valuable as it enables asynchronous communication and broadens the potential answers. I mentioned this before: everybody is part of the team and everybody’s opinion should be valued.

10. Estimating is hard

Douglas Hofstadter

Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Estimating is hard. When you do it more often, you will get better at it … but you still will get it wrong from time to time.

In agile projects, the entire team can participate in a planning poker meeting. Planning poker can expose unknowns when estimating a user story. In general, there are two approaches to cope with these unknowns: doing a technical design before starting with the user story (eg. by defining a spike) or accepting the risks, together with your business stakeholders.

As a technical lead, you will likely also need to do estimations before the team is actually building something or when responding to RFPs (request for proposals). This can be to give business stakeholders an idea of the potential cost, to decide on priorities or to evaluate staff.

To achieve this, I suggest using three point estimates, where you do an optimistic, a best guess and a pessimistic estimate and use this formula: (O + 4BG + P) ÷ 6 to get the weighted mean. Depending on the nature of the estimation, the number of unknown unknowns might be large: the project can be very similar to other projects or completely different. Factor these in. Estimate for the team that will do the implementation: you are probably estimating a real project. This is not the fastest time you can possibly do something, in the best possible conditions. The estimations represent the ability to execute for a team; not your ability to do the implementation yourself. Also make sure, you know your deliverables. This can be more then code and deployment artefacts, eg. code quality assurance reports, manuals, …

Document assumptions.

Mastering estimation is a lifelong journey. It will set you apart. And your colleagues will associate you with professionalism, stability, and quality work.

11. Interfacing with the outside world

Cats

The language used by non-technical stakeholders might be very different then that of the development team. A Tech Lead must find a way to communicate ideas in ways non-technical people can understand. Eg. by using analogies and using terms others can easily relate to.

In a DDD world, this means establishing a ubiquitous language.

Work closely with customers, try to detect requirements from them and continuously map their requirements with the on-going implementation.

As a technical lead, I don’t think you should be the Single Point of Contact. Because then you introduce a potential liability in the project: a strong dependency on you. Include your team in certain discussions, but make sure you prevent continuous interruptions of your team members … So don’t be the Single Point of Contact, but try to be the First Point of Contact.

12. Facilitate (agile) team work

I would urge all Tech Leads to facilitate agile team working. Of course this works better, when the business is involved as well. But even when they are not involved, assign a proxy product owner. Chances are, this will be you.

It doesn’t really matter if you use scrum, kanban or something else, but aim for short development cycles, feedback loops, etc.

Conclusion

Your team’s strength is not a function of the talent of individual members. It’s a function of their collaboration, tenacity, and mutual respect.

If you’d like more information on Technical Leadership, you can check my slides on SlideDeck or this video on YouTube of my talk at Devoxx.