People within an organization can each have their own views and thoughts of what that organization should be doing. In a functional organization, those people all come around the proverbial table, discuss those views, and then come to consensus on what the organization actually should be doing. Then they should go do that thing. In a less functional organization, that doesn’t happen, so everybody instead decides to go do their own thing. When it’s the leadership of the organization that does their own thing, people on the ground floor see this, get confused by it, and wonder what the right thing for them to do actually is.

A large part of what I deal with is the inherent contradictions from people above me not really talking to each other, or talking about some things but not others. People below me need to know what to do. Everybody needs to know what we are going to be doing. Yet, everyone wants to know what are we doing towards the thing they think we should do, rather than the single, shared vision of what to do that doesn’t actually exist.

This means you can’t just plainly blurt out the truth, which is that we’re going to vacuum up every spare bit of loose change we can find between the couch cushions and hope it adds up to multiple-millions of dollars. That makes us sound reactive rather than proactive (which we are), and like we don’t really have a clue what we’re doing (who is “we” kee-mo sah-bee?).

Instead, we have to say we have a plan. Because it’s a publicly traded company, we have to say it’s a plan for the year. We have to say that even though it’s a software company that uses Agile methods, which rejects the idea of planning on that time horizon in favor of planning for short iterations. We’re still expected to commit to the plan, even though everyone knows that anything I say is going to happen in Q4 is a mirage at best because everyone knows nobody can know what will really happen that far out.

In software, in a company that makes software products, this plan often takes the form of a “product roadmap”, which is theoretically going to show us where we are going along the road to the future. Except you’re not really going to do all of the things on the roadmap when you say you will. Even if you plan or guess correctly what you should do, someone or something else will ruin it for you. You’d better have releases at minimum of once a quarter, or else they’ll cut your budget to nothing. Except, you can’t actually get any work done on the product, because they’ll cut your budget to nothing anyway even if you make 2 releases a month.

Oh, and those are “product” releases – nobody cares that you actually ship working software to customers dozens of times a month, even though that is the primary source of revenue for the business. PRODUCT companies don’t create products for customers, they create products for markets. Got that? Which means instead of doing what actually keeps the lights on, you should actually build a bridge to a new market. Which market? Nobody actually knows, but they know your roadmap has a big, beautiful bridge on it, that spans the river that’s between the market you’re in now, and that fabled market you want to get to. Everyone knows the bridge needs to run in The Cloud™.

Nobody wants to admit its a bridge to nowhere.