My #1 absolute top priority as tech lead for any given project is to make sure everyone else has everything they needed to be as productive as possible. A huge part of this just means answering every freaking question ASA-FREAKING-P so that “blocked while waiting for feedback” doesn’t happen, even if your “answer” is just “go talk to this other person who knows more about that particular area.”
Staying this responsive is easy when your team is a few people, but as we all know, lots of projects don’t have the luxury of a tight knit dev team where everyone understands the intricate details of what everyone else is working on. My most recent project topped out at 15 developers (plus PMs, the QA team, Product Managers, analysts, etc., bringing the grand total up to about 30), and half of them worked for the client. With a project like that, you find yourself spending the entire day in email and IMs. Otherwise, the questions start getting backed up and people start floundering while they wait on answers.
How do you get any actual work done, in the midst of this?
It’s a tough problem, but there are some options. The option you end up with will depend on a lot of things, such as the amount of actual work you have to do vs. the amount of time you’re having to spend helping others, the potential to delegate to someone else to be the official question answerer when you’re away, the types of questions you’re getting, how much sleep you need, how much you like coffee, etc. Let’s dig in to a few possibilities, starting with prioritizing.
Keeping Priorities Straight
Let’s be honest, you only have so many workable hours in a week, whether you’re a human and you stick with 40, or you’re a monster and you dip into the triple digits on occasion. If you don’t manage it, then you will often find that you’re booked for 40 hours of real work and you have 40 hours worth of “help! how do I do this!” questions to respond to, and you just can’t get it all done.
So you have to try prioritizing. This is tricky, because the main purpose of the tech lead is, you know, leading the tech. That means architecting solutions to the tougher problems, or writing up implementation plans, or doing code reviews, or making sure you’re staying on top of security updates, or pointing out areas where this feature could share some code with that feature, or even jumping into the trenches and (GASP) doing some actual coding every now and then.
But at the same time, if other people are thrashing because they can’t get a dang question answered, then that’s ultimately on you. If someone spends 2 hours burning time trying to figure out an answer that you could have given in 2 minutes, then that’s 2 more hours of work that needs to be done at some point, and on a tight timeline, that might mean 2 less hours of sleep someone is going to end up getting.
So which is more important–getting your work done, or helping others’ get theirs done?
There are some options here, depending on your priorities:
- Block off some office hours where you’re available for questions for a chunk of time per day
- The opposite–blocking off some GTD time during the day during which you’re not available for questions.
- Answer questions all day, work when you can, and get the rest done during off hours when everyone is sleeping.
Can the project wait for 2 hours for an answer to something while you get some coding done? Can the project survive by only having the official question answerer available for feedback 2 hours a day? Would the project be better off if you took longer to help others or if you took longer to get your own work done? Can you survive on 3 hours of sleep?
These are all important questions, and they all come down to setting priorities on the project. Spend your time on the highest priority “thing”, whether it’s helping Buddy figure out how to add Widget X, or whether it’s getting some heads down time on a big feature and leaving everyone else to fend for themselves for a bit.
Documentation Can Help Or Hurt
You might be saying, “Why are you having to answer so many questions? Why not just write more documentation and refer the common questions to that?” And you’d be right–sort of. Documentation can be very powerful, but don’t forget the golden rule:
Documentation is only useful if it’s really useful.
For documentation to do any good, it has to have all the obvious things going for it, such as being correct, clear, up to date, etc. But most importantly, it has to have that X factor which is that _it has to be so complete and so correct and so helpful that people just assume that the answers to their questions are there so they go there for answers first. _Because otherwise, even if a lot of questions are answered there, nobody will think to look there at the start of their quest. They will just assume that it’s not there and will ask you instead.
If that’s the case, then what documentation is really doing is hurting you, because you’re spending time writing docs that nobody ends up using, and you’re still getting pinged about things when your answer is just “read the docs.”
Make no mistake, an IM and a link which might take 10 seconds from start to end can be a major productivity killer if you’re trying to get real work done. I have the science to prove it! That’s why your docs need to be so good that people just assume that their answer is there and is up to date, because otherwise your productivity is getting killed just by people asking you things and you replying “it’s in the docs.”
So if you’re going with documentation as the main source of answers, you better work really freaking hard to make sure that the documentation is superb, or else you’re just wasting your time.
And remember, if you happen to be on the quest for Agility, then it’s right there in the Agile Manifesto:
Working software over comprehensive documentation
Delegating a Question Answerer..er
Another common strategy is to select someone to be online and available for assistance when you’re not, so that you can get some heads down time in on a regular basis during working hours without anyone else spinning their wheels needing help.
This is great if there’s a good person on the project for that role. And that’s often a big “if”. It needs to be a developer (for coding questions), it needs to be someone who has a sufficiently high birds eye view of the project to know where all the major pieces are and who’s working on what, and it needs to be someone who’s responsive and knows what the heck they’re talking about.
Often, the only person who fits that description is the tech lead, since most medium to large projects are big enough that nobody knows all the pieces unless he or she makes a conscious effort to, which is something that devs working on specific features aren’t usually viewing as a high priority.
So if this is the route you’d like to take, some planning is required to make sure the person has time budgeted for studying up on the big picture and providing dev support, and that you have a good person for that role in the project in the first place. I didn’t do that.
Delegating Your Actual Work
If nobody fits the bill to give you some relief from questions/conversations for a couple hours a day, then maybe someone can give you relief at the other end of the work streams, by taking some of your actual work off your hands.
This is difficult for a different set of reasons. It’s typically easier to find a dev who would be good in this role, but it’s a harder sell. It’s easy to ask someone “can you be available for questions for a couple hours a day while I get some heads down time?” but it’s a lot more to ask of someone if you say “can you take 10 hours worth of tickets off my plate this week, in addition to your already full schedule?”
Even though they might have spent 10 hours giving feedback and helping others, so the time spent is the same, it just sounds like a bigger request, and the last thing Tech Lead Bill wants to be doing is asking their devs to work overtime to help out Bill with his own work.
So bottom line on this one is that you have to tread carefully. Try to pick someone who has a light load or even better, plan so that that person has a light load.
Sucking It Up
As much as we all hate to admit it, there’s often a point in the project when you have to help others by day and get crap done by night, and that’s just what has to happen if you’re going to hit a deadline. I’ve found that, while of course we all do all that’s in our power to avoid that, it’s best to assume it will happen at some point, and to prepare for the worst.
This means doing a few things:
- Figure out a caffeinated drink that you like and that helps you be productive without getting the nervous shimmy shimmy shakes. If you’re not a coffee person, check out some high-energy Tea or Mate or maybe just a good old Red Bull.
- Work at night in the same place that you work during the day, if possible. If not, then find a brightly lit room with an actual desk. Do not, under any circumstances, work in bed or low light, unless you want to spend the next few hours falling asleep or feeling grump that you’re not falling asleep.
- Stop wasting time at a computer on insignificant crap. Point time wasting sites like Reddit and HN to localhost in your hosts file so they’re not a temptation, or check out something like StayFocusd. Remember, each minute that you spend doing nothing is one less minute of sleep you’re going to get.
- Experiment with early rising instead of late bedtimes. I’ve found that I’m a lot more productive if I wake up at 3am than if I stay up until 3am, because I’m not spending the whole time thinking “Ok, as soon as this is done I can go to sleep” which is a pretty terrible frame of mind for building a quality product.
- Only turn on IMs at night in case of emergency. Yes, I know that by like 1am you’re wondering if other people still exist in the world, and you have a huge, undeniable urge to send a random YouTube video to the one guy you know who lives 8 timezones away from you. But you have to fight it–a sleepy late night IM session can be an hour long ramblefest that keeps you from your bed.
Choosers can’t be beggars
So you have a few options, and it’s up to you (and your team, and your project’s needs, and your company processes, and your 3rd grade teacher) to choose the appropriate one.
Once that happens, it’s important to try really really hard to stick with it. If you decide to rely on docs heavily but fail to update them early and often, then begging your team to refer to them isn’t going to earn their trust in them. If you prioritize doing your own assigned work over helping others, then begging your team to work harder to get questions answered and blockers resolved quickly won’t do you much good, because you already made that sacrifice.
Choose once, and choose wisely. And if you forget to choose wisely, then choose again!
Mike Crittenden 