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 Delivering versus Learning.
The case for delivering
In the commercial of software development, there will always be pressure to deliver software that satisfy user needs. Without paying customers, companies cannot pay their employees. The more software meets user needs, the more a company earns, and the more the company can invest in itself.
Business people will always be asking for more software changes as there is no way of knowing if certain features really do meet user needs. Business people do not understand (and cannot be expected to fully understand) what technical infrastructure is needed to deliver features faster or more effectively. As such, they will always put pressure on to deliver software faster.
From a purely money-making point of view, it is easy to interpret delivering software as the way of generating more earnings.
The case for learning
Software is inherently complex. Technology constantly changes. The problem domain shifts as competitors release new offerings and customer needs change in response and evolve through constant usage. People, who have certain skills, leave a company and new people, who have different skills, join. Finding the right balance of skills to match the current set of problems is a constant challenge.
From a technologist’s point of view, learning about different technologies can help solve problems better. Learning about completely different technologies opens up new opportunities that may lead to new product offerings. But learning takes time.
The conflict
For developers to do their job most effectively, they need time to learn new technologies, and to improve their own skills. At the same time, if they spend too much time learning, they cannot deliver enough to help a company to reach their goals, and the company may not earn enough money to compensate their employees and in turn, developers.
Encouraging learning at the cost of delivering also potentially leads to technology for technology’s sake – where developers use technology to deliver something. But what they deliver may not solve user needs, and the whole company suffers as a result.
What does a Tech Lead do?
A Tech Lead needs to keep a constant balance between finding time to learn, and delivering the right thing effectively. It will often be easier for a Tech Lead to succumb to the pressure of delivering over learning. Below is advice for how you can keep a better balance between the two.
Champion for some time to learn
Google made famous their 20% time for developers. Although not consistently implemented across the entire organisation, the idea has been adopted by several other companies to give developers some creative freedom. 20% is not the only way. Hack days, like Atlassian’s ShipIt days (renamed from FedEx days) also set aside some explicit, focused time to allow developers to learn and play.
Champion learning that addresses user needs
Internally run Hack Days encourage developers to unleash their own ideas on user needs, where they get to apply their own creativity, and often learn something in the process. They often get to play with technologies and tools they do not use during their normal week, but the outcome is often focused on a “user need” basis, with more business investment (i.e. time) going towards a solution that makes business sense – and not just technology for the sake of technology.
Capture lessons learned
In large development teams, the same lesson could be learned by different people at different times. This often means duplicated effort that could have been spent learning different or new things. A Tech Lead can encourage team members to share what they have learned with other team members to spread the lessons.
Some possibilities I have experienced include:
- Running regular learning “show-and-tell” sessions – Where team members run a series of lightning talks or code walkthroughs around problems recently encountered and how they went about solving it.
- Update a FAQ page on a wiki – Allows team members to share “how to do common tasks” that are applicable in their own environment.
- Share bookmark lists – Teams create a list of links that interesting reads based on problems they have encountered.
Encourage co-teaching and co-learning
A Tech Lead can demonstrate their support for a learning environment but encouraging everyone to be a student and a teacher at the same time. Most team members will have different interests and strengths, and a Tech Lead can encourage members to share what they have. Encouraging team members to run brown bag sessions on topics that enthuse them encourage an atmosphere of sharing.
Weekly reading list
I know of a few Tech Leads who send a weekly email with interesting reading links to a wide variety of technology-related topics. Although they do not expect everyone to read every link, each one is hopeful that one of those links will be read by someone on their team.
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.
“Business people will always be asking for more software changes as there is no way of knowing if certain features really do meet user needs.”
That seems completely inaccurate to me. Most businesses will have someone whose role on the team includes translating the business requirements into concrete features in the application(s). It should be completely possible to say whether a feature implemented with a specific purposes meets the business requirements or not.
Hi Gabriel. Thanks for your comment. You are correct, that there is normally a role on the team, who has the responsibility of translating business requirements into concrete features. I have found they are called either a Product Owner or a Business Analyst.
In my experience, “business requirements” do not always match what user needs really are, even with very good user research. Each business requirement is gamble or a guess, with the hope that the feature meets a user needs.
Users also have interesting ways of using an application, in ways that a Product Owner of Business Analyst can never predict. I have also found that as users interact with a product, their usage patterns evolve, and so their user needs change. How they will evolve, or why is never guaranteed.
I have also seen this occur as Product Owners or Analysts see working software. They experience moments like: “I like this (feature/screen) here. It would be even better if…” This is where I have found showcasing working software, or prototyping very effective.