Mandates vs Automation - 3 Ways to Drive Org-Wide Code Changes and Migrations

Picture this, you are a developer at GenericTechCorp??. You receive a Slack message in your #general channel that reads, "URGENT: Upgrade version of the core auth framework from v14 to v16 - across all your services. The spreadsheet to track the migration is linked - mark your cell done by end of next week."

Your eyes narrow. You open the spreadsheet and find your stuff among the hundreds of other services that need to do this. You hit the bookmark button, put this sheet among dozens of other migration spreadsheets that you had already bookmarked and had forgotten to update.

Welcome to the world of driving org-wide code changes. In this article, we will cover three acts of driving best practices across the engineering org – typically 100+ developers or software components. The examples include

• Dependency upgrades, both internal and external libraries.
• Migrating to the latest version of a core library or framework.
• Replacing one library or tool with something else - e.g. how to invoke Feature Flags from code-bases from provider A to B.

Act I: The Mandates (Past)

The approach is simple: the organization mandates changes and you as a developer, track your misery or "progress" in a spreadsheet. Imagine three scenarios -

• Your Backend Engineering committee has a spreadsheet tracking how many services have migrated away from the older version of Java.
• Your Web Engineering council has a spreadsheet if we have started to use the latest webpack plugin or not - something which makes the web pages load much faster.
• Your Product Security team has a spreadsheet asking you to ensure if you have branch protection enabled in all your repository.

This is death by thousand cuts for developers. Announcements after announcements. Mandates after mandates. Neither the platform engineering teams can accurately track and measure the progress. Nor the developers find it easy to keep up.

Unfortunately, this is how majority of engineering orgs drive changes. And this has to go away.

Act II: The Incentives (Now)

The three inherent problems with mandates are

1. Why should a developer or team make those changes in the first place? How does it help them?
2. How to make that change? How many steps to follow and how much time does it take?
3. There are too many things a developer is being asked to do - resulting in cognitive overload

This is when every change or migration needs to have a little bit of gamification or incentives involved for developers.

Here is a screenshot of Harness Internal Developer Portal. Achieve a service maturity score of 75+ and you unlock the Gold Tier badge for your service! It tells you exactly what you are not doing and how to do them. Companies are slowly catching onto this approach, which has been accelerated by the rise of Developer Portals.

Features like service scorecards also replace the pull-based status updates into an automated adoption tracker – showing the current status of the change you want to drive in your engineering organization. No spreadsheets, no manual tracking, no tapping the shoulders to ask for status every Monday morning.

Act III: No one has to do anything (Future)

Imagine a world where a wave of your virtual wand applies changes across thousands of services in your org.

Yes, you heard it right. Automated pull requests, code reviews, and even AI-generated diffs to replace obsolete libraries or upgrade to the latest API versions. This is not Hogwarts - it is the future of Platform Engineering.

Industry trends like Infrastructure as Code (IaC) and AI-powered single file code changes are already laying the groundwork for this kind of automation utopia.

Let's take the example of using Scorecards to measure and enforce best practices.

What if when the developer gets to knows that they don't adhere to one of the security policies, a button called "Fix it" shows along side. You click on it, a code change is submitted on all your repositories. With automated CI pipelines and strong test automation, it's automatically reviewed and merged into your code base.

Even better, the platform engineer wants to make this change in the entire code base of their org. The developer does not have to do absolutely anything. All 200 or 20,000 repositories. Whether it is to upgrade a version from X to Y or replace a library from A to B with its API usage in every single code file or tests. The engineer writes a "change set", filters all the software components that this would apply to and hits "Submit". This creates thousands of automated pull requests on all the code bases with the proposed changed.

Best case, the developer only has to hit merge after all the green checks. Worst case, they have to do a manual check on the staging environment to ensure the changes don't break anything.

Changes happen in weeks and not months with a tiger team driving migration. This is what Kelsey Hightower was saying at Unscripted - "make the changes in your platform and don't bother developers with unnecessary mandates."

Conclusion

As the platform engineering reaches the top of Gartner Hype Cycle in terms of expectations - the stage is set for the third act to become our new reality. It's not merely about streamlining processes; it's about revolutionising how large engineering orgs drive changes at scale. This is not just a pipe dream; it's the future of Platform Engineering.