In 2010, I got fired. I deserved it. I wasn’t wrong, but I deserved it. And I think there is an interesting lesson in that dichotomy.
I was managing a team of developers at a once-great Silicon Valley firm that had fallen from its peak. The development team was very good—elite, even. Our product was a once-popular but fading software development tool. Our management team—we called it “the Core Team”—was a great bunch. I enjoyed the job.
The product was monolithic—a single, large install that had to be built and deployed all at once. We shipped about once a year, and all development was geared around building new features and fixing bugs that would all culminate in that big, annual release. Being a development tool, it had many complex components, including a compiler, a run-time library, a visual framework, and an IDE. Getting everything pulled together and built was no mean feat.
A big part of keeping the product viable in the marketplace was doing platform shifts. The first one was going from the Win16 platform to the Win32 platform. The product made an ill-fated foray into Linux, as well as smaller shifts to newer Windows versions and Win64. The product was large and complex, and these platform shifts were not easily done.
The development and QA teams were very experienced and they knew what they were doing. They knew well what it took to ship a new version of the product, and they knew the extra effort it took to do a platform shift.
Seeds of misunderstanding
One of the ways that the company had been humbled was that a smaller database tools company had bought it and brought in a new team of senior leadership. The process went pretty normally, with our middle management team cautiously optimistic as we adjusted to a new set of executives. We did our best to integrate and be integrated into the new order of things.
While SQL/database development tools and more general software development tools have much in common, and seem very similar on the surface, our product was a level deeper and more complex than our new parent company’s product. This incongruity proved to be challenging to integrate. While a SQL IDE and a programming language IDE seem the same on the surface, our product’s underlying frameworks, libraries, and compilers were orders of magnitude more complex than a SQL parser and editor.
This difference was a challenge for the new leadership to understand. So, when the decision was made to take our tool cross-platform to both Linux and Mac OS at the same time, the new executive team appeared not to understand the challenges and difficulties of doing these platform shifts.
We on the Core Team looked at what it would take to provide support for those two platforms, and arrived at a general estimate of 18 months for each, given the current staffing levels. We recommended plans that could shorten that cycle by front-loading the projects and hiring more staff, doing our best to avoid Brooks’s law in the process (“Adding manpower to a late software project makes it later”).
And here’s where things started getting a bit dicey. Upper management was shocked at the notion that it would take three years to migrate to the two new platforms. They seemed to take the attitude that the team was “sandbagging” and “was exaggerating because they didn’t want to do it.” So they set a deadline of six months to do both platforms.
Temperatures rising
Doing two platform shifts in six months was beyond challenging—it was absurd. We couldn’t have hacked together a half-baked version for even one platform in that time. It was flat-out impossible.
Let’s just say I was quite unhappy with this request. It was completely unreasonable. My team of developers was being asked to work evenings and weekends on a task that was guaranteed to fail. The subtle implication that we were being rebellious and dishonest was difficult to swallow.
So I set about making my position clear. I tried to stay level-headed, but I’m sure that my irritation showed through. I fought hard to protect my team from a pointless death march—my time in the Navy had taught me that taking care of the team was my top job.
My protestations were met with little sympathy. My boss, who like me came from the software development tool company, certainly knew that the request was unreasonable, but he told me that while it was a challenge, we just needed to “try.”
This, of course, was the seed of my demise. I knew it was an impossible task, and that “trying” would fail. How do you ask your team to embark on a task that you know will fail miserably and that they know will fail miserably? Well, I answered that question very poorly.
What I did and what I should have done
What I did was exactly wrong. In the name of defending my team and sticking up for my people, I failed to at least pretend like I was on board with the project. I didn’t even remotely try to be a team player. I told the developers that I thought the plan was nuts and that they shouldn’t even try. I kept telling upper management that that plan was ridiculous and that the team could never do it.
What should I have done? This is the hard part. What I should have done was to make the best of a very difficult situation. I should have found a middle path. I should have found a way that supported management even though the plan was not doable and that supported my team even though they were being put in an impossible position. Would that have been challenging? Yes. Should I have at least tried? Again, yes.
In the end, my immature approach got me fired. Was I right that the project wouldn’t be completed in the ridiculous timeline? Sure. Was I right to press the issue so hard that I lost my job? No, I was not.
The lesson? Sometimes being a manager is hard—even impossible. Sometimes you have to give up being right and put the needs of the entire organization over yourself. Sometimes you have to balance protecting your people with being a loyal member of the management team. Sometimes you have to manage up as well as you manage down.
Being right isn’t enough—being effective matters more. I learned that the hard way.
