The Role of Technical Leads in Technology-Driven Marketing
Traditionally the Technical Lead has been synonymous with lead programmer, senior software engineer, or senior application developer. They serve as both the primary contact and technical representative to the agency, as well as the lead architect and engineer on the project with direct responsibility to the outcome of the product. Within the context of a dedicated software development organization this makes sense as the hierarchy may support a unit, team manager, and business analyst. Within the context of an agency, however, the weighted importance of several key factors of the functional role shifts. This shift redistributes the weighting of both technical and non-technical skills the Technical Lead must retain thereby altering the fundamental role requirements and definition of success within the role.
A Good Technical Lead == A Good Engineer. A Good Engineer != A Good Technical Lead
Two distinct areas of conflict arise when utilizing a Senior Engineer as a Technical Lead. First and foremost, a good engineer does not necessarily have the ability to manage and interact. Second, the wide breadth of client problems requires a broad domain or expertise as opposed to a deep understanding of any single technology area.
The Peter Principle posits that, within any hierarchy, every employee tends to rise to his level of incompetence. There is no place this rings more true than in technology management. What many people do not realize is engineering, as with an artist or writer, is a creative discipline. An excellent metaphor for the numerous distinct ways to solve even the simplest of problems with technology is “Hello, World”, the first and most basic program engineers write when learning a programming language which simply outputs the text “Hello, World”. To date there are thousands of ways an engineer can output the text “Hello, World” to your screen all of which can be considered the right way. As a result, the most senior engineers have refined their craft throughout years of participation in disparate physical environments with diverging requirements culminating in multiple “right ways” to accomplish any given task. Consequently, any two engineers may disagree as to the “right way” to accomplish a given task, especially when comparing the solution of a junior engineer to that of a senior. Does experience make the senior engineer correct, or does currentness give the junior engineer and edge? The result of this interaction is a responsibility/accountability curve on which engineers ride as their professional career progresses from coder to manager. As a coder the engineer is directly responsible for making their piece of the solution work but not accountable for the overall success of the entire project. As a manager they are accountable for the overall success of the project but do not physically code and, therefore, are not responsible for making a solution work. This conflict between what the engineer believes to be the “right way” and what is actually executed by coder may become an obstacle to delegation thus rendering the Technical Lead not scalable and often times requiring a scaled down project load.
Within the rest of the organization the Senior Engineer is not a Business Analyst or Strategist. Their primary role is executionary, not organizational or strategic. They are paid to succeed, not to question. A good metaphor for this is the amusing but true statement I give to non-technical persons, “never ask an engineer if something is possible; the answer is most surely ‘yes'”. This simple statement can therefore be extrapolated out to several addendum:
- Do not use the solution in the question. For example, “how long would it take you to build this site in wordpress”, where wordpress may not be the appropriate solution to the business need. This practice limits the scope of answers and, more often than not, the question does not contain either the best practice or the most direct solution to the business need. In problem analysis we’re taught The Five Whys method to getting to the root of a problem. In engineering we’re much more literal.
- Do not ask an engineer for an estimate — it will be accurate, but it will not contain external influences. “If I were to sit down at a keyboard today, how long would it take me to execute the request?” is not the same as “given the dependencies of other team members and the client, assuming I’ll be interrupted and requirements will be changed, with a limited budget, hitting these milestones, and still doing your other work, how long will it take?”
- The right way to do something is not always what’s best for the project. Engineers are driven by what’s interesting, new, and cutting edge. This is why we like them; they are an excellent source of information. Combined with Technology’s tendency to change over time and the associated learning curve, there’s always a better way. This often leads to work done which is either not required or not in scope. This is also why the new paradigm of software is called the perpetual beta.
- Engineers recommend what they know because they have a commitment and attachment to it based on years of disciplined learning. They also push for what they don’t know because they want to learn it. Technical Leads, on the other hand, must understand technology at a higher level and will therefore push for the most appropriate, potentially uncomfortable solution resulting in higher quality, more innovative products. An engineer’s drive is to succeed, a leader’s job is to lead.
While overarching coding principles and architectures, like frameworks, can be cross-domain the specific knowledge base of an engineer often runs deep in one particular area — .Net vs. Java vs. LAMP vs. mobile vs. flash vs. data modeling vs. social, etc. To operate effectively the Technical Lead must also possess a wide — analytics-based closed loop integrated on & off-line marketing solutions with a mobile component and corresponding media buys — not necessarily deep, breadth of technical knowledge. The degree to which their knowledge must go deep is the ability to compare the strengths, weaknesses, and interactions of each as well as best practices and channel appropriateness.
Roles & Responsibilities
Within the agency the Technical Lead is primarily utilized for their technical knowledge and wherewithal – not their specific implementation knowledge. Beyond technology the Technical Lead must posses several non-technical domains of knowledge including: project management, the software development life cycle, and the appropriateness of agile, RUP, waterfall or other methodologies; user experience; information architecture; and strategy. They are accountable for the technical management of all projects with a technology component from inception to delivery and on through maintenance and updates. This renders the Technical Lead responsible for the overall successful execution of the project. In short, the Technical Lead extends — not replaces — the Project Manager’s accountability into the complex technology environment.
As the representative of the Technology department within the agency and to the client, the Technical Lead is responsible for the following in each phase of innovation:
Strategy & Planning: The ability to listen first, ask appropriate and directed questions, and understand business requirements is the primary differentiators of a Technical Lead vs. other agency resource. To manage risk the Technical Lead must assess numerous possible solutions and key assumptions to prevent issues before, during, and after the project has been initiated. This requires a granular understanding of existing in-agency talent and solutions, how projects relate to the broader agency scope, a keen understanding of technology execution, and the ability to communicate this knowledge to the cross-domain project team. The Technical Lead must play an active role in helping project managers build project plans, estimate and set expectations within the team. Understanding both the business requirements and environmental constraints — being time, money, resources, or technology limitations — then proposing the appropriate technology solution.
- Business/problem analysis
- Technical feasibility analysis of possible solutions
- Discovery analysis architecture and scoping
- Communication/translation of any technical constraints or best practices
- Technical resource allocation
- Vendor identification
- Cross-channel campaign architecture
- High-level work estimation
Solution Design: Historically solution design has been left to the creative mind but the marketing world has changed. Today’s Technologist is a disciplined Creative mind. Technology is fundamentally oscillating toward art from science. Within the solutions design stage the Technical Lead is responsible for merging the previously desperate worlds of Art and Technology.
- Communication and technical translation of complex technologies
- Assist with and feasibility analysis of functional requirements
- Discovery and/or technical audit and findings presentation
- Technical requirements
- Assist with work estimation, schedule, and project plan
- Concepting and prototyping
- Vendor research and evaluation
- Concept revision
- Infrastructure design and implementation
- Information Architecture and systems integration modeling
- Scope management
Development: This is the most traditional of Technical Lead roles with a twist. Historically the Technical Lead would be the smartest and brightest coder but this is no longer the case. Today’s technology solutions change according to business need, which implies the project team changes according to that same need. Technical Leads rely heavily on their pool of resources for in-depth expertise in the wide breadth of expertise required to execute the ever more complex and integrated solutions. They rely on experts in the field resulting for the project in a broad scope of solution ideation but a specialist in implementation.
- Development oversight
- Quality Assurance test cases
- Tracking, analytics, and SEO implementation
- Vendor management and communication
- Scope management
Verify & Deploy: Because the Technical Lead is involved in more total projects over a given period than an engineer they gain more experience more quickly. This experience helps significantly when it comes to risk mitigation and deployment. Pharmaceuticals, for instance, have a distinct process from not for profits, which is different from retail, and so on. If the Technical Lead has managed the rest of the project well verification and deployment should be straight forward because the Technical Lead has done it many times before. Continuous integration, a result of the perpetual beta, emphasizes this. During this phase they are responsible for:
- Quality Assurance oversight
- Deployment oversight
- Backups and disaster recovery
- Code review
Measure, Optimize, & Maintain: After the project has launched there is still work to do. Systems need to be monitored, patched, updated, and generally maintained. Technology changes, Facebook updates it’s usage rules, software releases versions and patches, new channels enter the market. These things are important but often do not come through the agency from the front door. In these cases the Technical Lead is responsible for aggregating the knowledge of the technology team then communicating and escalating issues of importance to the project team along with recommendations, estimations, and and through to execution beginning the cycle anew.
- Bug fixing and risk management
- Maintenance & updates
- Assist with reporting
- Ideating the next solution
While the root of a Technical Lead must be based in technology implementation, the discipline must be that of someone more interested in technology as a whole. Moore’s Law loosely describes the tendency of technology to double in capability every two years. At the granular implementation level there are few people, if any, who can keep up with it. Combined with the non-technical disciplines of strategy, design, and project management the role of the Technical Lead is more important than ever and will continue to double every two years.