Software Engineering, Project Management, and Effectiveness
"Eight hours work, eight hours sleep, eight hours play, make just and healthy day." - King Alfred the Great
One of the most important lessons at Microsoft was learning the value of a 40 hour work week. I’ve been on time, on budget for 10 years on projects ranging from grass-roots or “best efforts” to $ million+ investments. In my first few years, I was on time, on budget through heroic effort. That’s not sustainable and folks don’t want to sign up for that more than once. Luckily, I learned early on how to drive more effective results by fixing time and flexing scope, while flowing value, and optimizing team health. I also learned the value of figuring out effective product-lines, managing portfolios of investments, finding the best “Hot Spots” on heat maps of customer pain and opportunity, and mastering the art of the WBS (work breakdown structures) and cuttable scope.
For some people that have experienced effective 40 hour work weeks on a regular basis, this will be “no-duh.” For those that haven’t, this may be unfathomable, so I’ll share what I’ve learned so at least it can give you food for thought and potentially help give you a mental model of what success can look like. I originally slanted this for individuals and 40 hour work weeks, but I realized it’s more effective if more team leaders drive 40 hour work weeks so that everybody wins.
Why a 40 Hour Work Week It’s not that I just want happier, healthier, more effective colleagues. I want a more effective Microsoft.
In my experience, a 40 hour work week is a benchmark of the most effective teams. They have work-life balance. They have buffer to respond to opportunity and to deal with crunches. They have processes in place, they invest in their learning and growth, and they move up the stack instead of always solving the basics. Instead of perpetual fire-fighting, they are more deliberate about planning and strategy and they anticipate their customers and the market (through empathy and staying connected to customers.) They learn and respond and can turn on a dime. They have a dashboard, they know the score, and they can change their approach.
There’s another reason that cuts right to the chase. If budget cuts will break you, then the first way to build a firm foundation and execution machine is to master the 40 hour work week. It’s a forcing function that fixes a lot of underlying execution issues that you just cannot see if your organization throws time at problems. If you can’t see it, you can’t fix it. When you bound it by time, you can start testing more effective ways to produce results. To make this actionable, make it an initiative.
60-80 Hour Week of Ineffectiveness Here are some of the attributes of teams that lead and drive 60-80 hour weeks of ineffectiveness and inefficiency:
Ultimately, it’s a lost of waste on multiple levels. Mostly, it’s a waste of human potential.
40 Hour Week of Effectiveness Here are some of the attributes of teams that lead and drive 40 hour work weeks of effectiveness:
While these insights and lessons might seem easy, intuitive, or simple, they are actually hard-earned and they are directly from the school of hard knocks. It took multiple managers, testing with multiple teams over multiple years, and a lot of trial and error to figure out what actually works.
Cornerstone Concepts for More Effective and Efficient Weeks There are some fundamental concepts and shifts to understanding why and how a 40 hour work week is more effective than a 60 or 80 hour work week. You need a few concepts under your belt to help guide you through change:
My Story One of my toughest lessons to learn at Microsoft was the value of a forty hour work week. I'm known for being a workhorse. 16-20 hour days, 7 days a week was just a way of life for me. Long ago, I heard the saying you'll have plenty of time to rest when you're dead and it stayed with me ever since.
To make it worse, when I joined Microsoft, I was surrounded by passionate people who also worked well beyond a forty hour work week. I was in the zone. Not just that, I was spending my time in my passion, so I never burned out. Throwing hours at problems was no sweat and I liked the pace.
My first taste that this was a problem was when my first manager sat me down and said that my perpetual over-time was a problem. He said I was throwing off the head count. I was doing the work of multiple engineers. It made it hard for him to argue for heads if the work was getting done, and he worried that I would burn out. Luckily, I never burned out. It turns out the primary ways you burn out are by trying to solve the same problem over and over like a broken record with no results, or by spending time in things that drain you. The simplest cure for burnout is spending more time in your passions or moving to new problems or changing your container.
My second taste that this was a problem was when I joined patterns & practices. After my first few projects, my manager told me I needed to find a way to work 40 hours and produce the same or better results. Additionally, I had to get more effective results from the rest of the larger team. In other words, I wasn’t setting a good example, I set an impossible bar, and I had to make the most of the team (Oh, and did I happen to mention that this larger team was always a distributed team around the world, from UK to Argentina to India and the US?) The good news is, the story has a happy ending …
To bottom line it, by setting a constraint around the 40 hour mark, it dramatically improved team processes, improved clarity on impact, and it helped flow value versus waiting for big bang. This also had an amazing set of by-products, including achieving work-life balance for all team members, helping people spend more time in their passion and strengths, reducing downstream risk and surprises, and keeping the energy strong across the team in a more durable way. It also helped us improve our daily, weekly, and monthly rhythms of results while improving our team practices and procedures. We basically moved up the effectiveness stack and it got faster each time we had to build a new team.
The basic approach I used is what I call Monday Vision, Daily Outcomes, and Friday Reflection. I did “show and tells” on Thursdays as a forcing function to drive results but to also give folks on the team a chance to show off their work and get feedback earlier versus later.
Call to Action Make a 40 Hour Work Week an initiative, for yourself, for your team, or for your organization. Start small. Lead by example. Start with yourself, then help other people. Focus on finding more effective ways to do things, focusing on the vital few things that matter the most, playing to your strengths, and improving your energy. Know what counts and be able to put your finger on it.
You can explore the system in Getting Results the Agile Way. The Scenarios and Solutions for Getting Results and the Guidelines for Getting Results are fast tours of the landscape and rich with strategies and tactics for changing your game.
Everything that you mentioned is not always applicable.
It all depends on the particular mission.
For example, if there is a new virus, people in security teams
have to work around the clock to find a way to defeat it.
There is no 40 hour work week for them.
This is called "dedication".
@ Dimitrios -- Thank you. That goes without saying, but I'm glad you said it -- you always have to measure effectiveness against what you want to accomplish. Your path on the mission is guided by the objectives.
There are always going to be exceptions to 40 hour work weeks, but that should be the exception, not the norm.
Some folks never see what a 40 hour week can look like and they don't know there are better ways for better days. It's their only mental model -- throwing hours or throwing bodies at problems.
I've often seen "dedication" used in place of poor staffing, ineffective planning, ineffective processes/procedures/red tape, you name it. I see it happen when people don't have clarity on value or how to measure value so they default to industrial age practices.
A simple cutting question I ask folks is, what can't you get done in 40 hours ... show me what falls off the plate? That sets the stage ... then we look at what gets done in the 40 hours and the outcomes, priorities, etc.
Nobody has ever been able to show me a great rundown of how their team spends their time in a super effective way to justify more than 40 hours of effective results ... and if they did have the workload justification, then it actually turns out they are understaffed. In those cases, something has to give, and effective managers prioritize their people for the long haul and sustainable results. When they can't get the people, they do less, reset expectations, and focus on the vital few outcomes that deliver the most value.
Fire-fighting will always happen and there will always be disrupters ... but when you have an effective, sustainable rythm of results ... you can better deal with those exceptions and everybody moves up the problem solving stack and quality of work and life.
Now, with all that said ... I'm a fan of people stepping up to the plate and going the extra mile because they are inspired and doing what they love. That's the kind of dedication I love to see.
J.D, I'm afraid your solution would only work for a mature and reasonably well built team, where eveyone's work generates a positive result.
I've worked on teams before, where management doesn't care and other members of the team produce code that has to be rewritten every night...
So I had to put in extra time just to keep the project from falling apart, and working a 40 hour week would mean leaving the project in the hands of those who will screw it up, and intentionally or not, introduce security holes into it..
I wonder what your perspective is in those situations, when the team's overall quality is worse than what you seem to have at Microsoft...
@ Robyn -- It sounds like you've had the joys of batting cleanup. I've been there. It's no fun.
The "heroic effort" pattern isn't sustainable, and isn't effective when people can "vote with their feet." So I had to find more effective ways ...
Unfortunately I don't get handed mature and well-built teams -- I have to grow them. Because all our work is project based, I've built a new team every six months with new people with different backgrounds, culture, work ethics, productivity skills, etc. from around the world. As you can imagine, I've had to go through many, many forming, storming, norming, and performing stages. Luckily, I've learned short-cuts along the way ;)
Rather than optimize around individual intelligence, I've learned to optimize around collaboration skills and team processes. For example, by doing "show and tells" each week, people improved their work faster. For example, by doing Daily Standups, people became accountable for their work. By pairing people up, people learned faster from each other and complemented each others strengths.
Keep in mind, I'm not a fan of heavy processes. As we say, the right amount of process is "just enough" so you don't get in the way of good people. The right process helps people move up the stack and stop solving the same basic issues.
Here are some proven practices from the school of hard knocks on improving team effectiveness:
blogs.msdn.com/.../patterns-and-practices-for-distributed-teams.aspx