Pragmatism — It’s A Survival Trait

You’ve probably seen some variant of this diagram, right? It’s really quite an interesting blend of cynicism and pragmatism. What you have is

1. 1. Where Marketing Meets Engineering: The nice folks in Marketing have looked at everything that the Market asks for — or they have seeded the Market with . They then match that up against the universe of everything that Engineering could ever deliver (“Rollerblades. With energy harvesting brakes that charge your phone”)
2. 2. Where Revenue Requirements Meet Marketing: So yeah, the company actually has to make money, right? Which means it actually needs to sell stuff. So the happy folks in sales look at their sales targets, and match that up against what the Market is asking for (“Rollerblades with propellers! That can fly! People would actually pay $100K for them! And if I sell 10 of them a year I make Quota Club!”)
3. 3. Where Engineering Meets Revenue Requirements: And finally, the engineering team should really only be working on stuff that can actually make the company money, right? (•) (“What we want to do is go scuba-diving, but yeah, we’ll work on actually developing rollerblades.”)
4. 
   

In the ideal world, the only stuff that Engineering works on is the nice little intersection-set in the middle, so helpfully colored red.

The belief that we can uniquely identify Market Demands, Revenue Requirements, and Technically Feasible is a nice exercise in vanity, something that doesn’t really hold up in the real world. The truth is that each of those are, at best, MovingTargets™, and at worst, Guesswork™.

Take Technical Feasibility for example. Oh, there may be some world in which the entire team works only on the problem at hand and everything works perfectly right off the bat — but this is not that world.
The reality is that, with the very best of intentions

1. 1. There will be ambiguity in the requirements (“Wireless charging? Or wired?”)
2. 2. Wrong paths will be taken (“Shit, our wheel-bearing supplier went out of business, we need to refactor to work with the new wheels”)
3. 3. Compromises will be made (“The entire Design team got the flu? And are out for two weeks? Move Alice and Bob over from the API team, at least they can use Photoshop”)
4. 
   

And that’s with the best of intentions. In actuality
 • you’ll also be working on other problems at the same time,
 • things will most definitely not work right off the bat, and 
 • #CowboyDevelopers will go off on some bizarre tangent of their own
and lords knows what else!

In short, instead of working on only the nice little red section, you end up working across the entire spectrum of stuff that is Technically Feasible. Hopefully, most of your stuff is shaded towards work that is relevant, but then again, it depends entirely on your organization.

To be very clear, this isn’t only about Engineering. The exact same thing is happening with Sales (“Are you sure we don’t want to sell helmets instead? With propellers?”), Finance (“We need to be compliant with the new GAAP Revenue Recognition standards, so no annual contracts. No, it doesn’t matter that we don’t need to be compliant for another 4 years”), Marketing, and pretty much everybody else.
That’s just the reality of organizations — the larger the company, the more likely it is that there is random stuff being done. You try to minimize it of course, but it’s just a fact of life…

Which brings us back to the title of this piece - the importance of Pragmatism, and the necessity of taking all the little inefficiencies that you see around you in stride. Yes, it could be better, but you are better off focusing your energies on the big picture and making sure that Stuff Is Happening. Otherwise, and this is a certainty, you will end up spending most of your time raging at the trees, and not noticing the forest that you are in.

(•) Yeah, yeah. “Working on OSS”, “Keeping the community happy”, etc. If you correct for nuance, this also makes the company money in the long run, in the form of Customer Support, Marketing, Brand Recognition, etc.