At Typeform's Engineering department, we had an exciting process for adopting standards that suffered from a major flaw. This process empowered every developer to propose standards that would not only benefit the company's growth but also enhance the developer experience and ensure consistency.
The process was straightforward:
The significance of this process is substantial. Firstly, it ensures that improvements implemented are adopted widespread throughout the company. This is crucial for changes whose benefits are only realised when implemented on a large scale.The decommissioning of a deprecated service is only possible once all dependent services have ceased using the old API
Secondly, this process simplifies the contribution to any project within the company. With the internal open-source model followed at Typeform, developers frequently contribute across different projects. By standardising certain aspects, the process of understanding and adapting to different project environments becomes much less daunting, thereby increasing the ease and frequency of cross-project contributions.
The initiative deeply resonated with Typeform developers. It was more than just a process or system; it was an opportunity. An opportunity for developers to make an impact beyond their team boundaries. It aimed at enhancing their personal developer experience while making a comprehensive, company-wide difference. As a result, developers were highly engaged, submitting numerous proposals and engaging in rigorous discussions during review.
However the reality was that adoption was extremely low. Despite enthusiasm and successful implementation in some teams, many projects remained stagnant for months without any signs of adoption. The teams that embraced the changes quickly were outnumbered by those that did not. Overall, adoption fell short of expectations, below 40%. This low adoption rate posed a significant challenge to the effectiveness and impact of the initiative.
Furthermore, the low adoption rate began to take a toll on team morale, with developers becoming disillusioned over the process. They had put time and effort into creating proposals and engaging in discussions, but the lack of progress was disheartening. This was more than just a setback in a project; it was beginning to reflect poorly on the organisation. It was reminiscent of the broken window theory - if a window in a building is broken and left unrepaired, all the rest of the windows will soon be broken too. Similarly, the stagnation of this initiative was akin to a 'broken window', which if left unattended, could potentially affect the overall functioning and perception of the company. It was critical to address this issue promptly, to prevent it from influencing other aspects of the company's operation, and more importantly, to maintain the trust and confidence of the developers.
One of my teams and I, Engineering intelligence, decided to accept the challenge head-on. The mission of this dedicated group was to harness the power of data and utilise it in a way that not only made the data comprehensible but also actionable. Their main objective was to visualise data in a manner that would empower the entire engineering organisation to make informed, data-driven decisions. We had a motto: Accountability through visibility.
When I analysed the situation through the lens of ADKAR (Awareness, Desire, Knowledge, Ability, and Reinforcement), it became evident that a data-driven solution was the ideal approach. The teams were well Aware of the need to adopt these standards. The initiative originated from their own ideas, fostering a strong Desire to implement it. With the necessary Knowledge and Ability, they were fully capable of executing the standards. But Reinforcement demanded focused attention. The team recognized the need for an additional push – a form of affirmation or reward – to create a feedback loop and encourage active participation from all teams.
While some projects encounter challenges when adopting a KIP-oriented approach due to lack of awareness or resistance to change, this specific project stands out as an great fit for a metrics-driven strategy.
Armed with this valuable understanding, we developed a strategic plan:
For project to succeed, it would act as a catalyst for continuous change. It would empower every developer at Typeform to make a significant impact across the organisation, elevating engineering practices and boosting team morale.
Over the following months, the Engineering Intelligence team at Typeform tirelessly carried out the plan mentioned earlier.
Setting ambitious yet attainable goals was not a challenge. After thorough discussion, I agreed that aiming for 85% overall compliance by the end of the quarter seemed reasonable.
In certain cases, exceptions had to be made. These were driven by unique circumstances of each team. Such exceptions were not taken lightly or made arbitrarily. Each instance was the product of thoughtful discussions between engineering managers and their directors.
Facilitating frequent tracking was a seamless process too. Typeform already had well-established procedures and rituals in place to serve this purpose. The initiative was officially announced during the engineering all-hands meeting, and the 85% target was incorporated into each team's OKRs. Engineering Managers would provide progress updates in their dedicated section within the Monthly Business Review. Additionally, we would send periodic reminders on Slack once a month to every team's channel.
Our layered approach to communication ensured that progress was constantly monitored and goals were consistently in sight. This set-up did not just aim for compliance to the initiative; it cultivated an environment of mutual accountability, drive, and, ultimately, success.
The tooling was one of the most exciting aspect. We understood that different audiences had unique requirements, so I identified two primary personas: Teams and CTOs. Each team had access to a comprehensive dashboard that showcased their compliance with individual goals, along with an overall score. Directors and CTOs, on the other hand, could effortlessly track the progress of the overall score across all teams, with the added flexibility to segment by standard and team.
Each visualisation adhered to the 5-30 seconds rule: Every chart must tell if you are on track in less 5 seconds. And allow you to identify where not in less than 30.
The Engineering Intelligence team devised an ingenious modular approach for implementation. They created an application called the Standards Adoption Tool, which performs periodic scans of all repositories within the organisation. Next, a set of evaluators, written in JavaScript, is invoked - one for each standard. These evaluators provide a compliance score and detailed explanations. The collected information is stored in a database and can be visualised using a Looker dashboard.
This was ingenious because creating these evaluators made it accessible for any developer who wanted to implement a standard. It offered a cost-effective solution that would greatly benefit adoption. More on the tool on their post "Adoption of engineering standards at Typeform".
As expected, we encountered challenges regarding the data quality. Initially, it was unclear which team was responsible for each repository. Numerous repositories were mislabelled or remained from past projects that had been abandoned. However, through the diligent efforts of our Engineering Manager and the implementation of automation, these issues were swiftly minimised.
The results couldn't have been better. Just a few weeks after the roll-out, the impact was already tangible. Initiatives that had remained stagnant for months suddenly started gaining momentum. And I'm delighted and proud to say that this success wasn't solely due to the novelty of the release.
While we didn't quite reach the precise target we set for the first quarter, aiming for 85% but landing at 83%, it remains a remarkable accomplishment considering our starting point was below 40%.
Additionally, we successfully exceeded the 90% threshold in subsequent quarters. It is important to note that this goal was constantly evolving, with new standards being introduced each quarter.
The impact was not only evident in the numbers but also in the behaviours. It was clear how the approval discussions for proposals became more thorough and people became more open to challenging them. To me, this is a clear win. People genuinely wanted to understand what they were getting into and ensure it was worthwhile because once agreed, it was set in motion.
This impact goes beyond the implementation of new standards. Typeform's engineering team now possesses an internal framework for driving change, which feels like a magic wand for making things happen. It has helped people grasp the power of metrics and placed developers at the forefront. All of this is thanks to the utilisation of data visualisations and a few tried-and-true change management techniques
I'm a fractional CTO that enjoys working with AI-related technologies. I have dedicated more than 15 years to serving SaaS companies. I worked with small startups and international scale-ups in Europe, UK and USA, including renowned companies like Typeform.
I now work helping startups achieving high growth and performance through best practices and Generative AI.