Strategies to Make Sure Your Software Developers Can Operate at Maximum Productivity
A Day in the Life of Shelley the Software Engineer
Its 7:35 a.m. Shelley, one of the world’s most productive developers, strolls into the office. A Starbucks in one hand, a briefcase in the other. She cracks open her laptop, a sticker-laden chuck of technology that boldly professes her love of kittens and the Pittsburg Pirates.
She opens her email. Her inbox is full again. About a third of them are status updates from various teams in her department. Somebody once thought it was a good idea for teams to send out daily status updates via email. Somebody else thought it would be a good idea to include all the developers in the department. Shelley has already built a sophisticated set of filters to send these status updates directly to the trash, but for some reason, a number of them keep getting through. Distractions! Shelley hates distractions.
By 8:05 a.m, she has responded to a number of emails, and filed a bunch more. She fires up her development environment. She’s been working on some major enhancements to the messaging engine. It’s a rather complex change that requires a serious refactoring of the existing messaging architecture. She spends the next 15 minutes loading context into the confines of her spacious brain. At 8:30 a.m., Tina stops by her cube. She’s got some questions related to some work Shelley did months ago. By 8:45 a.m., Tina has the answers she needs.
Shelley digs back into her work. She spends five minutes rebuilding context in her head. 10 minutes later, its 9:00 a.m., time for standup. Her team is co-located in a single area, so no travel necessary. By 9:15 a.m., Shelley is back at her desk. At 9:27 a.m., her IM lights up. It’s Tom, in charge of QA deployments. There seems to be some problem with the latest application deployed in QA. While the deployment process is mostly automated, the process is somewhat fragile, and often doesn’t deploy correctly. While Tom is quite familiar with the deployment process, he’s not a developer, and frequently reaches out to developers when debugging deployment and environmental issues.
By 9:37 a.m., Shelley has helped Tom determine that there was a data upgrade issue. A developer (not Shelley) forgot to add the required database upgrade scripts for a new feature. Shelley needs another cup of coffee. At 9:45 a.m., once again fully caffeinated, she’s back to her desk, puzzling over the new messaging functionality. At 10:00 a.m., it’s time for the weekly developer forum. Shelley provides a brief update on some of the new messaging functionality that will be coming soon. By 11:00 a.m., she's coding once more. By 11:30 a.m., Shelley has finally entered the “zone,” for the first time today. At 11:38 a.m., her phone is ringing. It’s her manager. She picks up. He’s wants a status update on Shelley’s progress. He’s got a 1:00 p.m. meeting with his boss, and he wants to make sure he knows what’s going on with the project. He’d also like her to sketch up some quick architectural diagrams that he can use in his meeting. At 12:20 p.m., Shelley sends over the diagrams, and heads for lunch.
She’s back at 1:00 p.m. She spends the next 20 minutes parsing mostly useless emails. For some reason, it’s become the norm for people to include practically the whole department on virtually any email chain that might have some relevance. The following 30 minutes are uninterrupted and by 1:47 p.m., she’s entered the 'zone' once more. At 1:54 p.m., Carol pings her via IM. She’s sending a link to a really funny YouTube clip. It’s only 44 seconds. Shelley relents. It is, in fact, 44 seconds long, and it is really funny! She and Carol spend the next 2 minutes dissecting its contents.
It’s now 2:00 p.m. More caffeine required. By 2:07 p.m., with a steaming cup of Java, Shelley is back into messaging infrastructure. By 2:28 p.m., Shelley is once more in the ‘zone.’ At 2:37 p.m., her IM is lighting up again. It’s her manager. He says that his boss liked her diagrams, but now he’d like one more additional diagram. He claims that it’s urgent. Everything is urgent with him. He’s constantly pinging with various requests. Some of them are important, some of them are not. Shelley spends the next 20 minutes putting together another diagram.
At 3:00 p.m. she attends a meeting with a number of architects to discuss the messaging enhancements that she’s working on. She spends the next 30 minutes answering questions, trying to work through architectural red tape. The meeting runs 10 minutes late. It ends at 3:40 p.m. Not much was decided in the meeting. The architects think that another meeting is required. They are concerned about some of the downstream effects of the changes that Shelley is making. However, none of them are able to articulate what specific downstream effects they are worried about. By 3:45 p.m., Shelley is coding once more, and by 4:05 p.m. she’s once again ‘in the zone.’ For the next 35 minutes, Shelley is extremely productive. At 4:40 p.m., Shelley closes the lid on her sticker-laden laptop, and heads home.
Plan B
Another typical day! Progress needs to pick up significantly if these changes are going to be finished in the near-future. It sounds like it’s time to develop another ‘bad cough.’ Tomorrow, Shelley is going to work from home. No email, no IM. Just Shelley, ‘in the zone.’ It’s the only way to keep the project on schedule
Fundamental Differences between Managers and Software Engineers
As a manager, your work tends to be interrupt-driven. You are providing updates to various leaders, you conduct staff meetings, you fight fires. On any given day, it's hard to predict what's going to come up next. One day may consist of bouncing from one meeting to another. Other days may be filled with strategic planning. You are constantly communicating both up and down your chain-of-command. This is what it takes to do your work efficiently.
However, developers operate in a fundamentally different way. The way to get the most productivity out of your developers is to give them long stretches of uninterrupted time. They can use this time to focus on their development tasks. Constantly being interrupted is extremely disruptive to coding productivity. By letting a developer focus on a single task for long periods of time, you avoid the extreme cost of context-switching that is associated with multi-tasking. Context-switching and distractions also keep developers out the extremely efficient state of ‘flow’ or the ‘zone.’
There is also a fundamental difference in how managers view meetings. Developers view meeting as flow-disruptors. Managers view meetings as progress, a forum for sharing information. Developers prefer information only at the point at which it becomes necessary, and will seek it out when they need it. While, certain meetings may be necessary, there’s a good chance that you could eliminate a number of developer meetings, and you’d be no worse for the effort. Take these thoughts into consideration the next time you plan on scheduling a meeting with your developers, or when you are about to ping them for a status update.
