Learn / Blog / Article
Prioritizing brilliantly: better alternatives to productivity guilt and grind
As software engineers, we pursue high-quality solutions against a ticking clock. But spending too much time perfecting solutions before delivery delays the result and increases the cost of adapting these solutions to new learnings. What’s more, the approach of grinding to the finish line is not sustainable.
Last updated26 Apr 2023
Reading time5 min
I realized I had to learn to pace myself for a marathon, not a sprint, while also enjoying the view. In other words, I needed to work smarter, not harder.
This post shares a few (engineering-adjacent) skills I’ve found useful for a successful career as a Senior Engineer and team lead.
Lessons learned as a Hotjar team lead
My team and I follow industry benchmarks that set elite performers apart from the rest. These benchmarks favor an iterative approach to learning quickly, reducing waste, and keeping up the momentum.
Over the years, I’ve also picked up a few tips from my mentors, who inspire me to be intentional in my work and align my efforts in the same direction as my team or company. The book ‘Coherence’ by Dr. Alan Watkins has been another great inspiration during this ongoing journey.
These helpful sources have enabled me in my career and encouraged me to develop a few strategies and ideas of my own.
Align your goals
In the beginning of my career, one of my major time wasters was flitting from one thing to another without gauging each task's importance. I needed a mental representation of the priority areas to differentiate between tasks that were high-impact activities for my goals and those that were mere distractions. I started by combining all my goals for the quarter.
It’s all too easy to be pulled into different directions by:
Objectives and key results (OKRs)
Tech briefs and guidance
Performance review opportunities
Personal interests and goals
Now, I put all these goals on one list and pick a theme to focus on for the month. The theme helps me prioritize activities that increase the impact of my work—especially if some groundwork is required before focusing on a particular area.
For example, if the theme is to tackle tech debt, it also helps to look at the north star direction. For an individual contributor, these goals may be squad-related, chapter-related, or north star-related.
Maintaining a laundry list of bottlenecks or implementations reaching a stress point also helps allocate the right amount of effort.
Some of these areas might align with the squad’s current focus area, and thus tech debt can be addressed as preparation for feature work. If not, laundry lists, at the very least, make good material for a proposal for upcoming focus areas.
Alternate between breadth and depth
Goals and themes require frequent alignment and refinement to continue serving their purpose. I often question decisions when they seem to be drifting away from our original squad goals.
Updating our direction with learnings and results from data helps the team align and evolve their understanding of what's next. Then, we shift our focus to the tasks in our backlog and identify what’s missing to reach our goal.
There have been many times we’ve known in our hearts that we won’t manage our original target. Or perhaps we gain new knowledge that changes our approach. This is either an invitation to grind to the original deadline or slice the deliverable differently.
Some questions I ask here are:
What resources do I have at my disposal to help me de-risk this work?
Can I spike the riskiest part to check for feasibility?
What is the minimum work I can do to get the whole system working from end to end?
Will excluding part X from this work still make it a successful release?
Slicing work into smaller deliverables maintains momentum and ensures timely feedback, so a pivot will not lead to much waste. (Sometimes, we even replace the original task with one of higher value to our customers as we adapt to new learnings.)
Use sync-meeting agendas for broad-picture thinking
The switch between breadth and depth is costly—and sometimes painful—because the brain wants to return to its previous train of thought. I like to use sync meetings as a time to address this: syncs can help switch focus faster. If I know a planning meeting is coming up, I spend 30 minutes preparing my contributions. The end of a sync meeting is also an excellent time to revise what was decided and identify any gaps or misalignments.
Ask for feedback
After aligning on the right priorities and keeping a bird's-eye view on the end goal, the next time-suck I realized I needed to avoid was perfection. Contrary to what you might think, perfection is more a vice than a virtue. I remember when I used to polish and perfect my work before asking for feedback, mostly out of fear that my work would appear sloppy. However, getting feedback on the initial direction, scope, and size proved extremely helpful in structuring my thoughts.
When a draft spends too much time gathering dust on my desk, I ask my lead or peers whether it’s valuable to continue pursuing it.
Set the right expectations
Naming conventions matter to help set the right expectations from reviewers. Here are a few examples:
A brain dump
High-level feedback is required to validate the direction of ideas
DRAFT: Merge Request
The reviewer will not nitpick with the incomplete parts but instead provide direction on boundaries and code structure
A proposal or RFC
Needs to be well thought out, and address a clear business case, to receive feedback on specifics
Perfectionism has value at the polishing stage of an article or deliverable. But the prior WIP stages are how we work together to achieve a higher impact—so hiding my work simply because it wasn’t perfect yet was not helping me. Iteration is more powerful than perfectionism because it refines the deliverable to the right audience, whether the company or the customer.
The key to effective energy management
All the strategies I’ve discussed continue to help me reduce waste and distraction—but being focused still takes up a lot of my energy.
Energy management is more impactful than time management. Having hard stops in my day allows me energy for activities that make my life more meaningful—like spending time with friends, family, and pets. This increases my motivation and sense of self overall. And restoring myself before I crash helps me work more consistently.
Crashing is expensive; it takes time to recover from. I’m still learning to notice the signs I’m slowing down and find healthy pick-me-ups.
I’ve also redefined success to represent my whole person—I’m not simply a brain attached to a body. Our life is so digital that sometimes our bodies become an afterthought. We eat and move on autopilot. Being intentional about improving my physical and mental strength has made my energy more consistent and reliable, helping me perform better at work and in my personal life.
Prioritize like a pro
Hotjar's tools and features help you manage your backlog, so you'll know exactly what to focus on next.
Hotjar's tech blog
How we optimized perceived performance to improve our KPIs: a Hotjar case study
No one likes to wait. Even at a nice restaurant, if the food takes too long to arrive, you’ll start wriggling on your chair and looking around for the waiter. Worst case, you might even leave.
This is nothing new: people are impatient by nature, and your users are no different. If you ask them to wait too long for their requested content, they’ll enjoy the experience less and eventually drop off.
Hotjar's tech blog
Observability for product teams: what, why, who, and how
Observability is not a new concept in the software industry, but it still amazes me how many different interpretations I hear about this term. In many cases, observability ownership appears ambiguous, and it's also common to see it treated as an afterthought.
Hotjar's tech blog
3 common questions from Hotjar’s engineering candidates, answered
At Hotjar, our Engineering team often gets questions from candidates in the hiring process about how we function internally. Questions like these tend to come up after a candidate’s technical interview, when we may have run out of time to discuss them in depth. We know this information is useful for candidates, and we can’t always address these questions as fully as we’d like. So, we’re sharing our responses here.
Simon Agius Muscat