If your job was installing an oven in a kitchen, and on the day you do your install the electrician hasn’t installed an electrical socket where the oven’s supposed to go, you wouldn’t run an extension cord just to get your oven to work. You’d tell the foreman you’ll come back when they’re ready for you to install the oven. And then later when you are installing your oven, let’s say the kitchen sink starts leaking. You don’t go ahead and try to fix it. It’s not your oven!
– My husband, trying to get me to see that I was actually solving other people’s problems
This is about boundary setting.
Okay, so you may be good at this, but I have a serious problem with boundary setting. I enjoy doing things people need me to do because I feel useful. It’s a pretty nice feature to have as a developer, because you shouldn’t be super overloaded and therefore have the capacity to support other people on your team, which is just great teamwork and followership.
But now, I’m leading a team. In which case this personality “feature” becomes a pretty big issue because my responsibilities as a lead already stretch me pretty thin. You couple a bunch of responsibilities with an inability to say no, and then you get burnt out – or maybe just sad.
When my husband gifted me that oven metaphor, it put this issue into perspective… myself and my team were totally “running an extension cord” for our solutions when other external dependencies were behind. We were helping fix the “leaky sink” because it would have flooded our oven and we weren’t going to be able to sleep well at night knowing that the project we’re working on was suffering. Sometimes, we would actually step in as acting foreman to help coordinate different efforts. I realized we were doing all of that because in software, especially at a services company, it’s really hard to define what the team’s oven is exactly.
What’s my team’s oven?
It took me forever to try to define what exactly was the extent of our work product. Was is just the product we were working on and tasks we were assigned? We take pride in helping our customers… were they our oven too? Or were they the sink? Do we even have a foreman right now?
I’m not going to pretend I can help you define what your team’s oven is. It’ll be extremely context dependent and it might be something totally different at the end of a project than what you thought it might be at the beginning of the project. This is something you should talk about with your manager. Because it changes over time, I’d recommend revisiting the conversation throughout the project.
I will say that if you can answer yes to any of these questions, it’s probably not your oven:
- Is this problem a part of someone’s current set of responsibilities?
- Was this problem introduced by someone else?
- Would managing this problem push you or your team past capacity?
- Is this unrelated to anything your team has worked on directly?
Mastering the art of saying “that’s not my oven!”
Once you do figure out what your oven is, be sure to start identifying what tasks come to the team that aren’t oven related. If you’re bad at improv, as I am, it also helps to have a canned phrase to use when it turns out something isn’t your job. I try to avoid offering to help. For example,
The sink is leaking and it’s flooding the kitchen, and it’s preventing us from doing our installation today due to the unsafe nature of the work conditions. We’ve put the oven on stilts for now. Who needs to be looped into this conversation to get it fixed?
<issue> <impact> <mitigation> <suggestion of next step>
You probably shouldn’t need to even include the last question… but I personally like to validate that a problem is being managed. baby steps
I’ve got time, I can totally slap some duct tape on that sink though.
For every rule there is an exception. We all enjoy going above and beyond for the people we work with. If you and your team aren’t overburdened, and if you know the problem and can help with the solution, feel free to go in there with a bucket and try to make things better. As with the flooding sink, most times in software, one person’s problem is everyone’s problem. That’s what makes this concept so hard to internalize. We’re all drawn to problem solving. We’re all drawn to helping our fellow developers. It’s hard to say “not my oven” in the software world.
So, if you take the time to inventory your own capacity for new responsibilities, and your team’s responsibilities, I think you can totally jump in and help. BUT you can help without also being responsible for the problem and it’s solution.
👋 In case you need to hear it… a problem that makes life more difficult for your team does NOT make it your oven. Those types of problems are so hard to step away from managing, tracking or solving. These are exactly the types of problems that you should be very intentional about not adding to your team’s set of responsibilities.
