I am going to be writing a series of articles about how I see technical leadership in the field of software development, what is its role, what tech leads should focus on.
Some may ask me, why do I need technical leadership? Since I am trying to sell my consulting services as part-time technical lead, it's a question I need to be able to answer convincingly.
The best way to start illustrating how can a strong tech leadership help may be to show you what kinds of things happen when it's not there. Some of these signs are very internal and only visible to developers, while other signs will be apparent to any other business actor that is a stakeholder of a software project (or even users).
When I talk about the Technical Lead role, I am not limiting it to a single know-it-all individual. In particular in large organisations, technical leadership is the remit of a team of high seniority engineers that collectively perform that role.
These are some of the symptoms I've spotted in teams where technical leadership is missing or weak. In those cases decisions are driven by short-term pressures from other parts of the organisation, and by individual developer tastes, with no concern for the larger picture and the longer term.
These individual symptoms can be rooted in different causes and may appear individually in many projects. But when you can see several of them on the same team and project you can tell the technical leadership is lacking.
Overall, these symptoms can be categorised as either:
- the developers don't work as a team (people),
- the team is improductive or ineffective (process/tools),
- or the end product is poor (product).
External-facing symptoms, that can be observed from the outside:
- Low productivity and low speed of delivery: it takes ages for the team to deliver features or fix bugs to production systems.
- Poor planning, and low visibility of work in progress
- When an outsider needs technical advice or has questions, it is not clear who to ask, and developers pass the buck to one another ("that is Jim's code, ask Jim")
- Lack of collective (and sometimes personal) responsibility. When things go wrong, the team plays the blame game.
- "Who makes the technical decisions and why" is unclear.
Internal-facing symptoms, as seen by developers:
- Lack of standards: inconsistent ways of doing things, depending on individual developers' tastes.
- No clear architecture or patterns: duplicated code, hard to figure out what code should go where, lack of tests.
- No identifiable processes, and as a consequence poor repeatability and lack of automation.
- Lack of quality: external quality, but also and above all missing internal quality (maintainability, readability...).
On subsequent articles, I will be talking in more detail about some of these problem areas, and my personal views of what good lookes like for them, and why I think so.