Share on facebook
Share on twitter
Share on linkedin

How to fight the corporate Kraken using new cloud tools and survival strategies

A Cloud Guru News
A Cloud Guru News

The Kraken will destroy your projects and grind progress to a halt. If you’re not serving customers — then you’re serving competitors

When working in the cloud, I always advocate focusing on features — not versions. One of the most common questions and obstacles is how to deal with cross-product and infrastructural projects while trying to focus on delivering features.

It’s easy to talk about individual user stories in your single application — but the implementation of broader, enterprise-level upgrades can trip up even the best feature-focused team.

Under the surface, these issues don’t look too complex and this type of work can often ‘just happen’ in startups — but it’s monster for most large companies. These horizontal IT efforts are usually complex big-ticket projects with many far-reaching tentacles and consequences. They can simultaneously spin up huge teams of disaster while bringing meaningful development to a complete halt.

Welcome to the Kraken.

The Kraken Attacks!

Imagine the scenario: you work on the mobile app team for a national car rental company. You’ve been kicking ass — releasing features consistently and wowing customers with the ability to scan their own drivers licenses from their smartphones and offering a ‘no line’ car pick-up.

Job promotion and riches are imminent.

Suddenly — corporate IT demands that you need to integrate all your efforts with a new version of Active Directory and centralize all logging activity with a new tool they’ve licensed. These are company-wide initiatives affecting all development teams.

Below the radar, the Active Directory project pulls nimble teams into the dark, dank hallways of network administration. These “matrixed” infrastructure teams are notorious for not using sprints and using a rigid ticketing system. Combine these elements with a vague-but-powerful manual testing process — and your progress grinds to a halt.

The new Active Directory requirements also hits every team across the organization at the same time. As a result, your mobile application is placed way back in the queue since it’s not considered essential compared to many internal systems in the organization. You’re looking at getting their attention 6–12 months from now — close to the implementation cut-off.

Your team has never heard of the mandated logging system. It operates at the UI, mid-tier and back-end levels, offering only a Java SDK. But your team is using iOS and Android, backed up with Node.JS and Python. The requirements from IT are new — and the team will need to create a layer of wrappers around the SDK to expose an API in order to consume the service.

These two requirements will destroy productivity and team morale, and create a year-long implementation effort that achieves very little.

The Active Directory project take all the authority and decision making from your developers, suck all the focus away from customers, and kills team momentum. Your apps will go from cutting-edge to mediocre as competitors catch up and some of your dev team will quit.

Behold, the Kraken has claimed another victim!

The customer is your first line of defense

When you have a lot of systems and a boatload of employees, there are endless Kraken projects that can suck you down into the whirlpool. They often look like upgrades of middleware or operating systems, or new security standards. Kraken projects typically all have one thing in common — they offer zero customer value.

The Kraken appears in many guises in corporate IT. Sometimes they appear as innocent consolidation efforts — like logging. On other occasions, it’s more sinister job-threatening projects like security. The first step is to keep calm and figure out if there is any actual customer value.

The Kraken may appear as an innocent effort, a security project, or Tom Cruise

The guards of IT yesteryear will often scoff at the need to show customer value — claiming that security and infrastructure are the foundation of this value. But cloud natives know that these are not value-added activities — in the cloud they are handled for you. Most often, these efforts are created by IT bureaucracy to keep itself busy and relevant. Mainly busy.

The customer is your first line of defense — so dare to ask the question:

“Where is the customer value?”

Do you really want to stand before the customer and explain what your team has been doing? Will the customer care that you have a new Active Directory version or logging tool?

Whenever you shift from actual customer features to IT make-work projects, you are only serving your competitors.

Repeat after me: If you’re not serving customers then you’re serving competitors.

Short-cutting delivery with the cloud

Some Kraken projects are difficult — if not impossible — to avoid. Most are dreamed up by IT senior management or demanded by regulators. Fortunately, there is usually a cloud-based service or solution that can used to bridge the gap.

In the scenario above, switching to Amazon Active Directory would use some of your team resources, but could be implemented as a single-step solution. It’s a managed service — so future upgrades will be invisible to your company. Building integration between your on-premise Active Directory and Amazon Active Directory is straightforward. For a bonus, other teams can start to migrate in parallel in lieu of waiting for the on-premise upgrade.

Logging is another activity where the cloud offerings shine. In addition to AWS CloudWatch, there many excellent third-party options such as StackDriver. The cloud-based logging approaches are mostly API-driven, language-agnostic and offer enough benefits to justify the rework. They even include the ability to publish logs back to on-premise logging systems — for some unholy reason. And as for cloud-based log analytics, just add popcorn.

The cloud alternatives to on-premise Kraken projects tend to be much more flexible, and also don’t require a massive effort when a new version of the service arrives. They also eliminate bottlenecks and dependencies on a single internal team. You can also avoid the atomic, all-or-nobody approach that happens when an OS upgrade “must” happen if you want to stay in your datacenter.

If you’ve designed your applications to be cloud-first, you will likely be using many of these tools already. The biggest challenge is convincing your management to take the cloud path and opt-out of the internal Kraken project. This is often my preferred path — this allows you to cooperate with the demands, use the right tools, and placate the corporate bureaucracy.

Saying “no” and going rogue

You might be very tempted to fight the Kraken by rallying your teams to protect your products with defensive support from your product managers and executive sponsors. This is a dangerous strategy — it will work once and then place your team in the crosshairs for future Kraken activity.

Nothing aggravates IT bureaucracy more than seeing one special team excluded from its upgrade drills or mandated policies. This strategy merely defers the fight with the Kraken and buys time — but now you have to radically shift to survive the next round.

For the follow up attack, your product group will need to have very few dependencies on internal systems to survive. I’m not just referring to APIs into internal systems — I mean different code repositories, laptop builds and networks. You will have to operate like a start-up within the company and have the ability to use whichever IT environments you need. This is a full-on existential battle with corporate and requires major high-level support and sufficient time to work.

For these reasons, this approach rarely works outside of pet projects, e-commerce, and mobile apps. At some point, IT will seek to reign in these efforts using the argument of operational efficiency, security, and consistency. Your team will get consumed with multiple, simultaneous Kraken projects until all that’s left are fragments of code floating in the water. In many ways, this strategy is doomed from the outset.

Why don’t Kraken projects work?

I am often amazed at how these zero-value-yet-essential IT projects go adrift again and again and derail important development work. It becomes a bit clearer when you look at the spectrum of workloads in an enterprise — from end-user application, all the way through the infrastructure found in the darkest, dankest caverns of the IT basement.

At the application level, life is better in every way. Your customers experience feature delivery here, individual teams control their own products, and there is a level of autonomy that makes it easier to manage risk. It’s also the area where the cloud can least offer product alternatives since applications are highly customized.

At the other end, infrastructure is rarely connected to customer features. It also tends to be an area that’s horribly underskilled in companies because good infrastructure people are hard to find. These trunks of code touch everything, change rarely, and there’s risk in doing anything here. Yet this is the area where cloud has the most number of drop-in of alternatives.

What does a non-IT Kraken project look like?

In many companies, the fact that corporate IT loves focusing on the hardest, least valuable areas is what unleashes the Kraken. But this approach wouldn’t fly in any other business.

Imagine if Subway grew its own wheat to make sandwiches, Avis manufactured rental cars, or Marriott started making linens and carpets for its hotel rooms — it’s nuts.

These highly successful companies know to focus on the areas that add value to the customer experience and let somebody else handle the commoditized parts. They do this even though their customers use the third-party products directly all the time.

If Avis were to decide to build their own vehicles for some awful reason, fleet oil changes would be like operating system upgrades in IT, and launching new car models would be so painful that they would only rent out one vehicle type that was last updated 10 years ago.

The value chain makes this even more obvious. Seattle’s Best also knows that the value of a coffee bean accelerates as it reaches the customer. Growing and picking coffee beans is one of the hardest, lowest-paid jobs in the world. Roasting and packing coffee beans is no picnic — but when transformed into the customer’s favorite beverage its value spikes from pennies to dollars per ounce.

And guess what? If health regulations change, affecting the production of coffee beans — the equivalent of a Kraken project at Seattle’s Best— it doesn’t impact the customer. The company is entirely insulated from these sorts of changes because they don’t manage them. IT has some lessons to learn here, and it’s not just about drinking more coffee.

TL;DR

  1. IT releases The Kraken whenever it launches infrastructural changes that impact every team. These projects are expensive, error-prone and don’t usually deliver any perceivable value to the customer.
  2. These same projects are handled by cloud providers all the time at the IaaS and PaaS levels, and there are great cloud tools available anytime you examine the fabric of your infrastructure.
  3. Three strategies to respond to Kraken initiatives: (a) focus on customer value (b) shortcut the effort by using a cloud alternative and (c) refuse to participate.
  4. Kraken projects look ridiculous because they are ridiculous. If you compare what corporate IT is trying to do with any real-life successful companies, it becomes obvious that they are focusing on the wrong part of the value chain.

Thanks for reading! If you like what you read, hold the clap button below so that others may find this. You can follow me on Twitter.

Recommended

Get more insights, news, and assorted awesomeness around all things cloud learning.

Get Started
Who’s going to be learning?
Sign In
Welcome Back!

Psst…this one if you’ve been moved to ACG!