The Art of Doing More

September 30th, 2024

Navigating Feature Work and Growth

Background

For a long time, I’ve been asked these questions by other engineers: “How do you balance xyz with feature work?”, “How do you do all this stuff?” and also “Are you on the platform team now?”

I haven’t had good answers to any of these questions (other than “No, I’m not on the platform team”). I probably get asked these a lot because I ship a reasonable amount of PRs that are unrelated to the product surfaces that my team owns.

This is going to briefly touch on why that is, but more importantly how I manage to do this while not falling behind on my team’s roadmap.

Why?

Growth

To keep growing my React technical skills, our codebase & infrastructure needed to be migrated to unlock React’s next generations (hooks, server components, compiler, etc). Migrations are full of technical challenges which are great growth opportunities.

Also, slow builds make it hard for everyone to get things done, so speeding them up is important. Our infrastructure and platform are broad and have a deep roadmap, so waiting for the core team to prioritize everything is a losing battle. Optimizing CI is also full of interesting technical problems that you probably wouldn’t encounter in your day-to-day work.

Unlocking “new” React features helped us improve the speed of our website, and optimizing CI increased our developer velocity - both of which are important to Faire.

These are just two examples, but there are many other avenues for impact that exist. “Finding opportunities” is up next on my list of things to write about, but the TLDR is: fix the things that pain you the most. If you’re unsure how to align your goals with your company's, it might be helpful to seek a mentor!

How?

For small swings

Estimate less of your effort towards the roadmap.

Here’s how I think about this:

When I first started, I spent nearly 100% of my time on roadmap work. After getting comfortable with our tech stack and build processes, I was eventually on par with the average engineer.

As I gained more experience with shipping features, I got more comfortable and started moving a bit faster.

This is where I think a lot of great engineers land today, and it’s a good place to drive a ton of impact. Once I got here, I decided to spend slightly less time on the roadmap and a little more time on non-roadmap work.

I try never to fall below the average amount of roadmap output, but some weeks will require more time spent on the roadmap than others & vice versa. So here’s how I think I spend my time:

My bias is always toward the roadmap. If I don’t have any non-roadmap work planned, I move the roadmap along faster. But most times I have non-roadmap work available to fall back on whenever there’s a gap.

Important notes

• The extent to which you can invest time external to your team’s roadmap is determined by the time you're able to carve out of a working week - either by being more efficient, putting in extra time, or reassigning / reprioritizing your responsibilities.

• A big part of this is managing expectations. If your manager knows you are trying to grow in a certain area and you are doing impactful work, then the team can make space and adjust timelines. If your manager has no idea what you’re working on then they can’t help advocate.

For big swings

Get your ideas onto the roadmap.

If you have an idea for something big that you’d like to work on, your best bet for getting staffing for the project is to bring it onto our roadmap.

A huge component of this is clearly defining the scope and plan to tackle the big swings. Teams can’t commit to work that they don’t know the scope of (i.e. is it 2 weeks or is it 2 months?). A key tactic here is to break bigger projects into incrementally deliverable milestones — this makes big projects much more palatable and also more shareable.