As ClearBank grew, it faced the challenge of maintaining its innovative culture while integrating more structured processes to manage its expanding operations and ensure regulatory compliance. Within boundaries of accountability and responsibility, teams were given space to evolve their own areas, innovate a little, experiment, and continuously improve, to remain innovative.
Michael Gray spoke about the journey of Clearbank from start-up to scale-up at QCon London.
ClearBank’s been on the classic journey of handoffs in the software delivery process, where they had a separate QA function, security, and operations, Gray said. With QA as an example, software would get handed over for quality assurance, before then being passed back with a list of found defects, after which the defects were fixed, then handed back to QA to test again. All of these hand-offs were waste in the system and a barrier to sustainable flow, he mentioned.
Gray explained that everyone is now a QA, as well as an engineer; the team that develops the software is also accountable for the quality of it. They maintain a QA function, however, their role is to continually coach and upskill the software delivery teams, maintain platform QA capabilities, and advise software delivery teams on specific questions:
We’ve found a significant increase in both quality and sustainable speed of software working this way. This also keeps the team’s feedback loops short and often, allowing them to make adjustments more quickly.
End-to-end ownership leads to direct and faster feedback loops, Gray said. A team seeing and feeling the consequences of poor quality sooner takes more pride in making sure software is up to a higher standard; a team feeling the pain of slow releases is more likely to do something to fix the slow release, he explained:
This is only true if we ensure there’s space for them to continuously improve, if not this end-to-end ownership becomes a fast way to burn folks out.
Gray mentioned that they are constantly trying to find the balance between autonomy and processes, and prefer processes that provide enabling constraints as opposed to governing. This allows people to make their own decisions within their processes that help them, as opposed to getting in their way and negatively impacting the teams.
As organisations grow, there is the natural tendency to add more and more processes, controls and overheads, but rarely do they review if the current processes are working, and remove processes and controls that are no longer necessary, Gray said. We try our best to be rigorous at reviewing our processes and controls, to make sure they are still effective, and having positive outcomes for the bank as opposed to getting in the way or creating wasteful overhead, he stated.
Gray explained that they communicate their strategy at three key levels to enable localised decisions:
- The business strategy
- The product strategy that supports that
- The technology strategy that supports both the business and product
Ensuring that strategies are clearly understood throughout the organisation helps people make much more informed decisions, he said.
Gray mentioned two aspects that enable maintaining an innovative culture while scaling up:
- Clear communication of the vision and mission, and a supporting strategy to ensure there’s alignment and a direction
- Ensure you create space in the system for people to experiment, so long as it is aligned with that strategy.
A mistake a lot of organisations make is trying to turn an organisation into a machine with very strict deliverables/accountabilities that take up 100% of teams’ time with absolute predictability of delivery, Gray said. While we should all have a good understanding of our boundaries and what we are responsible/accountable for, building and delivering software is not manufacturing the same thing over and over again and neither is evolving a complex system, it is a lot more subtle than that:
When we try to turn them into "well-oiled machines", it is not long before inertia sets in and we continue doing the same thing, no longer improving or innovating.
InfoQ interviewed Michael Gray about staying innovative while scaling up.
InfoQ: You mentioned that processes are reviewed and are being changed or removed if they are not effective anymore. Can you give some examples?
Michael Gray: One example is our continuously evolving development and release processes. This is a process that is very much in control of technology, where we are continuously reviewing toil, asking questions such as, "Is this step of the process still needed and adding value?"
Another example of this is how we review software for security. Previously we needed a member of the team to be a "security reviewer" which meant they would need to review every software release with a security lens. We automated this with tooling, and if software meets a minimum security standard, this can be automatically approved by our automation. All engineers now must have a minimum level of security training to be able to review software. This removed bottlenecks from teams for releasing software, improved the minimum security awareness of all our engineers, and removed friction from the process with automation, further improving our DORA metrics.
InfoQ: How do you support localised decisions at Clearbank?
Gray: We introduced the concept of decision scopes. We have enterprise, domain, and team. The question folks need to ask is who does this decision impact? If it’s just the team, make the decision, write an ADR (Architecture Decision Record) and carry on. If it impacts other teams in your domain, have a conversation, reach an agreement, or don’t- either way write the result down in an ADR. For enterprise decisions that are wide impacting we have our Architecture Advisory Forum.
