Excuse the rant, but I am tired of getting this question. Every couple of months somebody seems to ask it. It’s always someone outside of the product development team. Usually, it’s somebody from Operations or Marketing (no offense!) who is anxiously awaiting for their pet project to be finished.
It plays out like this… The co-worker walks over to tech side of the office one day at 6pm, sees some empty desks, and then assumes the team is not working hard enough. Okay, I get it. From your perspective, “butts in seats” has been a good proxy for productivity. Here’s why it doesn’t quite work that way for the technical team.
Engineers are not like you. Most engineers and technical team members do not feed off of ad-hoc drive-by conversations, long status meetings, and noisy, buzzing, open office plans. They don’t schedule their days in 30-minute calendar blocks of back-to-back meetings. To them, the normal 9-to-6 office hours seem artificial and arbitrary. In fact, all of the daily office hubbub is generally viewed as an annoyance and something standing in between them and getting their work done. And believe me they care about the work as much, if not more, than anyone else. These days, in case you didn’t know, engineers are in extremely high demand. They could go work anywhere and they are at your company because they believe it’s meaningful and interesting.
Context switching is expensive. It’s not like reading a book where you can open up the book to the dog-eared page you were reading yesterday and start reading again lickety-split. In software engineering it takes a while to get back into it. In order to be productive you have to load the whole technical situation into your conscious working mind. What are all the methods, variables, api endpoints, libraries, and how do they all relate to each other? The technical plan, product requirements and overall architecture need to be considered. Your development environments need to be ready to go. I’d say it takes about a half hour of focused time just to get to productivity. If someone interrupts that, there’s a good chance you have start over.
Every coder wants to be in the zone. For highly complex tasks or anything that requires complete focus, being in the zone is a great place to be. You become one with the work. You reach a flow state. Everything else fades into the background. You are at your best and your productivity is off the charts. You are getting three days of work done in an afternoon because you are TOTALLY THERE. It’s high quality too. Writers, poets, artists, rock climbers, you know what I mean. Actually, all of you know what I mean. Everyone knows what it’s like to be in the zone. The greater point is that if coders are not there, in the zone, it’s not going to be very productive. Coding is where they create leverage.
For this reason, many of the very best engineers I have known like to work late at night or early in the morning at home. There, they are not burdened by meetings, email or incoming Slack messages. They can finally avoid interruptions and find that flow state.
External forces can easily block technical work from proceeding. It very common for engineers to be blocked while waiting on a key deliverable from a team member, stakeholder, or a third party in order to proceed. Are final designs ready? Did the business stakeholder make the decision on pricing? Is that SaaS partner delivering on the APIs they promised? Any of these things can stop a project in its tracks. If that happens and your engineer has done everything else they can and nothing is going to change for a while, make them feel empowered to do something else. Go home. Go workout. Go work on your side project (almost every engineer has a side project to keep up with the latest technology). Go play Civilization. Don’t worry because…
…When deadlines, big launches or outages occur your engineers will be there. All. Night. Long. You know how your Product and Engineering teams always advise you to do small incremental launches on a regular, consistent cadence? Sounds okay, right? But you’re thinking nothing beats a big launch with lots of marketing sizzle, press and a party to boot! All that hoopla relies on shipping the code. The intensity will rise as the date approaches. Your engineers will work constantly to get you there. When the big day comes and all the hoopla commences, they’ll be pouring over logs, triaging bugs, and watching VIP accounts. When you are toasting your champagne or being interviewed by Recode keep that in mind.
A few tips:
- Read Paul Graham’s classic post, Maker’s Schedule, Manager’s Schedule. Many of these ideas find their seeds in that 2009 post.
- If an engineer has headphones on, don’t interrupt. Send an email or come back later.
- Keep meetings to a minimum. Let the engineers know when a meeting is optional for them. Consider having no-meeting days or afternoons.
- When an engineer occasionally requests a WFH day keep in mind it will probably be their most productive day of the month. (My personal view, however, is the right cadence for WFH is once every few weeks. Why? Companies are not great at remote working day-to-day and sitting next to each other creates unmeasurable benefits that are significant.)
- Support decompression time. With highly creative work you need down time in order to move into a mind space where you can see the revolutionary solution as opposed to only the evolutionary one.
- If you think someone is really just being lazy, question how well they are being led and managed. Do they have the full context of why their work is important? Has their manager clearly laid out their next steps in career development? Are they getting feedback and recognition on a regular basis? Are they technically up to the task?
Side note: It’s actually really hard to measure an engineer’s output. If you read this far, you probably get it: hours do not equal output. So how do you measure performance? Do you track lines of code? That’s a good recipe for crappy code. Do you count story points? That’s easy to game. This is why good engineering management is a must. It really takes an engineer to be able to properly judge an engineer’s work. If you want to try to assess the situation yourself and you are not an engineering manager try: 1) spending a decent amount of time with the engineer(s) to understand the complexity of the problem, 2) tactfully getting another respected engineer’s assessment of the situation, and 3) asking for more regular check-ins and feedback sessions–come prepared to discuss deeply.
Of course all engineers are different and I’m in danger of over generalizing. I’m also quite aware that many non-engineers will read this and say, it’s the same for finance–we get in the zone too! But I have seen these same themes and situations play out at every company particularly with engineers. I lived them myself back when I got to code. Perhaps it’s just my personal experience. Anyway, do me a favor. The next time you are about to ask me if the engineers are working hard enough, first check if I have my headphones on, if I do, please don’t interrupt. Just come back and find me later.
Like this? Please click the heart icon, share on social media, and/or follow me here or on twitter @johnv.
Thanks to Paul Devine, David Dobbs and Adam Nathan for feedback and input on this!
The NewCo Shift Management channel is brought to you by Work Market, the leading labor automation platform. Work Market empowers businesses and skilled professionals to unlock new levels of productivity, engagement and growth across the entire lifecycle of work. Learn more here.