Side Quests at Work
Hey!
Welcome back to another week of musings. We've had beautiful weather here in the Bay!
I've been trying to get back to going for walks daily. As well as starting to stretch again because of lower back pains.
Was this forwarded to you? You can subscribe here!
As engineers, we're constantly around "side-quests" on the job. There is always a never-ending stream of things trying to get our attention or requests that often come from people we work with.
When I started working, it was more about code-based 'side-quests,' like testing a new library, refactoring an implementation, updating a caching approach, etc. I could discuss these with my manager and carve out time during a sprint to work on them, gradually making progress.
As we advance in our leadership roles, we'll notice a shift in our responsibilities. We'll have less guidance from managers on setting priorities and allocating time. Instead, we'll be expected to independently decide what needs immediate attention and what can be considered a 'side-quest' for future development or to unblock other tasks.
The main priorities tend to be straightforward from the business perspective. They will generally include a list to help you prioritize work or a roadmap to help you understand what to work on next.
However, when it comes to 'side-quests ', the decision-making process is different. It's not just about importance or urgency, but also about the potential impact and whether you're uniquely positioned to address it.
When your company grows beyond a certain size, you probably have a lot of squeaky wheels lying around. Some of those go way to the bottom of the priority list, given constraints like people or simply because they have gotten used to the cost of running it.
There might be better ways to run a service or switch to a cloud-managed solution, or you might have one random service that sustains a critical piece of your company written in a language that no one currently employed knows (e.g., Perl, Fortran, etc.).
In general, these things might not be solvable by just you, but it might fall on you to devise a plan and delegate accordingly. Other times, they might be small enough for you to solve.
Realistically, it would be best if you were good at prioritizing based on the leverage they might produce because showing a win will make you earn trust from leadership to propose a project further down the line. You can't work on your "job" and follow up thousands of side-projects, so be careful not to burn out trying to fix the world.
Other times, side-quests might only need you so far, and it might be more about removing the "fog of war" around a project. You can think of projects with many "unknown unknowns"; while it may be necessary, people might not feel compelled to tackle such a project. You can think of yourself as guiding and then delegating the execution to managers and teams.
With time, you'll learn to identify the type of effort required and for how long. Knowing where to apply effort will be a useful skill in the long term, especially when, as a leader, you want to make a major impact.
Your turn!
Let me know how you handle "side-quests" at work or if you've had to take on such tasks outside regular work by replying to this email!
Happy coding!
Things I discovered in the past week
- 10 things software developers should learn about learning. An interesting blog, after I was researching about learning habit or practices.
- Migrations: the sole scalable fix to tech debt.. Another great piece by Will Larson.
website | twitter | github | linkedin | mastodon | among others