TL;DR: If you shield your team from unsustainable work hours, you might be accused of a lack of “output orientation”. However, there is more to “output” than meets the eye. Make your critics see that.

As a team lead, or engineering manager, you often read that you should be a “shit umbrella” for your team: Shield them against the bad stuff happening outside the team so that the developers can focus on their work. Protect the devs from political games, and ensure they have the long stretches of uninterrupted time that they need. Sounds reasonable, right? Sign me up! I want to be that guy! I want to be a shit umbrella!

Only: What kind of “shit” are we actually talking about? Let us look at an example: For the development of a thrilling new feature, there were unrealistic expectations, bad specifications, and a lot of last-minute changes. As a result, development is running late. There is a random deadline which only exists because something was promised to management by some date, and which was never aligned with the development team in the first place. There is danger of not making the deadline. Which of the two following scenarios is more likely to happen?

• Scenario a) The people who promised the feature by the date in question admit that, with all the changes and the incomplete specifications, the deadline cannot be made. They explain the situation to their higher-ups and agree on a new completion date, this time in alignment with the development team.
• Scenario b) Someone — either the people who promised the feature by the date in question, or the people who were promised the feature — pressures the development team to work faster or harder, or long hours, or weekends, or all of the above, in order to make the deadline.

I have actually, in a few rare cases, witnessed scenario a), where responsible product owners have corrected an ill-conceived prediction towards management. However, in a hurried, high-pressure environment, they have a strong incentive to choose route b), and pressure the development team to somehow make the impossible happen. This is exactly where you as their team lead or engineering manager come in, because one of the items in your role definition is to protect the development team from distraction and haste. Impossible deadlines fall under that category.

Pushing back

You don’t want your people to work overtime or on weekends, because it is not right. It is a last resort for extremely rare cases, but by no means sustainable when used regularly. Looking at the current state of the project, it is clear that a couple of “crunch-time days” will not resolve the situation, and overtime is counterproductive beyond that. Moreover, some of the team have family and simply cannot do it, which would create an unhealthy imbalance on the team. In general, you do not see the point in pressuring your people, because you know that people under time pressure do not think faster.

So you push back.

You question the deadline. You say it out loud that it will most likely not be met. You point out that additional time pressure will only lead to people taking shortcuts and producing technical debt, which will result in bugs and additional clean-up work down the road. You challenge the decision makers and their deadline: Is making this deadline, which is not even something that was announced outside the company, really worth pushing our people to unhealthy time investment?

Regardless of the outcome of this discussion, you will probably face resistance. People will call you unpleasant things, one of which might be: You are not output oriented enough.

If you were more output oriented, you would make your people understand that we are working on an industry-defining feature here, and that this fact alone should be enough to propel them forward.

If you were more output oriented, you would make them see that, if we do not launch phase two (1) of this feature next week, then we will not be able to start gathering data we need for stage three, and the schedule cannot be held, and further delays will happen.

If you were more output oriented, you would put company interests first.

The entire output

Ouch. You always considered yourself and your team pretty productive and hard-working, but now your amount of output is put into question. But wait a second… which output are we actually talking about?

The “output” that the proponents of more output orientation talk about is the working feature, or whatever “phase 2” comprises. However, as a manager who has people’s long-term happiness in mind, you have to think more holistically. From that perspective, the output of the development effort also includes the technical debt, as well as the impression your employees get from how the situation was handled. If it is handled in a good way, their satisfaction and loyalty will rise. If all the pressure is routed their way and they have to pay the bill for bad planning and unrealistic scheduling, they might feel used and exploited.

In Slack, Tom DeMarco reports on a project that was run on an aggressive schedule for several months. The result of it was that, before the project was completed, all of the original staff had quit and moved on to a different job. Here, “output orientation” produced a great deal of turnover. This turnover, along with its substantial cost, has to be considered as output of the development process.

Advocates of more “output orientation” — i.e., more pressure — are usually not aware of this cost. Moreover, it is unlikely that they will see it themselves. So it is our job as engineering managers to make them see at least these two dangers that come with additional pressure:

• Additional development effort resulting from bad, hurried choices made during the high-pressure phase.
• Productivity loss or turnover because of disappointment and low morale in the development team.

Beyond the current situation

If you can get the stakeholders to agree to a more sustainable plan of action, this will probably cost you political capital, so proceed with care. You do not want to end up in a corner where you are seen as the knee-jerk delayer and blocker who does not care about the business, but only that his people are comfortable. If it comes that far, you will not be taken seriously any more, and you can no longer be of real use to your own people. You can regain political capital by demonstrating that the time you invested in doing a clean job pays off through fast subsequent development, and by making an extra effort supporting the stakeholders in reaching their goals.

If, however, you cannot reach agreement on a sustainable plan of action, you can at least point out the risks you see. If things really go wrong some time later on — if delays or cumbersome rewrites have to be accepted, or if employee motivation and loyalty plummet — it is your job to hold the stakeholders accountable and remind them of your prediction. This is not about “I told you so”, but about organizational learning. The next high-pressure situation will surely come, and that one can be handled better if everyone is a bit smarter than during the previous time.

Worst case scenario: People refuse to learn from the failure. Then, the bad consequences that you predicted correctly should give you a good negotiation position for the next time. Unfortunately, this is little consolation if some of your key people quit.

Conclusion

Output orientation is often about the trade-off between short-term and long-term. Stakeholders see the short-term benefits of “squeezing out” some more results. However, they rarely see the cost that comes with it — more bugs, worse code, slower development, frustrated developers. The stakeholders do not have to live with these negative results directly, but naturally, they are by all means affected. It is our job as communicators and facilitators to make the cost visible to them.

By the way, you should not want to do this for the glory, or because you want people to thank you for your heroic perseverance. Ideally, your team should not even be aware of it, because it might distract them, which is exactly what we want to avoid. They might have a bad conscience that you take all the heat for them. So, from a development view, it is best if they are ignorant of the discussions that are going on. As is often the case as a manager, you are on your own.

Time investment

This blog post took me about 4 hours to write.

Footnotes

1. Turns out that “phase 2”, just like “phase 1”, does not actually change anything for the users. But it does allow us to gather some more data that we will not use for another two weeks.