Platform Engineering – Making Other Teams 10x Better

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today, I'm sitting down across many miles with Jessica Andresson. Jessica is in all the Swedish summer. Jessica, welcome. Thanks for taking the time to talk to us today.

Jessica Andresson: Thank you for having me.

Shane Hastie: My normal starting point is who's Jessica?

Introductions [00:27]

Jessica Andresson: Yes, I wish I had a really good quick answer to that one. So I'm currently in between jobs intentionally, but I identify as a platform engineer and also a leader of platforms. I've been doing both and looking forward to getting a little bit hands-on again, come this fall. I'm very passionate about enabling teams and accelerating developers and trying to empower teams to deliver a lot of value. I think that is something where you can have a big impact. That's something that I'm very passionate about. I'm also very involved in our local communities around cloud native, and I'm also a CNCF ambassador. It's a lovely community. I'm really happy to be a part of that and be able to help that community evolve as well.

Shane Hastie: Jessica, one of the things that we were chatting about before we started was platform engineering as empowering and enabling others. You in fact said this is the opportunity to be the 10x engineer. How does that come about?

Platform engineering is about empowering others [01:29]

Jessica Andresson: Yes, I think that it was a lot of talk many years now that everyone should strive to become the 10x developer, and it was a lot of pressure and did it mean to build more code? Did it mean to ship faster, or whatever did it mean? And there was someone writing on Twitter a while back that being a platform engineer was the closest I ever felt to become a 10x developer, and this resonated so much with me. So I think for my own leading star, it's not so much about becoming 10x of myself.

It's about enabling 10 other developers to help them provide the value they want to do faster and more efficient and removing a lot of their pain points. And I think being on a platform team and working with platform engineering, that's the chance you have to make an impact on that. As a platform team, we have always had the goal of empowering other teams to focus on things that they do to create value for their company or the organization. And so being able to help them to get there is really cool.

Shane Hastie: So what does a good platform engineering team feel like from a culture perspective?

Jessica Andresson: They are perceived from others as very approachable and helpful, I think. It's always a little bit of track of being helpful because you could always end up being a little bit too helpful and spend all your time just answering questions, et cetera. But if you don't have that approachableness and having people come up to you, it's very hard to understand the problems of the other developers and the pain points that have, and they need to be able to feel like they are not asking these stupid questions or at least that they can come to you with these stupid questions and not get dissed or something, because they obviously don't know the answer, and if you're going to help them, if you're going to empower them, you need to help them get to the point where they can solve themselves.

When it works really well, you should almost not notice that the platform team is there because the development teams should be able to do all the things they want to do themselves. I think it's very important to have this non-blocking self-service mindset. And so I think that a really good platform team is probably perceived as helpful but also not really there because everything's running so smoothly.

Shane Hastie: How do we create that platform team effectively?

Creating effective platform teams [03:44]

Jessica Andresson: I think you have to start somewhere. Everyone has to start somewhere. And when looking back on my own journey at Kognic, I realized that starting somewhere means that there is already a platform, because there's always an implicit platform even if you didn't plan for it, because if you're running software in production, you have a need for some certain common needs such as build time, CICD, runtime, observability, et cetera. So those that did not work with the platform explicitly, they try to make the things work out as best as they could, and once it worked good enough, they went on to building the product as they were trying to do from the start.

And so as a platform team, you have to figure out what is there, and then you can try to transform it and stabilize it and make it work more streamlined. And from there try to go on and build it up. And when it comes to culture and what leads us to a trust and adoption of your platform, I think, is that you need to show deep development teams that you can solve their pain points. You need to show them quite early on that you are there to empower them and not to restrict them or be the police of what they can do and not do. So making it easy for them to do the things they want to do while also making sure that you aren't blocking them so that it can move forward. And then you have to take one segment, make it work well, and then you take the next one and then you keep going. It's an endless repeat on that one.

Shane Hastie: So how do you build these strong trusting relationships?

Building strong trusting relationships [05:24]

Jessica Andresson: Actually, my partner Carl Engström, he used to phrase that trust is a currency and that you have to treat it as such. And so in turn then you have to use trust in order to gain adoption. And if we look at trust as something that we can earn or spend, we can look at what things can we do in order to earn trust and what things will we do that will cause us to spend trust, and then we can keep a track of that balance and try to make sure that we never reach a negative balance on our accounts.

And so some of the things that I've identified as something that can help you earn more trust is removing pain points. I know I keep coming back to it, but it's so easy to forget that in the daily life, the developers do things that they always think is slightly painful, but it's not painful enough that they are going to raise a flag or come screaming at you whatnot, but it's still slightly painful, slightly annoying, and it's repetitive. So if you can find those and you can remove those, then that will create more trust from your developers and build that relationship.

We talked about being approachable and helpful and I think that if you keep being approachable and you're keeping helpful and not be mean to people that ask stupid questions, they will keep coming back, and they will go back and they will tell their team that, "Oh, I had this issue and the platform team was super nice and helped me out," and the next time someone else in that team has a problem, they are not afraid to reach out because they knew that their teammate got a nice reply. And it doesn't mean that you have to always jump very fast trying to solve everything without thinking. It's just about, "Hmm, could you explain more about your problem? Ah, interesting. Now we'll look into that. I will get back to you," and then you get back to them when you have answer or not. It's about being treating all with kindness.

I think also if you are proactive while being approachable, you would probably hear things. The team stopped explicitly saying, "This is a problem," but you realize I can do something to improve this situation. And if you proactively do that to improve this situation, that will also help people that trust and create a better collaboration. And I think, so easy to forget, but understanding the team's perspective. They don't stick with the same technology as you do day out and day in. They have other things in their plans that they want to achieve. You're measured on different success rates. So understand where they come from, understand their perspective, and what they know and what they don't know, and that will help you have a common language when you talk, and that's very important in order to create a good collaboration and build trust.

And if we're looking at what you can do in order to spend trust, which I think is also easy to forget that there are actually things that will decrease the trust that the team's have in you. And I think that probably this one to understand it's like enforcing processes. In my experience, all teams hate when you try to tell them what to do, they always want to try to figure out themselves. It comes back to autonomy. I think that teams like to feel like they have the chance to decide themselves, but when you enforce a process or you tell them you have to do, like they see you remove that choice from them, and you're pushing them into a box that they did not know that they wanted to be.

Of course you can counter that by anchoring decisions and all those things, but still enforcing a process will cause you to spend some amount of trust. If it's much or little, that depends on how you do it. If you introduce blocking processes, I think you are also spending trust. If the teams can't do something themself, they have to go to a gatekeeper in order to get it forward, that's going to cost you. And it feels given, but worth mentioning.

Platform teams in general spend a lot of time on migrating and upgrading. We move it from one tool to another, we move it in a new version, some standard got deprecated, we have to get a new standard and whatnot. All migrations cost you, depending on how well you do it, depends on how much you spend on it. The best migrations are the ones that the teams don't have to care about at all. You sometimes you can get away if they feel like they're getting something extremely valuable out of migration, but it's still like a small cost, I would say. And I think diverse spending is probably assumptions. Like we are really good at our jobs, we know what the teams should want.

So if we make an assumption that they really want this thing and then we make it happen and they didn't really want it, then that's going to cost us a lot. And so we're back to anchoring change and understanding their perspective and all those things. So I think understanding the team's perspective and assumptions goes hand-in-hand.

Shane Hastie: You mentioned that platform teams have different success measures to product development teams. What are the important success metrics or measures that platform teams should be looking to?

Success metrics for platform teams [10:24]

Jessica Andresson: So I think that it's very easy to look at the DORA metrics when it comes to this. It's hard to implement, but it's easy to look at, because you have to figure out what those means to you. And so we have four main metrics or core metrics that I usually get to look at. So that is deployment frequency, lead time to changes, mean time to recovery, and change failure rate. And exactly how you measure those will be unique to your company.

There are some guidelines and some standards that you can look at, but you will probably have to make some slight adoption to your organization. But I think the important thing is not that you measured exactly the same as everyone else, it's that you measured exactly the same all the time for yourself and that you compare against yourself over time, because that's how you will figure out if you're making any difference.

I heard of a lot of people measuring things such as developer efficiency and developer happiness and those kind of things. From my point of view, it's probably not that easy to do, but we were playing around a lot with the idea of continuously sending out a survey. Kognic uses Peakon for employee satisfaction and those kind of things, and we had the idea that maybe we could send out something similar maybe every half year or something. We never got there though, because other things were very important.

Shane Hastie: The challenges in software engineering in my experience and what I see and hear are almost always people-related, not technology-related. How do we as leaders in that space engage people well to reduce those challenges as much as possible?

Most of the challenges we face are people challenges, not technology [12:13]

Jessica Andresson: As you say, the people problem is always the hardest one, and I find it very interesting to hear when I talk with other friends outside in other organizations is that we all seem to struggle with quite similar problems regardless of what product we are building. And so it's often comes down to communication, alignment, and all those kind of things that usually are the same that show up frequently. And I honestly don't have a good answer, I'm sorry, but I'm thinking working on making sure that everyone knows what we're trying to achieve, what direction we're supposed to go, and what is the most important right now, like alignment, that's something that you can start with.

And then working on how you communicate around alignment so that people have the right information when they need it and then they are not flooded with too much information that doesn't change anything for them so that they feel like ... Because you can end up in a state where you feel like a lot of things are changing while they really are not because of how you communicate, and the other way around where people feel like something needs to change but no one is doing anything, and that's because maybe you're having those meetings in a different setting with different group of people and you don't communicate to others. We're on it but we don't have the answer yet. So from my point of view, those are probably some of the hardest questions, and I think we will struggle with them.

Shane Hastie: A lot of our audience are people who are moving into leadership roles for often the first time. You've spoken about being an engineering leader and also being the practitioner. What are the big steps? What are the big changes when you move from that individual contributor practitioner into the engineering leader space?

Advice for new leaders [14:03]

Jessica Andresson: For me, I was very lucky because I had a chance of doing very gradually. So when I joined Kognic about four years ago, I was the first platform engineer/leader. There was no team. And so I started out very hand-on but also we trying out thinking about a strategy, trying to build a plan, hiring a team, and then getting started with a very small team while still working hands-on on the platform. And then over time, I took on more responsibilities and in the end the team kindly told me that they were not expecting me to contribute to the backlog anymore, also known as "Please don't mess anything up." And I think that was a very nice way of getting to know the different aspects a little bit at a time. And If anyone has a chance to do that, I probably would recommend it because I really enjoyed that process.

And I think something that I struggled with a lot at this pace when I was no longer hands-on in the team but still very much invested into what was being built technically is to not be able to have the full picture in my mind, because I was used to know how every system worked and how all things were connected together, and to go from not being able to do that while still being involved in the product and where it was going and what problems we were solving was very hard for me.

And I think also, because I'm one of those people that tend to have a lot of control over things around me, I know where all the things are in the house, I can pull up a lot of details from my mind, and not being able to have all that context was a bit of a struggle. But that's probably very personal for me. I think everyone will discover their own struggles. There's also so many things that you don't think about, like how doing salary review is probably more of a salary season than a salary review period for instance, and all those things that tend to be a lot more around the practical details of running a team of employees rather than building a platform. That's probably one of the reasons why I'm moving back to hands-on instead.

Shane Hastie: What advice would you give somebody who's stepping into that space?

Jessica Andresson: Probably try to figure out what you want to achieve. There was a great talk at QCon London 2024 regarding how to drive change without authority, and the speaker said that he wanted to get into management because he wanted to tell people what they should do, and then he realized that's definitely not what I should do. I should rather try to drive the change and try to influence people, because we are back to telling people what to do, it's usually not successful.

And I feel that if you try to get into leadership or a platform team or engineering in general, figure out why you want to do it and what you want to achieve with it, and then double check if your perception of what it means matches reality. What I did before taking on this role was that I had a contact that had done a lot of technical hands-on herself previously, and then moved into an engineering leadership position.

And so I asked her out lunch and asked if I could ask some questions about that transition, and ask all those concerns like will you feel like you don't connect to the lingo after a while? Like you lose connection to the technical aspects? Is it fun? Is it a lot of questions about handling conflicts? How do you handle those things? Because suddenly you have to do the things that are not fun as well because there's a lot of things in leadership that are not super fun. They might even be very hard, such as if you have big conflict or something is not working out the way it's supposed to do and no one else is there to handle it, suddenly it's your problem. When you are an IC, in most cases, someone is there to take care of those things.

So I had the chance to talk to her for a long time and ask all my questions and try to figure out what it would mean to be a leader and to probably voice some of my concerns and get some advice around that. And that's probably a really good advice if anyone is looking to move into engineering leadership, to try to find someone and have that conversation.

Shane Hastie: Where is platform engineering heading? What are the trends? What's next?

Trends in platform engineering [18:38]

Jessica Andresson: That's a very good question. I think it's just wasted hype, like the highest hype level. I know for sure that people have been doing platform engineering for a very long time, but I think it's just the recent two, three years maybe that we had the words for it so that everyone could share the same words for what they were doing, because a lot of people have been working with this for a very long time, and I've had knowledge sharing with other companies back before we even called it platform engineering. But I think in the future, it will probably have to try to deal with the awkwardness around what does platform engineering mean? What does DevOps mean? What does empowered teams and autonomy and all those things mean? Because right now, I'm a little bit worried that platform and engineer will follow the same road as DevOps did.

That means that you have platform teams, but they are just the new operations team with a fancy title, because that's a lot of what I feel happened with DevOps, to be honest. I think a lot of companies will be able to drive platform as it's meant to be. That means like internal developer platform, empowering teams to reach their goals, but also worried that a lot of companies will do a little bit of that and a lot of operations, because that's what they're used to, that's what always worked, and you always have these things that you don't have a better solution for, so why not just throw it on the team that seems that they get all those kind of things and that. Used to be the DevOps teams, in quotes, and now it might be the platform team, I worry.

Shane Hastie: So, hold the space carefully.

Jessica Andresson: Yes, I think so. And you need strong leaders with a plan, and leader in this case might be an engineering manager, it might be a product manager, it could be anyone, but you need strong leaders that can fight for maintaining the ID of running a platform team with the goal of empowering development teams. Because if you don't have that, you will end up being the sink where all the things go.

Shane Hastie: Jessica, a lot of good advice and interesting ideas here. If people wanted to continue the conversation, where can they find you?

Jessica Andresson: They can find me on LinkedIn and X and Bluesky. Mostly I'm solidtubez. I think we'll add a link somewhere because that's hard to spell. I'm happy if anyone would like to reach out. I love chatting about these topics, and I would really love to hear what everyone else is working on as well because these are a lot of my ideas. I think there are a lot of synergies with others, but everyone has their own flavor and you always have to adapt slightly to whatever situation you're in. So I think everyone has a unique story to tell about this.

Shane Hastie: Thank you so much.

Jessica Andresson: Thank you.

Mentioned:

• QCon London
• Jessica Andersson on LinkedIn, X and BlueSky