The software development process is cyclical. A team goes through relatively calm periods where they are just executing and then periods where a deadline approaches and the team has to turn the effort on and the pressure up. For the worst-managed teams, these periods turn from short sprints of extra pressure to long extended “death-marches” where the pressure is unrelenting for months.
Microsoft software teams would schedule regular “workaholic” nights to drive towards bug goals. When I was FrontPage dev manager, this was a normal part of the process as we drove to key deadlines like a Beta release and the final Release To Manufacturing (RTM).
After one release where this had become too normal a part of the process with multiple workaholics and dinners served per week, I changed my approach to these deadlines.
The first thing I came to realize is that you could not really change the total work product output of the team. Inevitably if you had people working late nights under pressure, you would end up giving back that output sometime else in the week. Maybe they would straggle in late morning or lose focus and productivity during the long afternoons. You didn’t actually see this big increase in productivity by creating this extra stress.
It was not a small motivation that I had 3 young kids at home and I would rather be having dinner with my family than sitting at work with my team. I also wanted to be able to take off some afternoons to coach their baseball, basketball, soccer or Ultimate teams.
The next release cycle, I continued my focus of being very clear what our team and individual goals were, but stretched those goals out to be weekly goals. This gave each developer flexibility to schedule how they reached those goals over a course of the week. Some continued an addiction to caffeine-driven late nights, while others liked the quiet and focus of early mornings.
The team goals were just a roll-up of the individual goals. Individual goals were driven by historical averages — different areas of the product tended to have different rates of bugs and bug fixes. Each week we would review our progress together and re-establish goals for the week. My policy was always to be transparent about how we were doing as a team and how we were doing as individuals — the team result was just the rollup of what the individuals on the team had accomplished.
There is a delicate balance to walk with individual accountability vs. “blame”. My focus on transparency was always “it is what it is” rather than “how did you screw up?”. Ultimately it was my responsibility as manager to deliver the product. If we weren’t hitting our goals, it was my problem. There were lots of potential knobs to turn and just yelling “work harder!” wasn’t a very effective knob. You could move people around to different areas of the product, move tasks around, use a simpler design, cut features or even slip the release date.
If something didn’t get done, you dealt with it and moved on. If someone was not actually producing the way you expected them to, that was something that was dealt with on a longer annual-review time-scale. In the near term you just adjusted your expectations to improve the accuracy of your goal setting and made tactical adjustments to deliver the product.
I gained a better appreciation for the delicacy of the balance required in avoiding a blame game after I left FrontPage. The manager who took my role was a good guy, but somehow shifted that weekly progress report and goal setting from a collaborative sharing of progress and challenges to a dreaded grilling session about missed goals and failure. Despite essentially identical processes, the dev team revolted over a process they felt had turned toxic. It took a ton of work for the team to regain trust in their management.
That experience reinforced a number of points for me.
- Never give up on transparency. Some managers respond to the risk of creating a culture of blame when exposing individual results by masking individual outcomes. This creates a slippery slope of information hiding “for their own good”. The cultural advantages of rigorous transparency are too valuable to risk.
- Assume the best. Virtually everyone is working as hard as they can. They want the team to be successful and they want to be personally successful. Your focus needs to be on making sure they have the information necessary to make the best possible decisions. If you start creating a culture of blame, the immediate effect is going to be you will get less clarity into what the real state of the project is and where the real problems lie.
- Deal with the underlying problem. Just working harder is unlikely to be the solution. As the manager, you have more degrees of freedom than the individual developer. Use them.
The one last point this experience reinforced is that managing is often a subtle art. You need things to go wrong sometimes to realize what you are doing right.