Going Faster
Speed is necessary in technology businesses. Challenges faced by these companies change all the time. Capability to adapt will make or break businesses. Change should be easy, with anti-fragility built-in.
I use the following framework to think about systems of change management and adapting to challenges frequently
Culture
Speed is primarily a cultural problem. Organisations with better information-flow function far more effectively than their peers. Start by taking a hard look at where the company lies on inter-team collaboration. Embracing a lean way of working simplifies the culture
Organizational culture is perceptual, and therefore, best measured using surveys.
Tactical suggestions I have found the Westrum survey measures (referred below) to be highly valid and reliable statistically. Run similar surveys across teams to measure culture, reveal gaps in team development and empowerment.
Process
Speed is also bottlenecked by inefficient processes. It is impossible to have a pull-based view on what is happening, if organizations are machines then we should know what is going on. Lean product development practices need to be in place, with, biggest one being value stream mapping. SDLC is needed to standardise: who owns what becomes clear.
As slow down happens: Lead time becomes significantly high compared to cycle time.
Key metrics to measure performance
What is not standardised, can’t be optimised. Standardisation makes measurement possible, giving companies clear levers to improve.
Tactical suggestions
- Have clear top priorities across the organization, with a Changelog
- Clear decider for projects which even spans across various teams
- Split backlog for each team into good-to-have and must-haves, with must-haves not more than a certain % (let say 40) of staffing
Technical Capabilities
Finally, speed is also increased with better capabilities. Getting basics right early is important, as getting them right later will always cost more. Most of the standards are very well known and researched. Listing a few here
- Version Control
- Deployment automation
- Continuous integration (CI)
- Trunk-based development
- Test automation
- Test data management
- Shift left on security (DevSecOps)
- Continuous delivery (CD)
A common pitfall I notice is that several teams, in spite of the right basics in place, lack well defined, known and adopted standards around various stacks. Continuously revisiting the adoption of these practices again as headcount churns, is equally crucial.