When Optimism Becomes a Career Risk
What the "glass walls" of a metro station can teach us about software delivery and accountability.
Many people know the story of the famous Sydney Opera House. The project overran the budget by a factor of 13 and took 14 years instead of 4. It is one of the most famous projects that went wrong.
I want to tell you a much less known but even more incredible story that unfolded in front of my eyes.
I live in Finland, in the town of Espoo, next to the capital Helsinki. Helsinki has had a single metro line since 1982, running from the east to the west of the city through the center. In the early 2000s it was decided to extend the line westward into Espoo. The project was called “Western Metro.” The first stage included 8 new stations.
I used to live a few hundred meters from one of the new stations called Sports Park. I watched it being constructed in real time. First there was a fence, then in 2016 the fence was removed, the launch was already a couple of years behind the initial schedule, work on the interior and exterior continued in full view.
The grand opening was set for August 2016. This had been a big undertaking — there was a lot of advertisement and buzz in the media. The capital region’s public transport operator scheduled the cancellation of bus routes connecting Espoo and Helsinki, as these would be covered by the new metro extension.
I was puzzled. During summer I walked by the station and could see that it was nowhere near ready. Neither the interior nor the exterior was completed, heavy machinery still surrounded the station, and I could see through the glass wall that equipment inside had not yet been installed. I kept wondering how they were going to open it.
The scandal was huge — the celebration was cancelled last minute and buses routes restored shortly after.
It took another year before the line officially opened.
After the fact there were plenty of excuses for the delay, but what amazes me is how the entire public transport company and two municipalities — Espoo and Helsinki — could not see that the project would not be ready, and happily continued to roll out the initial plan until almost the last day.
My guess is that someone was too optimistic, believing they could pull it off. Until it was too late. Then no one had the guts to say that it was not going to happen and that they needed to scrap the plan.
This Happens in Software Too
The same happens in software projects all the time. People overpromise, hope for the best, and then as time goes on get deeper and deeper into the swamp of their optimistic projections.
Another real story.
A CTO told the rest of the leadership team and the board that a mission-critical project, that had already been a bit late, would be finished in the next quarter. In the end it took five.
The CTO was let go before the project ended.
We can do better and avoid putting the business and our careers in the harm’s way.
If You’re Delivering
If we are in the position of the person responsible for delivery, we need to communicate any possible schedule change as soon as the projection changes. It might not be a pleasant piece of news to deliver, but it is the best thing we can do. Postponing it will only make things worse — much worse. On the other hand, openness about problems early on builds trust. Stakeholders will appreciate the early heads-up so that they can make adjustments on their side.
If You’re the Stakeholder
If we are in the position of the stakeholder expecting a timebound delivery, we need to set clear expectations. The delivery schedule might slip — sometimes nothing can be done about it — but it is crucial to have this information as soon as possible. The bringer of bad news should not be punished under any circumstances. Quite the opposite — provide your support and guidance on how to improve the situation and get the project back on track together, if possible.
Do This on Monday
If you have a timebound delivery on your hands — ensure that you are on track. Be pessimistic — consider that things won’t go according to plan. If you see a risk or your project is already off track, talk to your stakeholder, explain the situation, and tell them what your plan is to handle it.
If you are a stakeholder — ensure that the team working on your project understands that you would rather hear the truth early than have a nasty surprise in the end. If you see that the team continuously holds back on bad news, explain that you expect accountability and transparency going forward. It is important to distinguish between missing the original estimates and misleading the stakeholder. The former is fine, the latter is not.
About the Author
I’m an engineer at heart who spent 20 years building software before taking on the challenge of scaling a startup’s engineering department and stepping into a top leadership role. I learned management the hard way—in the trenches—so you don’t have to. Today, I provide the guidance I wish I had when I was first building and leading teams.
Need Engineering Advisory or 1:1 Leadership Coaching to stress-test your strategy and scale your tech org?
👉 DM me here on Substack or just reply to this email. Tell me a bit about the challenge you’re facing, and we’ll see if I can help.
Have a nice week,
Roman