On Developer Productivity

2014-04-08

The best developers optimize every aspect of their lives. Optimization is built into their DNA. We are always looking for ways to not repeat ourselves and strive to make everything we do faster. Everything from doing the dishes to serialization. If it’s not as fast as it possibly could be, then we spend countless hours making it so. Now as a manager I get to code a bit, but a big part of what I’m responsible for is optimizing developer productivity. I have a long way to go, but I have definitely improved as a manager over the last 10 years, so I thought I would share what I have learned.

You’ll see two approaches below. The left column is written from the perspective of the out of touch manager and the right column is written from my point of view. Hopefully you’ll get a laugh or two out of the former.

Hours

Bad Manager	Good Manager
The first thing you want to do is set the expectation that your developers will be working very long hours. They should be working from the moment they wake up to the moment they fall asleep. If not coding that whole time, they should at least be thinking about code. I find it best to set mandatory in-office core hours from 8am to 8pm. That way they get in a solid 12 hours a day in the office and then they can make up the remaining 4 hours of their 16 hour day on their own time. It’s fine if they chose to come in earlier or stay later, but everyone must be in their office for core hours. Try roaming the halls at the start and end of each day and take notes on who is and isn’t in their office. That way you know who the really productive people are. You could also go the punch card route or you could require them to install a service that monitors their activity and alerts you when they aren’t meeting their numbers.	On my team the expectation is that you’ll work roughly 8 hours a day, but it is very self-managed. Some days you’ll work 10, some days you’ll work 6. I never track developer hours. The code you produce speaks for itself. I work an hour or so in the morning, get in around 9:30, leave at 4:30, then I’m back at it for a bit before I go to sleep. That allows me to eat breakfast and dinner with my family on a regular basis. I’m never going to stop someone from working long hours. Some love pulling all-nighters. I might give a nudge here and there that someone might want to rest, but we are all grown-ups and should be able to recognize when we need a break.

Bad Manager

Good Manager

The first thing you want to do is set the expectation that your developers will be working very long hours. They should be working from the moment they wake up to the moment they fall asleep. If not coding that whole time, they should at least be thinking about code. I find it best to set mandatory in-office core hours from 8am to 8pm. That way they get in a solid 12 hours a day in the office and then they can make up the remaining 4 hours of their 16 hour day on their own time. It’s fine if they chose to come in earlier or stay later, but everyone must be in their office for core hours. Try roaming the halls at the start and end of each day and take notes on who is and isn’t in their office. That way you know who the really productive people are. You could also go the punch card route or you could require them to install a service that monitors their activity and alerts you when they aren’t meeting their numbers.

On my team the expectation is that you’ll work roughly 8 hours a day, but it is very self-managed. Some days you’ll work 10, some days you’ll work 6. I never track developer hours. The code you produce speaks for itself. I work an hour or so in the morning, get in around 9:30, leave at 4:30, then I’m back at it for a bit before I go to sleep. That allows me to eat breakfast and dinner with my family on a regular basis. I’m never going to stop someone from working long hours. Some love pulling all-nighters. I might give a nudge here and there that someone might want to rest, but we are all grown-ups and should be able to recognize when we need a break.

Meetings

Bad Manager	Good Manager
If there’s one thing I know, it is that developers love meetings. Especially meetings where they have nothing to contribute. They can just sit there and nod and pretend to be listening, which is a great opportunity for them to stress about all the code they need to write. The two best types of meetings are all-day meetings and ad-hoc meetings. If you do an all-day meeting, make sure you still follow the 16 hour a day rule and also make sure it is well known that “meeting time” doesn’t count against core working hours. For example, an all-day 8 hour meeting equates to a 24 (16+8) hour work day. Ad-hoc meetings are also very helpful. Those are the kind of meetings where you randomly stop by to see how things are going, see if they need anything and check if their work is done yet. I usually put a reminder on my calendar every 45 minutes to get up, see who is in their office and ask them questions that help them context switch. After all…context switching is a skill that is learned – and it’s your job to develop your team. By all means do not do one-on-one meetings, especially when you become a manager of managers. If you have tons of people on your team, there’s no way you can meet with them all, so don’t meet with any of them. If you want to know how your devs are doing, just send them a survey and pretend like you thought about the responses. Do not do “No meeting Fridays” or “No meeting afternoons” and put a 30-60 minute gap in between meetings so they can get a good 20 minutes of coding time in between them. At the end of the day they should spend 80% of their time in meetings and 20% of their time developing.	Meetings are necessary, but can be optimized. On my team all recurring meetings are scheduled before noon and we suggest that all meetings take place in the morning, so Devs have the afternoon to get into the Flow. I’m a manager of managers and I meet one-on-one with every FTE on my team at least every three weeks. I get a lot out of those meetings…I’m usually the one who comes away with action items. Everyone also just got Blync lights to help minimize context switching via ad-hoc-stop-bys when someone is trying to get into the Flow.

Bad Manager

Good Manager

If there’s one thing I know, it is that developers love meetings. Especially meetings where they have nothing to contribute. They can just sit there and nod and pretend to be listening, which is a great opportunity for them to stress about all the code they need to write. The two best types of meetings are all-day meetings and ad-hoc meetings. If you do an all-day meeting, make sure you still follow the 16 hour a day rule and also make sure it is well known that “meeting time” doesn’t count against core working hours. For example, an all-day 8 hour meeting equates to a 24 (16+8) hour work day. Ad-hoc meetings are also very helpful. Those are the kind of meetings where you randomly stop by to see how things are going, see if they need anything and check if their work is done yet. I usually put a reminder on my calendar every 45 minutes to get up, see who is in their office and ask them questions that help them context switch. After all…context switching is a skill that is learned – and it’s your job to develop your team. By all means do not do one-on-one meetings, especially when you become a manager of managers. If you have tons of people on your team, there’s no way you can meet with them all, so don’t meet with any of them. If you want to know how your devs are doing, just send them a survey and pretend like you thought about the responses. Do not do “No meeting Fridays” or “No meeting afternoons” and put a 30-60 minute gap in between meetings so they can get a good 20 minutes of coding time in between them. At the end of the day they should spend 80% of their time in meetings and 20% of their time developing.

Meetings are necessary, but can be optimized. On my team all recurring meetings are scheduled before noon and we suggest that all meetings take place in the morning, so Devs have the afternoon to get into the Flow. I’m a manager of managers and I meet one-on-one with every FTE on my team at least every three weeks. I get a lot out of those meetings…I’m usually the one who comes away with action items. Everyone also just got Blync lights to help minimize context switching via ad-hoc-stop-bys when someone is trying to get into the Flow.

WFH

Bad Manager	Good Manager
Working from home?...it should be……“Xboxing from home” because you know that’s what they are doing all day. It’s a trick. Don’t fall for it. You can let them have every other Sunday to themselves if they are hitting their “lines of code” count and code coverage percentage for the month. But, never on a regular basis. When someone says they need to work from home immediately schedule an early morning meeting and require them to be there in person.	Most of my team has regular “work from home” days and just yesterday Will and David paired at Cafe Cesura for an afternoon. I usually use Fridays as my WFH day, but I’m flexible. If a dev can honestly say they are more productive at home or if they want to save an hour in driving then that’s cool. You want them to figure out what sets them up for success and support it.

Bad Manager

Good Manager

Working from home?...it should be……“Xboxing from home” because you know that’s what they are doing all day. It’s a trick. Don’t fall for it. You can let them have every other Sunday to themselves if they are hitting their “lines of code” count and code coverage percentage for the month. But, never on a regular basis. When someone says they need to work from home immediately schedule an early morning meeting and require them to be there in person.

Most of my team has regular “work from home” days and just yesterday Will and David paired at Cafe Cesura for an afternoon. I usually use Fridays as my WFH day, but I’m flexible. If a dev can honestly say they are more productive at home or if they want to save an hour in driving then that’s cool. You want them to figure out what sets them up for success and support it.

Software

Bad Manager	Good Manager
When you get developers the latest versions of software it just means they are going to spend a bunch of time learning how to use it, which is valuable time away from coding. Visual Studio 2005 is fine, don’t let them convince you otherwise. Everything that was ever needed was in .NET 1.0, so don’t waste your time hearing arguments about upgrading to .NET 4.5 – async/await…blah blah blah. If they coded things right in the first place they wouldn’t need to process so many things at once.	When it comes to software, get them whatever they need. My whole team runs on the latest version of VS (2013) uses ReSharper and Web Essentials…and many more. The tools were created for the sole purpose of developer productivity, so embrace them. Let your team experiment with new VS add-ons or other editors (try WebStorm for example). In the whole scheme of things it’s not worth it to skimp on Dev Tools. You may spend thousands on tools, but that can result in much more savings in dev hours and frustration.

Bad Manager

Good Manager

When you get developers the latest versions of software it just means they are going to spend a bunch of time learning how to use it, which is valuable time away from coding. Visual Studio 2005 is fine, don’t let them convince you otherwise. Everything that was ever needed was in .NET 1.0, so don’t waste your time hearing arguments about upgrading to .NET 4.5 – async/await…blah blah blah. If they coded things right in the first place they wouldn’t need to process so many things at once.

When it comes to software, get them whatever they need. My whole team runs on the latest version of VS (2013) uses ReSharper and Web Essentials…and many more. The tools were created for the sole purpose of developer productivity, so embrace them. Let your team experiment with new VS add-ons or other editors (try WebStorm for example). In the whole scheme of things it’s not worth it to skimp on Dev Tools. You may spend thousands on tools, but that can result in much more savings in dev hours and frustration.

Cloud

Bad Manager	Good Manager
Developers heads are in the cloud enough as it is. All good software that was ever created is sitting on a computer under someone’s desk. Every once in a while you get a site that takes off, like Twitter, and you need to do shared hosting, but we aren’t Twitter. The cloud is just a buzzword cooked up by marketing folks. All clouds eventually precipitate and disappear – see “the water cycle”. I’m not making this up. That’s just science. If you really want a productive dev then they need to know how to mount physical servers on racks and swap out hard drives when they fail. As far as work items management and bug tracking, you definitely want that in Excel and on an internal SharePoint site so they have to VPN to get to it from home.	I was going to say that the Cloud is the future, but it’s not. It’s the present. Are you still running your stack on-prem? Come up with a plan to get it to the cloud. Developers love the Cloud because it greatly simplifies the part of their job that they just inherited when they became a combined engineer. Push, push, push - everything cloud all the time. Everything from your source to your production bits to your work items should be in the cloud.

Bad Manager

Good Manager

Developers heads are in the cloud enough as it is. All good software that was ever created is sitting on a computer under someone’s desk. Every once in a while you get a site that takes off, like Twitter, and you need to do shared hosting, but we aren’t Twitter. The cloud is just a buzzword cooked up by marketing folks. All clouds eventually precipitate and disappear – see “the water cycle”. I’m not making this up. That’s just science. If you really want a productive dev then they need to know how to mount physical servers on racks and swap out hard drives when they fail. As far as work items management and bug tracking, you definitely want that in Excel and on an internal SharePoint site so they have to VPN to get to it from home.

I was going to say that the Cloud is the future, but it’s not. It’s the present. Are you still running your stack on-prem? Come up with a plan to get it to the cloud. Developers love the Cloud because it greatly simplifies the part of their job that they just inherited when they became a combined engineer. Push, push, push - everything cloud all the time. Everything from your source to your production bits to your work items should be in the cloud.

DevOps

Bad Manager	Good Manager
Back when I started out as a dev I did everything. Developers these days label that “DevOps” and think it’s something new. What can be better than copying and pasting code from your /bin/debug folder to prod? Or better yet, just have them write a script to copy every local build to prod. That, my friend, is agility.	Get consistent about your deployments and code sharing. Learn how to dynamically scale with Azure or AWS. Simplifying deployments, environments and scale simply leads to a more productive developer because they can focus on creating. Encourage them to come up with new ways to save time. There’s a big effort on my team right now to automate every piece of our deployment and compliance process so we can get back to coding. The criteria for a DevOps task is 1) Do we need to do this thing? 2) If yes, then optimize it so we don’t have to think about it.

Bad Manager

Good Manager

Back when I started out as a dev I did everything. Developers these days label that “DevOps” and think it’s something new. What can be better than copying and pasting code from your /bin/debug folder to prod? Or better yet, just have them write a script to copy every local build to prod. That, my friend, is agility.

Get consistent about your deployments and code sharing. Learn how to dynamically scale with Azure or AWS. Simplifying deployments, environments and scale simply leads to a more productive developer because they can focus on creating. Encourage them to come up with new ways to save time. There’s a big effort on my team right now to automate every piece of our deployment and compliance process so we can get back to coding. The criteria for a DevOps task is 1) Do we need to do this thing? 2) If yes, then optimize it so we don’t have to think about it.

Hardware

Bad Manager	Good Manager
Everyone knows that major search engines run on commodity hardware. Why should developers need a better dev box than what one of the most sophisticated pieces of software on the planet needs? 4 Cores? 1 Core is more than enough. 32GB of RAM? When I was a dev I got by just fine with 2GBs. SSDs? Faster, yeah, but expensive and quiet. Every good dev needs a disc spinning in the background. Monitors? One 15 inch was fine for me 10 years ago and it’s more than enough pixels for today. Visual Studio takes up more screen real estate now, so that’s why the good people at Microsoft put scrollbars in there. Plus, we are using Visual Studio 2005…that version only has 42 context menu items – yes they go off the screen, but that’s what the keyboard arrow keys are for. Mice? Keyboards? Good devs don’t need them. Period. Everything that can be done with a keyboard and mouse can be done faster in the command prompt. Do not buy them Blync lights. It’s just one more thing you’ll have to ignore.	Invest in good hardware. Devs love working with reliable hardware. Crappy hardware gets in the way of what they love to do. I’m not saying buy everyone a 4k monitor, but make sure they have a super fast machine.I just got everyone on my team new SSDs so VS loads faster and local build time is reduced. Everyone has at least 2 24" monitors, Microsoft Sculpt keyboards and fast dev machines. I just placed an order for a couple of “3.7ghz, 6 Core, 32GB, 256 SSD, 1TB HDD, 8 video 4k output” machines.

Bad Manager

Good Manager

Everyone knows that major search engines run on commodity hardware. Why should developers need a better dev box than what one of the most sophisticated pieces of software on the planet needs? 4 Cores? 1 Core is more than enough. 32GB of RAM? When I was a dev I got by just fine with 2GBs. SSDs? Faster, yeah, but expensive and quiet. Every good dev needs a disc spinning in the background. Monitors? One 15 inch was fine for me 10 years ago and it’s more than enough pixels for today. Visual Studio takes up more screen real estate now, so that’s why the good people at Microsoft put scrollbars in there. Plus, we are using Visual Studio 2005…that version only has 42 context menu items – yes they go off the screen, but that’s what the keyboard arrow keys are for. Mice? Keyboards? Good devs don’t need them. Period. Everything that can be done with a keyboard and mouse can be done faster in the command prompt. Do not buy them Blync lights. It’s just one more thing you’ll have to ignore.

Invest in good hardware. Devs love working with reliable hardware. Crappy hardware gets in the way of what they love to do. I’m not saying buy everyone a 4k monitor, but make sure they have a super fast machine.I just got everyone on my team new SSDs so VS loads faster and local build time is reduced. Everyone has at least 2 24" monitors, Microsoft Sculpt keyboards and fast dev machines. I just placed an order for a couple of “3.7ghz, 6 Core, 32GB, 256 SSD, 1TB HDD, 8 video 4k output” machines.

Process

Bad Manager	Good Manager
Developers like to live in silos, which is why they like waterfall. What they really like is a lot of planning, usually around 6-9 months, and then coding for about 1-2 weeks and then feature cuts or project cancellations and then more planning. Agile? I love agile. I mean the team is saying that anyone can come at any time and request anything and they will accommodate it? Perfect. Standups? No. Devs should be sitting and coding and not talking. People will know when their stuff is done because they can hear them yell “compiling!” from down the hall. Discourage pair programming. You are the one paying them to code, not to be buddies. You definitely don’t want two people working on something that one person could do alone. Plus, you have the added benefit of discovering that those two devs actually developed the same thing independently and then have to wrestle over which implementation is better. There’s nothing like a good unnecessary heated debate to boost productivity.	Whether you like it or not, your developers will use agile. As I mentioned before we are very efficient humans. We optimize. We start a lot of things, but also know when to stop them when they are failing. Why not embrace agile and be a strong advocate for it? That will definitely motivate your devs to come up with new ways of doing things that help them be more productive. Support their ideas. Try anything once. Agile doesn’t mean you just adopt Scrum or you do a standup. It’s a cultural shift that embraces iteration and constant feedback. You have to be okay with uncertainty, but by doing so leads to team to productivity.

Bad Manager

Good Manager

Developers like to live in silos, which is why they like waterfall. What they really like is a lot of planning, usually around 6-9 months, and then coding for about 1-2 weeks and then feature cuts or project cancellations and then more planning. Agile? I love agile. I mean the team is saying that anyone can come at any time and request anything and they will accommodate it? Perfect. Standups? No. Devs should be sitting and coding and not talking. People will know when their stuff is done because they can hear them yell “compiling!” from down the hall. Discourage pair programming. You are the one paying them to code, not to be buddies. You definitely don’t want two people working on something that one person could do alone. Plus, you have the added benefit of discovering that those two devs actually developed the same thing independently and then have to wrestle over which implementation is better. There’s nothing like a good unnecessary heated debate to boost productivity.

Whether you like it or not, your developers will use agile. As I mentioned before we are very efficient humans. We optimize. We start a lot of things, but also know when to stop them when they are failing. Why not embrace agile and be a strong advocate for it? That will definitely motivate your devs to come up with new ways of doing things that help them be more productive. Support their ideas. Try anything once. Agile doesn’t mean you just adopt Scrum or you do a standup. It’s a cultural shift that embraces iteration and constant feedback. You have to be okay with uncertainty, but by doing so leads to team to productivity.

Quality

Bad Manager	Good Manager
TIP (Testing In Production) is cool, but TIP-WAU (Testing In Production With Actual Users) is even cooler. If you want to know where the bugs are in your software then just ship it. Users will report any bugs. That way you don’t need to distract developers from what they do best…creating new features. Those new features may break other features, but as long as the new feature somewhat works it’s all good. There’s this popular concept that “good enough” is better than “perfect”. I like to take that a step further and say “Compiling? Ship it!”. Hit F5. Build Succeeded? Ship. Don’t think, don’t test it, just ship it. Devs like to ship. Give them that opportunity. Since devs should be working on new features, they don’t really have time to be writing unit tests. If they wrote the code right the first time then unit tests aren’t really necessary. What has worked for me is just happy-path testing every other release when they have time, which is never, because they are coding new features. Most features get cut anyway, so the chance of them ever being seen by a customer is slim to none.	This is a transitional year for Microsoft. We are moving from a 4 team setup (Dev, Test, PM & Ops) to two team setup (Dev and PM). The Test and Ops roles are merging with the Dev discipline. We inherited a lot of responsibility and are working through it. My team is investing heavily in test automation. From unit tests to end-to-end test to performance. We are coming up with a solution that allows us to build functional and end-to-end tests upon unit tests. The idea is to optimize testing and get it as close to the code as possible. There’s no way we can ship as fast as we’d like to without automation. Fixing this means better quality releases and more time focused on making sweeping changes that were too risky before automation.

Bad Manager

Good Manager

TIP (Testing In Production) is cool, but TIP-WAU (Testing In Production With Actual Users) is even cooler. If you want to know where the bugs are in your software then just ship it. Users will report any bugs. That way you don’t need to distract developers from what they do best…creating new features. Those new features may break other features, but as long as the new feature somewhat works it’s all good. There’s this popular concept that “good enough” is better than “perfect”. I like to take that a step further and say “Compiling? Ship it!”. Hit F5. Build Succeeded? Ship. Don’t think, don’t test it, just ship it. Devs like to ship. Give them that opportunity. Since devs should be working on new features, they don’t really have time to be writing unit tests. If they wrote the code right the first time then unit tests aren’t really necessary. What has worked for me is just happy-path testing every other release when they have time, which is never, because they are coding new features. Most features get cut anyway, so the chance of them ever being seen by a customer is slim to none.

This is a transitional year for Microsoft. We are moving from a 4 team setup (Dev, Test, PM & Ops) to two team setup (Dev and PM). The Test and Ops roles are merging with the Dev discipline. We inherited a lot of responsibility and are working through it. My team is investing heavily in test automation. From unit tests to end-to-end test to performance. We are coming up with a solution that allows us to build functional and end-to-end tests upon unit tests. The idea is to optimize testing and get it as close to the code as possible. There’s no way we can ship as fast as we’d like to without automation. Fixing this means better quality releases and more time focused on making sweeping changes that were too risky before automation.

Rewards

Bad Manager	Good Manager
Devs are already really well paid for what they do. Typing and thinking is not that difficult. When someone does something that deserves a reward, like when they check-in code without it getting reviewed or when they overwrite someone else’s changes or go out of their way to delete production data…that’s when you’ll be tempted to reward them, but don’t. It only leads to more ego inflation and further distraction from coding. The last thing you want is a developer walking around thinking they are valuable.Since devs are so well paid and aren’t really interested in making more money so you have to give them mundane work that anyone could do. Like fixing content bugs or updating documentation. Then when they get to code actual features they will be way more productive because they know how bad it could be.	Money definitely isn’t everything, but you have to be competitive. I take a pulse on how people in the industry are paid and I think Microsoft is doing well. Especially if you consider the entire compensation package. I stand behind my theory that if you do your absolute best you’ll be rewarded for it. And if not at least you know you did your best and can start thinking about places where you are better appreciated. My hope is that no one on my team feels that way. A big reward for doing something well is the opportunity to take on more challenging work. Devs love a good challenge. Small wins lead to bigger challenges and my team is usually thrilled to take them on.

Bad Manager

Good Manager

Devs are already really well paid for what they do. Typing and thinking is not that difficult. When someone does something that deserves a reward, like when they check-in code without it getting reviewed or when they overwrite someone else’s changes or go out of their way to delete production data…that’s when you’ll be tempted to reward them, but don’t. It only leads to more ego inflation and further distraction from coding. The last thing you want is a developer walking around thinking they are valuable.Since devs are so well paid and aren’t really interested in making more money so you have to give them mundane work that anyone could do. Like fixing content bugs or updating documentation. Then when they get to code actual features they will be way more productive because they know how bad it could be.

Money definitely isn’t everything, but you have to be competitive. I take a pulse on how people in the industry are paid and I think Microsoft is doing well. Especially if you consider the entire compensation package. I stand behind my theory that if you do your absolute best you’ll be rewarded for it. And if not at least you know you did your best and can start thinking about places where you are better appreciated. My hope is that no one on my team feels that way. A big reward for doing something well is the opportunity to take on more challenging work. Devs love a good challenge. Small wins lead to bigger challenges and my team is usually thrilled to take them on.

Fun

Bad Manager	Good Manager
No ping-pong. No darts. No kickball. No pool. No “wine-downs”. No “morale events”. No alcohol. No fun. No. Never. That’s what their every other Sunday is for (see “Hours” above). Fun just means time away from coding, which is what developers love to do. So, in fact, you are doing them a favor by not forcing them to pretend that they like getting to know other people.	We have a dartboard, ping-pong and foosball table. We play kick-ball in the summers. We just had a ping-pong tournament. We are going to K1 racing later this month. We just saw 300. The result is that we get to know our peers, build respect and have a good time when we get back to coding.

Furniture

Bad Manager	Good Manager
Amazon uses doors as desks and they built an empire. I coded on a 2’x2’ desk for years. If they are sitting, they shouldn’t be complaining. Some developers out there even have to use their treadmill as a desk and they aren’t complaining. Get your dev a chair, preferably a metal folding one, and they’ll be happy. Do not get them ergonomic evaluations. You only have them for a year or so; let the next manager deal with their health issues. Also, it’s best to put them in an interior facing office. Microsoft didn’t build “Windows” by looking out the window all day. Give them an office with a view and their mind will wander. Yes, by giving them time to think they might come up with a better solution, but it will take longer – and we are talking about productivity right?	Microsoft in general is very good about setting people up with ergonomic workstations. We have sit-stand desks, ergonomic chairs and we have a team of ergonomists who can do one-on-one consultations with people. Devs are way more productive if they aren’t hurting.

Bad Manager

Good Manager

Amazon uses doors as desks and they built an empire. I coded on a 2’x2’ desk for years. If they are sitting, they shouldn’t be complaining. Some developers out there even have to use their treadmill as a desk and they aren’t complaining. Get your dev a chair, preferably a metal folding one, and they’ll be happy. Do not get them ergonomic evaluations. You only have them for a year or so; let the next manager deal with their health issues. Also, it’s best to put them in an interior facing office. Microsoft didn’t build “Windows” by looking out the window all day. Give them an office with a view and their mind will wander. Yes, by giving them time to think they might come up with a better solution, but it will take longer – and we are talking about productivity right?

Microsoft in general is very good about setting people up with ergonomic workstations. We have sit-stand desks, ergonomic chairs and we have a team of ergonomists who can do one-on-one consultations with people. Devs are way more productive if they aren’t hurting.

Food

Bad Manager	Good Manager
Joel Spolsky was wrong. Never. I mean never eat with your team. You don’t want to make them think you are one of them do you? Encourage them to bring their own lunch and eat it at their desks. If they want coffee then tell them to get instant and use the hot water from the sink. Think about loss in productivity if two of them go to get coffee at the same time and accidentally bump into each other and start talking? Devs eating alone at their desks means more code. That’s just math.	We eat lunch together almost every day of the week. If not the Microsoft cafe, then one of the many restaurants around Bellevue. It’s a great way to get to know your devs and talk about non-work stuff. We often chat about software and business ideas and of course Breaking Bad.

Bad Manager

Good Manager

Joel Spolsky was wrong. Never. I mean never eat with your team. You don’t want to make them think you are one of them do you? Encourage them to bring their own lunch and eat it at their desks. If they want coffee then tell them to get instant and use the hot water from the sink. Think about loss in productivity if two of them go to get coffee at the same time and accidentally bump into each other and start talking? Devs eating alone at their desks means more code. That’s just math.

We eat lunch together almost every day of the week. If not the Microsoft cafe, then one of the many restaurants around Bellevue. It’s a great way to get to know your devs and talk about non-work stuff. We often chat about software and business ideas and of course Breaking Bad.

Personal

Bad Manager	Good Manager
Do not, I repeat, do not add your developers to Facebook. You do not want them seeing pictures of your kids and dogs. They might actually think they relate to you in some way and will want to talk about it when they see you. You don’t want them to think you are a normal person with a normal life. The last thing you want is people commenting about how cute your kid is or asking about your Mastiffs. Don’t talk about stuff they are interested in. If they like cars, then talk about hunting, if they like sports, then talk about music. Anything to divert the conversation from their interests. Under no circumstances should you ask them what their kids names are and if they tell you come up with a memory trick to immediately forget them. You might slip and say their name in the future and the developer might think you care. Which, as we know distracts from them coding.	We are all pretty tight here. It’s Saturday and I just got back from bowling with my family and my co-workers family. We know the names of each other’s family and we hang out regularly. It’s like an extended family. It’s got to be organic though. Some like that, some don’t. Know when to back off.

Bad Manager

Good Manager

Do not, I repeat, do not add your developers to Facebook. You do not want them seeing pictures of your kids and dogs. They might actually think they relate to you in some way and will want to talk about it when they see you. You don’t want them to think you are a normal person with a normal life. The last thing you want is people commenting about how cute your kid is or asking about your Mastiffs. Don’t talk about stuff they are interested in. If they like cars, then talk about hunting, if they like sports, then talk about music. Anything to divert the conversation from their interests. Under no circumstances should you ask them what their kids names are and if they tell you come up with a memory trick to immediately forget them. You might slip and say their name in the future and the developer might think you care. Which, as we know distracts from them coding.

We are all pretty tight here. It’s Saturday and I just got back from bowling with my family and my co-workers family. We know the names of each other’s family and we hang out regularly. It’s like an extended family. It’s got to be organic though. Some like that, some don’t. Know when to back off.

Reviews

Bad Manager	Good Manager
I like to take the “shock jock” approach to reviews. Like a volcano waiting to explode, I save up all my “constructive feedback” for the annual review meeting, then I just let them have it. You have to keep them guessing all the way up to the last moment. If they ask for feedback before the review, just tell them you don’t work with them day-to-day so you can’t really know how they are doing. You don’t want them thinking they are doing a great job because then they will relax, which decreases productivity. Software development is purely science. Many developers will try to convince you it’s an art, rather than a science. You should combat that with objective measurements like line of code per day, code coverage numbers and status reports. “Big data”, right? It starts with collecting data on developer productivity. Reward stuff that can be measured like number of check-ins and “hours in the office per day” and you’ll have a team that is cranking away.	I have a whole post on “My Thoughts on the Microsoft Employee Review Model”. But the gist of it is that Devs need regular feedback. Good or bad. Their annual review should be a review of what you’ve been telling them for the past 12 months. No surprises. Devs are very self-critical people, but if they know they are doing well or not doing well then they’ll likely be more productive either way.

Bad Manager

Good Manager

I like to take the “shock jock” approach to reviews. Like a volcano waiting to explode, I save up all my “constructive feedback” for the annual review meeting, then I just let them have it. You have to keep them guessing all the way up to the last moment. If they ask for feedback before the review, just tell them you don’t work with them day-to-day so you can’t really know how they are doing. You don’t want them thinking they are doing a great job because then they will relax, which decreases productivity. Software development is purely science. Many developers will try to convince you it’s an art, rather than a science. You should combat that with objective measurements like line of code per day, code coverage numbers and status reports. “Big data”, right? It starts with collecting data on developer productivity. Reward stuff that can be measured like number of check-ins and “hours in the office per day” and you’ll have a team that is cranking away.

I have a whole post on “My Thoughts on the Microsoft Employee Review Model”. But the gist of it is that Devs need regular feedback. Good or bad. Their annual review should be a review of what you’ve been telling them for the past 12 months. No surprises. Devs are very self-critical people, but if they know they are doing well or not doing well then they’ll likely be more productive either way.

Training

Bad Manager	Good Manager
People on my team have spent a ton of time and money on college. Everything you ever need to know was learned in college, so why should you spend your budget on training? Don’t get them Pluralsight subscriptions and definitely don’t send them to conferences. Can they code a for loop? Can they get it to compile? What more do you need to know? Time spent training is time away from coding.	I just renewed my 30 Pluralsight licenses for my team. We log hundreds of hours of training each month. Many on my team go to conferences, some speak at them. I usually recommend at least 40 hours of training a year. We also have a great internal training program. I have never turned down a request for training. You have to invest in yourself. I’m just the enabler.

Credit

Bad Manager	Good Manager
Your job as a manager is to take credit for the work that your team does. If someone has to demo what your team developed to the VP, then it should be you doing it. Make sure you mention that “I” did it…never use the word “team” and definitely don’t mention anyone on your team by name. If anyone is going to get attention it should be you and you alone. Developers don’t really care for the spotlight anyhow, so everyone wins. They get to keep coding and you get promoted.	My team just did a demo for our VP on what we’ve been working on over the last 6 months. I was in the room, but my leads and architect did the talking and demos. I want their work to be recognized and I want them to be associated with it, not me. We are constantly congratulating each other on our successes and are very supportive of team efforts. We are great about talking about what we have accomplished and who helped us along the way.

Bad Manager

Good Manager

Your job as a manager is to take credit for the work that your team does. If someone has to demo what your team developed to the VP, then it should be you doing it. Make sure you mention that “I” did it…never use the word “team” and definitely don’t mention anyone on your team by name. If anyone is going to get attention it should be you and you alone. Developers don’t really care for the spotlight anyhow, so everyone wins. They get to keep coding and you get promoted.

My team just did a demo for our VP on what we’ve been working on over the last 6 months. I was in the room, but my leads and architect did the talking and demos. I want their work to be recognized and I want them to be associated with it, not me. We are constantly congratulating each other on our successes and are very supportive of team efforts. We are great about talking about what we have accomplished and who helped us along the way.

Vision

Bad Manager	Good Manager
Visions are overrated. You want to keep them guessing about what you are thinking. Don’t come out and say you don’t have a vision. Keep talking about how you are working on the vision and how you will “reveal it soon”. Encourage them to be tactical, focus on today and let you handle the future. If you have a vision, then your team starts to think you have their back and will want to stick around on your team. Or they could see the vision, not agree with it and leave. Either way it’s a lose-lose situation. People are attracted to what they can clearly see, so make the future as fuzzy as possible so they gravitate towards coding for today and then surprise them at the last possible moment.	Developers like to go deep, but everyone once and a while they like to peek into the future and see if they’ll be interested in where the team or product is going. You don’t want to shove it down their throats, but it is the manager’s job to have the vision ready for them when they need it. They have amazing insight into future potential for the product they are working on and they should be deeply involved in shaping its future. Having that view into what is coming helps them either rest and focus makes them nervous because they see you don’t know what you are doing. Make sure it’s the former.

Bad Manager

Good Manager

Visions are overrated. You want to keep them guessing about what you are thinking. Don’t come out and say you don’t have a vision. Keep talking about how you are working on the vision and how you will “reveal it soon”. Encourage them to be tactical, focus on today and let you handle the future. If you have a vision, then your team starts to think you have their back and will want to stick around on your team. Or they could see the vision, not agree with it and leave. Either way it’s a lose-lose situation. People are attracted to what they can clearly see, so make the future as fuzzy as possible so they gravitate towards coding for today and then surprise them at the last possible moment.

Developers like to go deep, but everyone once and a while they like to peek into the future and see if they’ll be interested in where the team or product is going. You don’t want to shove it down their throats, but it is the manager’s job to have the vision ready for them when they need it. They have amazing insight into future potential for the product they are working on and they should be deeply involved in shaping its future. Having that view into what is coming helps them either rest and focus makes them nervous because they see you don’t know what you are doing. Make sure it’s the former.

Closing Thoughts

If your goal is to ship at all costs, then the price you’ll pay will be counted in the number of developers who have left your team. I believe that a happy dev team is more productive. The second you realize that every single one of your developers could be doing something else with their time, you don’t take them for granted. They won’t turn down more money, but money isn’t the be all and end all for developers. They want fun, interesting, challenging and meaningful work. It’s up to managers to set the team up for success by finding out what makes them tick and doing everything they can to remove obstacles. Some of these obstacles are imposed by you the manager. Not fostering training hinders progress. Not caring about quality crushes motivation. Not rewarding leads to disenfranchisement.

You can start helping with dev productivity by taking baby steps. Hear from you team about what makes them tick. Prioritize, execute and repeat.
Jon

*My Thoughts on Work/Life Balance at Microsoft
*My Thoughts on the Microsoft Career Model - Do I have to get into management to be successful at Microsoft?
*My Thoughts on the Microsoft Employee Review Model
*Microsoftie Perks
*How to get a job at Microsoft

LeadershipProductivity

Hours

Meetings

WFH

Software

Cloud

DevOps

Hardware

Process

Quality

Rewards

Fun

Furniture

Food

Personal

Reviews

Training

Credit

Vision

Closing Thoughts