The Holiday Rule
New language? New database tech? New abstraction layer? New cloud provider? No more cloud provider? New CI/CD component? New Monitoring? New test framework? New build system? Drop-in replacements? New RBAC system?
Subject them to the holiday rule
!
As an engineering lead, be it at team, department or company level, being at least in part responsible for the technology stack you’ll at some point have to let go of making all decisions yourself. If you hang on to all decisions, you’ll find yourself being a top-down, controlling, blocking, overworked and ultimately grumpy tyrant.
So, how do you give some freedom and responsibility to team members when they suggest new libraries, languages, components and frameworks? Let me introduce you to the holiday rule
.
If you pick any technical component and there are no 2 colleagues available that can support it, you're not allowed to go on holidays
How serious is this?
You can make this as serious a topic as you deem it risky to implement the proposed piece of tech. Most of the times it’s a tongue-in-cheek threat. But, then again at times it’s not. Depending on the importance of the system and the impact of the tech chosen, you actually might want to play this out to the end and challenge not just the person picking the tech, but also the colleagues that co-support it.
Why does it work?
If people can explain you that holiday planning is not going to be an issue, they’ve got some of the most important bases covered: support and buy-in from colleagues. They collected enough support in the organisation to seriously consider their proposal. Most hot-off-the-press, just-came-out-of-stealth, hot open source and I-got-inspired-by-something-pure-and-beautiful tech will not get enough buy-in from the team. True buy-in that is putting holidays at stake, not the i-agree-that-this-is-interesting buy-in. You will find yourself saying 'no' less and 'maybe' more
.
Various things are at work here:
- The more wide-spread the effect of the newly chosen tech, the harder a person has to lobby to gain a support group.
- Most single teams hold less than 6 engineers, so you’re effectively asking for a majority vote if the tech only hits 1 team.
- You’re not just committing the person proposing the tech, you’re also committing the (at least 2) co-conspirators.
- If the tech spans multiple teams, you will require cross-team collaboration and communication (never bad).
- If you don’t like a chosen tech, you have at least 3 people to talk to. First of all, that’s fair, because you probably hold some given or earned power, so most 1-on-1 conversations are imbalanced. Talking at least 3-on-1 keeps that balanced.
- It’s more likely to have a good conversation with 4 people about pro’s and con’s than it is to have that conversation 1-on-1.
- If you propose alternatives for the chosen tech, you immediately have a good group of peers to have a sparring session with. Your pick will also see scrutiny.
The holiday rule doesn’t block you from making clear, strong, smart decisions when you need to. Decisions by committee are not always the best. That is, as long as you backup your tech choices, with a knowledge management and/or training plan so that you and your team members can go on Holiday. Give people the time to play, to experience and to learn especially on components that they didn’t pick.
You have to face the fact that at some point you will simply not be able to catch up with all things new in the industry
. The larger the team you manage, the larger the product you architect for, the less likely it is that you know of all nooks and crannies and smart things you could do.
Furthermore, the further you are along in your career, it becomes increasingly likely that you hold a position or have a stature that skews any technical proposal
. Great ideas might not reach you!
The holiday rule gives ideas a fighting chance. It creates as way for any team member to drive a technical change conversation. If you don’t like the change, the holiday rule will keep you on your toes and raise the quality of your decision making.
Last, but not least, the holiday rule scales! Small team, small choices, short lines. Large department, many teams, many sub-leads. If each and every one of them follows the holiday rule, most tech choices will naturally get the right amount of scrutiny and support, also when you are not directly involved.
Hope it helps!
Wilco