Could/Should/Will/Why
I had an interesting conversation with my manager this week. I’ve been working on a lot of different projects, and was a little spread thin. In one of our calls my manager asked me why I’m working on .
We sat and chatted about it, and I tried to answer the question: why am I doing these things? After hearing me out, they agreed that everything I was doing was important. Then they repeated the question, with a slightly different emphasis:
Why am I doing these things?
I didn't have a good answer. The things needed doing. No-one else was doing them. I could do them, so I took them on. But why was I the one taking them on?
A day has a finite number of hours. If I’m spending my time doing X, then Y isn’t getting done. If Y is something that only I can (or will) do, then isn’t that a better use of my time than X?
Here’s a concrete example. I had a choice to either:
- Write some tutorials for one of our products using the API
- Build a proof of concept Terraform provider to understand if we want to invest in the next financial year
My decision? To do both. Work on the proof of concept first, and write some tutorials between my meetings once it's done.
That’s the wrong answer.
It turns out that writing tutorials isn’t my responsibility. More than that, by writing them I’m taking away learning opportunities from others. I’m taking it away from the product manager that wants to learn to write documentation. I’m taking it away from the writer that wants to learn more about API development.
Anything I take on should meet one of the following criteria:
- No-one else can do the work
- It’s time sensitive, and no-one else has capacity
- There’s a learning opportunity for me
Building a system
When my manager asked why I was working on these projects, I realised that I couldn’t answer. We talked about who could do the work, who should do the work, and who will do the work. This gave me a good framework for evaluating projects before starting them.
I’ve added a final column - why - to help keep a record of why the person that will take on the project is responsible.
Here’s an example with a couple of projects:
| Project | Could | Should | Will | Why |
|---|---|---|---|---|
| Public Demos | DevRel, Sales Engineering | Sales Engineering | Sales Engineering | Demos are a core part of the SE role. If DevRel build demos, there would be duplication. |
| Release Demos | Product, DevRel, Product Marketing | Product Marketing | DevRel | DevRel has an engineering background to understand the features + how to get started |
| Splunk Tutorial | Docs, DevRel | Docs | DevRel | Docs team is at capacity with regular release documentation |
| VSCode Extension | DevRel, Engineering | Engineering | N/A | Project not prioritised. |
| Terraform Provider | DevRel, Engineering | DevRel | DevRel | This is an initial proof of concept exploration. If the idea shows potential, it's added to the Engineering roadmap. |
Let’s work through the tutorials example in more detail:
- A community member asked how to send logs from Kong on a VM to Splunk
- DevRel couldn’t find any existing documentation to send them
- DevRel the docs team if they could write a new tutorial
- The docs team share that they’re already overcommitted.
At this point DevRel have three choices:
- Abandon the project
- Submit it in to the docs team backlog
- Do it themselves
This is your classic prioritisation problem. Whichever option you choose, fill out the why column with the rationale then move on.
Has it helped?
Kind of. I still take on more projects than I should, but having an explicit will step forces me to think about why we’re taking on this specific project. It forces me to talk to other people about the project. Could their teams take on the work? Do they want to take on the work? Are there learning opportunities?
Next time you have an idea for some work that needs doing, run it through could/should/will/why to make sure that you’re the best suited person or team to complete the project.