The spectrum of involvement
This is a mental exercise I’ve applied to help senior engineers better respond to unexpected requests.
As software engineers gain tenure and experience, others in the organization naturally seek their expertise. Some examples: A junior engineer asks for an introduction to an unfamiliar component. The finance team needs to know how an edge case is handled in a report. Customer support wants to highlight a bug, and ask how hard it’d be to fix.
Engineers can become stressed trying to respond quickly and thoroughly to requests from colleagues that they do not have time for other important work. The best intentions for being helpful can devolve into delaying important work due to frequent pauses while responding to the latest request.
Visualizing the “spectrum of involvement” generates a larger set of possible responses than the de facto first-thing-that-comes-to-mind.
First, recognize the two extremes: ‘The least I could do’ is usually to politely decline (“Sorry, I’m too busy”), or redirect (“Please ask so-and-so instead”). ‘The most I could do’ is to pause my current task until I’ve completely addressed the thing.
These extremes are rarely the most effective responses. Use them to open the gamut of possible responses.
Next, think of 2–3 moderate responses ranging from ‘a little involvement’ to ‘a lot of involvement’. In the example of the junior engineer learning a new component, ‘a little involvement’ could be sending them links to documentation, some relevant code files, or pull requests. ‘A lot of involvement’ could be scheduling 1-on-1 time to discuss the architecture, show how it’s tested, and pair on their feature. You can offer to give early feedback and code reviews.
Finally, combine elements of these responses to synthesize new ones. If the component is well documented, you could say “Check out these docs for an overview of the component. If you have questions, let me know. Also, I’d be glad to review some work-in-progress code.” Or it lacks documentation, “Let’s discuss the component and write some documentation together.”
In the case of the bug report from customer support, ‘a little involvement’ could be to add extra context to the bug report so it can be more easily triaged. ‘A lot of involvment’ could be implementing a partial fix yourself while backlogging the complete fix. A synthetic hybrid response could be to add context to the bug report, and ask stakeholders whether it’s worth implementing a short-term fix, or wait for a long-term fix to be prioritized.
The whole mental exercise takes 30–60 seconds. In my experience, one of the synthesized responses usually jumps out as the most productive use of everyone’s time and attention, and is a significant improvement over the first thing that came to mind.
