Give Them the Fish, Then Teach Them to Fish
A colleague came to me with a request the other day. I didn't handle it quite how I wanted to. The request went something like this:
"I remember you were on the team for Big Scary product a couple years ago. Do you know if I can delete this List of Stuff from Big Scary product, and if I can automate that?"
I did not know. It was two years ago. Big Scary product had gotten Bigger and Scarier in the meantime.
But I knew where my team linked to our API specs from our customer-facing documentation. I applied the same principle to discover where Big Scary product API specs were. I looked at those specs and found the List of Stuff in a response body for an API call, but noticed that my colleague wouldn't have the ID the request required. So I looked at the API specs from a Bigger Scarier product. Combining a call from there would get the ID Big Scary product needed.
I was short on time, so I answered the question directly. I said it was possible, and possible to automate, and provided the links to the specs for both products. My colleague thanked me, and left the conversation able to solve their problem quickly.
I gave them the fish. What they learned from that interaction was: Elizabeth knows where to find stuff. I can come to her when I don't know how to find stuff and she will find it for me. That was the wrong lesson.
Give Them the Fish, Then Teach Them to Fish
A better lesson would have been: I know where to look for things. Elizabeth will give me the tools to know where to look, and empower me to do so. Now that I've got the access and seen it done once before, I can take a few more steps before I reach out Elizabeth the next time.
Here's what I could have done to get to get this colleague there:
- Explain where all the API specs live: I could have explained my thought process for finding the API specs, showed how I navigate using the headers and
Ctrl + Fon the page, and compare the requests and responses to what's needed. - Update them about who's on the team for Big Scary product now: I could have listed a few team members names who I knew were working on Big Scary product, or pointed my colleague to the Slack channel for the whole team.
- Introduce colleague to a member of the team for Big Scary product: Since this colleague was a tester, I could have started a direct message with them and the tester on the team for Big Scary product, copying the question from the DM I first received.
What If I Only Teach Them to Fish?
What would have happened if I'd skipped what I'd done, and withheld the links to the API specs?
I wouldn't have been able to guarantee that my colleague was in the learning zone. From what I knew about their situation, they were accumulating a lot of data that they wanted to delete. I didn't know what other pressures were coming from the team, but the need to automate it suggested it was a bigger problem than just a few extra entries in a database.
Giving my colleague the fish, and then teaching them to fish, relieves any of that pressure to deliver, and helps open them up to learning and growing.
Tell Them What You're Doing
Some colleagues are distracted, or dense, or not able to take away meta-information from a conversation along with the information. They may stop listening after they have the answer.
Combat this by sharing your motives. Remind them that you too are busy. Explain that your goal is to empower them. Encourage them to reach out to the team working on Big Scary product, so that those team members can also get good at knowing where to look and answering colleagues' questions. Tell them you're happy to help them again, but you'll expect more details of what they tried first. Then hold them to that.
The best lesson is: I want to take a few more steps next time I have a problem, because I know I can, and Elizabeth expects more from me.