Atomic is home to lots of very high-level wizards. Their abilities and specialties span the whole of the software craftsmanship space, and each one has their own skill set to leverage when tackling the many unique problems that come through our door.
I’m not a very high-level wizard yet, but I’ve found that deliberately striving to steal/pick up spells/skills from others as I observe them has been a pretty productive way to level up.
Lately, I’ve found that my project has been very turbulent, with new and changing requirements and ever-increasing demands for unavailable resources. Being unable to fulfill every one of those needs has been making me anxious. So, I observed how my higher-level teammate and Delivery Lead handled the situation and noted that he’s been carefully protecting our project: He’s been really good at saying no.
For wizard consultants, this is a Protection Spell, and it’s a very valuable skill to have. It’s not feasible to constantly build new things or go to battle; sometimes, we need to be on the defensive or to resist a certain change. Maybe we need to protect a codebase’s integrity, to protect a project from going over budget, or to protect ourselves from burning out. In these times, it’s important to be able to stand our ground and say no.
Protecting a Codebase
Codebases, like all things, tend toward chaos. The outside world is chock-full of special cases; it wants your code to be more convoluted, more brittle, more confusing. The developer’s job is to protect the code from the pull of chaos by being a steward of code quality and craftsmanship.
Some of the protection spells I’ve cast on my codebase have looked like this:
- No, we shouldn’t add a special case here. Can we update our model to be more robust?
- No, I’m not copy-pasting that component. Can we make it more generic, so both of these tools can use it?
- No, Module A shouldn’t be doing something that is Module B’s responsibility, even though it’s easy. Can we make it easier for Module B?
Protecting a Project
It’s easy to for a project to fly off the rails quickly if we don’t take steps to protect it. This is why Atomic is careful to keep an eye on scope control. It’s very hard to say no to cool new ideas and urgent tasks, but we need to protect the integrity of the project in order to find success in the long term.
This may look like:
- No, we’re not going to mix unplanned-for items into the sprint; it’ll jeopardize these features getting done on time. Let’s add them to the backlog and prioritize them.
- No, we’re not going to make everything top priority. We have to prioritize to protect ourselves from risk.
- No, we can’t add Feature X. It’s in direct conflict with Feature Y. What’s the business need we’re trying to serve?
Protecting Yourself
I’ve found protecting myself to be the hardest item on this list. When push comes to shove and something isn’t going to get done without more resources, my time/health/happiness is the “easiest” thing to sacrifice since it doesn’t seem to hurt anyone else.
I’ve found that I can work up the nerve to protect myself if I try to remember that failing to do so will eventually come back to hurt others in the form of missed commitments and a burnt-out teammate.
I might need to say:
- No, I’m not going to promise that I can do X amount of work in Y amount of time. That’s not realistic, and you and I are both just going to end up disappointed. What’s the highest priority?
- No, I’m not going to accept responsibility for Thing X. I don’t have the power to change it. Is there someone who does?
- No, I’m not going to sacrifice my own happiness/personal time for this new task. If I do, nobody will know that this workload is unsustainable until it’s too late.
Protection Spells are Really Hard
I learned while practicing this skill that saying no can be incredibly uncomfortable. We’re builders, people pleasers, and makers. It’s right there in the name.
We want to say yes, and then we want to make it happen. Bending over backward for people gives me a sense of accomplishment; I’ve done the impossible. But doing the impossible can have some pretty severe consequences:
- We’ve set an unsustainable precedent.
- We’ve set expectations too high and are going to disappoint.
- We’ve agreed to something that is ultimately going to be harmful to the code, our project, or ourselves.
I’m definitely still honing this skill, but being conscious of these consequences helps motivate me to cast protection spells when they’re needed.
I’ve also found that it helps to ask for help when trying new spells: I told my teammate that I was having a hard time saying no to a request, and he offered to back me up and cheered when I succeeded. This lessened the sting of saying no, and it replaced some of the missing sense of accomplishment that I would have felt if I said yes.
I’ve been writing about skills learned from my senior colleagues for a little while now; check out my other Wizard Skills™ posts!