Often in software engineering, we talk about doing the right things – like enabling self-service, unlocking flow, or stream aligning teams. What often gets overlooked are the things you ought to avoid. Often teams do the wrong things while doing the right things. How does that happen?!
It’s easier than you may think!
Today, I want to share a case that exemplifies a few things you shouldn't do when you're building an internal or industrial platform – or any large-scale system. The company did a lot right, and it still went sideways! It's an ideal case study of why having good intentions, a compelling vision, and vast resources just aren’t enough to deliver success. The system always wins, and failing to see and connect all the dots can burn through even the biggest stack of cash.
The difference between positive and negative outcomes is the how. Doing the right thing is always less important than doing the thing right. The Predix case is a perfect example.
The Predix case
Predix is a platform-as-a-service that caters to the industrial internet. It aggregates data from sensors, IoT devices, and factory equipment to support analytics and various applications, building on AWS for its cloud offerings as well as supporting on-premises deployments.
The Predix Platform is helmed by one of the world's biggest companies, General Electric. With that kind of backing, you might think the company's platform development journey would have gone smoothly. Unfortunately, the reality was anything but.
Setting lofty expectations
When GE announced Predix, it made waves thanks to its promise – easy IoT deployments, condition-based monitoring, and a uniform platform for streaming and batch analytics processing. Built atop Cloud Foundry and using enterprise-grade technology, it was all set to be a truly big deal.
To understand what happened, it helps to consider the project's beginnings. In line with what I like to call the best of Silicon Valley thinking at the time, GE Digital brought in Eric Ries, writer of the Lean Startup. They focused on areas like rapid delivery and deployment while observing a host of good technical practices.
Working with Ries, GE also created its own development process called FastWorks. You can think of this as a variation on classical Lean with Lean startup elements mixed in.
As observers have pointed out, making the switch wasn't an easy task. The company's Six Sigma-heavy track record meant that the transition required massive training efforts and significant cultural shifts.
Why go to such lengthy efforts? Predix may have only been one motivating factor – GE wanted to flesh out its infrastructure-as-a-service and platform-as-a-service offerings, but it also had its eye on building an entire digital ecosystem to support them. They could see that software was eating the world, and wanted to be a part of it rather than just be carried along.
They went deep, and broad. They even built their own data centers to own the end to end value chain. Building a data center isn't quite lean startup material – It's a huge expense that most companies wouldn't want to experiment with, but let's give GE the benefit of the doubt. After all, it's a huge company, so maybe these plans weren't too far out.
The problem was that building the data center was only one of the project's requirements. The company would also have to implement features like on-demand infrastructure pipelines, application scaffolds, templates, and a host of hardware, networking, and other applications designed to facilitate the original objective: Fluid internet of things development.
The problem's expansive domain placed even more demand on the platform. For instance, when developing IoT ecosystems, it's common to create bespoke hardware products, digital twins for performance monitoring, and other tools that support custom applications. In other words, the IoT is a vast space – and GE wanted analytics across the board, including integrations from its factories, customers' facilities, sensor prototype pipelines, monitoring beacons, and all kinds of other sources.
You might think that sounds like quite a lot for one platform to handle. You'd be right, but that wasn't even the whole of it. GE also thought it'd be a good idea to create a marketplace to sell its offerings to its developers internally and support partner reselling under white label terms. Like Amazon, they wanted the tooling they developed internally to become a public-facing platform. Sounds great, but it’s not quite a free bonus.
Cruel reality rears its head
I like to say that the first thing to remember when you're building anything is that building it might be the worst decision you could make. There are many hoops you need to jump through before you can even start creating because it's almost certain nobody's going to care about what you've built – unless you do everything in your power to drive interest.
It's also vital to remember that most digital transformation efforts fail. It doesn't matter whether we're talking about the projects themselves, the money and effort that go into digital transformation, or the cultural adaptation to digital workflows, environments, and platforms – These efforts fail because they force organizations to venture into realms they've yet to explore.
Did GE somehow forget these rules? It may be more a case of never sufficiently appreciating them to begin with.
GE is nothing if not an extremely physical enterprise: It's firmly anchored and rooted in the brick-and-mortar world, from its history of traditional manufacturing in factories to its limited exposure to the digital arena.
This was very new territory for the company. The odds were accordingly low that GE was going to get everything right the first time, particularly since it seemed to be reliant on the oft-debunked "if you build it, they will come" approach.
A timeline of a failed platform
I first heard about this project in 2015 at the DevOps Enterprise Summit. GE's team took to the stage to announce their intention to build a platform and learn from their mistakes in public – a solid start for communicating where things were headed and holding themselves accountable.
Fast-forward to 2016, and GE's confidence remained high. The company even publicly predicted that its efforts would account for 15 billion dollars of revenue by 2020.
So how did things look by 2020? It's not an overstatement to say the revenue projections missed the mark considering they fell short by about $14 billion!
By this point, the company had already shelled out more than $7 billion on consultants, marketing, partners, and more. Adding further insult to injury, GE's competitors weren't sitting around waiting for the company to get its act – or platform – together. In my research, I discovered at least 25 IoT cloud platform vendors that have since established firm footprints in a space that GE could have completely dominated.
I should point out that GE made quite a few moves that ought to have worked well. Unfortunately, this is a tale of efforts being aimed in the wrong direction despite the underlying good intentions.
Big goals vs suboptimal implementations
One of the first things I noticed was the scope of GE's vision. They clearly communicated what they wanted to do, and they weren't off the mark in assuming that a cloud for the industrial internet would find a welcoming market. In my view, the problem with this was that the vision and goal didn't align with GE itself.
GE may have mistakenly viewed its digital endeavors from a "siloed" perspective – treating its platform as a separate entity instead of an underlying substrate for the whole business. The company never quite made the mental shift to acknowledging its platform culturally, living and breathing it the way devs should.
It's like having a weight loss goal but eating fast food every day – Your vision doesn't align with your track record and current practices.
Such discrepancies also led to significant organizational conflicts, primarily between the mindset of good platform development practices and GE's traditional Lean manufacturing style. The company also dropped the ball on managing its dev teams by building a massive facility in San Ramon – close enough to San Francisco to be in Silicon Valley but not near enough to keep new hires happy.
An over-dependence on outside help
It's also worth questioning whether GE invested in itself enough: While it certainly hired excellent consulting teams to help its transition, those people eventually had to go away. The company simply wasn't devoting sufficient effort to creating the internal capabilities and organizational infrastructure required to make up for the gap. With any modern initiative, nothing ever ends. There are no more projects. When you’re building a platform, you’re building a living thing that needs to be not only continuously maintained but continuously improved - for as long as you’ll be in business.
Failing to adapt to the culture
In most cases, building massive projects like this involves creating just enough to learn and then pivoting. You have to adjust in response to feedback and continually work to keep stakeholders on the same page.
When I dove into this story, however, I encountered numerous stories of misaligned teams – Some people were gunning for efficiency and cost savings, while others were focused on tackling a brand new market or catering to end users. It was a case of trying to do too much – and too many things – at once.
What should GE have done?
One thing I repeatedly heard while talking to people involved in this fiasco was that organizational silos were extremely common. People in sales didn't know what was going on, developers didn't know what other devs were doing, and so forth. This led to each group pulling in their own direction, and little effective collaboration.
This is no surprise considering that GE thought of Digital as its own siloed business, rather than a foundational aspect of everything they did. The danger is there for platforms as well. A platform has to enable every team it serves as infrastructure as critical as their laptop computers, or internet access. It can’t just be part of what you do, it’s supporting everything you do.
From the beginning, the odds were stacked against them because they didn’t see the problem and opportunity in a useful context. I view this partially as a failure to appreciate the value of clearly defined and communicated outcomes. What was it they were really trying to build, and for whom? That can seem clear or even self explanatory until you ask around and realize that everyone gives you a different answer. When I consult organizations on big projects like this, I like to walk them through an outcome mapping process to make the vision explicit and define it clearly for everyone involved. This preliminary collaborative stage helps clarify why projects are important, what obstacles might crop up, how things could go wrong, and how to establish effective learning-informed decision-making processes. Before people start making assumptions and go off to work on their own, it’s worth getting crystal clear on what we’re all trying to achieve, what’s in the way, and what we’re going to do about it!
Another collaborative method I commonly use is value stream mapping, which involves looking at how everything is happening in the organization today and asking how you'll accomplish all of your different goals by working more effectively. By walking through the value stream map and building out each step in terms of what's involved and how long it takes, this method enhances your understanding of where you can – or should – focus. With a value stream map you not only get data on what’s happening now, you can map out a future state so everyone knows what a better flow looks like. That allows you to build a better way of getting work done. Your future state can involve all the platform improvements you intend to implement, and how those improvements will affect workflow.
Wardley mapping could have also been a big help here. It reveals what the ecosystem, problem landscape, or environment looks like, giving stakeholders a better appreciation for what they can adjust to get closer to the goal. It allows you to not only plot where all your pieces sit on the board, but also consider how you can move them and connect them in new ways. Wardley mapping is an effective approach for communicating the value of specific changes and strategies, such as relying on off-the-shelf software or outsourcing for certain parts of a platform.
To wrap all of these practices into a simple framework, it’s helpful to view the effort through three lenses: value, clarity, and flow.
- Value: Platform implementers should align value propositions for the business, customers, and employees to create a compelling vision. When communicating these objectives, they need to avoid presenting conflicting incentives.
- Clarity: Come together to align people's perspectives and further common understanding. From there, you can chart your unique course based on your territory and adjust it to accommodate new learning. Clarity enables every contributor to consistently make the best decisions.
- Flow: This is all about understanding your workflows and constraints while responding to feedback. To make it all work, you need flow to be a primary concern. Look at what engineers are doing to deliver, what customers expect from delivered work, and what leaders need to see in order to adapt and plan.
Hindsight may be 20/20, but by keeping these concepts in mind from the start, you won't have to wait until your next project has successfully wrapped up – or spectacularly failed – to improve your platform engineering skills.
Keep in mind:
- Platform engineering supports your efforts, it’s not an isolated effort
- Strive for clarity from wherever you are - it pays off every day
- Look at the big picture as a system - a system that needs flow to deliver outcomes
- Consultants can be essential to get you started - but you need to build capabilities
- Start small, learn, and adapt
Want to hear more about driving positive outcomes while avoiding the biggest pitfalls? Check out thinking.visible.is, or follow the Value Stream Show at valuestreamshow.com for more on doing flow right.
.avif)
