It’s a Large Batch Life for Us

It’s a large batch life for us!
‘stead of feedback we just wait!
‘stead of options we trust fate!

— Little Orphan Annie…sort of.

Before I talk about “large batch life,” I’d like to take a moment to share with you a bemused chuckle at really poorly done verbal tribalism.  Rather than try to explain in the general sense, I’ll offer an example: an out of touch father trying to determine if his kids are doing drugs by saying, “so, dudes, are any of your friend-bros on the pot?”  He’s attempting (and failing) to crack their linguistic code to gain credibility. The kids, presumably, have a tribe with its own invisible speakeasy, and Dad is trying to get in.

There are tons of tribes, and you’re a member of many.  When you say, “pull request,” in casual conversation, you’re indicating that you’re part of the tribe that puts open source code on Github.  When you tell people to “put it on my calendar,” you’re indicating that you’re part of office culture. There’s nothing particularly notable or bemusing about that — it’s simply the mechanics of human communication.  Where things start to get awkward is when Dad enters the mix in the form of a recruiter or hard-charging project manager and wants to establish cred in that world without really having any: “Hey dudebros, can I pull request a phone interview with you?”

This attempted short-cutting creates a linguistic equivalent of the dance between high-end purse makers and knock off makers.  Tribal language is constantly evolving both for communication and to keep impostors from becoming comfortable.  But impostors are constantly trying to keep up.  It’s for this reason that terms like “agile” explode on to the scene, create sea change, and then wind up in games of tug-of-war where cutting edge contrarians reject them, hucksters sprinkle them liberally, and traditionalist tribe members attempt to purge and purify the definitions.  It’s not just “agile,” of course.  Throw hashtags in front of them, and “craftsmanship,” “lean” and “disruption” are all starting to experience authenticity fatigue.  (I actually have a partially formed draft that goes into a lot more detail on this, so if you’d like to hear more, let me know)  Eventually, it’s only the hucksters that are left using the terms as everyone else moves on, evoking memories of the following scene from an old Simpsons episode:

Krusty: Ooh! Sex Chat! (dials)
Sexy 900 Number Voice: You’ve reached the Party Line! In a moment, you’ll be connected to a hot party, with some of the world’s most beautiful women! Now, let’s join the party!
Krusty: Hello?
Man 1: Hello?
Man 2: Hello?
Apu: Are there any women here?
Krusty: Hello!?
Apu: Are you a beautiful woman?
Krusty: Do I sound like a beautiful woman?
Apu: This is not as hot a party as I anticipated.

Dudebros, Let’s Get Lean

It’s a particular bummer with “lean,” which has a rather long and interesting history.  But it now has the misfortune of being the simultaneous darling of the consulting and startup worlds, resulting in a whole lot of people making it a whole lot of vague.  The logical conclusion of all of this has been that “The Lean Startup” is cheapened from an ingenious book about applying the scientific method to business ventures to a glossary of buzz words for hucksters.

“Minimum Viable Product,” is perhaps the worst victim of uncool business Dads everywhere.  What Eric Ries actually meant by this term is, ironically, a contradiction to how it’s commonly used in business.  The minimum viable product in Lean Startup land is basically the cheapest thing you can build that will let you learn about the profitability of your business model.  It could be you walking around your neighborhood collecting signatures if that proves validity.  It may also be that you build something that people buy and want their money back because it’s not actually a product — it’s just a thing you threw together to learn whether people would be willing to pay.

But in the business world, it seems to have come to mean “prototype” or “version 1,” even.  The “minimum viable product” is what happens when you filter out all of the bits that the project manager relents and agrees aren’t strictly necessary.  It’s the minimum thing you can build that will make the customer happy(ish).  It’s not that one definition is inherently better (and the term is rather vague), but there is dissonance when people with these respective definitions chat.

The result of this dissonance tends to be that terms fall out of use.  At some point, fatigue will set in over all of these buzzwords and vagueness and people will move on, forgetting all about disrupting things, getting lean, and having minimum viable products.  And that’s a shame, because there are great lessons to be learned.

Specifically, the Lean Startup talks a lot about the concept of batch size and how to make it smaller.  In the programming world, we tend to think of this in terms of “feedback loops.”  The salient question is “how much time expires between when you take an action and when you see the results of that action?” The smaller the amount of time for feedback, the better.  One of the things that people tend to like about test driven development (TDD) is that it really shortens the feedback loop.  But you don’t need to practice TDD to appreciate that it’s more fun to program if building and running the application happens quickly.   When the feedback loop is tight, there is no dead time where you’re waiting to see if your changes were the right changes.

Agile methodologies for developing software take this and apply it at the project level.  Instead of shipping software in some massive rollout after three years, start shipping early and correct course as needed.  Optimize the software delivery pipeline so that you can ship on a regular basis, and take the lessons you learn with each shipment to apply them to the next.  Generally speaking, approaches that tighten the feedback loop are gaining steam in the world of software.

The “minimum viable product” is an example of applying this concept to the entrepreneurial world.  Instead of securing funding for an idea and spending years building the thing for a grand unveil, do as little as humanly possible to see if it will actually make money, and then either go ahead or adjust and try again (the latter is known as a “pivot”).  In talking to members of the startup community, it appears that investors now tend to look for this as well, preferring to see proof of profitability where in the past they might have been satisfied with an impressive business plan and presentation.

Small Batch Software, Large Batch Lives

And yet, once a company is born, a large batch, slow feedback world takes over.  Companies form with the goal of getting to a million in revenue and then to a billion.  They aim to change (or even take over) the world, employ tens of thousands of people, and live on in perpetuity.  In principle, at least, they aim to establish themselves, create a ‘culture’ and a safe zone where employees can ideally spend an entire career.  That is, they aim to enable the largest batch there is in our lives — the one where we pick what we want to do for a living at 18, do it for 50 years, and then ride off into the sunset.

Oh, sure, people switch companies, make lateral moves, and even occasionally return to school for a complete career makeover, but announcements of such intentions are met with raised eyebrows and initial skepticism, if only of the whispered variety.  People who do such things clearly swim upstream.  For the rest of us, it’s a life of early dues paying, slowly working our way up, managing people, having offices, getting old and tired and eventually wheezing past the finish line when we hit the magic number of saved dollars that allows us finally, mercifully to stop.  Then it’s a ride off into the sunset, that dream cruise we always wanted to take, followed by a lot of doing nothing and running out the clock.

In a world that’s discovering the operational efficiency benefits of small batch approaches, it’s a cruel irony that the default, comfortable pattern of existence for humans is a batch size so large that we only get one in a lifetime.  To engineer a situation that’s different and that involves distributing enjoyment throughout life and having different career phases is no small feat.  I consider myself fortunate to have escaped this cycle, but, then, fortune is relative.  It’s required moonlighting, night school, risk-taking, and 70 hour weeks for the better part of a decade.  That shouldn’t be table stakes for a human to enjoy the same ability to adapt, pivot and grow that is given to nascent corporations and software products.  Iterating rapidly to find work that you love and do well shouldn’t have to be a high risk proposition.

One of the things I’d most like to nudge along in my lifetime, if I can, is a different way for us to conceive of work and a different way to approach a working life.  This is basically the subject of the book that I’m writing, entitled Developer Hegemony: The Future of Labor.  In that book, however, I don’t talk about batch size and the failure to apply lessons in efficiency and sustainability to our own lives.  That’s unique to this post and the imbalance I’ve noticed between improving product development and improving people development.  There’s no real call to action I can offer here, so I’ll just close by hoping that it’s at least put the idea in your head that there may be some better way to structure knowledge work endeavors.  If we can engineer processes that prevent building the wrong product or even the wrong company, it seems like we can engineer working structures much less likely to produce human lives misspent in perpetual unhappiness.