Being right isn’t enough. Learn from one manager’s firing and how to navigate impossible software project deadlines. #ProjectManagement #SoftwareDevelopment #LeadershipLessons
Explanation in video
Oops! I Got Fired: A Tech Manager’s Tale of Being Right, But Still Wrong
Hey everyone, John here! Ever been in a spot where you were absolutely sure you were right about something, but things still went completely sideways? It’s a frustrating feeling, isn’t it? Well, today we’re diving into a fascinating story from the tech world, but don’t worry, this isn’t about complicated code or super-advanced AI. It’s about people, decisions, and some really valuable lessons learned when managing big software projects.
This is a personal story from a manager who learned things the hard way. Grab a cup of tea, and let’s see what we can all learn from his experience!
Meet the Team and the Beast of a Product
Imagine this: our storyteller was a manager leading a really talented team of software developers. These folks were top-notch, working at a company in Silicon Valley that had seen better days but still had a strong product. This product was a tool that other developers used to build their own software. Think of it as a super-fancy workshop for programmers.
Now, this software product was what we call monolithic.
Lila: “Hold on, John! ‘Monolithic’? That sounds like something out of a history book about big stones!”
John: “Haha, good one, Lila! You’re not far off. In the tech world, a ‘monolithic’ product is like a giant, intricate LEGO castle built as one single piece. It’s huge, and all its parts are tightly connected. If you want to change one small tower or add a new window, you often have to adjust many other parts of the castle because everything is linked. This company’s software was like that – one big installation that was built and released all at once, usually just once a year. It had many complex bits, like its own special language translator (a compiler), a library of tools, and a design studio (an IDE).”
A big part of keeping this product alive and kicking was making it work on new computer systems. This is called a platform shift.
Lila: “Platform shift? What’s that, John? Is it like moving a stage?”
John: “That’s a neat way to think about it, Lila! A ‘platform shift’ is a bit like taking a popular video game that was designed to work only on a PlayStation and then doing all the hard work to make it run perfectly on an Xbox or a Nintendo Switch too. Each system – or ‘platform’ – has its own rules and ways of doing things, so it’s a really big job to adapt the software. They’d done this a few times, moving from older Windows versions to newer ones, and even tried to make it work on Linux. It was tough work!”
New Owners, New Misunderstandings
So, things were chugging along, and then the company got bought by a smaller company that made tools for databases. With new owners come new senior bosses. Everyone tried their best to get along and work together with the new leadership.
Here’s where a little crack started to appear. While on the surface, tools for databases and the super-complex developer tool our storyteller’s team worked on might seem similar (they both help people work with code, right?), there was a big difference. The storyteller’s product was like a deep, intricate machine with many interconnected, complex parts. The new parent company’s products were, comparatively, simpler.
John: “Think of it like this: imagine expert chefs who specialize in creating those enormous, multi-tiered wedding cakes with incredibly detailed decorations. Now, imagine they start being managed by someone who has only ever run a successful cupcake shop. Cupcakes are delicious and require skill, no doubt! But a massive wedding cake is on a whole different level of complexity, time, and engineering. The new leaders didn’t quite seem to grasp this difference in scale for our storyteller’s product.”
This difference in understanding became a major problem when a big decision was made: the new bosses wanted to take the complex developer tool and make it work on two new platforms at the same time – Linux and Mac OS.
The Impossible Deadline
The experienced development team, including our storyteller (the manager), looked at this massive task. They knew their product inside and out. They estimated it would take about 18 months for each new platform, so three years in total, given their current team size. They even suggested ways to speed it up, like hiring more people carefully to avoid something called Brooks’s Law.
Lila: “Brooks’s Law? That sounds like a rule from a sci-fi movie, John!”
John: “Haha, not quite sci-fi, Lila, but it’s a very famous and important idea in the world of software development! Brooks’s Law basically says that if a software project is already running late, adding more people to it can actually make it even later. Think of it like this: if you have a few chefs in a kitchen trying to cook a complicated meal and they’re already behind schedule, just throwing more chefs into the kitchen might create more confusion, people bumping into each other, and more time spent trying to coordinate, rather than actually speeding up the cooking. It’s all about the extra communication and organization needed when you add more people to a complex task that’s already in trouble.”
So, the team gave their honest, experienced estimate. And what did upper management say? They were shocked! They thought three years was way too long. They seemed to think the team was sandbagging.
Lila: “‘Sandbagging’? What does that mean in this situation, John?”
John: “Good question, Lila! ‘Sandbagging’ here means the bosses suspected the team was deliberately exaggerating how long the job would take or how difficult it was. Maybe they thought the team was being lazy, didn’t want to do the work, or wanted to make themselves look extra good if they somehow finished ‘early’ – even if the team’s original estimate was the honest and realistic one.”
So, instead of the three years the team estimated, the new leadership set a deadline: six months to get the product working on both new platforms. Six months! For a job the experts said would take 36 months.
When “Trying” Just Isn’t Enough
Our storyteller, the manager, was understandably upset. Six months was not just challenging; he felt it was completely impossible. Even a rushed, poorly done version for one platform couldn’t be made in that time, let alone two. He felt his team was being set up for failure, asked to work crazy hours on a task doomed from the start – something often called a death march in project management.
Lila: “A ‘death march’? Oh my, that sounds really awful, John!”
John: “It is a pretty grim term, Lila, and for good reason! In the project world, a ‘death march’ refers to a project where the team is forced to work under extreme pressure, with impossibly tight deadlines, often knowing that the project is likely to fail anyway. It usually means long, stressful hours, low morale, and a feeling of hopelessness – like being forced to march endlessly towards a goal that everyone knows is unreachable. It’s a very tough spot for any team to be in.”
The manager also felt that there was an unspoken accusation that his team was being dishonest or rebellious. He believed his main job was to protect his team, a lesson he’d learned in the Navy. So, he pushed back hard. He tried to explain why the deadline was unreasonable.
His own boss, who also came from the original company and knew the product’s complexity, understood the request was crazy. But he told our storyteller that, while it was a challenge, they just needed to “try.”
This “just try” attitude was the beginning of the end for our storyteller. He knew it was impossible. How do you ask your team to pour their hearts and souls into something you, and they, know will fail spectacularly?
What He Did vs. What He Should Have Done
Here’s where our storyteller admits he made a big mistake. In his effort to defend his team and stand up for what he believed was right, he didn’t even pretend to be on board with management’s plan. He didn’t try to be a “team player” from the perspective of the higher-ups.
- He told his developers that he thought the plan was “nuts” and they shouldn’t even really try.
- He kept telling upper management that the plan was ridiculous and impossible.
So, what happened? He got fired.
Looking back, he realized that while he was right about the project timeline being impossible, he was wrong in how he handled the situation. He pressed the issue so hard that it cost him his job.
What should he have done? He reflects that this is the hard part. He should have tried to find a middle path. He needed to find a way to:
- Support management, even though their plan was flawed.
- Support his team, even though they were being put in an impossible position.
This would have been incredibly challenging, but he admits he should have at least tried to navigate that tricky balance.
The Real Lesson: It’s Not Just About Being Right
This whole experience taught him a crucial lesson: Being right isn’t enough—being effective matters more.
Managing people and projects, especially in tech, is like handling a double-edged sword. It’s tough, sometimes seemingly impossible.
Here are some key takeaways he shared:
- Sometimes, you have to let go of being “right” and think about what’s best for the whole company, not just your own feelings or even your team in isolation.
- It’s a delicate dance: you need to protect your team, but you also need to be a loyal member of the overall management team.
- You have to manage up (meaning, communicate effectively with and influence your bosses) just as well as you manage down (lead and support your own team).
It’s a powerful reminder that leadership is complex and requires a lot of skill beyond just technical knowledge.
Our Thoughts on This Story
John: This story really resonates with me. It highlights such a common but incredibly difficult part of being a manager. It’s a tough balancing act, trying to be loyal to your team and loyal to the company, especially when those loyalties seem to clash. What stands out to me is how crucial communication and approach are. Sometimes, how you deliver a message, especially a difficult one, is just as important, if not more so, than the message itself.
Lila: Wow, John, that’s a lot to take in! It makes me see managers in a new light. It’s not just about telling people what tasks to do. It’s so much about understanding people, understanding the bigger picture, and trying to find the best way forward for everyone, even when the path is super rocky and unclear. It sounds like a real test of character and skill!
This manager’s honest reflection is a great learning opportunity for anyone, whether you’re in tech, aspiring to be a manager, or just interested in how big projects (and sometimes big disagreements!) happen in the working world. It shows that even when you have the best intentions and the facts on your side, the way you navigate the human side of things can make all the difference.
This article is based on the following original source, summarized from the author’s perspective:
Managing software projects is a double-edged sword