Let’s say that you have a growing technology shop, such as for analysis and development, or that you’re establishing a new team. In short order, you’ll become concerned with matters such as ensuring their timely delivery, quality targets, and readiness for a competitive and ever-advancing technology landscape. In other words, you’re going to need some kind of technology leadership. Enter the technical leader!
What is a Technical Leader?
I’m glad that you asked. Technical leaders are charged with the timely delivery of high quality results to the customer. Results can be varied, such as software or training, but invariably they meaningfully produce value and require the investment of skill and time that only a team can provide.
The idea of technical leaders is not new, having been adopted from other engineering industries into the modern technology domain; however, the manner in which a technical leader adds value is often misunderstood. In this post, I am going to explain why you should have a technology leader and what you should expect from him or her to ensure that you get the most out of both the role and the team.
Fundamentally, a technical leader is a facilitator: they balance the customer’s vision with what the team can achieve (within organizational tolerance and contributor ability). That means they will be constantly ensuring everyone’s understanding of how the job needs to be done and which aspects of the job need to be done at all points in the delivery cycle. It’s all about logistics and knowledge sharing.
Let’s start with communication.
It’s imperative for teams of any kind, and especially those doing technical work, to be able to quickly and succinctly impress upon their peers, partners, and customers their challenges and needs. The topics are broad: feature and schedule discussions with the customer; data exchange and component behaviour with partners; and with peers designs, quality benchmarks, capability constraints, location of work, and more. The technical leader must constantly refine everyone’s ability to signal and exchange in a conceptually uniform manner. Easy wins are common programming and spoken languages, but what about design patterns, pseudo code, and functional demonstrations? Even the names and positions of branches and tags within version control systems indicate a state of activity, concern, and acceptance among team members. All of these variables, business and technical, need to be streamlined and standardized by the technical leader so that the team spends more time doing things for the customer as opposed to determining what needs to be done. A good technical leader will use every opportunity, from hack-a-thons to code reviews, to ensure that their team members, customers, and partners can effectively exchange ideas in manners suitable to their environment.
When a team communicates effectively, everyone will be eager to start doing things. It’s great when those things result in a delivery satisfying the customer’s intention, but not all decisions made by individuals will jive with the realities of the business or team. The technical leader needs to be regularly available to the customers, partners, and team to ensure that decisions are accounting for the potential of the situations at hand. In effect, the technical leader needs to be the best connected person on the team, sufficiently aware of the political, resource, talent, schedule, and technology realities of the day. The technical leader will ensure, for example, that the most capable individuals aren’t introducing ideas that cannot be carried by the team’s average skill-to-bandwidth ratio; and that code being prepared by each team member is of sufficient relevance to the critical path.
Obstacle Removal
A key aspect of decision support is obstacle removal, and this effort in various forms will be the core of the technical leader’s daily activity. An astute technical leader will spend significant time evaluating (in advance) the skills, tools, and access carried by the team. Such insight will permit the technical leader to do things such as rotate junior members into appropriately challenging situations to increase their potential; advocate for aligned training plans; and establish systems or permissions relevant to a high quality delivery. When funds fall short or new information arises impacting the path to success, the technical leader needs to provide educated instruction to members so that they can proceed or involve the proper authorities who can make the necessary call. In agile environments, the technical leader has the responsibility of forcing recommits by customers and sponsors if the landscape changes so sufficiently that the team cannot produce any reasonable value. Not least, there will be many instances in which members will want to tackle work that seems, at face value, productive, but in reality does not contribute to the immediate needs of delivery; or would result in unnecessary risk to the project due to an incomplete knowledge or availability by those who would become involved in seeing the solution through to completion.
When it comes to less experienced members, the technical lead assists by researching, demonstrating, and closely guiding how work should proceed. That doesn’t mean that they do the work of the junior engineers, but rather that the lead sets the context for productive progression. For example, the technical leader might prepare a series of unit tests that exercise the API of a new framework so that the team gains a living example of how best to use the functionality. Or, a test framework might be prepared illustrating the lead’s desired outcome for component interactions. In many respects, the technical leader will always be one step ahead of the team by participating in or making use of technology radars, conferences, journals, industry peers, defect lists, and similar to ensure an awareness of options that can result in better deliveries for the customer. The lead will also establish a sufficient learning environment so that the team can make use of new options without the risk of mistakes and delays along the critical path.
Are they the most practiced?
Clearly the technical leader is going to be a team expert, familiar with many tools and tactics for getting the job done. It might surprise you to learn, then, that despite the critical role played the technical leader will probably not be the best programmer or analyst on the team! It’s true, and it’s an important fact for organizations to remember when managing their teams. While the technical leader will be competent, experienced, and wise, the fact of the matter is that they need to split their time between concerns such as feature specifications, user story specifications, engineering metrics, team member environment optimization, business interlock, customer interlock, and more. That means, for any kind of balanced life, the technical leader is going to do less coding, less modelling, and less testing than his or her peers. In other words, they might well be experienced, but they’re going to end up being less practiced.
Don’t panic, especially if you happen to be a technical leader. It’s okay, and in fact it’s an acceptable trade of implementation productivity. In the balance between getting things out the door and into the customers hands versus running the business, the technical leader offers wisdom and refined decision making in the context of external pressures so that the rest of the team becomes more productive. If the technical leader simply coded alongside everyone then the team would be, well, the team + 1 with just a linear increase of productivity instead of factoral leaps. It’s similar to having an engineering manager: they don’t (or at least shouldn’t) code with the team, instead they deal with human resources, budgets, policies, and the translation of business strategy into tactical outcomes. The work needs to be done regardless of whether it is hidden in the team or tackled directly via a supported mechanism.
Balancing Act
But less practiced means less experienced at some point, right? Yes, unfortunately. As Stephen Covey once noted, a sharpening of the saw must occur. This can be achieved either by having the organization invest in training time and resources for the technical leader, or the organization can adopt a rotational model by which different people share the burden. An example rotation strategy is to use a primary-shadow-worker approach by which for a period of time an individual acts as the technical leader and has the part-time assistance of a team peer. The part-time peer, known as a shadow, helps the technical leader such as by doing research or grooming the backlog, and in so doing remains aware of the overarching concerns for the team. At the end of the period, the technical leader transitions into a traditional engineering role within the team, the shadow becomes the new technical leader, and one of the team engineers steps up to be the next shadow. The length of period depends on many things, but for agile teams the feature commit cycle can be a good alignment. The result will be a balanced, self-enabling technology team capable of succeeding in many challenging situations.
In all, technical leaders are vital to healthy and productive teams–but to be the most effective these individuals need to exercise their engineering prowess by focusing less on implementation and more on communication, logistics, and knowledge sharing. Organizations need to recognize that the value of these activities are critical to successful outcomes, and by promoting strong technical leaders they gain the benefit of strong delivery teams.
