Replaceable
Hey!
Welcome back to another week of musings.
We're in the first week of the NFL! I definitely enjoyed the first few games, and it was nice seeing them play in Latin America! I hope you had a great weekend and managed to restore your energies.
Was this forwarded to you? You can subscribe here!
Things I enjoyed in the past week
I've been reading Empowered by Marty Cagan and Chris Jones*, it's been an interesting read, some new things around how to better empower the teams I work with.
How AI is reshaping the product role | Oji and Ezinne Udezue episode from Lenny's Podcast, an interesting opinion on this whole AI topic, and how it's changing the different roles of a tech organization.
From time to time, I wonder what it is I do here? It's good to feel like you're helping the people around you, or that you're carrying your portion of the water.
At other times, I feel overwhelmed because I end up taking on tasks that any other engineer could handle. And I remember people in my past jobs who built some piece of software that no one else can take care of. I don't think we want to be in that situation ever. I recall they were always on call; they couldn't take vacations without being asked to fix bugs, etc. While it might feel safe, you're a few leadership changes away from being laid off.
Delegation
The most straightforward way to avoid keeping tasks that other people can do is through delegation.
I've discussed this with some mentors in the past, and whenever they discussed it, some made it seem like an instinct to them. I realized they are very good at saying no, but not in explicit terms, but rather, framing it as: "I know this other engineer is interested in this topic", or "I forwarded the meeting to X, who can take this project forward".
I've been trying to improve this skill myself, as I've recently become more aware that I often realize I should have delegated a project too late. So, the lift of knowledge sharing is larger, and sometimes I feel it's not possible due to all the decisions that have been taken.
Incorrect Assumptions
One of the reasons it has been hard for me to delegate earlier has been incorrect assumptions.
For example, I assume there won't be anyone who wants to take on that project, or they don't know all the people needed to work on it. By the time I think, someone else could have done this, I'm already halfway through the delivery.
In practice, it's my role to fill those gaps, and allow other people to take on
Documentation
Other times, it's easier to scale ourselves out by documenting more. While it requires a significant amount of time, it is also a good way to share your thoughts, especially if your company uses Confluence or Notion for hosting documentation.
We do not have infinite bandwidth, so we write down ideas or thoughts on possible projects or features to implement down the line. The key to adequate documentation is that you also need some time, such as office hours or an IC forum (think an architecture forum), to share these ideas with others, so anyone interested can run with them.
Your turn!
Are you intentionally sharing your knowledge with others or coaching them? Have you ever found yourself in a situation where you were the only one who could perform a specific job or task? Have you thought about delegating such tasks?
Happy coding!
website | twitter | github | linkedin | mastodon | among others