The second key area of responsibility for tech leads is the technology stack. From programming languages, frameworks and tools to platforms for provisioning, deploying and monitoring your application, all these elements can make the difference between the success and failure of the project.
The tech stack
Each company or project can be composed of a dozen or hundreds of tech elements and keeping track of all of them can be effort intensive. Therefore, to have a good overview, I recommend building a tech radar by using the open source solution offered by thoughtworks. The vizualisation will help you make strategic decisions and reflect how your team perceives the benefits or disadvantages of each item, promoting dialogs with others on best practices and key learnings.
Medium to large size companies already have projects with a lot of development years behind them and most of the time the decision of what tools and languages to use is already taken. Sometimes you have the benefit to decide how to build the tech foundation, but, either when starting a new project at a startup company or either continuing a ten yeas old codebase one pattern that repeats over and over is that technologies and tools come and go. So make sure that you and your team can adapt quickly.
The ability to change
Software by definition is meant to be “soft” and flexible to change. Delay big decisions (e.g. what type of database to use, or what cache layers are needed) as long as possible and focus on building value for the users. Bring features in the hand of the users as early as possible and use their feedback to drive your architecture decisions. Never commit too early to a decision that would take too much effort to change, since this implies rigidity, one of the biggest enemies of successful products. Business requirements will change, not because someone wants to break your perfect design framework or feature, but because external factors, like the industry or the market, the competitions, or the behavior of the end-users change all the time. Your team’s ability to adapt is one of the most important KPIs that you must look at and improve.
Help your team to adapt by coaching them to “learn how to learn” new skills and technologies. Personal development plans must include challenging techniques, patterns, and projects where the team can demonstrate how fast they learned something new and how comfortable they are in a new domain or context. John Sonmez in his book “Soft Skills – The software developer’s life manual” offers a complete chapter on learning new things and shares his ten step process. I really recommend having a look on it and see what works for you.
At one moment, with a lot of exercise and experience, your team will start seeing the principles behind all the designs patterns, frameworks, and tools. These principles have been there since half of the century and they are the key to preparing for the future, regardless the languages or tools of tomorrow.
Over time, technical debt will increase and different pain points will appear. Therefore it is vital that a list of all technical debt items is created and is visible to all stakeholders. I would recommend even having it physically on a board or wall inside your team space. Tackling this debt must be made a routine and it should not be treated with less importance otherwise the team and the product will pay a very expensive price.
In 2009, Martin Fowler wrote an interesting article where he categorise technical debt into four quadrants:
- Reckless and Deliberate (“We don’t have time for design”)
- Reckless and Inadvertent (“What’s layering”)
- Deliberate and Prudent (“We must ship now and deal with consequences”)
- Prudent and Inadvertent (“Now we know how should have done it”)
As a tech lead it is important to see where your technical debt stands and take the adequate actions to avoid reckless technical debt, since these two quadrants shows either irresponsibility or incompetence.
One other thing that a tech lead should observe, is that the corrective actions are the right ones at the right time. Sometimes it can be tempting to optimise, refactor and change components or even entire systems only based on internal team pain level only to discover that the estimated benefit was lower than expected. To prevent this, before making any change, put in place systems that can measure the impact. Secondly make the results as public and visible as possible, especially if they differ from the initial expectations. Use them to share the lesson and knowledge across team members and always try to keep the end-user in mind.
Jack of all trades
One question that I encounter quite often is if a tech lead should specialise in one domain or know a bit of everything. As a leader I find it more useful to have a broad knowledge rather than a focus one. Nevertheless, you should hire or make sure that you bring specialists in your team, since you must rely on their opinion and advice to take important decisions. Your communication skills and ability to understand them and lead them towards a common goal is your main responsibility and not to bring ideas and solutions to difficult problems. Having a deeper understanding of the programming language or of a certain framework will help, but trying to always be the one that solves technical challenges will reduce the time that you should lead your team.
Delegating and empowering other team members will show them your trust and provide opportunities for them to grow. Take technical decisions with your team, involve them and hear all the options. In my experience, I found that all these different perspectives build better solutions and give more impactful results.
- have a clear overview of your tech stack and plan strategic changes ahead
- keep in check technical debt and do not take reckless decisions
- make sure that your code base and your team can adapt to changes with minimum effort
- take technical decisions with your team and don’t be the specialist of your team
Also published on Medium.