"Too Hot, Too Cold" Organizations
Guess what? Either way, you die.
In some periods of a year, there's no sense of urgency. Software developers tend to build more than what's necessary as an attempt to release "the best" code possible. It turns out "the best" is an over-engineered pile of… well. It would be easy to dismiss everything if it didn't work, but it does — at least most of the time.
In other periods of the year, there's a maximum sense of urgency. Deadlines start coming from nowhere. Managers start to put pressure on themselves and their teams. Developers create fancy shortcuts that even Leonardo da Vinci would be impressed with their creativity.
At any point in time, it's "too cold" or "too hot". Guess what? Either way, you die. Either through burnout or freezing boringness.
Does this sound familiar to you? Maybe you have been in a situation like this before. It's the reality of business.
When you get your Series A, everybody is happy. You relax and do "the best" job you can as if money is infinite. It turns out that money is not infinite, and "the best" turns out to be not that good. At some point, the heat comes down and reality kicks in so you have to get shit done.
When you work within a government deadline for an unfamiliar project far in the future, everybody is happy. You relax and do "the best" research for the compliance requirements you can as if you have more than enough time. It turns out this is software, and Parkinson's Law documents very clearly: "more than enough time" doesn't exist. You'll never have any idea for how long something is going to take when developing software unless you and every member of your team have done the same thing in the past.
Bad fund management and not setting deadline expectations are some of the many reasons for the "Too Hot, Too Cold" effect.
My preference is to work on an environment that is not too hot, neither too cold. There, I can make reasonable progress and have a sense of urgency that allows me and everybody else to work at a reasonable pace with a clear set of constraints without negatively affecting group psychology.
In the case of the "Series A" example, the company can split the funds by several months or weeks instead of pretending they have enough money for their goals. The principles of Incremental Delivery allows the teams to have 100% deliverables at any point in time. Even if you don't achieve the big goal at the end, you should have the ability to pivot in various directions throughout the journey.
The ability to always have something working can counteract the feeling of "too cold" by having goals set every day and every week. It also counteracts the feeling of "too hot" by always delivering something in which the company can get feedback and change directions quickly before the money starts running out.
In the case of the "government deadline" example, the company can first tackle the requirements required by law so that they don't risk a fine. It's not like "raising expectations" works very well to some governments. Later, after the company completes the compliance requirements, they can use the remaining time— if any — to tackle the requirements of the user experience, which may be easier to enhance over time and deliver incrementally.
That counteracts the feeling of "too cold". You prioritize the objective law requirements first and also work towards the essential user experience, which can have a significant impact on the revenue, with a lot of effort to find the balance with the time available. It also counteracts the feeling of "too hot" by tackling the most pressure-sensitive requirements first, then the least pressure-sensitive requirements later.
Either way, "too hot" or "too cold" affects performance.
If it's too hot , people dump on improvement ideas and tech talks or katas/dojos because they feel they don't "have the time", even if they believe the improvement is worth it. They also tend to avoid working together and increase their Work In Progress. Instead, they use meetings to "talk" together instead of "working" together, where the quality of the information interchange is not as efficient as working on the same thing, at the same time, in the same space (or in the same video call). They also don't want to try new things or reflect on what they did, they stay within the status quo and fall prey of the natural entropy that emerges if nobody actively fights against it.
If it's too cold , people forget about this mantra: make it work, then make it better. It creates incentives for developers to look at opportunities to try a different technology for their shiny attributes or bikeshed on pointless coding style discussions, unaware of the potential implications and costs to the project. If it's a new team, it's reasonable to expect performance to go down. However, a "too cold" environment doesn't have enough incentives for performance to go up.
If it's too hot, people make silly mistakes and ignore stuff that can make them more productive; if it's too cold, people over-engineer and focuses on unnecessary stuff that's going to consume most of their time.
Either if you have too much money, deadlines, or neither, working in an environment that is "too hot" or "too cold" is inefficient. In fact, everything taken to an extreme tends to become inefficient.
You need to point out the extremes.
You need to invest some effort and find the balance.
After all, if balance is not there, you'll end up either in a burning Hell or a frozen Niflheim.
Thanks for reading. If you have some feedback, reach out to me on Twitter, Facebook, or Github.
Top comments (0)