Letting Go
Hey!
Welcome back to another week of musings. This was my first week back at work, so I spent much time catching up.
Between updating meeting invites, checking updates, emails, etc., the week went fast enough for me to complete some of the other tasks I wanted to. Anyway, I hope you had a quieter week! As always, I wish you had some restorative time.
Was this forwarded to you? You can subscribe here!
Things I discovered in the past week
The Danger of Overreaction by Lorin Hochstein is a good article about how overreaction increases the risk of having an incident again.
I've been trying Ghostty instead of iTerm for the first time in a few years. It has nice defaults, so I don't need to change many things. We'll see how it goes for the rest of the month.
The Best of JS 2024 I discovered this existed recently, but it seems to have been published since '16.
As I was catching up with different teams as I started to work this past week, I thought that one thing I've been trying to learn as I moved into staff+ engineering roles is learning to let go.
Choosing Battles Carefully
While it is hard to let go, in most cases, I have been reframing it less as letting go of things I care about and more as choosing my battles with more care. During this past week's task review, I noticed I had successfully delegated a few tasks, which meant checking in with teammates instead of figuring out what I needed to do next.
Last year, I met with someone who asked about this topic. He felt he couldn't let go because it meant losing control.
Building Trust
While losing control is true, in some ways, you have to build trust with the person to whom you delegate the task. Conversely, choosing your battles also means letting go, like walking away from a problem. In either case, picking our battles also helps other teammates take these as stretch tasks.
Trust and high-bandwidth communication with the people you delegate these tasks make it easy to follow along. As the saying goes, "Trust, but verify."
Not exactly my problem
While this sounds rude, in some cases, people contact me to report problems across multiple teams, domains, etc., that don't exactly fall within my area of responsibility.
It's easy to care about every detail and everything wrong at the workplace; in many cases, someone else should care about that issue. In these cases, I set up time with leaders in those areas and try to communicate what I'm hearing and seeing otherwise.
This is the most difficult, especially as people look up to you and expect you to do something about it. In most cases, I have to say if I would look into it, but in general, they give clarity about my involvement, so they manage their expectations.
In other cases, I try to empower and guide them so that if they care about a problem, they can propose a solution, implement a proof of concept, etc.
Trying not to burn out
In other cases, my calendar or my body chooses for me. If you've ever felt tired from trying to do too many things at once, it's time to start saying no to things.
Saying no is not as easy as it sounds, but it's a reality that you need to pace yourself to have a long career. Other techniques have helped me say no, such as finding someone looking for a stretch project for growth, someone who cares about the problem, a leader who should look into it, etc.
Your turn!
How do you manage which things you take on? Do you take tasks outside your assigned tasks? Is your role less defined, and do you need to define it? How do you choose what's in and what's out? Let me know by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others