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.
Very timely Pat. I am trying to wrestle with one such a paradox at the moment!
Your post made me realise that I think of this slightly differently. I try really hard to force myself to think (and label) things in terms of business need. Whilst I acknowledge that technical needs often need to be prioritised alongside those of the business – I find thinking of these things as different “types” of thing can cause issue… The most abused of this IMHO is the “technical task” which often sneaks its way onto Kanban boards and eats its way into delivery capacity without a clear articulation of benefit.
From my own experience I have noticed that, in most cases, the business benefit of fulfilling technical need either works towards achieving a cross-functional requirement or results in an overall reduction in cycle-time.
When teams’ feel compelled to request that “technical needs” be prioritised over “business needs” – this is often a symptom of cross-functionals having been neglected or tactical as opposed to strategic decision-making by the product owner taking its toll (and consciously accrued tech debt needing to be paid down).
I think “Tech need vs Business need” is the wrong way to think about it… In my head, a better way of expressing this paradox is “tactical need vs strategic need”.
I mentioned that I am dealing with one such paradox at the moment… Perhaps you can point me at some data/case-studies that will help to better inform my decision?
OPTION 1
Tactical – Chase the money. Build something for a particular distribution channel that I know to be historically lucrative from a business perspective. All this with the knowledge that doing this exclusively will restrict our ability to expand into multiple distribution channels in the future (without incurring significant re-work).
OPTION 2
Strategic – Build out multiple distribution channels from the outset. Bring the risk forward and maximise the opportunity to consolidate both process and technical approach across multiple distribution channels. This makes for a more extensible “platform”… but does not speak to the problem that historically, only one of the distribution channels has been lucrative. (The other distribution channel, whilst being less lucrative, is widely believed to have the biggest growth potential.)
hmmm….
I’m sure the real answer is probably somewhere between these 2 options but am interested in hearing your thoughts… (Perhaps over coffee and a whiteboard for old timessake! ;-))
Hi Darius!
Thanks for your detailed reply. It’s almost like a blog post in itself! 🙂
While I agree that most Technical Needs can be expressed in terms of a business benefit (as I outline a Tech Lead should be trying to express), in many organisations the reality is that “Product Owners” may not really understand how significant those are. It’s the Tech Lead’s responsibility to champion and to ensure a fair balance in Technical and Business needs – even more so where there is no Technical Business Stakeholder, or the Product Owner does not fully understand the implications. I would assume you are slightly different having worked with many technical teams and technology in the past – many Product Owners (or people who prioritise work) do not have this same empathy. Thus, a Tech Lead must work hard to ensure those items are neglected.
In response to your particular suggestion, “Tactical vs Strategic”, I agree that it is a paradox. I see this as a challenge for all leaders, just not exclusive to Tech Leads. I’m not sure I can really give you a good answer via email – I like your suggestion about meeting face-to-face but will have to do that when I’m back in London!
The challenge to “Riding the Paradox” in your situation, is seeing if there is anything that you can do to find a solution that lets you work on both things at the same time (those Tactical decisions should be contributing to overall Strategy, after all). Perhaps there is a technical solution that allows you to easily add new distribution channels , but I’d have to know more about the problem domain.
Another issue is support. We often have to push our support teams to give us feedback on our systems.
Are they easy to support? What features can we build for them that makes their lives easier. This can take pressure off the developers by reducing “3rd line” support requests they might receive.
Thank you much! A great post, and an issue I have struggled with many a time. An example is illustrated in my post: “A real world journey of fighting toward Continuous Delivery ”
http://subvertingcomplexity.com/post/journey-to-continuous-delivery/
An extract:
“Slowly it started dawning on me that the people with the most power to make the dev teams’ life better was the dev team. Business doesn’t live in our world. They do not feel our pain. They do not understand our problems. And hence they would probably never prioritise the ‘features’ we needed. Not because they were being nasty, or spiteful. Merely because they live in a totally different paradigm.
So we stopped asking for permission, and just started making the changes we needed to improve the delivery pipeline interspersed with our ‘normal’ development. It was by no means easy, as there was no let up in pressure, but the team, lead by some champions, kept biting at the problems little bits at a time. And so slowly, systematically, and consistently we started gaining higher ground. One by one, systems were configured to run through the CI server, and then to be deployed automatically. We wrote a tool to apply our DB scripts to the Databases (DbScriptomate), and then automated it. We still deployed on Friday evenings at 9 PM, but deployments started going down to under 2 hours. Then to under 1 hour. Then to 30 minutes.”
Great information, thank you. I just wanted to say this post has helped me tremendously and thanks so much for sharing such wonderful tips!