Do what it takes

I've been going over a clash that I had this morning for the last couple of hours. It wasn't a screaming and yelling kind of thing. It was much more subtle than that. It was the collision of two very different orientations towards learning in a corporate environment.

I stand for doing what needs to be done to make the project a success. I favor a proactive stance, picking a simple system that we can understand in minute detail and build further capabilities onto that knowledge. The first thing we make may not be a product that other parts of the organization feels is ready for the market, but this is our project. We should pick a system that we feel we can manage. We're not driving the project if we let somebody else tell us what we should do. The stakes are high. Why should we leave the success of our venture in the hands of another entity?

My standoff was against a colleague who seeks the path favored by our managers. His sole intention is to do what they think should be done in the manner that they feel it should be done. The answer to every question requires looking at the problem from the perspective of whoever has responsibility for this project at a more senior level. Any proposal must pass the muster of the manager's expectations. Possible objections are the end of the discussion. Nothing risky is allowed. Stick with what's safe and expected. Deviations are the quickest route to failure.

Every point that I raised today was refuted with some variation on the theme of "because the manager's said so." What if they're wrong? That was my point. Why should we go off and do something just because they said to do it that way? If we recognize a significant problem in the approach, isn't it our responsibility to raise those concerns? We're the ones in the thick of the problems. We're going to see trouble long before the managers will. They're relying on us to deliver a totally new capability. Part of delivering that capability is ensuring that we can perform every step of the process.