I’ve been in IT for over 20 years now, some of them as a developer, and when I see a recurring pattern, it’s that those who try to put unnecessary pressure on developers or engineers almost always achieve the opposite. Most of the time they don’t understand that, because they see themselves in the right. But it’s actually quite easy to understand.
In this article, I will use an instrument whose author I do not know, and I would be super grateful if someone could clarify this. Sometime 20 years ago, an IBM employee or something taught me that, and I still find it impressive.
The instrument works like this: In the graphic, a project object is drawn as a square with 4 dimensions, quality, quantity, money and time. And in the middle is the productivity of the team, P. If I want to change something, for example receive the delivery item in less time, then I have to distribute the area of P differently, because the area of P always remains the same. So I can push P down on the axis of time (hence the minus for less) and then I have to choose how much of the other parameters of quality, quantity and money I want to modify so that the area of P can remain the same. For example, I can say, ok, then I’ll go down in quantity (direction -), or down in quantity and up in money, whatever. But I just have to change something somewhere to be able to change the change of a parameter. This can be seen quite well in the second picture.
Because here it was done exactly: less time, but also less quantity. Perfectly logical, right?
But it is the case that some think they can increase P by exerting pressure. That’s sometimes the case. P can be temporarily enlarged. And if we’re honest, if you don’t accept that, then you’re wrong in this industry. It’s part of it. Because you know, for example, that a lot depends on a launch date. Because you have invested a lot of heart and soul yourself and want to get your baby up and running. So it doesn’t always have to come from outside, the pressure. Because if a developer sees the need, then he or she will always do everything to make it work. It’s a kind of code of honor. I can’t live with it if I didn’t deliver properly, even though I promised. And I don’t care about the night shifts either.
However, P cannot be enlarged forever. At some point, the oven is off. You can’t take it anymore. Or you no longer see why there is always such poor planning. Or, even worse, you don’t see why P has to be enlarged at all if reasons are given that don’t really make sense or are even exaggerated at the end of the day. During my time in the dot-com, I overheard by chance that a product manager said that the pressure on my team must always remain high. It wasn’t meant for my ears. But she hadn’t seen why it wasn’t healthy either. At some point, people leave. And then usually the better ones leave. Those who are not good and are not willing to go the extra mile, who stay. And those who are willing to invest because they damn much enjoy their job, they leave. Because they don’t see it. So constant pressure does not help, quite the opposite. In the short term, perhaps, but you pay umpteen times over because the best leave. And then P is even smaller. And it takes a long time for a new colleague to be trained in such a way that P is back to the old level.
Worse still, you also make yourself untrustworthy as a pressure giver. Especially when it is said: “We have to stick together as a team.” It’s like, “Man, yes, you’re carrying me on your shoulders, but we have to stick together, so go on again.” Sometimes these people don’t mean it that way. They have deadlines themselves and they pass on the pressure. OK. But if a team already has a lot to do and then someone else comes, then you shouldn’t be surprised that P doesn’t go bigger if it has already been voluntarily (!) enlarged by the team anyway. And then at some point this will no longer be done.
In addition, every escalation only costs more time. Every email, when something is finished, every meeting, nothing leads to the day having more hours. On the contrary. You simply steal time from the people who have to do the work that they actually need to do their jobs. Every “But I absolutely need it today” does not mean that the day would have more time or that other deadlines can be abandoned. This should actually be clear to the pressure giver. But that’s how it’s played. With the opposite effect.
How can this be solved? For example, I always like to draw this square. And explain that P can only be temporarily enlarged if I can credibly prove why. Some developers increase P intrinsically. But not forever either. And I will always stand in front of my team if P can no longer be increased sensibly and the pressure giver also plays unfairly. Experience also shows that the further the pressure provider is from what the developers are doing in terms of understanding, the greater the unnecessary pressure. 20 years of experience. Despite all the new methods, processes… nothing has been able to change the validity of this square. Take it or leave it.