Transcript
Max Korbacher: My name is Max. I'm what you normally would call a consultant. At least that's what I earn with my bread and butter, which feeds me to be here. I spent actually the last 5 to 6 years all on open source, being in conferences, sharing the knowledge which we have gained in projects, writing a book. Normally I'm talking more about platform engineering for architects. With the feedback which we got for the book, we found out it's more like platform engineering for everyone. That's what we're talking about today. I would like to go with you through the experience of why success for platform engineers can't be coded. The success comes from somewhere else. That's what we're going to look into today.
First of all, I would like to know with whom I'm talking to. Who of you is using daily, for example, something like a developer portal? Let's say Backstage, for example. Who of you is working and living and maybe crying over an entire platform, like provided by a platform engineering team? Would be interesting to know for those who are more working on a platform why they do not have a portal. Most of the time, I know the answer, because Backstage is sometimes a pain, at least from what we can see. It's interesting, because quite often, every company starts with a portal and not with a platform. It's the sexy UI which you would like to first deploy, because it's built by Spotify. If Spotify does it, so it must be good. Who of you is responsible for a platform? Who of you has already built a platform or is in the process of building a platform and has a feeling that it doesn't go that well at the moment?
Why Internal Development Platforms Tend to Fail
Normally, if we talk about the development of so-called platforms, we call it sometimes a cloud-native platform or an internal development platform, however you want to call it. Those projects, and I really hate that word, because projects have a deadline, and if you reach the deadline, the project is dead. It's bad for a product. They tend to fail because of certain reasons, like the adoption, some management expectations that are not met, that you didn't cohere to the needs. Maybe you never have heard of the needs of your development team, or you just sometimes miss the promised value. This is the Backstage experience. Why Backstage is failing is because you see a super-cool platform for developers. You install it first. You go in, and it's empty. Until you have configured the first extension, and you feel happy, you need five engineers and a couple of months, and then it's like, burn money like hell.
You still do not have the feeling that you have got the value which you actually expected out. All of these problems are more laying actually on some other points. Quite often, a platform doesn't have any kind of purpose defined. Why am I going to build a platform? For which reason? Do I have an engineering problem that I need a platform? Sometimes platforms don't have a vision, a picture. I would like to speed up the development speed by two and a half times. That's where GitHub, for example, is. Or like Toyota would like to save millions of euros, or dollars every year. Sometimes it's because of the technical debts. In my experience, it's not always the tech. Sometimes it's over-engineered. Who of you was at a KubeCon or an Open Source Summit, came back and said like, "Fantastic. I love that tool. It looks so awesome. I have to put it into my platform?" You have never asked someone if you really need it. It's over-engineered. Or you didn't listen or measure to the actual people who are going to use it.
My personal favorite is randomeering. I don't know what the term is called, but it's a mix of random and engineering. I like to use that tool just because I have seen it. There are plenty others, but I saw that one, I would just put it in. It would be right. It looks ok. The biggest killer itself is the infrastructure-first thinking, and that has a reason because most of the platform engineering people actually come more from a cloud or infrastructure perspective, got a little bit relabeled. Maybe had a 10-year painful journey as a DevOps, and now there's the secret land of platform engineering, but in our heart, we love infrastructure. The thing is, you can even ask your favorite AI about what does it think about infrastructure-first thinking. We have points like technology-centered, which doesn't sound so bad. Begins with architectural decision. It's good to have a good, clear vision and mission where to go.
It's tool-oriented, also doesn't sound so bad. Or designs from the infrastructure layer upward. Or, solution before a problem. It doesn't sound so wrong. If you ask why infrastructure-first thinking might be a problem, it focused primarily on the technology stack and the infrastructure components. I want to build something that technology-wise is awesome, where I as an engineer come out in the end, similar to building a car by hand, it must be awesome. It must be shiny, fast, loud, whatever. That's what I would like to have. It very often becomes a problem because thinking first about the infrastructure means that you never think about the person who in the end will use it, and it's not our nature. I had the luck that after my studies, I was working in demand management for one-and-a-half years. I had to go out as an IT guy and talk to people, what do you want?
Define requirements, and write them down and have interviews, and challenge the things that they really like to have and try to put all the different perspectives to it. It was a painful process because it's not my nature to go out and ask people, what do you really want? It's not my responsibility as someone who built infrastructure in the past. This is the one big part.
New Tech Stacks - Shift Left, Adoption, and Duplicated Efforts
Then the other perspective is that all these new technologies actually require this shift left. In one conference, one of the speakers said shit left. I think that's not that wrong because it's like pushing the problems away down the pipe. Like, you as a developer, you can deal with the CI/CD and the observability, and you have to put in the tracing, and security is also not a big issue, so why don't you do that too? Have you heard about compliance in GDPR? Please put it in. Shift left, shit left, that's not a big difference. The thing is, it often scales up because, especially when you're an enterprise or even a medium-sized company, you're not normally the only team, so you have maybe a silo or a team that does sales application. Then you have some who do your portals, web application. You have maybe something that is more in the backend, orchestrating some logistics, whatsoever.
You have different teams, and this sums up. You have multiple teams doing it their way, and yes, with some organizations, they try to be harmonized. I'm doing long enough consultancy to see that there's always waves in a large enterprise. You have some time where you have harmonization. Everyone is like, we use one tool, we use one approach, and then comes a reorganization, and shit goes down. It's not by purpose or by intent. Actually, the company wants that you work together, that you have a common approach to it, but with each of these waves, you have normally a very high rotation in the staff. A lot of people usually try to quit. You bring in new people, and then also in addition to those waves, you have industry hires. Ten years back, everyone was IoT. IoT will be the next big revolution. We will make IoT everywhere.
Everything will be connected. IoT is still there, but where's the revolution? I don't know. Everything needs to be cloud-native. We do more containerization. I'm a Kubernetes dude. I love Kubernetes and containers, but it still doesn't make sense every time. Hype is gone. Nowadays, AI, machine learning, LLMs, everything must be with AI. Look at the latest studies. You can see the story. It's failing. It's more failing than being successful. You're wasting more money than you actually bring success to a company. That's very often because a lot of teams need to do things their way, and because of these waves, because of these hypes, it's always breaking up a harmonized environment. Then after a few years, they need to go back to being harmonized again, so it's always going in those waves.
Obviously, you have duplicated effort. You need to operate something. Operation, not the favorite of everyone, but every application needs to be operated. That's one part of it. You need to make a release management if you want to do it properly and right. The more you use all the tools internally, you have user management, InnerSource, try to inform others about your features, about the new things which you have put out there. This ultimately normally results in such kind of patch solutions. This picture was true 20 years ago. This picture was true 10 years ago. I think still the picture is true today. You maybe don't call them sysadmins anymore or the ops team. It's now the very cool DevOps team, but the dev is usually extremely small-written, and the ops is very big. Most DevOps which we meet that do DevOps all day long, also do it on weekends and in the night and on on-call, and have in their contract written, "If it's burning, I call you, and you have to answer in five minutes." That's DevOps in some way. However, those patch solutions are obviously somehow problematic because a patch is normally nothing which you can have for longer. It's something that comes up naturally, but it's not necessarily something that you would like to have your organization to be continuously there.
Leading to Platform Engineering
That's where after many years of these up and downs and back and forth, breaking, harmonizing, and so on, we come to the point to select platform engineering. It's not DevOps. Hopefully, it's not the same DevOps team, but we need one team that doesn't continuously break things up and put it together and harmonize it, but who produces a product that I don't have to enforce, where I don't need to run around as a CIO and say, you people have to use it, else whatever. Usually, companies cannot do any consequences, at least not in Germany, so it's very worthless that someone scream at you and say you have to use it. It also doesn't help for a product that it gets thrown at your head, and say, you need to use it. Who likes to do that? I hate it. Someone comes to me and throws it at my head, and say, do it now.
My resistance is growing immediately, from, I would have tried it if you didn't scream at me, to, I don't care. You can create an account for me if you want, but I don't care. Platform engineering itself needs to have some kind of product mindset, not a project. It needs to understand its customers, the internal developers, but it can be also anyone else. That's sometimes a little bit misconception about it. If you have a platform, that's not only for the developers. It's also for your security personnel. It's maybe for the compliance officer. It's for your product owners. It even could be for business people. One of our most successful platforms doesn't have any kind of fancy frontend, but almost half of all VPs are looking at least once in a week somewhere in GitHub for a report about the platform, the usage, the deployment, and so on.
Served to the inbox, click a link, it pops up. They don't have to do anything, and get information about how it's going. This is people using actual tech. For me, a platform without any kind of adoption, and this is about making people to happily use it, is just infrastructure, and just infrastructure is usually very unsexy. Also, I like it, but for most people, what it means to have a server, a serverless framework, and so on. We need to emphasize about the product mindset, and this turns a platform into an indispensable tool that developers want to use.
How to Build a Platform
How do I get there? How do I make people really want to use a platform that I've built for someone? First, we need to be aware that it's actually difficult. That's a graphic from our book where I try to redefine the iron triangle and give it a new perspective, which is, we have the feasibility, we have the desirability, and the viability. Or in other words, how do I build the thing right? How do we build the right thing? How do we build something that the customer wants? Similar with the iron triangle, I usually can fulfill only two of these aspects very well, and I have to sacrifice the third aspect. It's like I always say, imagine it like you have a metal band which connects all these three triangles. If you pull in one direction, the band goes in this direction, but it means it lowers another angle flattened.
It's not a rubber band. You cannot pull it that way and that way, and it's all good. That's not how it's normally working. It has something to do with budget, time, amount of people you have available to work on it, and so on. Platforms who can fulfill this iron triangle in all dimensions are usually large, but if they fulfill it, they don't have to scale more further. This is always like a little problem to explain to someone, listen, there is a certain threshold which we need to reach, and then your world will be nice and perfect, and we can fulfill everything, but until we have not reached that dimension, I cannot build you a perfect platform. Only with a lot of time and effort, but yes, it doesn't work that way.
How do we get there? How do we fulfill this iron triangle and find a way that people really desire the platform, that they really love the platform, and that the platform is actually good? For me as a former enterprise architect, I need to say, principles are sometimes the gold which we are missing nowadays. Everything is about, we need to make it agile, and let's sit together, and we plan something, and so on. Very often you have not so many people anymore who are driving a decision or who have an actual guiding framework to take a decision. Decisions are taken because of a subjective favor very often of single people, those who are allowed or those who maybe have more experience than others. Principles put a framework back to that, and say like, if we focus, for example, on common problems, then I do eliminate the aspect maybe of randomeering.
Because adding a random tool to my platform doesn't mean that I solve a problem. It just means I add a new tool to the whole thing, or that we focus on eliminating waste. In former times, my team did FinOps for cloud providers. They've now become an own team, or an own company. This was not our intent, but every company we went into, we could cut costs by 50% just because we are there. Eliminating waste. If you do the platform from the beginning right, you don't need to cut costs. Your costs are already where they are. They are perfectly aligned with your demand. If you do not focus on that, your costs go on overspend. That causes often also harm and problem, obviously, for the platform and infrastructure which you are providing because it's eating budget. Sometimes, even as an engineer, it is helpful to think a little bit in economical aspects.
If we can reduce the budget a little bit, we have more money somewhere else to do more cooler things. If I have to hire someone or buy a tool for it, fine, but the budget is there to do that. There are a few ways on how to do, actually, with the principles, and that's more a recommendation from my side. You can form we will principles. Those we will principles have the actual aspect to cause a unity. We all together as a platform engineering team are going to drive transparency for the resource consumption. Sounds better than eliminating waste. Eliminating waste sounds like someone tells me to take the trash and bring it out. That's not an awesome job, but saying, we all together, we want to make the people aware of what they are using and how much they are using and that they can make it better.
That's actually a good thing. The other way to define principles is you must. Don't prescribe specific ways, but guidance through best practices, or provide full transparency of deployments with a fine-grained access to operational data. They are not extremely strict in the way of formulating. I know organizations who are really like, you have to do X, Y, Z, but then it's not a principle anymore. Then it's a directive. A directive is a totally different story. If someone tells you what you have to do immediately, it's not a principle you can follow because principles usually have to align somewhere with your personal perspective too. That's why I always recommend you need to mix something between we will and you must principles. The musts are more the things where you need to push people into a direction, and the will is where the people's unity is laying, where your team's personal interest is laying. This is a mix of both. You can actually emphasize for everyone to consider principles to do that.
Another perspective is that you need to be aware of the drivers. It's not always you who decide in which direction you have to go. It's very often suddenly coming from someone with a way higher title than your team lead or your product owner, and says you have to do that. This is a strategic driver often. I'm not so sure how strategic it is, but it's reality in enterprises, given by management or given by a partnership that you suddenly have to use a tool which you didn't want to use. You have the partnership. You get it a little bit for free, so use it. It doesn't suit the problem. It doesn't help you to build a platform, but you have to use it. What you often underestimate is also personal drivers. This is what companies often do not like to think about or try to dig into, because personal drivers really means personally.
Maybe you have ethical concerns. Maybe you have a moral perspective where you say, I don't want to support this, or I do not want to use X, Y, Z tool because the owners are investing in something I do not like. It sounds stupid, but you really can sometimes kill the motivation and interest of some individuals of your team to use something they really do not want to use. We have seen these frequent times that someone says, no, are you not going to build this into? Yes, but you're the security expert. I don't care. I don't put this tool into. I do not support the political orientation of where this company is located. It sounds stupid, but it really can harm the development of a platform. Sometimes it's good to understand when do you get the best out of your people and what actually drives them to do that, and where is actually the border where they do not want to do it.
Market drivers is like everything that doesn't come from your management, but which comes from, for example, the open-source community that you have changes in licenses. You had a few years back a few open-source products which suddenly didn't have the open-source license anymore and were accidentally a business license agreement, putting a lot of companies in trouble. Could also harm your platform, change the direction. Or, that you, for example, focus more on local solutions than international solutions. Europe, or especially Germany, you have a lot of the sovereignty push at the moment that could also drive, for example, what are you using. That can go sometimes even more crazy, saying, the majority of this open-source tool of the contributors are not located in Europe, so it's not really European. I have heard already this discussion. I found it a little bit too much over the top, but sometimes you have to deal with that.
Then, obviously, you have the data and insights for analysts, insights and reports. That's my most hated category, but it's still often the driver because that's what the management is buying, but that's also what our providers are buying. No provider on this planet is ending up in a report because they have not paid for it. There's no product which is so good that it needs to be named in a report. You always have to pay for being in the report for reasons.
The Importance of Purpose
The last aspect, and that's what all platforms we have seen so far are really missing, is a purpose for it. That someone found a statement why we actually need a platform. It's the same thing like why you need Kubernetes, for example. It's a complicated cost overhead. It's expensive, and so on. The same discussions we have actually with platform and platform engineering. It's repetitive in those regards. If you do not have an answer for what is the business value. Why, for example, a user can really need it, what does it help for them? Or sometimes we have even questions, are you sure you can build that? Are you technically able to do that? Because it sounds like a dreamland sometimes. For this, we need to always discuss and that's also something which I love to highlight, is really, you need to define the purpose for the platform itself: for which reason, for which user, why we are doing it.
That purpose can change. It's not a vision. It's not a mission. It's a sense why you have that. In addition to our book, we've defined The Platform Engineering Purpose Canvas, which you can just get for free on Miro, for example. Just to very shortly show you because it's super simple, it's nothing else than try to ask your people like, which different people and roles do you have in your organization? What are your actual targets? What are your values? Most companies are not sure what are the values of the people, and most people are not sure what is the value of the company, which is sometimes surprising. You're working for a company. You're dedicating, you put the name of the company under your name on LinkedIn or wherever else, but you don't know what is the value of it? Sometimes you should take some time to understand your employers more.
You see here the principles are coming in. KPIs, we will talk about it. You need a product mindset. Stakeholders and strengths in development areas. All of this together can lead to finding the purpose of your platform. You sometimes spend just a day or two days with architects, with product owners to discuss about for which reason you want to do that. I would like to earn my money. I can always say like, the platform will solve all of your problems, but what does it help me if you build 6 months, 12 months as a platform and then no one uses it because we completely missed everything? It doesn't help me. I will lose a customer. The customer will lose a lot of money. The people who are responsible for deciding it, they will get cut off one part of the head. Yes, everyone is a little bit unhappy. That's a lose-lose-lose situation. If you define all those processes around and you're very aware why you need to do something, then you're more likely to go to a win-win-win situation, because you always know what to communicate, to whom to communicate, what, and why you're doing it. Internally with your team and externally with your stakeholders.
Key Performance Indicators (KPIs)
What we're also quite often missing is that companies don't measure. They just don't measure. They're missing KPIs. It happens that they start measuring the performance of a platform after the platform is, for example, available. Against what do you compare those numbers now? I cannot define the success of a platform if I start measuring how good it is after I've implemented it. It's maybe a feeling. It's a subjective report. Maybe if the platform will improve over time, which we always recommend, so you start with the thinnest viable platform, one, two little features that really can help, and then go step-by-step with the new features. You should see always improvements. That's not the point. You also have a time before the platform was actually there. It's good to understand like, how do you measure the success, for example, amongst the active users? For example, Toyota invests a lot of time to understand how many people, for example, are using the documentation which was written.
The answer is almost everyone in IT uses the documentation provided through the platform because it's easy. Before, it was distributed. Hundreds of repositories, a website here, something there, something in the intranet. No one cares where to find the documentation. Now you go to an app, there's the documentation. You use it. Thumbs up. Awesome. How do you get transparency about its usage? How is it used? Do people really use, for example, a service catalog? If so, what is the most used service? We need to change a little bit the mindset again. We come from an engineering perspective, and we talk here really about the product. We need to understand the people, how and what they are using, and not just throw a feature. What is relevant performance information? I add here the time-to-market in quotes, because very often platforms are also just used for internal products or internal solutions, but actually also they have a time-to-market.
How long did the team need from, I need something to solve X, Y, Z problem, to, here it is deployed internally for production? You still can measure a time-to-market, even so you don't go for a customer or something like that. How do you know that a platform is desired? Trace, for example, the shadow IT. It was one of my favorite jobs when I was enterprise architect to find out, who has which server standing under which table, or nowadays, who is using his private credit card for which cloud provider and is expensing it every month. If you spend some time to find out the shadow IT or maybe you're even checking it, if you're successful with a platform, it goes down. We have one larger Telco customer where we saw after a very short time that the expenses for external IT services have drastically dropped, because suddenly they had internally an answer to their problems. It was even not finalized. It was just solving one, two problems which they have identified on the road to actually build the platform. It was so helpful for them that they more or less cut a huge amount of the shadow IT out of it.
What you will often see is like, use the DORA metrics for that whole thing. I'm not a fan of it. Yes, it is nice. What most organizations are actually doing is like evaluating your team's performance based on DORA. In the end, someone comes around the corner and says like, your code, which you deploy, you need too long, develop faster. The amount of features which you have put in these last two weeks' sprint is too less, make more features. Or, you have too many failures when you deploy. Yes, obviously, if I increase the pressure, if I want to have more features, so I reduce the actual time which I spend on writing code, the quality drops. Everything can have a reason. DORA, which on the one hand, it is good meaning. If you see that management get it into their hand, it's a weapon, and it usually stresses out teams.
Teams actually very well know how much they can develop, and they know how much time they need to produce qualitatively high output. It's not always understood by people who didn't code for a very long time. Are they helpful? Yes and no. They're helpful for understanding your team performance for some time, maybe you raise awareness that you have to improve something. I would not give too much to them. Wrong hands can lead to a lot of stress to the team.
I'm more a fan of the SPACE metrics, but they necessitate also that you have to do a little more effort. SPACE is more looking into the satisfaction, the performance, activity, communication, and efficiency. Another Packt author, Michael Kaufmann, has put this actually into some nice dimensions. That's why I like actually the SPACE metrics, because it's not about just like a very high-level view. You can do that per person. You can do that per team. You can do that per system. The system in this case would be, for example, a platform. The thing is you have to adjust a little the understanding for it. When we talk about performance for the individual, having a code review velocity. For some people that can be a really stupid metric. What do you want to evaluate? Five people have developed an extremely complex piece of software, and then after a week someone comes to you and says like, you need a very long time for reviewing this piece of code.
Yes, 50,000 lines of code is not something which you do overnight. You always need to put them into a relation, and that's why actually those metrics are helping to understand like, ok, a team has shipped a lot of code, and the person whom I measure for the review of this code, this is correlated, this depends on each other. The more code I ship, the longer I will need for the review. Simple. If I look in the SPACE metrics, I don't have that. That's why the SPACE one is actually quite interesting to do, but it really needs some time to set up probably, and it needs to change from time to time. It's helpful if you have someone in the team who's continuously working on it, try to understand if you measure it right, maybe change how you're measuring it, maybe drop some KPIs or postpone them for later. It's totally fine. You need sometimes also some clearance internally.
However, what I think is even more helpful is for example the DevEx metrics, and they are more about the flow. They're more about understanding the end users of the platform, and how is their experience. For flow state, we have metrics like reopened commits, and change requests, and commits per pull request, but this is the thing which you can measure. Then always on top comes the personal feedback. You have to go into the field, or into the office, and hunt down your actual users on the coffee machine, or somewhere else, and ask them a certain amount of questions. Do you like that? Do you feel comfortable using it? Does it really help you? What would you like to change? Those are the things where you actively need to go into, and it sometimes can be annoying if you come back, and back, and back again. It's the only way you can improve your platform, because numbers can lie.
Two numbers which look like they're correlated, don't need to be correlated. It can be just an accident that it's like this. Cognitive load, I would say almost an overloaded term to use for it. It's just like, in my world, everything which comes on top to my work, that makes my life a little bit more difficult, which make me think about other problems than the actual problem I want to solve. Also here, we can find out like, in a feedback, how often do you need to switch context? If you spend some time more on understanding cognitive load, it's quite an interesting science behind it, if you take the science aspect. Who of you have, on the day, let's say, at least three meetings that may be just 15 minutes long? Three meetings times 15 minutes is 45 minutes. Do you know how long your brain is busy with that?
For every 5 minutes you are disrupted, you can add up up to one hour where your brain is still processing information. It's almost impossible to shut down your brain. There are a few techniques where you can stop your brain overthinking. You can start randomly counting some stuff in the room, for example, and a few other ways of trying to break down your brain. The reason, quite often, why people are too late from one meeting to the other meeting is not because only the one meeting took so long. It's also because it's hard to go to the next one and then think, now I'm talking about a completely different topic. I know it from myself. I'm talking in the one minute with a customer and try to pitch something, and then literally a minute later, I jump into a call with my team leads talking about personnel and hiring requests.
If I had here a bad meeting, what do I bring there? It cannot be good. I will come feeling grumpy, into that meeting. It's almost impossible to change it, even though it's a completely different environment. Your brain sticks with it. Then you have, also with everything, what is around in your daily use, that increases your cognitive load and makes your brain stuck, and you cannot move forward. Then, that you all need to put into a feedback loop, and this feedback loop, again, can be very mechanic, can be measured. If you like the outcome of deployment, give a thumbs up. Easy-peasy, you can measure that. Even that's sometimes a feature in some of the tools, but you can also, again, make interviews and collect subjective feedback. Get information. Only written feedback is good feedback. Everything else is often a direction or a little bit noise sometimes.
Insights - Platform Adoption KPIs
Going into the last part, actually, is to talk about technical debts. It was listed also in the beginning of the slides, why often platform adoptions are failing is because of technical debts. It is linked, actually, to a couple of things that are relevant. Feedback loops, we have talked about enough. Collecting subjective feedback from people. User research, maybe I didn't underline it enough, but you have to talk to the people who want to use your platform. You cannot start making a restaurant and then you find out that soy sauce with tomato ketchup doesn't fit together. Test it before. You have the iterative design aspect, but I skipped today the architecture part of it. For the user research, just to emphasize it more, ask about the current tooling. How does the current workflow look like with that? What do you think the migration effort looks like from one tool to the other?
What are the existing gaps? What would be the ideal workflow? Five questions which you can ask if you start building a platform. You do not ask about the exact tooling itself. You ask which tools they are using, but it's more about the functionality which you're looking for. It's simply just to get an overall picture, what does the day-to-day life look like? When we make an interview, it's always one of the questions which we get from someone whom we interview, how does your daily work look like? If you have an awesome platform, you can say like, easy. I have a solution which we can go into. We see how is the current project state. I see if something has failed. The tool I'm responsible for, I have a simple dashboard for it. If I want to develop a new feature, I can start it out of one tool.
You can describe it. What is the most description in companies about how is your day-to-day work like? I need to report on a daily what I will do and did. Then I need to find out what I actually should develop today, but I think I have a bug from yesterday and so on. Platform is not solving all of those problems. The message here is like, problems are caused because of people and processes and not because of the technology itself.
Implementing the feedback loop is hard. Most companies are telling me, yes, we do regular feedback meetings. I always get, once in a year, feedback from my team. Once in a year, how fantastic? I know companies who ask their employees like in summertime, how they are doing and what's going on, which is a perfect time to do actually a quiz or feedback, because in summer people are happier. Usually, you get the results a couple of months later because it's difficult to condense 15,000 feedbacks into one useful thing. Most companies don't really do feedback loops. It's because you have to do it from the team who's responsible for the product. It doesn't help me if some organization very far away is asking 50 different questions, and one of it is, are you happy with your tools? Yes, which tools? If I at that day have a problem with my VS Code, then I will write into it, no, my VS Code is shitty.
If I had that day a very lucky experience with Claude, like, yes, Claude Code is fantastic. It's always like this one-time snapshot. If you ask continuously, then you will get a more full picture. You have one feedback here. You have another feedback there. It can be like one day a tool is good, other day tool is bad. Feedback is moving because we're human beings. We do not make a summary out of our experience of the past life. I'll make a summary of my day. If I have a bad start in the day, I have a bad day. You will not change it. Every meeting I'm going to have for that day will be bad. If you're consciously aware of it, you can avoid it. Really have a look into some stuff like, what works, what doesn't work? Why did you do anything that you thought of not to work?
A little bit more complex thing, give people something which they have to process through. Don't ask yes and no questions. Do you like that tool? Yes, good. It's my normal statistics. Thanks for practically nothing because next day you cannot like it. It doesn't help me. Get feedback. What do you want to have better? What do you like? What do you want to change in the future? What are your requirements? Will they change? Is there a new project coming up? Yes, we start the next AI project, please put something into your platform which supports my development of AI because we don't have it. Stuff like that.
Then you have to manage actually the technical debt. This is very hard because most companies have a problem with this sunk cost fallacy. It has a very stupid economical reason. It has something to do with accounting and taxing. If you have invested the money into a product, you need to use it until you get all your taxes back. It's such a German thing, but it's so stupid. If you have invested time and money and effort, you build up the value for something even if it is completely useless. No one uses it, but you have to keep it there, keep it running until you get all your taxes back. Because else the account office will be very mad at you. Never make your accountants mad. That's a stupid idea. They also can find other ways to get your money back. There are a few ways you can approach this.
The one way is to be very careful in defining the requirements which you put up, and do things step by step. You start with the thinnest viable platform and build up carefully one feature after the other feature. This will hopefully cause that you do not have too much technical debt. Because we are on Kubernetes, most of the time you will have very fast, after one year, a lot of technical debt. Because you also need to maintain, you need to update. Maybe you need to remove a tool because suddenly the contribution base from the tool is gone. You have to implement something else. The challenge is that the people who are in charge need to understand that all of that thing is more like a living creature and not like a bed on a block where you put all the time some more concrete on top of it.
That's not how it's working. It's more like this FIMO, children time where you have this squishy mass which you can form and shape and so on. It's more like that. It's difficult to talk to management and say like, listen, we have invested half a million euros in the last 5 years and now we will throw it out. That's not a good message. Find a reason why you have to throw it out. That's my message. It causes more harm than it brings me value, for example. That's why you need depreciation criterias. It helps you if you define from the beginning for every platform which you're doing the same way how you define a purpose, you also need to define when something is trash. Not just the metrics of the user feedback but the actual subjective user feedback. If an overwhelming part of people say like, the workflow is horrible, it costs me more time, the tool is bad, outdated, I don't like the UI, I don't like the CLI, whatsoever, you have to dig down to it.
You need to find somewhere, the point where it's very clear for you and everyone in the team, ok, it's bad, we have to cut it off and make something else. Because it's a product, it's not a project, it's continuously evolving. Even if you have something which you really love but if everyone else hates it, maybe you need to jump over your own shadow and also start hating it and get rid of it. Depreciation criterias are the same and important as, for example, the purpose and the KPIs for measuring it, and get all the people on board.
For my message, what you should take from me is like, platform engineering is not about the latest Kubernetes. It's not about the latest tools and technologies. It's not about Backstage which a lot of people get confused about with platform engineering and IDPs. It's not about the GitOps practices or rebranded DevOps team, on the worst case, an infrastructure department which now have to build a product, that's not all platform engineering. Platform engineering is defined by all the people who are working in it and really spend time to work with the people. It's about the culture, the company culture, understanding it, but also shaping it, because platform engineering is very often also a cause for InnerSource, sometimes for open source. Inviting other people to help to improve the platform. It's defined also by the purpose, and everything else that you can think about these technical layers in between, but not necessarily the technical layers. That's not where the platform engineering is successful.
Summary
As a little compass, just to summarize a little bit of everything, clear purpose. User research, this is the hard part. If you don't know how to do that, get help. There's a lot of resources on how you can conduct very effective user researches. Technical debt management. The imperative of change, this is something which you need to make clear to your management. The only thing which is continuously there is that you have to change something. Nothing will live forever in a platform. Even Kubernetes, also it's the same name, it will change over time. Not that drastically but it will change. Build a community that's for the most customers who are very happy and successful with their platform, the lifesaver or the game changer. As soon as they're inviting other people to contribute some stuff into their platform, the adoption rate and the happiness rate increases because they're like, "That's a fantastic idea.
Thank you very much. Here is a little Amazon voucher," whatsoever. It's not about the Amazon voucher but it's just about like saying thank you for something that has more than value. Also, a lot of the people saying like, "I'm open for your feedback, I'm open for your contribution, and put it into my product which I take care of. I'm open to your stuff." Challenge Conway's Law. It's very difficult. The form of a platform is following the processes of a company. To change that is super hard. Build a platform with an ideal workflow and adjust the company to follow the platform workflow. That's a journey you can calculate a couple of years into it. You need change management and so on. It's one of the effective things which we can see. Establish the principles, and measure and adapt.
Final Note on Platform Success
With that, that's why for me the big message is that the success of platforms isn't in its code. The technology doesn't matter so much. You can use any tool. If you like Flux or if you like Argo CD, who cares? If it does what it should do and it deploys the tools where it should be, and no one has to complain about it or there's just one single complaint about it, you're in the right direction. You will fail with your platform engineering activities if you just focus on the tech to make it technology-wise very cool, but you ignore people, culture, and process. Then you will fail for sure. If you want to have way more of this stuff, we have everything in our book, "Platform Engineering for Architects."
See more presentations with transcripts
