Time Management for Senior Engineers

I recently joined LinkedIn as a Senior Staff engineer–an individual contributor role more senior than any of my previous roles. As such, I’ve been inundated with every manner of request for my time. Part of my journey toward handling this situation is writing up my thoughts. Let’s go.

Does time work differently for “senior” engineers? Yeah, pretty much. The way you need to manage your time changes dramatically throughout the course of a career. Take an intern, for example. They’ll have their 6-to-18-week project that they work on, with a manager checking in maybe once a week, give or take. They’re expected to attend customary project planning meetings including daily standups or similar.

Junior engineers have it much the same, though their assignment shifts over time. Gradually, they might start jugging multiple projects, and having to make their own prioritization decisions. In this mode of work, it’s helpful to block out chunks of time on your calendar for focused work. Bonus points for pushing back on excessive meetings.

At some rung of the engineering ladder, part of your job is figuring out what to work on, rather than just getting handed assignments. This complicates time management, in much the same way that Star Trek-style 3D chess is more complicated than ordinary chess. But with great responsibility, comes great power…

Time Domain Mastery Part 1: Delegation. One of my most productive working relationships was with a now-retired Principal Engineer. This guy had achieved a high rank–across thousands of engineers, there were a only a dozen or so PEs at the company. He made a point of never insisting on his way. In fact, he encouraged disagreement. But in those cases where you disagreed, you had better come equipped with data to make your point. That made collaborating with him invigorating as well as productive.

Now, as I look back at those days and see myself inching toward playing the part of the mentor, I also see valuable that must have been for him. He never viewed spending time with up-and-coming engineers as a chore, but rather as a force-multiplier for the team. It will always be the case that the set of things you’d like to do is bigger than the time available to get stuff done. Working with teams, you don’t have to do it all yourself. The more you raise up those around you, the greater the effect.

Time Domain Mastery Part 2: What have you accomplished today? Calendar blocks don’t seem to work any more at these higher rungs. At least in the role as I’ve experienced it, there’s a lot of temporal noise you have to deal with. Keeping afloat requires constant and intense skepticism to avoid the folly of the urgent. (And there’s always something urgent going on.)

One of the main ways that engineering leaders add value to an organization is by providing steady-handed distinction between the urgent and the important. It’s too easy to get caught on the treadmill of the urgent, rushing from one firefight to the next. The solution, of course, is to instead focus on important things, like making sure those fires don’t start in the first place!

To this end, every day you need to strive to have one notable accomplishment. And putting out fires isn’t an “accomplishment”. Concrete improvements to culture, process, architecture, or documentation, are. More than before, your success will hinge on your capability to set aside time at the start of the day, start of the week, and the start of the quarter to think and strategize. Bill Gates famously set aside “think weeks.” That’s not a bad start.

But what we really need to talk about is meetings. Thought experiment time. If you were an Apple engineer in the 90s, and Woz happened to pop in for one of your meetings, how would that have affected the dynamic of the meeting? I picked Wozniak for this example because he was (and is!) widely considered a strong technical player. Most engineers would look forward to the honor of working with him in a technical context. If it was Steve Jobs stopping by to scream at people, then there’d be all kinds of blame and accusation flying around. Yuck.

Politics aside, the higher up the engineering ladder, the bigger of a deal it is for you to be in a meeting. As you climb the ladder, it’s your imperative to make an impact at any meeting that’s worth your time to be in. This could mean asking the obvious questions that others are afraid to ask or to say what everyone is thinking. It might be using your technical capital to insist on sticking to the planned agenda and avoid rathole-ing on unimportant details. Based on your higher level of context, experience, and vision, you can reshape a meeting from a waste-of-everyone’s-time to a sharp-edged tool for your organization.

But not if you keep your nose in your laptop, working on one of your other urgent projects while only half-listening to what’s going on around you.

The most valuable contribution to a meeting might even mean taking notes when nobody else is willing (or able) to. A succinct summary of a complicated discussion can be worth its weight in gold. So is knocking the legs out from a corrosive culture that considers writing stuff down too mundane for senior folk.

The key takeaway–as a senior engineer, every action you take matters. Your actions have second-order effects–for example if junior engineers see you enduring through a useless meeting, they’ll start to think “that’s how things work around here.” Thus, for senior engineers, even second-order effects need to be carefully crafted due to their outsized impact.

You’ve spent a career becoming a leader. Act like it and you’ll be rewarded.

Production note: Version 1.2 Special thanks to Charles Greer, Jason Hunter, Tomomi Imura, and Evan Goer, for helpful feedback. This essay is a work in progress. Please comment below with suggestions for improvement.