One year ago, I was working in a Dilbertesque company. On the team working on their main product, they had a technical lead who was… well, not particularly knowledgeable. So one day, the lead decides that code style matters. He spends a few weeks drafting the style guide himself. Then, the team tries to enforce it by hand, but over time forgets more and more about it. From time to time, the team recalls that style should be enforced, makes some efforts, wastes a day for that, and then forgets about it again.

What the lead doesn’t know is that:

• In C# there is an official set of style rules,
• StyleCop enforces them at every commit,
• You should enforce style rules at every commit: postponing this until code reviews results in pain and waste of time.

Result: by not having a real technical lead, the team wasted efforts drafting the style rules and originally enforcing them, and continues to waste time enforcing the rules from time to time.

What is a purpose of a team lead?

What is a purpose of a team lead? Why is the team lead I described above a bad one?

To provide the team with technical expertise required by a given project. The ultimate goal is to reduce as much as possible the waste of time which can be occasioned on two levels:

• Key decisions. Dead ends and wrong paths. Some key decisions are better be done by a knowledgeable person, because a wrong decision may lead to a situation where the team should get back and pick another decision instead.

  Examples of key decisions:

  • “Should we use WCF or reinvent our own communication layer?”
  • “Should we implement caching?”
  • “Should caching be distributed?”
  • “What’s better for our project, WinForms or WPF?”

• Technical questions. Developers sometimes don’t know very well the language or the framework they are using for a given project. There is always Stack Overflow, but it’s often better to have an answer from a person who is right there, available for you, knows you, knows your technical level and your thinking, adapts his answer to you and with whom you can interact, for example when you don’t understand some parts of the answer.

  Examples of technical questions:

  • “Why is this piece of code not working?”
  • “I don’t understand lazy initialization.”
  • “Doesn’t var means the type is dynamic?”

The technical expertise here is key. You don’t become a team lead to learn a language or a framework. You become a team lead because you already has the required knowledge.

Another very important concept is trust. Team leads are not really named by management, but informally chosen by a team. Sometimes, the one who is named and the one who is chosen are the same person, but this is not always the case.

Trust is inherent to expertise, and trust is also a key element in time waste reduction:

Any team tests, often unconsciously, a new technical lead. Team members may be interested by the career of the lead, what books or articles he have written, where have he learnt all the stuff he knows. Team members may also not automatically trust every decision, but either ask him to justify himself, or search for other sources.

For instance, if the lead attempts to enforce a common code style on commit, some members may fight back and ask for a proof that this has any value. A good answer the lead can give is to explain in details the subject and his experience. A bad answer is: “because my previous manager told me that” or “because I read this in a blog”.

Another example: if the lead tells that the team should use a message queue service, team members may ask for proof that a MQS will be the best alternative in this particular case. It is then the job of the lead to explain why is this a good choice, and what are the drawbacks of other choices.

A third example: a few years ago, I was a technical lead on a C# project. At the beginning of the project during a code review, I pointed out that a technique which the author was considering being an optimization technique is useless in terms of performance (the compiler does the job as well) and harmful in terms of maintainability. The person wasn’t particularly happy with my feedback, so we sat down together for a few hours and I’ve shown him the IL produced with his code and mine, a few refactoring techniques, Visual Studio’s Code metrics, and a few dozen of other things. Few hours later, the guy was happy that in one afternoon, he have learnt more than in the past two years.

With time, the lead becomes a trusted source. Decisions taken by the lead may be accepted as-is by the team. One can think that this is a bad thing (what if the lead actually took a bad decision?), but it’s not. If the lead is unsure, he will tell it to his team and expect the point to be discussed. On the other hand, avoiding pointless discussions on points where the lead takes a decision based on his deep knowledge and experience can speed up the project tremendously.

In an ideal project with no time constraints, every decision could be based on evidence. When confronted to a choice, the team will simply follow each alternative and compare the results. In the same way, each answer could be justified and explained in detail.

In practice, there is simply no time for that. I can’t possibly test whether my product will perform better with Microsoft SQL Server, Oracle database, IBM DB2, PostgreSQL, MySQL, MongoDB or any other of hundreds of database engines available, and I can’t possibly take one to six hours to explain every technical answer I give to my colleagues.

Where does the technical expertise come from?

A crucial mistake the management can do is to name a technical lead who doesn’t have the required skills. The team will quickly understand that their lead is not particularly useful, and avoid treating him like one (eventually informally choosing another lead).

In order to win trust of your team, you need technical expertise. You gain this expertise by reading and practicing.

Reading is an essential part of learning experience. By simply practicing, you’ll be limited by the knowledge you already have. Reading books, articles, Stack Overflow answers or code gives you an opportunity to have those “Aha! I didn’t know that you can do this like that!” and “I never knew this thing is possible in my favorite language!” moments.

Practicing is crucial as well. I’m glad to hire a programmer with no prior professional experience, but certainly not as a technical lead. Again, the main concern is how much can he reduce the waste of time for the team. The lack of professional experience can be particularly harmful for key decisions.

For example:

• If you are about to decide whether your team should use Code contracts or not, I don’t care that you’ve read all MSDN documentation about Code contracts: you should be able to tell what are the pros and cons of them based on your experience.

  If you’ve read an article written by a Microsoft’s employee, you’ll think Code contracts are magic (and believe me, they actually are). If you’ve read an article written by a guy who tried Code contracts but was more concerned about his CPU usage than the benefits for his project, you would think that Code contracts are difficult to use and to get right (they are, too).

  On the other hand, if you’ve actually used Code contracts on small and large projects, you know the benefits and you know the caveats, you can explain them if needed to your team, but more importantly, you can take the right decision for your team without having to explain them why are you taking this decision.

• If you are building an app which relies on WCF, there are no books you can read that will tell you that WCF may be is often painful to configure right. As a technical lead, you’re expected to encounter many of the possible WCF-related trouble cases, and know how to solve them.

How do you start learning about a new domain and programming language?

C# in Depth by Jon Skeet can be a good start. And then, practice, practice, practice.

So what should you do?

Giving advice is difficult. I don’t know you. I don’t know your company. Nor your future role within your future team. Nor your skills.

Still, there is one important thing. Be extremely clear with your manager/boss. If you think, especially after reading my answer, that you don’t have the required knowledge and training right now, ask for more training or for more time to handle your own training yourself before starting the project.

Being clear with your manager/boss is crucial. Your manager/boss may not have technical skills, and he may not even know the difference between C++ and C# or between Java and JavaScript. He looks at your CV, sees “C-something: lots of years of experience”, and decides to make you the technical lead. If the project end up being a technical failure, you will be the one to be blamed.