It's Too Easy - Part II - I Have Nothing But I Want the Ferrari!

 

Rome wasn't built in a day, but these Roman soldier pixel characters were.

When starting a new project - usually one that addresses existing quality or operational issues - a lot of conversations seem to take the following form:

Person A: We need to move our quality from tricycle level to Ferrari level.  We're MajorCo, and we can't afford to have second-rate quality in our systems.

Person B: Agreed.  What's your plan for getting there?

Person A: Well, first we need to create schematics for all of the parts in the Ferrari and ensure that all of our people are trained to manufacture and assemble the parts.

Person B: That's ambitious.  I agree that we need to get there eventually, but maybe we should start with something simpler.  Let's train all of our people to ride bicycles instead.  There are some very nice bike models with good performance, and will help us on the next step toward Ferrari-level quality.

Person A: No.  A bicycle is too simplistic.  It doesn't have the anti-lock, enhanced tread, middle-aged-crisis-augmenting system we've planned.

Person B: But we don't have that now!  Literally any improvement is an improvement over the tricycle that we're currently using.  And, if we move incrementally, we can take advantage of momentum as people see the overall improvement across time.

Person A: But I want the Ferrari!  We'll continue holding design meetings until we've come up with a plan to enumerate all of the details for reaching our goal.

Ok, I'll be honest.  I've never had that exact conversation, but I've had several Ferrari-adjacent ones.

I'm not entirely certain why people buck incremental change for a dream that's not - at the very least - immediately attainable, but I have a few guesses.

First, once people have formed a grand idea, it's hard to dial back and compromise.  It's why we all start out wanting to be rock gods, buy hundreds or thousands of dollars' worth of guitar gear to fit that ideal, practice for two weeks, and give up when we haven't mastered fret tapping after day 14 (also, fret tapping is overrated).

Second, there's probably a latent expectation that if we don't shoot for the stars, we'll simply settle for the first solution we design and implement.  This argument has merit, especially in a setting like MajorCo, where the Product Roadmap changes more often than a toddler with an upset stomach.  But that leads to another, related question.  Namely, is the final goal actually worthwhile if we're at risk of abandoning it during the next quarterly review in lieu of something shinier?  If so, then it's important to be disciplined and view incremental change as tangible milestones in service of the ultimate goal.  If not, then why are we doing any of this in the first place?

Finally, these goals are often set by leadership with a lot of bluster promoting them, but no details to support that bluster.  People often - understandably - demur from challenging leadership's strategy, because (a) they must know something more than we do and (b) they're the boss.  (b) is invariable and you can't simply accept a premise because someone in authority issues it.  At some point, if you're going to live a purposeful life, you'll need to stand up to authority.  But, this is much easier to accept if you don't accept that (a) is always true.

In a healthy organization, you should be able to ask your leadership why we're doing this and why we're doing it in this manner and receive a coherent response.  If it's not coherent, you should be able to challenge it and work to come up with something more realistic.  In an unhealthy organization, don't even bother.  Just bide your time until you can find your way out.  Or herd cats.  It'll be more rewarding.

Outside of incremental progress and the ensuing confidence-building that accompanies each successful milestone achievement, following a step-wise path also gives you the gift of reflection.  At the completion of each step, you have the chance to view your progress toward the Ferrari.  If you need to make adjustments, it's much less painful to make minor adjustments along the way than it is to dive into the deep end and inadvertently build a Porsche (which happens more often than you think).

Even more magically, you may be on step 3 or your 12-step program to build a Ferrari and realize that, what you may not need is a Ferrari, but something that simply goes very fast.  This realization, built from the lessons learned while implementing actual improvements, can help you short-circuit your path, and, often meet your original goals without a lot of the complexity that accompanies micromanaged design. 

With that, I hope that I've convinced you that building a Ferrari isn't always necessary (while also imparting the value of using a truly terrible metaphor in your writing).  Next, we'll tackle the complexity of true simplicity.

Until next time, my human and robot friends. 

Comments

  1. https://www.laws-of-software.com/laws/gall/

    A complex system that works has evolved from a simple system that worked. A complex system built from scratch won’t work.

    -- John Gall, 1975

    ReplyDelete
  2. I like that. It says in about 20 words what it currently takes me about 1500 to express. I won't comment further on the irony of that difference in a post on needless complexity.

    ReplyDelete

Post a Comment

Popular Posts