Agile Manifesto signatory Jim Highsmith talks about riding paradoxes in his approach to Adaptive Leadership.
A leader will find themselves choosing between two solutions or two situations that compete against each other. A leader successfully “rides the paradox” when they adopt an “AND” mindset, instead of an “OR” mindset. Instead of choosing one solution over another, they find a way to satisfy both situations, even though they contradict one another.
A common Tech Lead paradox is the case of Technical Needs versus Business Needs.
The case for Technical Needs
Before cloud services were available on the Internet, most companies would invest in hardware to run their services. The work to setup and configure machines was easier for non-technical stakeholders to see because of its physical aspect. Today software requires even more software and non-physical services that need configuring, testing and releasing. Much more of it is virtual.
Practices such as Continuous Delivery do not come without some overhead, although it provides an invaluable business capability. All of these “internally-facing” technical requirements demand time from the software delivery team.
The case for Business Needs
A lot of software is written for businesses, whose overall goal is to make money. A business that does not evolve their business offerings will lose out to competitors or to the ever-changing consumer marketplace. This means a business wants to always experiment with their existing services, or provide new services to keep their existing customer base, or to attract new customers.
This pressure to modify, or introduce new services demand either software support, or new software to be developed.
The conflict
A business will always put pressure on a development team to produce as much software as possible. At the same time, effective delivery of software is not possible without addressing some level of technical needs – such as technical debt, deployment pipelines, or automated test suites.
Time spent on technical needs is expected to improve developer effectiveness, but this is often hard to measure and prove to outside stakeholders. An endless amount of time can always be spent tweaking, optimising and improving technical infrastructure and tools. What starts off as “just an afternoon” turns into a week, or a month and business features are put on hold as a result. If this happens too long, the business might miss agreed external deadlines for certain features and thus lose customers, or money.
What does a Tech Lead do?
Champion time for Technical Needs
A Tech Lead champions for time to spend on Technical Needs by being part of the prioritisation process. They ensure that enough work is delivered, or finds solutions to business problems that minimise the amount of software that needs writing. They ensure the team is not over-loaded with delivering new features and changes and finds small slices to work on technical needs that will provide a good benefit.
Explain the business benefit of each Technical Need
A team can spend an endless amount of time investigating, configuring and supporting their technical infrastructure. A Tech Lead will have support from non-technical stakeholders if they understand what benefits they bring. The successful Tech Lead can explain not just what the team is working on, but also why and who else benefits.
Some typical business benefits include: reducing the amount of repetitive work, improving the quality (by minimising the chance of human error), or to prove out a business opportunity.
The Tech Lead builds trust with non-technical people by highlighting benefits on Technical Needs and also demonstrating if they reach those benefits.
Work on high impact items first
A list of Technical Needs will often be endless, so a Tech Lead will work to prioritise the list, culling items that no longer make sense, or pulling work items forward that may have an immediate and significant effect.
Keep a balance
The Tech Lead is mindful that the team cannot work on Technical Needs alone, and watches to ensure a good balance is met.
Maximise the use of “quiet” periods
Sometimes a development team will outpace the ability for a business to prioritise, “What’s next?” You might recognise these periods when a Product Owner has met all their objectives, or they are working on clarifying the next set. The Tech Lead uses these “quiet periods” as an opportunity for their development team to work on infrastructure, or tasks that have always been deprioritised.
These are often good periods for a team to run a “Hack Day” or for the team to work on small ideas they have had themselves that provide a good benefit.
If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.
