Most values are cringe. They are corporate-sounding and bland truisms that cannot be used to guide teams or set direction. We can do better.
- Good values help you make decisions. They say, “We care about X more than Y.”
- Good values help you make a decision once and reuse it.
- Good values are opinionated.
The last point is key. Values have to be at least a bit disagreeable to be useful; values that sound like universal truths are wasting space on your page.
For example, in Platform teams, it is common to ask: what’s our role in this project?
- Are we implementing the whole thing? e.g. migrating everyone to micro-services.
- Are we implementing the first few examples, and then driving adoption? e.g. building a few micro-services, then asking teams to do it themselves.
- Are we consultants? (What’s consulting?)
- How hard should we drive the adoption of each new pattern?
- Do we create new patterns and frameworks before they are needed, or wait until there is a clear need?
Sometimes the answer is “it depends”! However, if your answer is “it depends” all the time, then you are wasting precious time, focus, and attention energy re-negotiating every case. Once you have seen a few examples, you can find yourself and your team ready to write down a few heuristics. These heuristics are values — values help you make consistent decisions quarter after quarter.
Consistent decisions lead to consistent behaviors, which lead to consistent interactions with your teams, which lead to consistent expectations.
Example 1
- We will not create new patterns or frameworks in a vacuum. Instead, we will always wait for 3 examples before designing abstractions.
- We will always migrate 2 examples, and drive organic adoption for the rest.
- Our success is measured by the degree of organic adoption. If adoption is poor, then clearly the problem wasn’t sufficiently painful, and we have prioritized inappropriately.
- As a result of this mode of working, we accept that some of our stakeholders will experience pain and friction that remains unaddressed because we have yet to see enough examples to confidently build an abstraction.
This is an example of a value: we prefer to abstract well and late, instead of early and wrong.
Example 2
- We will proactively forecast the needs of our stakeholders by studying the roadmaps of our stakeholders. By understanding where the company is going, we can identify gaps in our Platform and build them ahead of time.
- For instance, if we project doubling headcount, we will proactively build onboarding tools and other DevX improvements. We will prioritize work that gets us to higher code quality and consistency (e.g. linters) in the face of an incoming workforce with diverse preferences and biases.
- Because we value consistency and reducing friction, for every pattern or framework, we will always start by (a) introducing controls to enforce the adoption of the new pattern, and (b) migrating 80% of the existing occurrences that are out of compliance.
This is another value! It says, “We prefer to forecast and build early, even if we might get it wrong”. Furthermore, it states a more opinionated approach to driving adoption.
Example 3
- We expect the Platform team to be consistently resource-constrained, and to maximize efficiency, we prioritize self-serve.
- This means documentation.
- This means building tools that others can use without assistance.
- This means training.
- This means building UX and DevX with nudges and guardrails.
- This means understanding the work in our triage queue and backlog and prioritizing automation.
- This means measuring and reducing operations load.
- This means that every “consulting” engagement is an opportunity for us to learn how to improve on the above dimensions so that teams can self-serve in the future without consulting.
The above examples describe values for 3 different teams. All of them are valid, and it depends on your needs.
My current teams have two values:
- Value 0 is Self-serve. This means we build for others, then get out of the way. If teams we support keep depending on us for daily operations, then we have not built it right.
- Value 1 is YAGNI. We aim to build the minimum we need, using technologies we already have, and evolve as we grow. Assume there is more unknown than known, and use evolution to drive change.
🌶 Hot Take 🌶
Saying “We will evaluate this on a case-by-case basis” is not leadership. It is an abdication of responsibility.
