Strategies to Make Sure Your Software Developers Can Operate at Maximum Productivity

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 worlds 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. Shes been working on some major enhancements to the messaging engine. Its 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. Shes 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. Its 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 doesnt deploy correctly. While Tom is quite familiar with the deployment process, hes 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, shes back to her desk, puzzling over the new messaging functionality. At 10:00 a.m., its 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. Its her manager. She picks up. Hes wants a status update on Shelleys progress. Hes got a 1:00 p.m. meeting with his boss, and he wants to make sure he knows whats going on with the project. Hed 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.

Shes back at 1:00 p.m. She spends the next 20 minutes parsing mostly useless emails. For some reason, its 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., shes entered the 'zone' once more. At 1:54 p.m., Carol pings her via IM. Shes sending a link to a really funny YouTube clip. Its 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.

Its 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. Its her manager. He says that his boss liked her diagrams, but now hed like one more additional diagram. He claims that its urgent. Everything is urgent with him. Hes 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 shes 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. shes 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 its time to develop another bad cough. Tomorrow, Shelley is going to work from home. No email, no IM. Just Shelley, in the zone. Its 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, theres a good chance that you could eliminate a number of developer meetings, and youd 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.


Related Posts