Why Large Companies Should Use a Feature Flag Management System

Over the last several years, there's been an interesting dichotomy to my work.  I earn my living as a consultant, helping IT organizations with strategy.  And, in the course of that work, I've found myself helping both large international enterprises and startups.  This happens because most of my paid clients are enterprises, but I also donate my time to helping fledgling startups participating in a startup incubator. The stark differences between these two profiles of companies shouldn't surprise you at all.  Big versus little.  Established versus new.  You get the idea.  But one you might not immediately think about is how both types of organizations regard risk.  Startup survival requires courting large risk in a controlled fashion.  But the operating mode of the large enterprise generally involves intense efforts to minimize risk. This dichotomy shows up in how they make use of tools at their disposal, including software tooling.  Take a feature flag management system, for example.  Following the wisdom of The Lean Startup, nascent companies would use this to get an MVP to market faster so that they could learn what worked in their market and what didn't.  Feature toggling is a no-brainer for startups, who are in an existential state of figuring out which value propositions to their users work and which don't. But what about the enterprise?  Most people associate large enterprises with slow, plodding public releases and crusty internal line-of-business software.  Why toggle features when you have binders full of specs and annual releases?  Well, in a sense, I would argue that a feature flag management system is exactly the medicine large companies need.

One bit of quiet irony that I've observed in my travels has to do with the greenness of grass.  Startups, for the most part, dream of striking it big and becoming big enterprises.  But, wouldn't you know it?  Most big enterprises consist of groups, departments, and teams yearning to run like startups.  They chafe at the bureaucracy, the regulations, and the forced CMMI level 5 compliance. But it goes beyond simply finding the environment stifling.  Massive plans for multi-year releases never go according to plan.  Once out of the planning phase, the implementation picks up steam like a runaway freighter, smashing through deadlines and obliterating budgets.  These projects struggle. And, usually, they aim to cure the struggle with practices aimed at "modernizing" and changing their thinking.  They decide to "go agile" and "do the DevOps thing" and whatnot.  And then they bring in waves of consultants to help them change, and call it an "agile transformation." But keep in mind what I said earlier about risk.  Process modernization and working with the latest techs and tools makes line level folks happy.  But for the enterprise, this is still about risk mitigation.  Missed deadlines and busted budgets are failures, so they seek to transform and inoculate against more failure.

As you might expect with thousands of such transformations happening at hundreds of companies, some go better than others.  And no two look quite the same, either.  But I've seen enough now to recognize patterns and themes, and to have my opinions as to what makes them successful.  For example, adopting clean coding practices and tightening feedback loops rank extremely high among prerequisites for success. But there's a more subtle and less well known consideration I've come to think of as vital to the success of transforming organizations.  It's what successful startups do well and what enterprises lose as they grow.  I'm talking about a concept called thin slicing. I'll give the best example I've ever heard to illustrate the concept.  Think of building a website for a pizza place that allows people to order pizzas.  If you're thinking of how to accept credit cards, how to manage topping selection, and how to deal with coupons, you're not thin slicing.  How about a site that has a button and a box for your address that says, "ship me a medium pepperoni pizza and I'll pay in cash."  Seem crazy?  Maybe.  But this is an easy, tiny slice of actual value that can result in orders for the company.  And you might be surprised at just how many customers want nothing but a medium pepperoni pizza to be paid for with cash. You can transform to agile.  You can have daily standups and play planning poker.  And you can even remake your entire office to be modern and open planned.  But if you don't figure out how to thin slice your software, you're still going to struggle.

Let's revisit now the idea of the feature flag management system.  And let's say that, from day one of an enterprise program, you decide that you'll manage features this way.  Well, whether you realize it or not, you're casting your lot with thinner slices than you might otherwise have. Feature toggle in general and, specifically, a feature flag management system force you to conceive of your systems differently.  Large enterprises are used to commissioning software the way they might commission building construction.  You don't deliver a building as a loose collection of wires, pipes, drywall, and studs -- it's a largely all or nothing thing.  But how different would a building look if, from the outset, occupants had to be able to remove pipes, drywall, or wires at any time, with the push of a button? Well, it would look so different as to be impractical and absurd.  But, luckily for us in tech, building software isn't actually anything like construction, however much people still insist on that metaphor.  Building your software from the outset to allow toggling is actually practical and quite beneficial.  And it forces enterprises, used to monolithic scope, to start thinking of software as loose collections of capabilities.  This gets things to market faster, mitigating the risk of work in progress.  And it undergirds the idea of going agile.

In my consulting practice, I'm frequently called in when programs go off the rails to help them figure out why.  And, that's fine, but it produces a source of endless frustration for me.  That's because I often find myself saying, "I wish you'd have called me when you were kicking this project off."  I say that because the company has attempted a forklift upgrade with their software. The plan goes something like this.  They have old internal system X, and they want to modernize to new system Y.  So they assemble a tiger team to build Y in parallel with the ongoing existence of X. Then, one day, when all specs are met, they'll throw a massive switch, taking X offline and inserting Y into its place.  Doing years of development and expecting everything to go well on the big switch-over day.  What could possibly go wrong? Now, think back to thin slicing and feature toggling.  What might the X to Y conversion look like in thin slices?  Might you not go live with a tiny slice of Y, turn that same slice of X off, and migrate?  And, if anything critical went wrong, might you not use your feature flag management system to turn X back on?  You see, conceiving of your system in toggleable slices has implications beyond just one single piece of software.  It lets you, like a startup, run experiments for lower stakes.

Agile methodologies and thin slicing, specifically, aim to distribute risk evenly across the project rather than accruing it as you go like a snowball rolling down a mountain.  Deliver an "order a pizza" button only and deal with the risk of that before proceeding.  Take a thin slice of your system upgrade and deal with the risk of that before moving on.  Deal with risk before it snowballs on you. At the enterprise level, you have impressive levels of funding, resulting in no shortage of tools and options at your disposal.  Many of these will help you to varying degrees.  But if I were going to pick just a few to help you navigate the enterprise risk mitigation journey, I would definitely pick feature flag management systems. Feature flag management systems aren't just a tool like a logging framework or a text editor, though they're that too.  Feature flag management systems act as an opinion about the way fundamental way that you should think of your software.  And they're a great opinion on that subject.