It seems to be a truth, universally accepted, that the armies of the world run on their sergeants and the navies on their chiefs. These non-commissioned officers provide a valuable, nay essential, link between those who do and those who tell. (They also try to keep the new lieutenants alive and out of trouble, but that's a different essay.) It is my opinion that a Technical Lead is like those sergeants and chiefs. They are at the top of the pile of those who do and directly beneath those who tell. And as such they are a key link in the corporate I.T. structure.

Most roles on a project are easy to place in the timeline. Everyone knows that requirements gathering is an upfront activity, that computer programmers work in the middle and that quality assurance testers live on the tail end. A Technical Lead is more difficult to place, because they operate everywhere.

First In, Last Out

The Technical Lead is typically one the first people assigned to a project and usually one of the last to leave it. They are involved in every part of the project lifecycle. When a project is scoped, it will be done by a small team and the Technical Lead will be there, bringing their experience and domain knowledge to ensure that the project attempts to do enough to be useful, but not so much that it will collapse under its own weight. The decided scope then leads to initial estimates. Again the Technical Lead's experience guides by knowing the work to be performed and the capabilities of the team that are envisioned to do the work. Without great care in these important steps, the project will be unlikely to reach its full potential.

Once the preliminaries are completed, the Technical Lead switches to primarily leading. There is design and coordination to be done. While the Technical Lead is unlikely to personally design the user experience or the database schema, they will provide input and coordinate the efforts of everyone involved. And as the project progresses, they will be strongly connected to the QA testers to ensure that the resulting product does everything that it was supposed to do, in the way that it was supposed to do it.

Whether formally, through company mandated project reviews, or informally by making their own notes, a Technical Lead will gather lessons learned. These lessons learned are worth their weight in gold. They are distilled wisdom ready to be applied to the next and subsequent projects. Each lesson learned is one less thing that is likely to go wrong on their future projects.

Engaging End Users

There is a principle in pastoring that the pastor, in his role as shepherd, should smell like the sheep. This gently reminds the pastor that the people are their focus. My biggest I.T. projects have been in warehouses, so it's quite possible that I have ended my days smelling of cardboard. Regardless of any olfactory indications, the technical lead should spend time with the users and business leaders alike.

The goal of any project is to produce happy, smiling users, and the best way that I've found to know if you are on the correct path to do that is to spend time with them. Visit them and talk to them. Watch how they do their jobs and join in if they'll let you, but at least watch carefully and find the pain points in their current processes. (I have been on several large warehouse projects where many of their pain points were more literal than metaphorical.)

Rallying Your Team

At all points of the project, the Technical Lead will be rallying their team. Programmers are not soulless automatons, so the Technical Lead must work with each team member in whatever capacity they need at that point. The majority of the leading is that of directing the technical work. While the Technical Lead often writes relatively little of the code, their style is likely to be all over it. Code communicates well to programmers, so I have often written example code to explain how I thought a need should be addressed and then the programmer would often take it and adapt it to everything else similar. I have created object hierarchies and internal APIs and defined the scopes of modules to ensure that each programmer could do their own work without stepping all over their fellow team members. And most important of all, have been the conversations at my whiteboard where we can think through important points of the system until I see a solid plan of approach form in my programmer's mind and I see them eager to head back to their desk to begin implementing what we had thought through together.

I have found that the roles of mentor, cheerleader and counselor also tend to accompany the position of being a Technical Lead. The role of mentor is not unexpected, with a Technical Lead typically being an experienced programmer. In most cohesive and productive teams, there is a natural mentoring dynamic where the experienced members guide the newer ones. Technical Leads quickly learn to adopt a cheerleader style of encouragement because normally they are not positioned above their team in the chain of command. They learn to motivate by encouragement rather than issuing commands. Finally, the counselor role does not always fall upon the Technical Lead, but where they have excellent people skills it's an easy addition to their leadership of the team.

Buffering

Buffering your team from everyone else in the organization is likely the toughest thing a Technical Lead will ever do, but it is perhaps the most important. Many people will have valid interests in the state of the project you are leading, but every interruption of the team causes delays. As the Technical Lead, you are the one who should be ready to share the project status and answer questions to protect your team from distractions. Keep in regular communication with your IT leadership and business management. Schedule weekly meetings if that will help ensure that you can get some time on their calendar. Strive to ensure that all of the stakeholders of the project never feel that you are difficult to find or that you have hidden any information from them. If you are honest with your estimates, your ongoing status reports and promptly fold in business feedback and requests wherever possible, you will build trust and that trust will carry you safely through the occasional slipped deadline or milestone. If your users and their managers know that you are in their corner, then they will move mountains to get you what you need and will shelter you from everything they can to protect the project.

Your Good Friends in Infrastructure

For as much as we like to think that nothing happens without software, that software needs somewhere to run and resources to support it. Enter your good friends on the infrastructure side of the I.T. house. Some of the best relationships that I have ever built have been with infrastructure folks. Project problems have a wonderful way of being solved when you're friends with the database, server and system administrators. Walk over to their desk, smile, ask how they're doing and then mention the problem your team is having. If you've done your relationship building well, they generally make that problem disappear quickly, often before you even leave their desk.

Perhaps this doesn't need saying, but I'm going to say it anyway, remember that your relationship with infrastructure goes two ways, so be prepared and willing to do them favors whenever you can. Buying doughnuts after a particularly big favor never hurts either!

Real Artists Ship

The phrase "Real artists ship" is often ascribed to Steve Jobs and indicates that no matter how much creativity or technical excellence you are pouring into a project, it still needs to be completed and delivered and most importantly needs to make it's recipients happy. While I am not a fan of arbitrary deadlines for I.T. projects, I am a fan of delivering something decent in a reasonable time frame. Yes, every user in the history of users wants perfection from their delivered business systems, but they also don't want to wait that long for it. (Deliver a core and then follow-up with enhancements.)

Experienced Technical Leads strive for a balance of sufficient functionality with a business helpful delivery date. These things can often be negotiated, especially if you have built trust in your previous interactions with the business.

Stick Around A While

As a Technical Lead who understands the importance of a good relationship with their business users, build as much time into the plan as possible to be able to be with the users when they receive the final version of the system you have provided for them. If the system has been built using incremental processes and with good user input, then the system should not be a surprise to them, but at the end of the day there are always things that didn't quite turn out to be as good an idea as they thought it would be. When these things are discovered, an attentive Technical Lead can swiftly direct their team to apply modifications to bring the system to the user's full satisfaction.

This approach helps with your relationship with your users. One of my greatest satisfactions is going around town and seeing users from a previous employer who still recognize me and take great delight in assuring me that their system is still delivering value and satisfaction more than a decade after it was delivered.

Surveying The Technology

Forward thinking Technical Leads track technology changes. This is a challenging task, but one that should be done periodically. At appropriate intervals and always after a project completes, check to see what's new and potentially useful for your area. Filter the large volume of new things by your understanding of your work environment. Microsoft shops can probably safely ignore Java news. Web developers are less likely to need embedded software tools. Finally, everyone (kinda) loves JavaScript, so you'd better have some fact-based opinions ready for the inevitable Node.JS questions.