I’ve spent a third of my life leading tech teams in both the public and private sectors. Some teams were small (around ten people), and others were large (100s of people from many professions).
Over the years, I’ve focused on building teams, setting standards, and increasing maturity. After many years of leadership, my eyes have scanned all the ways of working at an organisational level.
The industry accelerated its maturity 10x over the last five years; however, there are still two things I see pretty often.
- Some companies and organisations still need to catch up in maturity at a higher level, which can hinder the learning and growth of those working within them.
- Those who matured the fastest have become disconnected from their best years and become stuck in their ways, limited by broken ways of working, processes, and bureaucracy. They need to remember what they can do to be great.
I want to discuss two things organisations did well yet have either stopped or been forgotten over time.
Technical insight/feasibility and prototyping at speed as early as possible in your project’s ‘understand’ or ‘discovery’ phase.
User Research and understanding the problem you’re trying to solve are essential and should be part of this phase. However, looking under the rug to see what’s there from a technical point of view and prototyping as soon as possible are equally important, primarily as teams have touched more surface areas.
When we only focus on the user needs at this stage, we often miss the possibility of a trapdoor the size of the Atlantic beneath our feet. All user needs might be null and void if the technical feasibility isn’t there. If we understand both, we’re in a much better position to avoid getting caught out later.
In addition to this, I’ve seen prototyping happen later and later in the discovery or understanding phases.
Prototyping enables us to learn something, anything, even if it’s terrible news. You can not understand that from ‘shiny’ UI or being devoid of putting anything in front of users to see if it will meet their needs. A prototype doesn’t have to be all singing and all dancing. It needs to be ‘just enough’, and ‘just enough’ can be done quickly and earlier than you’d think. The excellent time for this was 6-8 years ago, and since then, I’ve seen ways of working conform to something else: a non-agile, non-nimble, non-quick-learning process.
It takes maturity as a team and organisation to balance understanding, innovation, and technical feasibility. We used to do this. We used to treat it as fun, learning quickly and failing fast if need be. It takes a high degree of communication between a team and the ability to leave ego and bias elsewhere.
By understanding technical feasibility and prototyping earlier, it’s far easier to communicate with stakeholders and make them aware of what the playing field looks like. It mitigates the question of “Can we even do this?” and “It’s going to take six months of work and £XXX, XXX”. Whether there’s trouble ahead that you need their help to unblock or whether not to invest time, money and effort. It makes setting expectations easier as things progress.
Something I’ve talked about a lot over the last few months is ‘impact’, ‘impact towards outcomes’, and ‘speed of impact towards outcomes’ by people, teams, and organisations. Positive impact happens in many ways. Focus on positive outcomes; when your organisation does that quickly, it’s a win-win situation for everyone.
The two things I’ve described will get you there.
Remember, any process is a floor and not a ceiling. Any process can be challenged and changed.
Focus your process on the speed of impact on outcomes.