Delegation Mistakes
Hey!
Welcome back to another week of musings.
I spent my weekend resting from a very tiring week, but overall, I greatly enjoyed it! Hope you had a restorative weekend.
Was this forwarded to you? You can subscribe here!
Things I enjoyed in the last week
- How I Maximize My Creativity. A Podcast Episode by Emma Chamberlain. I've been exploring creativity and how people don't seem to run out of ideas.
- Episode 1: Winning From Third Place by Stay SaaSy. If you've ever read their newsletter, it was a good first episode.
Over the past few weeks, I've been thinking about large, complex problems and how they are solved. And how to measure the reach of a solution to the health of an organization.
I've also been thinking about what makes delegating effective and successful for all involved. I've also been thinking about what I've done wrong in the past. So, this is less of "this is how you do it right" and more like "this is what I have failed at", so learn from my experiences!
Unclear Expectations
One of the first times I "delegated" something, a person came to me, looking for projects that could be their "staff project".
I always have cross-functional problems to solve lying around. So I asked him to solve our API issues. We had some undocumented and outdated documentation, as well as REST, gRPC, and GraphQL, with no way to determine the status of each one. In my naivety, I said, 'I need help with our APIs,' whatever that meant. Needless to say, they didn't go further than creating some experiments they wanted to conduct under the banner of this project.
In practice, I should have explained our current situation more thoroughly and brainstormed possible next steps, such as cataloging existing APIs, assessing their maturity, and standardizing them to a typical documentation pattern.
Lack of Feedback
The second issue I've encountered when trying to delegate is assuming people will take a problem and run with it.
In practice, we need to have regular touchpoints, and I need to provide clear direction to ensure they're going in the right direction or estimate the dates for delivering milestones. Many times, I've said things like, Please figure out if we can move our caching to this new technology. Please let me know if you encounter any issues. And never check again.
Wrong Project
At other times, when people reach out looking for projects or ways to stretch their skills, I used to give them whatever problem was top of mind for me (recency bias).
In practice, I should have given more thought to which projects aligned better with the person's interests and skills. I've seen firsthand that people who are deeply interested in a topic can manage to deliver through the milestones because they maintain their interest throughout the journey. I've also been that person!
In some situations, it can be more challenging to understand, particularly when determining which project is a good fit, if any. Some people might be bored and looking for something to do. Not interested in stretching their skills, only in finding something interesting to do. And they might leave any project behind whenever their team comes up with new work.
Setting up for success
All of these failures effectively set people up for failure and create unfavorable situations for everyone involved, leading to feelings of defeat, missed deadlines, and sometimes overwork.
Delegation is a science and an art. Because you need to build trust with the people, and work up their skills to take larger and larger tasks, but also work with management, and create accountability and a "framework" for people to execute. Eventually, you can determine whether someone can come through or not.
Your turn!
Have you ever delegated work? Or have you been delegated some work? How did it go? What made it succeed or fail? Let me know your thoughts by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others