Just now found this awesome description:
The “tech lead” role can be treacherous at times. While the name implies “leadership“, most of the times it doesn’t come with implied authority like a manager role for example. It often happens that this role is in a no-man’s-land where it brings a lot ofresponsibility but not enough formal authority. In order to successfully help a project from this position one has to navigate through narrow and convoluted straits.The role is not clearly defined in most companies and it is placed in a continuum starting at the senior programmer level and extending to architecture and management positions.
Set yourself up for success
1. Define early on what success means for you, the team and the business
You have to have a clear idea of what you want. You also have to understand what team members and the management want. You also have to be aware that what people really want, what they say the want and sometimes even what they think they want are very different things. Try to be very honest at least with yourself. Success has different definitions for different people. If there is a big disconnect between these definitions you have a problem before you start.
2. Believe in the project: idea, architecture, time, team
You cannot have any kind of success if you are convinced you lead a team of morons to implement a stupid idea using the wrong architecture in a ridiculously short time. You have to really believe in the project to have a chance to success. This does not mean lie to yourself. It means do whatever you can to understand your concerns and work on them with the management. As for the architecture, it is best if you have a heavy word or if you are the architect.
3. Understand the domain, the business requirements and the technical challenges
You should be an expert in the technologies used for implementation. You also have to become very knowledgeable in the problem domain and the business case. This will help you understand the business decisions dropped on your head from upstairs and also will help you stand a chance at negotiating them.
4. Know your team: strengths, weaknesses, ambitions and personalities
Software is created by people. Your job as a “tech lead” is to support them in doing that, both from a technical point of view and at a human level. You want to lead a team of motivated and enthusiastic people. But each person gets motivated by different things.
5. Have a plan as a result of a planning activity
“Plans are useless but planning is essential” – (Dwight D Eisenhower, US President, general 1890-1969). Planning will make you think about the problems you face in detail. Also keep in mind that “a plan is just a list of things that ain’t gonna happen” – (Benicio Del Torro in “The Way of the Gun”).
6. Be part in the design of everything
This does not mean do the whole design. You want to empower team members. But your job is to understand and influence each significant subsystem in order to maintain architectural integrity.
7. Get your hands dirty and code
Yes you should take parts of the code and implement them. Even the least glamorous parts. This will help you not getting stuck alone between management and the team. It will also help you gain respect in the team.
8. Act as a communication proxy for your team
In long complex projects with big teams communication is one of the most complicated aspects. The more people you have involved in solving a problem the bigger the communication matrix becomes. Since people need information to be able to make the right decisions this will lead to an exponential increase in the time consumed for communication. Agile methodologies alleviate this problem. But in the end it is up to you to propagate important information to the right people.
9. Make sure everybody understands the big picture: their work has implications
This will help you greatly because will allow team members to design and implement in a way that you don’t have to fight. It is also hard work from your part.
10. Fight for architecture and design consistency
Doing the right thing from the design and architecture point of view is not more costly. It is actually cheaper in every project longer than a couple of months. Every early investment in architecture pays for itself later during integration and maintenance. Even if you have to admit an occasional hack or prototype in the code base you should contain it in very specific modules.
11. Know the status of everybody’s work and detect slippage
This allows for corrective actions and for early communication with the management. You don’t want to be caught by surprise. Remember that during 90% of the allocated time for a task the code is 90% complete.
12. Record technical debt if you need shortcuts but try to maintain architectural integrity; report the debt
This one is very important for products that will have multiple releases. Technical debt should be analyzed at the beginning of each iteration.
13. Use the process that makes sense in your particular case
Tough one. Sometimes (most of the times?) the process is not up to you. In the enterprise usually the process is pre-decided. But always keep in mind that the process in itself means nothing. It is the people who give meaning to the process. Good people can make the worst process work while the wrong team cannot make any process work. Waterfall can be implemented in a very agile way and the agile methodologies can be applied with “
rigor mortis” agility (see
The Agile 800 Pounds Gorilla).
14. Avoid dogmas – question why everything is done the way is done; make sure everybody else knows the reasons
Sometimes I hear from programmers: we are agile and combine XP and Scrum and we also do TDD (Test Driven Development – I still hope for a TDD that means Thought Driven Development). The questions that pop up in my mind are: Do you need all those? Do you “really” do them by the book?
Anyway the point here is don’t do anything just because it is the way it has always been done. Understand why. Then explain the reasons to all team members. Rinse and repeat.
15. Avoid design by committee; listen to everybody but make your own decisions
No good design is born from referendum. There are lots of people making wild exotic suggestions when their a$$ is not on the line. There are also excessively prudent ideas born from fear. Even with good ideas you have to filter them and make them yours before you can include them in the design. A good architecture and a good design is usually born in one mind, an open mind that looks around. The obvious example is Linux.
