The Tractor vs Cadillac Delivery Trap

If you’re a developer, you’ve heard about the argument of delivering the Tractor vs the Cadillac.

If not, here it is in condensed form.

Tractor – rock solid, gets you from A to B with little fanfare, doesn’t look great, does the job, never falls over, stable as a rock.

Cadillac – it looks really pretty, it’ll give you the smoothest ride from A to B (when it works), it has all the bells and whistles (but doesn’t always work).

So the question becomes when debating the delivery of a new feature is whether you want it to be solid and simple or unstable but looking pretty.

However, there is an oft-used trap used to reduce delivery expectations and time by “hiding” behind the tractor and not delivering what is really needed by the customer because it goes into the “Bells” class.

For example, if it takes 4x as many clicks to start the tractor vs the Cadillac, it doesn’t mean that adding in this functionality will make it a Cadillac, it means that it will be a more usable tractor for the customer if you can reduce this to 1 or 2.

Adoption of any feature you build is key, no one wants to work on the functionality that no one will ever use.  Seriously, no one wants to hear that their work is never seen by the customer – what a complete waste of time to have worked on something no one uses it.

This is why, when designing your tractor in early iterations (good, focus on the tractor first) there is always room to ensure that the tractor runs better than the Cadillac.  It’s not a bell or whistle that you are adding, it’s an easier way for your customer to get from A to B to increase adoption and be ready to use the Cadillac when it comes around the corner.

Practice, Practice, Practice

At the time of this post, I have written over 750+ blog entries, another 40 – 50 articles on other sites (Medium, LinkedIn, others) and am still toiling away on endeavors elsewhere.

But it’s not enough.

I’m not there yet.

I’m in that valley of Craptivity, not yet out, still deep, still taking that swing for the fences every day.

Just like everyone else who shows up to put in the time, chip away at the beast and make something happen.

Don’t stop practicing.


A follow-up on the Gatekeeper

A quick follow-up to last week’s post on being Getting Past the Gatekeeper.

If you ARE the Gatekeeper, it’s not a free ride for you either.

In front of you, there is this candidate which probably can do a number of technical things you can’t do (or might even care to do).

And that’s okay (you’re not the developer).

But on top of identifying who they are and whether they are a good fit for your company, it’s on you to make sure that their interest never wanes and they are excited to join your little corner of the universe (yes, even Microsoft and Amazon are little corners of a much larger universe).

To do this, you must know what they are interviewing and what it relates to.  You won’t keep them interested in buzzword bingo alone so you must know the “what” of “what” they want;

  • the growth opportunities
  • the team culture
  • the projects
  • the development toolsets
  • other company benefits

If you can’t convey these “whats” when acting as a Gatekeeper, then you will lose the potentially amazing candidate sitting in front of you.

(and yes, that is the correct order for which they should be discussed)

Fastest to the Mess

It’s easy to get flustered by someone next to you that is ripping through the code, their keyboard is on fire and they are knocking off bugs faster than you can open them.


Take a piece of paper right now and split it into two sides, with the following headings – “Who Cares?” and “Why does it matter?”.

Fill in the one column with the people that really care about speed and the other with why does it matter to them that this person is going so fast.

Are these people that matter to you and appreciate your work?

Probably not.  Most likely they are interested in speed and delivery as metrics but not with the ensuing mess that comes thereafter.

And the mess always comes, the person that does it fastest;

  • Never learns the right way to accomplish the task.
  • Always has to clean up again and again and again because it never worked right the first time.
  • Doesn’t care to follow-up with the customer or client to make sure that it really worked as expected.

Fastest to the Mess only means you got their first, what condition you made it in is anybody’s guess.

I don’t need to tell you the opposite of this, you’re already doing it, but hopefully, now you can start ignore the ones that are the fastest.

Always have the last laugh

Not the last “I told you so” laugh.

Not the last “This is so dumb it’s silly” laugh.

Not the last “I got my revenge on you” laugh.

No, I’m talking about the last laugh that happens when you and a bunch of your co-workers are sitting around trying to figure out why X is broken you realize it is a semi-colon in your code.

I’m talking about the laugh that happens when someone tries something new and it blows up in their face.

I’m talking about the jokes you make in your weekly meeting with the team to discuss what the priority is when all you have are priority ones and the team is clearly stressed out about it.

I’m talking about the humour you can use in a sales presentation to get your point across and make it fun for you and your customer.

That’s the last laugh we need more of.

(side note: if you’re looking for more information on sales and humour, check out Jon Selig and what he’s doing with “Comedy for Salespeople”, it’s a great approach to working with customers through sales)