Get control of the interaction
Shift from a request-response dynamic to a collaborative approach. Instead of bearing all the responsibility, establish a plan where both parties contribute, alleviating your workload
Hi everyone, Fran here 👋
First of all, thanks to everyone who subscribed. We are already 10k in Substack! 🎉
Second, you may have noticed some weeks without a newsletter issue. I considered the options of prioritizing consistency vs writing when I dedicate the time and effort to produce something I am happy with.
I chose the second. Even if this doesn’t optimize for platforms like LinkedIn, it’s the one that makes this sustainable and enjoyable for me. Hopefully, it’s the same for you.
All important things said, enjoy today’s post.
I’m sure you feel annoyed when someone is demanding a lot from you, and you can’t fulfill everything they ask for.
I have read that the same thing happens to entrepreneurs. Sometimes the smallest client is the one taking most of your capacity with unreasonable requests.
💡 The approach we’ll follow
An advice is to “fire this client”. But this is a luxury. You may not have this option.
What we’ll do is change the dynamic away from a request-response where the responder has all the responsibility.
Instead of you being the bottleneck, you set up a plan in which you both collaborate.
This alleviates your effort and removes the annoying periodic polling that most requesters have. I’m sure you have seen these kinds of threads when some people manager asks periodically “Any news on this?”.
This is very useful when teams request something from your team. Once we had a request where the requester team was apparently impacted by us, but didn’t understand how things worked.
So we asked for additional details to be able to do our investigation. The requester engineer didn't provide any details; the only updates were from a people manager asking for “Any news?”, and “When will this problem be fixed?“.
We saved ourselves a lot of time trying to debug blindly. And we prevented the power dynamic from being one in which we were not fulfilling our role as the team owning a system.
It doesn’t mean to ignore the problem altogether. We solved their problem thanks to a team who provided the right details when impacted by the same issue.
🎯 Conclusion
Don’t take all the work on your side.
There are tons of requests lacking the required due diligence, and requests that aren’t as important as some people make them seem.
Reduce your effort and filter the requests by putting some responsibility on the requester.
🗞️ Other articles people like
👏 Weekly applause
Perfectionism - one of the biggest productivity killers in the engineering industry by
and . Iterating and being constantly exposed to the problem is much better than being in a cave perfecting a solution. Don’t wait for perfect timing. It doesn’t work when investing, and it doesn’t work as engineers. “Time in the market > timing the market”How Meta Achieves 99.99999999% Cache Consistency 🎯 by
. A small percentage of failures is not to be ignored. When dealing with scale, this will be a huge number of impacted customers. Meta created a separate service to orchestrate cache invalidation, managing both the database and the cache.Managers, be explicit about what you need from your team by
. This is a very good example of not relying on the good intentions of people, but defining an SOP for an action that is repeated over time.
Great, concise article, Fran. This is underused but I love this tip.
Another way I think of it is switching your "No" to a "Yes, if..."
"Requester: Can you take this on?"
"Responder: Yes, if you provide me with <x> details and fill out <z> form so that we're following our standard process"