Technical Leadership 101

I’m presently working with a client to help mentor and transition one of their senior developers into a technical lead role. I figured I’d share my thoughts with the community at large. So this is the first of what I expect to be several posts about the role and responsibilities of a technical lead.  (I don’t make a distinction between architects and tech leads.  In my opinion, they are just variations on a theme.)

The traditional definition of a technical lead in IT goes something like “an individual with responsibility for the technical architecture and design of a system or sub-system and for leading a development team to implement it within the time allotted.” However, that definition does not adequately represent the business aspect of the role. In enterprise software development, a technical lead is one who has responsibility for pairing business objectives with technical solutions. You serve as a bridge between technologists and business people. You must help the business make educated decisions based on technical options and constraints – and must help the development team make educated decisions based on business objectives and constraints. (Note the use of ‘objectives’, rather than ‘requirements’.)

To be affective, you must work hard to stay intimately familiar with both the business and technical domains. Many people fail in this role because they consider themselves, at best, loosely associated with the business. That loose association is represented solely by the requirements they are given to implement. However, there is a significant distinction between business requirements and business objectives.

When interviewing technical lead candidates, one of my standard questions is: “Which is more important – delivering a solution that meets client expectations or one that precisely delivers on all the requirements?” I suppose this is a spoiler for any future candidates that read my blog, but the answer is meeting expectations. Unfortunately, most candidates make the wrong choice.

Requirements represent a means to achieve one or more business objectives – not the objectives themselves. And, more often than not, requirements are incomplete and open to interpretation. If you don’t understand the business objectives, you will likely miss-interpret the requirements. The expectations of business representatives will be aligned with business objectives, not software requirements. If you deliver a system that addresses all the requirements but is not aligned with business objectives, you will have failed from the client’s perspective. Sure, you can defend yourself by holding the requirements up as a “contract” for development. That will likely stand up in court, so to speak. But that adversarial attitude completely misses the point and fosters bad will between business and technology organizations. If you’re a consultant, that will likely result in forgone future business. If you’re an IT employee, it will make your next project more difficult.  Regardless of your employment arrangement, you are partnering with a business organization to solve business problems. A good technical lead will invest time in understanding the business domain and objectives and will help interpret, define and revise the requirements to make sure the end result is aligned with the business objectives.

If you are in the enterprise software business – whether you are a direct employee, contractor, or consultant – all of your decisions should be guided by business objectives. Fortunately, that does not conflict with making good technical decisions. In my next post, I’ll extend the discussion beyond requirements to technical design.