Don't Get Railroaded
In any project, there are bound to be different opinions, as each of us brings different perspectives and experiences to the table. Many of these different opinions can easily be resolved through exploration, but some will flare into conflict. While some are warranted, based on different technical perspectives that need to be reconciled, others will be based on issues that fall outside the technical domain. When that is the case, we need to be careful to ensure that we don’t make a rash decision.
Way back, oh, about 17 years ago now, I was working on an air traffic control system project. A huge project, with perhaps 250 engineers at it’s peak. Because of its size and complexity, we literally scoured the earth for the talent we needed to pull it off. We had a few people that were involved in creating the Ada language we used for development, we probably had people from every continent but Antarctica on the team. I’m sure some of you reading this were involved with that project.
Unfortunately, along with that talent, came many egos of the same magnitudes.
Once we got started on the implementation, we quickly fell into a death march, where expectations for delivery in our 6-month iterations far exceeded our capacity to deliver in a 40 hour week (with one exception, perhaps another column). We were regularly running 10, 12, 14 hour days, often 6 or 7 days a week. At one point I was working 12 hour shifts, and was on pager the rest of the time. Not a great deal of fun. Looking back, extremely counterproductive.
With all this pressure to deliver, you can imagine that there was plenty of pressure to agree to impossible expectations. This is where the story today focuses.
There was one person (let’s call him Bob) on the project that was not willing to play that game. When asked to develop some functionality, he would sit down, analyze what was required, and come back with an estimate of effort required. Most importantly, he delivered on that estimate, with a clean implementation that rarely came back to haunt him with bugs.
That estimate, though, rarely satisfied the powers that be. Much of the team had fallen into the trap of negotiated-down estimates, often to the point where ridiculous promises were made that could not possibly be met. Those promises did fit the crazy constraints we were given, though, which allowed those powers that be to pretend that they had a schedule in place that met their constraints. Never mind that it fell apart as soon as the first progress reports rolled in.
Bob’s behaviour wasn’t popular with the powers that be, and being greater in number and influence, they decided the easiest solution to their apparent problem was to jettison Bob from the project. The writing was on the wall, but I didn’t like what I saw. It was clear to me that the majority of opinion was not the right way to go.
I did a bit of an end run around these technical leaders that wanted Bob off the project, and went over their heads to plead Bob’s case. It took quite an effort to convince people that Bob was indeed a valuable asset, that solid code that solved a problem was preferred over constrained implementations that contributed to technical debt on the project (this project was amazing for introducing concepts that would only get names years later). We didn’t manage to create a wholesale change about planning approaches, but we did manage to keep Bob on the job.
Fast-forward to today. I’m involved in a similar situation where a smaller team has become polarized, where there is a clear majority view against a single person, and that view, in my opinion, is unwarranted. I guess I haven’t softened that much with age, because I still won’t stand for it.
In both cases, the position of the majority is unwarranted primarily because they fail to appreciate the merits of the opposing view, and fail to recognize the flaws in their own logic. There are at least two sides to any story.
In the recent case, there was the suggestion that this person in the minority should be removed from the project, backed by the argument that in the industry, that is how it would have been handled.
Unfortunately, it is true that in the industry, this person would have been jettisoned long ago. It is also true that in the tech world, the average project overruns by 120%, the average team spends about 40% or more of their time cleaning up their messes, we are all resigned to poor software quality, there are specific amendments to the labour laws in this province that support death-march environments, and stress, conflict and turnover is far higher than it needs to be. I would suggest that voting someone off the tech island is just as dysfunctional.
Be careful to avoid being railroaded by a majority decision: hold yourself to a higher standard than what is currently the norm in the industry. – JB