Make the Easy Way the Right Way
Feature teams differ from teams working on common infrastructure in some important ways. While feature teams focus on solving customer problems, infrastructure teams need to provide services that are used widely throughout an engineering organization. Anything that isn’t related to business logic, like maintaining workflows to meet security requirements, should be treated as a service.
The best way to develop services like this, I think, is to rely on abstractions. These can provide greater functionality and improve features built on them over time. The higher the abstraction, the greater the potential value. But this comes at the expense of constraining developers and teams
Given this tension between abstraction and constraints, how should a common infrastructure team approach building services? My view is that any tool is best designed when it gets out of your way and makes things easy. This requires a combination of sane defaults, straightforward conventions, and simplicity that allows feature teams to focus on their goals — and not the service itself.
The entire workflow has to be treated as a product
At PlanGrid, we used these guiding principles to create our development experience with a specific end goal: that teams use our common products because it’s the easiest way to do things, even when under pressure, and not because it’s dictated. I call this making the easy way the right way.
Merging easy and right is how you scale up development. The entire workflow has to be treated as a product and sold accordingly. The constraints and abstractions put in place must give feature teams the freedom to focus their creative energy into solving their customers’ problems.
Painting is a good analogy. Oil, acrylic, and watercolor can all be used to paint, but few great artists use them together in one work. Painters constrain themselves to one tool in order to create something beautiful, and they take advantage of the particularities of that tool. They don’t overload themselves with switching contexts. By removing the cognitive load of managing multiple tools at once, they can focus on the goal of expressing themselves through their art. In the same way, making the easy way the right way removes the cognitive load for engineers so they can focus on the customer’s problem.
One drawback of this approach is that it has the potential to limit a team’s choices. The cloud space and its available tools are constantly evolving and improving, which potentially prevents a team from using a very specific tool to solve their problem. Two things help mitigate this risk. Extension points should be built in to allow future enhancements, and you need to address the tax required in maintaining the tooling long-term.
Let’s start with extension points. These are one of the best ways to future proof a tool. It’s important to remember that you are never the top layer, and if you create something useful, others will build on top of it. Extensions can be hooks to call out to new code, such as a Git hook or webhook, or they can expose more of your features as APIs so others can programmatically built on top of you.
These ideals have to be built into the products your provide with an eye on preventing over reliance or requirement of their use. In the end you have to solve real problems. If all of your users are using different bespoke extensions to do the same thing, you haven’t built something truly useful yet.
A large part of making the easy way the right way is keeping things simple. Limiting choices for non-essential decisions gives people more time to solve real problems. This prevents the Paradox of Choice and encourages people to look at problems with the eye that Done is Better Than Perfect. Their problem might not be solved perfectly, but it’s more important that they’re unblocked.
What about the tax involved in maintaining your tooling long-term and the trust you have in them? Most senior and even mid-level developers would question adding a tool with two stars on Github as a required dependency. And it’s easy to see why. They lose time fixing broken dependencies after Webpack upgrades, and it’s certainly no fun to understand why deploys are failing on a tool no one knows about because of unknown fields in a config.
Trust must be earned
Services add additional dependencies on other teams. Anytime you use something maintained by someone else, you are beholden to them in some way. At its core, this is an issue of trust. Many companies trust AWS for services like RDS or SQS even though they have nearly zero ability to influence roadmaps and give feedback. If you use something from an internal team, you have to similarly trust that they will build a quality product and be responsive to your evolving needs. Trust must be earned.
One of the most effective ways to empower teams is to give them the ability to focus on their work. This is the whole idea behind Serverless. Small companies today can do more faster by leveraging Heroku, GCP’s App Engine, or AWS’s Lambda exactly because they are highly prescriptive systems. In larger companies, this becomes even more critical as requirements and regulations become unwieldy. No developer wants to spend time collecting SOC2 audit data or figure out how to bridge two VPNs so their app deploys. The complexity of handling these requirements should be provided as a service to feature teams.
A rising tide lifts all ships, and everyone benefits from enhancements to tooling without getting lost in problems that are specific to just them. In this way, making the easy way the right way ends up being a powerful force multiplier.
