Big and small, companies have similar mission statements.
Make a product so good that people who don't work for you are excited to tell their friends. Charge people for the product. Make money.
Sometimes, larger companies have an even narrower focus.
Buyout the competition. Charge people for the product. Make money.
hint: run far away from companies that grow significantly through acquisitions. They care even less about the journey.
The problem is that these mission statements describe the "destination" and ignore the "journey".
Competent leadership is as much interested in the how as they are the what, for they know that to get from A to B, there's a journey. Poor planning and preparation can be cause for a much longer and harder journey.
Welcome to Enablement Engineering
I just coined this term. Maybe it takes off. Enablement Engineering is about writing automation, abstractions, conventions and patterns that work across teams and projects. It's about being passionate for honing the "Developer UX" of tools and processes. Finally, it's having a deep understanding of the costs and risks involved in writing and deploying software, both from 3rd parties such as AWS, Heroku, Datadog, etc, but also the time factor that keeps developers from moving as quickly as they can, since in theory, you could measure the cost of a feature, by how long it takes to deliver it.
Here's the evolution of Enablement Engineering:
Stage 1
- Convert a runbook with manual steps into a script
- Use workflow tools like Jenkins
Stage 2
- Run the script above in response to an alert or page
- Store workflow definitions as code (like yaml) in a git repo.
Stage 3
- Perform Blue/Green and Canary Deployments with automated rollbacks.
- Templatize/Parameterize your YAML files to increase reuse and encourage patterns.
Stage 🧙♂️
- Write frameworks and libraries for your configuration in order to reduce copy/paste and boilerplate
- Leverage Git hooks, PRs and Merges to automate the generation, linting, and validation of configuration
- Write Kubernetes Operators that detect and automatically converge/resolve differences in current state vs desired state (e.g. MySQL Failover, K8s [mutating] admission controller, anything that listens to logs, metrics, or events)
- Enable "Branch-Based" deployments for all applications. Meaning, a full, usable, isolated deployment of their application every time a new PR is created. That environment would also automatically be torn down when the PR is merged or closed.
When you reach the end, things seem to "just work". There's seldom a need to perform any "special" or "adhoc" tasks or deployments. And all code and configuration is in Git, allowing developers to interact with, update, and manage every aspect of their application and operational mechanics without needing to reach out to another team.
Teams become autonomous units, being able to focus on delivering features as fast as they can think them up, all while maintaining a high level of confidence that nearly every conceivable check, pre-check, alert, or rollback is being done automatically to keep the application running with minimal customer impact.
Every tool, every new feature that an ENABLER writes, can be used by any team, and any project.
This has an exponential effect on the business's bottom line. The ability to deploy and maintain high quality code by doing what developers already do... commit.
When builds and deployments happen in minutes vs hours, days, weeks, or months. Developers can move quickly, write, commit and publish smaller, low-risk changes more frequently. They can perform A/B testing to get feedback on design decisions. They can react in real-time with the demands of the business.
Top comments (1)
Fascinating writeup! Would love to hear more from you