How we won Atlassian’s Partner of the Year (and what it means)

[Kalle] (0:03 - 0:08) Why is security the problem? Security isn't the problem. It's actually the way we approach security.

[Darren] (0:14 - 0:22) Welcome to the DevOps Sauna, the podcast where we deep dive into the world of DevOps, platform engineering, security and more as we explore the future of development.

[Pinja] (0:22 - 0:32) Join us as we dive into the heart of DevOps, one story at a time. Whether you're a seasoned practitioner or only starting your DevOps journey, we're happy to welcome you into the DevOps Sauna.

[Darren] (0:38 - 0:58) Welcome back to the DevOps Sauna. Back in April, we got some interesting news from Atlassian at team 25 when we actually won partner of the year for world-class software design. Today, we're joined by our CTO of managed services, Kalle Sirkesalo.

Hello. And of course, Pinja is joining me.

[Pinja] (0:58 - 0:59) Hello, and welcome Kalle.

[Darren] (1:00 - 1:19) So I think the elephant in the room, the part that confuses me is why did we win this award? That sounds much worse now that I say it out loud, but we are not a software design house. We don't code.

So it might be difficult for some people to understand what we're adding to the software development sphere.

[Pinja] (1:19 - 1:46) And it's not like we're saying that we should not have been the winner of the partner of the year award, but we're now talking about the category called world-class software development. And I guess we're not still a software house. That's not something that happened overnight that we just didn't realize.

But Kalle, how do you see the contribution that a consultancy, DevOps consultancy house like us, for example, makes for the software development that others are doing?

[Kalle] (1:46 - 2:52) So I think it starts from the whole thing that what's Eficode's vision, and it's the future of software development. So we are here to create the future of software development. We are not here to create the best URL service management experience or best Atlassian experience.

We are here to make it available for the creation of software. We're here to develop best-in-class software for everybody. So we're not really developing software, but we're helping customers develop world-class software.

So if we were developing software, we could only impact a handful of companies with the same amount of people that we have. But when you are working with us, we are really helping the whole organization to transform. So we might have five different organizations transforming to become the future of software development.

And that leads to us having a way bigger impact than we even think about it ourselves. So if you think about it, for example, through cases that we are helping customers, like for example, Daimler Truck converting their whole tool chain around while being separated from their parent company, because they were split in two. And comparable, we are here to change the world by doing better software, but not developing the software ourselves.

[Darren] (2:52 - 3:00) So it's helpful to take a wide view to understand this award, to kind of see the bigger picture. And I guess that's what we're striving for.

[Kalle] (3:00 - 3:59) The whole aim isn't to make good software from our side. It's to make everybody better at software development. Because no matter how good you are at software development, you're one person or one team doing software.

Versus if we can actually help those teams across the world, it becomes really effective. And we can really improve how they look at making software. Especially now that we're looking at the whole AI creating a bunch of different agents, a bunch of automation, it becomes this massive thing where anybody can create software.

Anybody can create a new thing that runs in production. Then the question becomes, how do you actually make it so that it doesn't become a pain in everybody's life? How do you make it secure?

How do you make it so that you can orchestrate these things? How do you actually like to get those ideas that now can go to production from ideas in a single day? Shouldn't probably, but can go.

How do you get everyone in that alignment to work better? And that's what we're here for. We're creating those rule sets.

We're helping customers and really making better software.

[Pinja] (3:59 - 4:41) And if we think of the reasoning that Atlassian gave for this award for us, they said that we have made contributions to their customers, Atlassian customers throughout the last year. And we have showcased the innovation, expertise, and dedication to delivering these solutions that must be, of course, transformative, as you say. And I'm thinking of the whole chain of what does a software development take?

As you mentioned, it's not just one person, it's not just one team. But if we think of the whole, let's start from building code, building the CI/CD, so the excellence and the delivery to actually going into being a team of teams, a cross-functional organization and having a technical excellence to it. I guess that's the whole thing that we need to think about when we support our customers.

[Kalle] (4:42 - 7:24) Yeah. So I was at the conference last week, actually. And most of the time when I was talking to the other speakers and the other CTOs and those people, we weren't really talking about technology anymore.

Technology is an enabler, but the reality is that no robot is going to buy your software at the moment. We don't give our robots our credit cards. So what ends up happening is you still need to make software for people.

And the whole thing is you need people to make that software because robots don't yet know, why would I buy it? All of you have probably seen how YouTube has an amazing algorithm, but it's not the greatest. They need to tweak it all the time because we as humans change our view on videos and people and how they make videos.

We get bored. We don't like the same thing that we used to like. We want a change.

We want to like, if you make it into a process or a program, it's a good thing for a short period of time for us humans. But reality is that the team behind it has to constantly keep changing it. So if you look at like soft game developers, most games don't look like what they looked like 10 years ago.

They keep changing constantly because we as humans otherwise get bored. Like there are very few people that like playing chess as chess. Like they start adding a chess clock to it.

Then they start adding like other timing limits there so that you can add more challenges, more new things in it. Because you get otherwise bored on these things. It's the same thing that software developers have to solve for software.

Like when the customer is buying it, yes, it can solve that one problem. But if you only solve one problem, you might make from the same pool of people the same amount of money every year. But that's not going to grow you.

And as we have all seen with inflation, not growing your business is basically a death sentence. I guess that's a roundabout way of saying that you really need to focus on the people and the ways of working so that they can deliver the best possible excellence. And on that side, like for example, we created an ethical Root connector that connects the data from Atlassian, Jiras, GitHub and so on.

And gives us visibility on what you are doing correctly. What are you not doing correctly? And like trying to help you again, programmatically approach the thing that like, okay, this is your bottleneck.

Let's figure out how we can improve that? Like let's come in and coach you, for example. Or let's look at it from the point of view, what can we change in the process?

Why does the approval or policy step take so long? Why is security the problem? Security isn't the problem.

It's actually the way we approach security. Because we are sending them an unlike, we didn't make our risk management. We didn't make our plans.

We didn't actually think about the software from the security point of view. So then security becomes a problem because they have to do all that work for us. Whereas if we send it to them, Darren knows, right?

If I send him a risk matrix and risk description, it's pretty easy to say, okay, because it has quite a lot of explanation already. Why? What are we doing?

And how am I mitigating risks? Whereas if you said to him, I want to open an iframe, you don't really make any decision on that.

[Darren] (7:24 - 7:56) Yeah, sorry, just flashbacks. These extremely ill-defined requests coming from various places and digging. There's actually this weird industrial dissonance that's happening at the moment.

So you were mentioning how the idea is to impact the people who are developing software. And then we also are seeing this, as you've mentioned already, this dive into AI. So there are these kind of two things that people might see as opposing forces that are kind of occurring.

But to me, it feels like the idea is to pull those together.

[Kalle] (7:57 - 10:03) Yeah. So the big thing there is that, like, we can call it like removing jobs, but it's the same thing that happened when we invented industrialization. Like, we removed jobs.

Like, everybody thought that, oh, my God, everybody's going to be unemployed. We're going to have so... These factories are going to solve all of these artisan works.

News flash, programming has been an artisan's work where you are amazing at, like, being the master, and you have the apprentice, and you go one by one, and you have to have one master, one apprentice. And then you scale up bit by bit by years of repetition. Same as we did before industrialization.

And now we're on the verge of actually becoming more industrialized. So we're making more software than ever. And it's going to affect everything in our lives, because we can make more software.

The sad thing is what I'm seeing is that it's going to increase the amount of experts we need, because we're going to create an exponential amount of software. Like, anybody who remembers, we used to have this thing called the World Wide Web, which was WWW. That was Web 1.0. Web 2.0, we are basically, if you ever look for information, you go to Reddit, because if you want to meet your friends, you go to LinkedIn, Facebook, Instagram, whatever, and you message your friends. When I was young, we used to go to forums, and you had 50 different forums with 50 different accounts. And you were talking to many other people to find the people that were interested in your topic, because there was no central place. And I see that AI is going to fragment that now again, or centralize it, it might go even more central for a moment.

But because we can create so much faster, and so much more, it's not possible to follow the amount of software that's going to come out like it used to be. Like, you can't, as a Facebook, implement every single feature that somebody is going to invent everywhere, if 1000 people are competing against your 100 engineers. So they need to keep hiring if they want to compete.

And the big thing is there, when we create this software, I have this love-hate relationship with Kubernetes. I love technology. I love the whole idea behind Kubernetes.

It's a fantastic API machine. It's a fantastic engine. But then you go into business, and you're like, you're a startup, you have five employees.

Why do you have a Kubernetes cluster? Why did you do microservices without your first customer? How did you prove that there is a business case for this?

[Darren] (10:03 - 10:09) Yeah, I think Kubernetes had an issue with it basically becoming a buzzword and being used for the sake of Kubernetes.

[Kalle] (10:10 - 10:45) But now, imagine if you have 100 agents running on that Kubernetes as the day one, because you create every day a new agent that automates one flow. Now it's actually very useful for anybody, because they can easily put AI workloads running on it. So it might actually be that Kubernetes was ahead of its time, even though it's now even still rising, because we're going to be orchestrating so many of these AI machines.

And that's what we're working on here in Eficode. We're trying to solve these kinds of problems before they become problems by helping you orchestrate, helping you create the security lanes, making things better, and at the same time, increasing your communication across your organization.

[Darren] (10:46 - 11:10) Yeah, I think we've characterized them as the DevOps guardrails, the idea of having like the jobs are going to switch, they're going to become more in the verification of things, more of the understanding what an AI has created, validating whether that is first off same, but secondly, useful, and, you know, switching things over to where we would see progressive delivery currently.

[Kalle] (11:10 - 11:52) Yeah, I think that's what we're like, again, very much what we're saying everywhere, and very much the whole thing. I think the bigger question then becomes like, how does Atmosium fit into this? And that's where we really like to start to see the feedback groups.

So when you have customers outside, like 10 customers, how do you get the feedback back to developers? Well, you need to create some kind of like service desks, so ITSM solutions that we've been doing, you have to create some kind of automation for task management, Jira side, processes on scaling across the company, again, Jira, finding documentation at the 3am Confluence, calling somebody, Opsgenie, and all these kind of stuff that help you get the feedback group from production to developers, or the product managers, or anybody else related to the process.

[Pinja] (11:52 - 12:22) This is the human interface of things. And Atlassian tools, that's the thing that they're so familiar and so widely adopted, that they are perhaps the first interface that somebody sees when they move into development from perhaps a non-technical perspective as well. But now that we see AI being on the rise, and the feedback loops are getting just shorter and shorter all the time, having that, let's say, the aid for the human mind to be able to see where the feedback loop is coming from is perhaps one of the crucial things here.

[Kalle] (12:22 - 12:55) Yeah, and also being able to show the manager all of the work that comes in. Like, if your AI agent is bad, and you want to refactor it, how do you prove to your manager that it's bad and you need to work on it? Well, it's Jira tickets.

Like, from the service desk, you pull out the tickets, and you're like, this is how many Jira tickets we got because of this bug. Let's start working on it. Like, this is like, it's going to take this much time, but it's going to solve all of these issues.

And that's the easiest way of communicating in a corporation, when you can actually solidify something that is like, otherwise, it's a big, but if you can convert it into customer problems or money, it's always easier.

[Pinja] (12:55 - 13:31) And we're also talking about maybe the, let's say, the readiness of the organizational side to adopt these tools. To me, sometimes it seems that people and organizations are very keen on solving the problem just by adding a new tool. I heard that somebody else is using this, somebody else is using AI agents, but that's not the real issue, right?

So, we're not going to achieve better software development just by adding Atlassian tools, by adding GitHub and adding GitHub Copilot and adding new agents. But that's sometimes it kind of seems that it's the easiest way out before actually seeing that it might be an organizational or human problem there in the background.

[Kalle] (13:31 - 15:20) And so, the big problem here is that most of us engineers forgot why we got into the industry after learning how to program. So, we were really interested in creating web pages because we could see something moving on the screen. We made games because you could make something move on the screen.

We were creative people. And then we learned how to program and we realized technology is really cool. And we forgot that, hey, it's not the technology that was cool.

It was showing your mom, for example, look at this pixel moving across the screen. I made it do that. Or look at this guy who made really cool water physics.

We forgot all of that in our lives at the moment. And we are so focused as engineers that like, oh, I need a bigger tool. I need a better tool.

Google is doing this. I should do it. But the reality is that like most of the time, I'm doing this DevOps toolchain analysis for customers at the moment.

And GitHub had a research that said 72% have more than six tools in use in their development pipeline. I was like looking at our Root customers. I was looking at our Managed Services like DevOps tooling customers.

And I was figuring out like, ain’t no way someone has only six tools. Like there is no way of building these pipelines with just six tools. Like GitHub has to be wrong in this research.

So I then started doing DevOps toolchain analysis to customers. I've done now like 50 of them or something like that. I have found zero customers that have less than 20 tools in their pipeline.

Because it's just ridiculous how many tools you need to make a software. Because when you start thinking about what you need, you need something to log in. Okay.

Azure Entra maybe. You need something to start writing things. Okay.

Your ID. You need a Copilot for it. Or you need Duo for it.

Or you need a Cursor as an ID. You need GitHub or GitLab or Bitbucket or whatever version control tool. Then you need a CI.

Maybe in GitLab. You need monitoring. You need cloud.

You need crowd resources. It gets ridiculous how many things we have in the tooling space. And that's why we feel like it doesn't matter if we add another tool.

Because there are already like 100 tools in your pipeline. And you're just so used to it.

[Darren] (15:20 - 15:43) I think that's where it comes down to the idea of platform engineering or what we expect from it is to maybe not reduce these tools, but abstract them away. So obviously if everyone needs to learn all of these tools, you're going to have a massive problem. But if you have a platform team to focus on these tools while the developers can just develop, I think that's a decent goal.

[Kalle] (15:43 - 16:55) Yeah. And it's a fantastic goal. But the problem is that if you leave the maintenance to them, they bit by bit turn into your IT.

So what you need to do is make sure that your platform team is developing the new features, the new stuff that your engineers want and working with the customers in the field. So preferably even coming from the development teams as a virtual team and not being dedicated to the team. Kind of annoying not to have them dedicated, but that's why like, for example, we did the ethical rules.

So you can buy the tools as a service from us. And then like you have customers coming in and managing the tools on top of it and creating the features. And the secret behind that is no manager is going to pay your platform team to upkeep the tools because they're going to see it as a cost instead of creating the features.

And that leads to your platform getting old. And bit by bit, when your platform gets old, you start getting funding cuts and you need to spend more time in maintenance. That's something that you need to really start tackling.

I think I made a 40-minute video about talking about the maturity of DevOps platforms because like your platform engineering. Platform engineering is a fantastic initiative and it's really fantastic to do it. But if you're not maintaining a good connection with your management, they are going to start cutting the funding after they see the benefits that you promised.

And that's something that is difficult, like we try to keep your platform teams alive and push them forward.

[Darren] (16:56 - 17:49) Interestingly, it kind of mirrors this idea that we're having some problems also in the AI side of things with the quality of data. And it seems like this is about the buy-in. So if you buy into platform engineering without any solid comfort level from the management, you're not going to end up anywhere.

If you try and buy into AI without a decent buy-in on data, you're not going to end up anywhere. And it all comes to this idea that we have to ensure that we're all wanting to move in the right direction. And I feel like that gets cut out a lot when we talk about tech, because these are like human decisions.

As you were saying, the AI can't figure out how human decisions are made yet, which is actually accurate because I don't think humans really understand how these decisions are made a lot of the time. So it all comes together in an interesting way to me.

[Kalle] (17:49 - 18:04) Pinja is here, but Jess, also in our organization, but Pinja is here in the call to explain how we do things like change management style and things like this. A lot of it boils down to how do you actually change the organization? And I'm not talking about ITIL change management, I'm talking about organizational change.

[Pinja] (18:05 - 19:04) And this is about the readiness to do things like does the culture support, for example, doing experiments? Because if it's not, that's a very key thing. Kalle, you're saying just earlier here that this is a creative craft, right?

This is a creative business that you're supposed to be doing. And if we do not allow people to make mistakes and do their failures and actually be that creative, can we have an experimental culture? And it's all about this, having that feedback loop.

Do we make things transparent? Do our tools support that? And does the way that we work support that?

And it's not about just like, hey, let's just add one more tool, as you say, somebody having 22 tools to do whatever. But do you actually use them? What are you using them for?

And does everybody even know that you're using it? And can something be done in a better way? Because that's, I think, as you said, it's about the people and not just about the tooling.

And that's what I think, at least, as well, the world-class software is all about.

[Darren] (19:04 - 19:22) Okay, so I think we've veered a little bit off topic from our original discussion. We received the award from Atlassian. I think we could take a moment to discuss.

We've already talked about what the next, let's say, five years are going to look like for Eficode in various places. But what do we think they're going to look like for Atlassian?

[Kalle] (19:22 - 20:23) So if you're not in the cloud, you're probably going to be in the cloud. That's been their message for everybody, pretty clear there. They're probably, based on what I'm checking at the moment and following them, they're probably not going to be that heavy on the developer side.

They're going to focus more on enabling business to communicate towards the developers. Because they've been left behind on the version control development or CI development. And the question is also, are those going to stay the same?

Is GitHub really going to be the platform that we build everything around? Or is GitHub going to be the platform? Or is AI going to develop everything so that we don't even care about what the source code looks like?

And nobody knows that answer for five years from now. We can say that in the next 12 months, yeah, we're going to need version control. Yeah, we're not going to trust AI.

But if you look at the massive changes in the world, we're really bad at exponential understanding. I think Atlassian is really going to focus on bringing together different teams, like bringing marketing into Jira, bringing finance into Jira, and integrating better those systems so you can have a holistic view of the organization. That's my guess.

Yeah.

[Pinja] (20:23 - 20:57) Last year, Atlassian introduced this concept called System of Work. And this is totally in line with what you just said, Kalle. Trying to get the organizations to just pull into the same direction, bringing in the visibility and bringing in the thread from that we have the business goals into developer actually creating the value and then pushing that onto the customer.

And of course, bringing in, as you say, the other parts of the organization, such as marketing and, for example, sales, to be able to see what's going on so that everything would be connected. So that's also what I've seen from Atlassian in the past year and what their focus area might be.

[Darren] (20:57 - 21:01) So it sounds a little bit like DevOps is trying to take over the world.

[Kalle] (21:02 - 21:27) That was kind of the goal from the beginning, but that was Agile's goal also. And Agile failed horribly due to the complicatedness of trusting humans. And now DevOps is trying to do it with automation.

And DevOps is kind of a dead trend in the sense that no manager wants to buy a DevOps project. They want to buy an AI project or a platform engineering project. That just turns into DevOps projects because it's the same thing that we keep doing.

It's still the automation, still the cartwheels, but we just call it a different name now.

[Pinja] (21:27 - 21:28) Exactly.

[Darren] (21:28 - 21:31) Yeah, it's the rebranding problem of DevOps.

[Pinja] (21:31 - 21:47) Yeah, that's what we've been talking about as well previously with Darren. Is platform engineering DevOps? Is DevOps taking over the world by just reframing it and now calling it platform engineering?

But I guess it's still safe to say that DevOps is needed, even if we call it something else.

[Kalle] (21:47 - 22:22) And we were talking in the conference how DevOps engineer is a dead term already. It's like, why would you ever hire a DevOps engineer? Because the whole point of DevOps is that you'd have developers and operations or the whole organization working together.

So why do you have a DevOps engineer? Is he the whole organization? No.

Is he the developer and operations working together? No. So it's an oxymoron title that we decided because we wanted to be able to hire to the latest hype cycle.

So now it's going to be the same on many other things. But the whole key is how do we get humans to work better with humans?

[Pinja] (22:22 - 22:42) We will have the tools still supporting us. We cannot get away from tools. And I think when we go back to the whole conversation of, yes, we won this award, yay, is amazing.

But also why we do what we do at Eficode is to enable people and organizations to work better with the tools that they have. Usually they're using tools anyway.

[Darren] (22:43 - 23:00) Okay, so there we have it. We're really focusing on the people in the era of AI, which is actually kind of refreshing to hear. And I think that's all we have time for today.

So thank you, I think, to Atlassian for giving us this world-class software development award. Thank you, Kalle, for joining us.

[Kalle] (23:00 - 23:01) Thank you. Thank you for inviting me, finally.

[Darren] (23:01 - 23:04) And thank you Pinja as always.

[Pinja] (23:05 - 23:08) Thank you so much. And Kalle, thank you for joining us, finally.

[Darren] (23:08 - 23:09) We hope you join us next time.

[Pinja] (23:13 - 23:18) We'll now give our guest a chance to introduce himself and tell you a little bit about who we are.

[Kalle] (23:19 - 23:36) Hello. So I'm Kalle Sirkesalo. I work as the CTO of Managed Services here in Eficode.

And I've been an Eficodean for 11 years now. I started by founding the Eficode Root product. And right now I'm helping customers make better software by selecting their tools correctly.

[Darren] (23:36 - 23:39) I'm Darren Richardson, security consultant at Eficode.

[Pinja] (23:39 - 23:44) I'm Pinja Kujala. I specialize in agile and portfolio management topics at Eficode.

[Darren] (23:44 - 23:46) Thanks for tuning in. We'll catch you next time.

[Pinja] (23:47 - 23:55)