Managing Your Time as a Senior Engineer

There’s an oft repeated adage in the tech industry — that task switches are bad/counter productive for an engineer, while being required for a manager. The common advice seems to be: if you’re an engineer then you need to work uninterrupted extended lengths of time to get anything (of non-trivial value) done during your day/week. On the other hand, say the same wise men, if you’re a manager you need to be able to multitask, switch very quickly from one context to another. While that is true to some extent — to a fair extent, to be honest — I have realized that it just doesn’t paint a realistic enough picture of the demands of the job, especially, say if you’re a Tech Lead or a Senior Tech Lead. I’m gonna reflect in this post on my own observations and learnings, some of which I dare say, help me be more effective at my role as a Tech Lead in my day job.

Why You Should Block out time

If you are a Tech Lead or a Senior Tech Lead then you are going to be contributing to multiple projects at the same time. Or may be you are working on one big project where it’s your job to ensure that the technical collaboration is smooth and that folks are not blocked or that fundamental system-level or architectural issues are surfaced and addressed in time. Either ways you are going to need to work on different stuff, with different sets of people or even different teams and the expected work output will be different in one or more of these. For example, you may need to review a couple of pull requests, or need to document the overall architecture or a particular component interfaces, or work on a particular feature yourself, or just help a fresh hire on your team get bootstrapped with the code. All of these are different tasks and call for different levels of involvement, rigor and collaboration. Blocking out your time helps you align your commitments with your energy/focus levels.

The Trap

Too often as we step into senior engineering roles we continue doing what we’ve been doing in our previous role. That is, we start working on a feature or a task in full earnest and get totally immersed in it. Which is fine and also what you want to do. You want to get distraction free time to write the code and tests of that module or component. You want to ship quality code. However as a senior engineer your role is not only to write good, high quality code. You want to make time to review code that other people are contributing. If you’re a Tech Lead you should ideally be reviewing every pull request that gets merged. Not all pull requests require the same amount of rigor and of course there should be someone else on the team that pairs with the developer to do a thorough review, but you want to be aware of everything that’s getting merged. You also want to look at the tech/product roadmap, you want to see where the ship is heading — figuratively speaking. You want to read up on new frameworks, have objective evaluations of if/how your product will benefit, trade offs involved in installing this new framework in your product. You want to make sure that the team is paying back tech debt from time to time, ensuring that accumulated debt is not reducing your velocity of shipping new features. And so on. The point is, if you retreat into a shell for extended amounts of time to just hammer out code, you will not be doing justice to your role, and you are not growing. Now, it’s fine if you want to just code and want to have the time exclusively for it. But if that’s so, then you need to find a job/role that requires that of you. Most tech lead/senior tech lead roles require you to do more than just code, so the above assumes that you are in such a role and you want to grow in it, be effective in it.

How to block out time

Alright. So you know now that discipline in blocking out time will help you get more done, help you be more effective as a senior engineer working on (with) a team. So how do you go about it? I’ll list out some things that I find helpful, and some pitfalls to avoid. If you have any tips, add a note or share in the comments!

1. One thing that I trained myself to get used to was to work in blocks of about 75 minutes to 90 minutes. Yes, I do work longer intervals, too, but I’m talking of not being encumbered by having roughly this time in one go. The above is a constraint yes, but constraints force you to get smarter, get more efficient. And that gets you more bang for your buck per unit time that you invest on something.
2. One thing that absolutely bugs engineers is to leave something midway. You’re all “wired up”, “plugged in”, or whatever, and you hate it when you are interrupted. So how do you reconcile this with working with time blocks of about 75–90 minutes? I’ve found that the trick is to think more deeply up front and have conceptual clarity on what you want to do. Once I have that, what I try and do is basically look to commit something non-trivial but logically complete in that time. I make sure that I have no or little uncommitted work at the end of the time block.
3. One more thing that I have been working on doing is building the ability to come back to your work after a reasonable interval of time (say a few hours to a day) and resume where you left off. This takes practice and I’m myself still at work on this. But I’ve found — even with whatever effectiveness I’ve been doing this with so far — that this absolutely helps to get more done; and not just more done on a single project but more done overall — on the job, in side projects, in life.
4. As I wrote above, different tasks have different outputs, have different needs of rigor and focus. I like to align those needs with my individual energy peaks and troughs, as well as (implicit) commitments that are part of the job. I usually keep individual work for early mornings — I’m usually up before 5:00 and start out work within about 20 minutes of getting up. I’ll work for about 60–75 minutes and I usually do any code development, conceptual thought work in this time block. Then early mornings at work — roughly between 9:30 through 11:00 are for reviewing any pull requests that need review, or reviewing all open bugs or reviewing a document a colleague or team member has authored and requested a review on. Afternoons are for collaborative work — this is when I’ll work with someone on anything that needs white boarding, or just stepping through code, or to just sound out some thoughts on some conceptual work that we need to do. Evenings are more for documentation — writing an engineering spec or test cases/test plans, or putting down design/architecture thoughts on paper. And finally some individual work to wrap up the day. I’ve found that organising my day this way helps me get more done — both individually and collectively, it keeps people on the team from being blocked too long and of course gives me the interruption-free time where I can focus on really hammering out code or working on some conceptual stuff.
5. Finally, and this might sound counter intuitive, be sure to take a break! Yes, sometimes folks would have us believe that we should be churning out code faster by pulling all nighters, working weekends and generally draining ourselves out, but honestly, nothing could be more damaging in the long run. You don’t want to get burned out. You want to stay fresh, you want to treat this as a marathon and not as a 100 meter sprint. What I do is I take a break about every 50 minutes or so — I find my Apple Watch incredibly handy here — to sip some water or just take a walk around the floor. Sometimes the obvious is staring you in the face but you’re too deep in it to see it. Taking a break helps you with that!

I have found that awareness about the above things and then actively working to bring about some of these changes helped me be a better Tech Lead. It has helped me be more effective, helped me grow and I would like to believe helped my team get the most out of me. Is there something you’d like to add? Feel free to add a note or comment!