How to do Rapid and Continuous Technical Evolution

A primary responsibility of a senior technical team (CTO & Down) is to keep technical strategy progressing and fit for purpose. This means supporting an environment to enable experimentation leading to technical evolution. This sort of facilitation takes experience, technical enablement and know-how to do it right. Let’s briefly discuss how this might work.

A Bias For Action

Bias for Action is an incredibly useful principle to embrace for technical progression. An experienced architect or technical lead will understand that ‘perfect is the enemy of good’.

Having a bias for action means that a technical lead will experiment to stand something up quickly for evaluation and rapid feedback. This evaluation facilitates answering questions on feasibility and correctness. Which helps the org decide to invest to pursue things further.

Analysis paralysis is at the other end of the spectrum if you try not to do too much up front. This is something to avoid. As it will present questions that you cannot answer. And can result in leadership becoming hesitant to support your endeavour.

Make it Work – Enable Fast Experimentation

Lets’ think about this phrase from Kent Beck:

Make it Work, Make it Right and Make it Perform

Kent Beck

In most modern cloud organisations, developers and teams have access to their own account. This comes with liberal permissions and access to services that they might not have in their test and production accounts. Teams are comfortable in using the console to rig something together to get it working.

A lot of the workshops available from the cloud provider are taught or explained using the console. By embracing Serverless-First, your teams will find that their experiment excels. Services have low ops and high configurability. Experiments take only a few hours. And it evolves into an excellent way to facilitate experimentation and learning across all teams in an organisation.

Make it Right – Commit

Experiments born in the console should ideally never make it into a higher environment like dev, test or production. It violates everything good that we know about Continuous Integration and Continuous Deployment. And it goes against how we like to have our teams aligned with the Well Architected Framework.

The next phase is ‘Make it Right for right now, after the experiment passes initial feasibility and correctness challenges. This is where the team will begin moving the solution to their Infra as Code (IaC) framework.

You can commit to a Well Architected Review at this stage. A Well Architected Review helps to check your setup. It looks at Cost, Security, Performance, Reliability and Operational considerations. You can ‘make it right’. And you can move to a higher environment eg. Test or Production. And get more validated real use feedback.

Make it Perform – Invest in Future Value

Your experiment could enable a future product. And it could help a team facing the same technical challenge. The team or organisation may decide to extract an abstract pattern from their experiment. And place it into the open-source repo or developer self-service portal, such as Backstage.io.

This will allow other teams to learn from the original work and embrace something that has been hardened in a production environment. This enables other teams to deliver quickly in a safe reliable manner. There are scaling and speed benefits. And typically teams consuming the pattern will submit changes and enhancements to the original pattern. It gives your experiment a life of its own.

This may lead to many other higher-order implementations. This is a Value Flywheel effect. We describe this in our book: The Value Flywheel Effect.

Technical evolution is an important characteristic for any organisation looking to leverage the Modern Cloud to its full potential. A significant requirement of supporting technical evolution is having a Bias for Action mind-set. Along with having the discipline to apply the rigor of Well-Architected configuration. And that opens up the path to higher environments for the experiment.

With organisational support for sharing that production hardened pattern with other teams. And by supporting future enhancements and contributions means that the organisation is set up for sustainable technical evolution and efficacy in delivery.