# Circle K EV Charging Organizational Transformation

**Podcast:** Software Architektur im Stream
**Published:** 2026-03-18

## Transcript

Okay, so welcome to another episode uh of uh Software Tech Tom Stream.
Uh again, live from uh Adramids Architecture.
Uh so thanks for providing the space.
Um and um today we are going to talk about a talk that um we had yesterday here at the conference.
Um so do you want to introduce yourself, Guru, first?
Yeah, so my name is uh Guru Storal.
I've been uh working in Circle K for the past five years within a team that's uh called Immobility.
It's the team that is responsible for the charging business in the company.
I've been working with different roles in the product and tech setups uh for those uh five years.
Yeah, and do you want to introduce us?
Sorry.
Yeah.
So my name is Eduardo Silva.
Um I'm currently an independent consultant, actually been for the past four or five years.
Um before that I did a lot of different things academic, uh, software engineer, software architects.
And yeah, and for our context, so I've been working with uh Circle K and and Guru for the past two and a half years.
And that was our uh story yesterday at the conference.
Yeah, and I think it was really a great uh presentation about uh that that case study um because it actually talks about what what happens out there in in real life.
Um so do you want to say a few words about Circle K first?
Yeah, so Circle K is uh Canadian fuel uh retailer, has more than 17,000 stores globally.
And this e mobility team I mentioned is a global function that is uh supporting the work that's going on for EV charging um in all the business units.
For now, that's um the strongest footprint uh for the EV charging is in Scandinavia and the rest of Europe.
So that that's really where we're focusing.
Uh has been um journey of uh growth from a small scale up in the beginning.
A handful of people, I think there were four or five that started.
Um and now kind of a proper organization with uh different functions, as we also talked a bit about sales marketing operations, product and tech, finance and business development.
So we've grown into a proper organization within that big global enterprise, I would say.
Yeah, and that is basically the journey that you were talking about yesterday.
So and it started in 2018.
So what was the situation like by that time?
Yeah, it was this project team more or less that was taken out of their normal day-to-day job in the fuel and retail operations and started exploring about uh what can we do with charging?
Is this really a business that we want to go into?
And as I also mentioned yesterday, we started to kind of now we see really declining for fuel volumes, but already at that time kind of the predictions were there.
It was uh national incentive schemes in Norway that really put fire to the new car sales of EV, uh, which meant for a fuel retailer that you need to look into okay, where is the opportunity?
Is this something we're gonna do, or is this not really something that fit our business model?
So this was a bit how it started: the exploration, learnings, figuring out uh if this is a space where circle K can succeed, and we've been trying and failing over these uh years, trying different products as well.
Like, does this really make sense or not?
I mean, we was uh at the point also electricity uh provider into people's homes.
Uh so we have been trying, learning um and figuring out where we could really uh make a difference, which I think now also business-wise, we have kind of a viable product out there that is uh fitting the market needs.
And maybe just one one comment from my side.
I think it was around that time when I was uh spent my my vacation in Norway and it was very obvious that there is a lot of EVs uh in in Norway.
Yeah it's very very different already by that time and there were a lot of German cars um that I've never seen in Germany like the e up which I never saw here so it's it's obviously an interesting market that that you're a part of and quite a change.
So from the organizational standpoint you said yesterday there was one streamalign team.
Yes yes so um basically what uh as Guru was mentioning this was just a group of uh five or six people from sales and marketing uh you need some people more on operations because you are actually deploying things right uh around chargers um and um and and the way we we show we show this uh uh on on on our talk is to basically using team topology's language, which is you have uh a streamalign team.
I call it the startup stream aligned team, just because they were really focused on basically validation validating product market fit as a startup, right?
So validating if it makes sense.
Uh and they also had all basically all the necessary skills to to start doing that.
Um and what we also went a bit into is that they didn't have engineers because they there were some um platforms they could leverage to do those first experiments.
So this is basically how the team topology looked like at that time, right?
Um yeah.
So with uh the goal of validation and that the platform team that would be external and that one streamalign team.
Yes.
How is team topology useful in that context?
I I think in this case it it's mostly so they were not uh at that time team topology didn't even exist, right?
But it we used it more as uh as a way to to show that there was a team really with a clear mission and um and skills and to end ownership of their mission, if you will.
And then also seeing that they are leveraging this platform as a service, right?
So they are not uh they are just using most of the things white label and out of the shelf, um, not making big changes to to validate the to achieve their mission, right?
Um so in this case it's it was m it's more like uh we use team topology as as a way to express, and and many people today are are sort of understanding these basic uh concepts to express this say this snapshot in time uh they had.
Yeah.
And I I think that's actually a good point, right?
And uh sort of like like the pattern language was that we also have that the provider shared vocabulary, and once uh you you see I saw the slides uh that you presented, it was very obvious what it means, right?
Because there's a streamline team, so you know what that is.
There is access service, you know what that is.
Yes.
Okay.
And then I think the next step is or anything to add to this 2018.
So that was really I think was roughly around that date.
The the starting, and then this was really, I think that focus on validating and uh and uh and yeah, and this was Norway as a lab.
So, as you were sharing, uh not only they are using Norway as a lab, but uh like the German cars, probably they are probably doing the same, and then things started to just uh go up, right?
To go into into other um yeah, opportunities from there, yeah.
Yeah, and that that's the next step.
So that's 2021.
I I took us a note.
So what what happened then?
I think they had uh grown.
So at this first phase we were talking about, it was not that many people, information were flowing very well across the people that was working with the mobility.
So you didn't need any structures to ensure that um things were happening in the right direction and aligned, and uh uh collaboration was good, and then uh we were growing very rapidly.
Um I joined the company around uh this time and uh um you I think uh people were just adding up new tasks and starting to uh do their things within their different um um domains or uh a focus of Rios.
And then in addition, I think a similar point we started to grow our engineering uh teams as well, which I think you pointed to in one of your side slides yesterday.
Exactly.
Yeah, yeah.
So so that was when that platform that we started talking about um wasn't anymore suitable to to satisfy all the needs that you were having from the the market, right?
Um so you needed you wanted to expand.
So initially was mostly B2C, right?
Uh normal normal people uh charging their cars, but then they also started seeing the opportunity of actually businesses, right?
They they are extremely interesting to um to also be clients, and then you need new features, and they were not necessarily there on those on that initial platform.
And also the I think around that time growth to um Sweden and Denmark, right?
So expanding.
So the I think we highlighted the you started having like product management, product design skill and and engineers to actually start building up these more custom um experiences and and capabilities that that that were needed.
And this, yeah.
So this started making that small team actually not anymore a small team, but uh a group of people working on many things, uh, right?
Because that's sort of the phase of hey, uh, let's uh keep on on building stuff and uh uh and on the platform side here.
We saw that um this white label solution we have been using weren't able, uh I think I used it was a decent driver experience yesterday.
Um for that time it was okay, but then kind of in 2021, a lot had happened since 2018, and we saw that okay to be competitive in the market, we need to take more ownership to our uh customer experience, which I think at this point in time in the whole industry was really happening.
Starting people started building their own apps, and it was this app explosion uh in the market.
And we also took then ownership to this customer uh um front ends and started to uh take some more ownership to some of the components in the uh that we usually that we used to do a white label for.
We started um building some of these things ourselves, um, which also caused that we had to replatform to a new kind of back end or platform service that uh had some of this core charging platform capabilities um in the same point before we scaled to the uh Scandinavian other Scandinavian countries.
Yeah, which basically means that uh the the platform team of the platform became uh became more important or did treated differently for with triff different uh different uh goals um before we dive deeper into into the team topology stuff uh I would like to uh to say a few words about one comment that we have um concerning the step before and that's doing team topologies before team topologies and then there is uh a golden heart I think it is yeah uh the principles were always there would you agree?
100% yeah yeah yeah I think what Matthew and Manuel did was they were just very good at listening to these great patterns we were doing and they were good at finding some yeah good uh model that allowed to represent typical types of of team of of teams we see around and and very importantly the interaction side of team topologies like how how these teams interact right teams don't exist in in isolation.
So yeah, yeah we but even though kind of we now represent this with this team topology uh phrases, uh at that point that was not um uh a vocabulary we used, uh so that was not something we at that time used to describe how we worked, so that's something we've kind of done now in retrospect, and we're talking about the journey to illustrate how we've been growing.
So we were not before then uh to start using these terms just to be explicit on that.
Exactly yeah so so um my understanding is that team topologies actually says this these are magnets, these are like the the goals that teams should evolve towards so and and if you if you say or if that that uh LinkedIn user says that the principles were always there, um those magnets should all always have been there.
And I'm not sure whether that's actually true.
I I think it's true, to be honest.
I think it's true.
I think we if you look at some um for example, I had the the how do you say the fortune to work on uh on a very um on a great uh company with a lot of good principles, and we we basically had the streamaligned teams, we called them product teams.
We had very clear platforms, they were really listening to what the streamaligned teams needed.
We had like these um we used to call them task forces, they sort of the enabling team.
So uh I I think it's um we we were sort of mm companies that were more um explicit thinking about like good practices, they they were sort of already doing a lot of this, and um yeah.
Okay, I I I I I think it's um yeah, but we use many different names for this, right?
Uh feature teams, Scrum teams, uh product teams, uh all sorts of things, yeah.
Yeah, it sounds like uh patterns all over again, right?
Where we are basically discovering what is going on and then we we we coin some terms for it yeah you use the term that team topologies just is like uh a a pattern a uh uh um set of patterns to to describe uh these typical types of teams and interactions yeah right um during that period or when when you were talking about that period uh you mentioned undefined teams and I understand I mean if you look at team topologies there are streamlined teams which do the changes then there are platform teams as we just discussed and there are undefined teams and actually I've heard that before how they are so very important and that makes me wonder because undefined team uh it sounds like well we don't know what the these people are doing it doesn't fit to any pattern.
So how is it any good to have that that uh that term yes so the undefined team types and in undefined interactions um so uh I didn't say on my in introduction but I'm one of the team topologies valid practitioners so we are roughly six, seven people that work uh a lot with uh Manuel and Matthew.
And one of the things we started after the book came out is um that sometimes teams are in certain uh they have certain shapes that don't necessarily fit one of those typical four fundamental team types, and we just try to create a way to express that.
So if you are modeling and trying to see what that looks like, what what is that?
And um, so we we came up with this idea of and this is undefined.
Uh and as you said, it could be that they probably are closer to a streamlined team, but maybe they, for example, are you have uh multiple teams that are owning something and they are always intertangled to do that work.
Um, so they don't have like clear end-to-end ownership.
So we we try to use this also as a way to see where you are, and then okay, what maybe improvement things that you could do to actually become more uh a more uh say rounded streamlined team or a more rounded platform.
Um and so on our talk, what we we we were trying to leverage that because as Guru was saying, on that phase of expand expanding a lot of the teams uh there was so much going on and so much to do that the teams were sort of evolving rather organically, and particularly the engineering team, they were sort of uh very sort of trying to get things done and just building up uh um things on the same systems uh or uh rather intertangled.
So they they they we model them as as these undefined uh team types with the undefined interactions, which is uh continuously uh having to coordinate to um to to talk with each other, which uh sounds like a good thing to talk with each other, but we know that you don't want to be all of the time talking, right?
Right.
So this is roughly the that the idea of using these modeling elements to capture that those things that probably are not setting up the organization for what team topologists would call call the fast flow of value creation, right?
So sounds like uh that this is something as I think that's that's what you said, that there is room for improvement and because they are undefined, so they are not uh uh conformant to one of the topologies so you need to work on it.
Exactly.
Yes.
The other thing that I found interesting is that uh, and I think in a way we we are uh started to discuss that.
Um is that you you said uh that at that point um the system was a big ball of mud.
Um and that was because there was a lack of vision.
Um so did I get that correctly?
How are these two things, the big ball of mud and the lack of uh vision uh related?
I think also to touch a bit uh on this when kind of um things are evolving organically based on the requests coming in, the things that we want to do, and then the work is a bit intertangled, and a lot of the things we had wanted to do was touching the same part of the um architecture, um, and you get a lot of dependencies, and you kind of the engineers did their very best to kind of solve all the kind of incoming requests in uh what they wanted to do uh from the product side in terms of features, which also were um not aligned.
So you had some product people that had focus on something, and then you had teams that wasn't necessarily mapped towards uh the product uh in that sense.
So uh you didn't have one vision that uh the engineers could follow to understand like okay, what are we?
We're doing this thing, I get this kind of list of requests, uh, but I don't really see like where this heading uh for the longer term.
So it's like then it's also difficult to take the right decisions in terms of how do we uh take this forward because you don't really see how it fits into the bigger picture in a way.
So I think that was what we saw like um and speed became everything because like you got the delivery pressure as well.
So then it was like, okay, how can I just do this fast enough um to kind of um please my stakeholders in a way?
Yeah.
So so that vision, if it had been there, what would it have been like?
I mean, like a document, what would the documents say?
Uh some some visualization or any idea?
To be honest, I think that phase they were going through, they they didn't have enough to define that vision.
Okay.
So they were probably just on that phase of trying to figure out what what still made sense.
They needed more people, and um I think naturally what happened is that the vision started emerging from the the pain and the learnings.
But unfortunately, you also built up a bit of this in order to go fast and uh sort of experiment a lot of things, you neglected the bit of more what probably your audience would look into, like more the architecture, clear architecture, uh thinking where are we going?
Are we placing things in the right places?
Um yeah.
Um but yeah, I I that's sort of I I think it's very important to to understand um they this was not uh like a well-established uh organization.
It's it's sort of uh as we were saying, a startup trying to to to grow and to establish a bit themselves.
And we started to develop more and more on our own platform uh compared to also using the platform that we sourced, um which also then lacked this platform vision, as I was pointing to yesterday, because like we didn't really know where the uh boundary were in terms of what we should do uh or where we should ask the vendor, and how if the vendor weren't responding to the thing as we expected, then what is the steps we are taking?
Because how where do we want to go with this?
Which things do we need to uh take ownership to?
What should we do ourselves?
Where should we source?
And these things were they were not uh we hadn't explored and we hadn't uh kind of anchored and assessed that part.
I mean, the the impression that I get from from what you're saying is that uh this this um I even get the impression that that vision emerged once you you had all these operational things to co cope with and you couldn't have had it beforehand.
I I I wasn't there, Guru sort of you basically.
They were learning, yes.
They were learning that's what I'm trying to do.
You can carve out so uh Simon Ward is is very known for that.
Like you can carve out uh uh a vision, right?
So ask his uh uh strategy generator to create one and that happy thing, but I think they were just trying to learn what made sense or not.
And um, I think later on the the presentation we started, and I think this was the what actually happened that the the sort of you start seeing okay, we can't scale, we actually need now to take a step back and uh bring the that vision element that you were that you were uh alluding to.
And I think the learning and the experimentation was really what we wanted to do in this phase as well.
So um it was happening, uh, but we also over time when things started growing, it goes from kind of being learnings also into pain points uh in a way, and at some point it uh the pain is so big that you need to address it because it's for a period of time you can work around those and make it happen and utilize it as learnings.
But at one point for us at least it came to a conclusion that okay now we need to take a step back and understand what is really the ways we are going to address these pain points because now we've seen them over time and they are big.
Yeah yeah and maybe that's inevitable.
I mean that's that's what I'm basically trying to or the the impression that I get.
And famously our former counselor Schmidt said that people who have visions should go and see the doctor because okay so anything else for for that phase no I think I think we we touched it okay so the next phase sorry yeah so the next phase uh I uh I I wrote down the years 2022 to 2024 um so what did you do did you do during that phase I think this was roughly when the points that we were sort of starting coming into that guru was is talking about right?
So okay, market fit seems to be there um uh B2B, we are starting to serve B2B customers.
Um we start expanding to Sweden and um and Denmark, right?
But uh all of these things that we were doing to to cope with that um are now rather intertangled, so the big ball of mud thing.
Um and uh we we talked about this idea of uh burning platform.
So we we we circle K wants to go even further, right?
So the mission is to go to more countries in Europe and globally.
How can we do that if we are now we if we can't move fast?
So this was when uh um well when you took sort of a step back and started doing some of that understanding of what do we have, what should we own, what should we leverage from partners.
Um yeah, so maybe you can uh talk a bit about that because you were there, yeah.
Yeah, I think as I uh also mentioned yesterday, there was uh several things we started to see that we wanted uh to do.
Um, and one of that one of those points was to start um looking into a platform strategy.
Um, so how do we want to be able to serve these uh countries at scale going forward?
Um, where we found these 12 capabilities uh that we need in a platform um to be operating in this industry.
Um, and uh that was a bit how things uh started.
Um, and uh then we also saw that we needed to address like how do we actually uh fill this uh capabilities with the people and architecture that can make it happen.
Um and we saw kind of the mismatch between how it currently looked like and uh what it kind of should be.
And that was the point where we reach out also to Nick Tune and Eduardo to get uh help in the that next uh phase.
Yeah, and one of the tools that you were using are independent service heuristics.
So do you want to say a few words about that or explain that so yeah, maybe so what just before uh I came in, what Guru and uh and other people were doing, they did uh value stream mapping.
So this is a way for you to understand the sort of what are the activities you you do, and and then you start seeing okay, what are roughly boundaries of things that we have?
And this was that initial idea of the those 12 capabilities, right?
So we we saw these, and independent service heuristics is um sort of a technique that um Matthew and Manuel from uh Team Topologies came up with as a sort of a quick assessment to see if these things are show the traits of being independent enough to be owned by a team, for example.
Okay, um, so what's uh you you can check them on Team Topology's GitHub.
There is like this is basically I think eight questions, I always forget seven or eight uh sort of dimensions, and you try to for each of the capabilities that were identified in some way, so you value stream mapping, event storming, whatever uh technique you use, you can then try to ask these questions as a way for you to get a feeling for is this independent or not?
So you could for example one some of the questions is could this be deployed as an independent service that you could offer to someone like like externally and then directly as a service.
Okay.
Imagine having um could this be provided as a website uh to uh to to customers do you have a clear uh customer that who's using this um could you for example um manage costs of this thing could you understand how to do that so there are like multiple dimensions that allow you to get a bit more confidence on this seem to be or not uh good to be independent uh capabilities or so so this is uh this is it seems like uh a checklist that you can run those core capabilities it's a checklist so and what what was the result like?
How was it useful?
It's yeah no I think you did it.
So yeah so yeah.
So we had uh different um uh candidates that we run through this checklist, and what we started to see was that uh some were clearer, um, and some were a bit more of a safe.
The answer was yes or no uh to the those questions.
Um so I think we used that when we embarked on that journey of starting to mapping out the domains together with uh Eduardo and uh Nick and we started with the ones that uh we were more confident in.
Um so we used this as kind of okay.
We used it as a checklist for these domains, and then we used it also in the next steps to prioritize okay where to start um the next uh step of uh our mapping.
Okay, so so you're basically so uh it seems what you're saying is you did a value stream mapping, then you figured out which are the ones who were uh truly independent service uh independent in terms of independent service touristics, and then you started working on them in more detail.
Yes, yes, okay.
Yeah, what is what's um what's the reason behind that?
I mean, obviously, an alternative would be to get uh to get to all to uh a list of truly independent services first before you do the next step.
But they didn't have any of that.
They they had no the the services were just some monoliths with a lot of things uh intertangled, and they they wanted to understand what are say say more like the business capabilities that as uh e mobility they should have, and then they they started sort of looking at the all of the different activities, workflows, and things, and and trying to see what what are these essential capabilities that that they need.
In some of them, they already had some of uh some application services, in others, no, uh in others they were on these external platforms.
So that that is a way for you to start seeing okay, what what do we have as a business?
And then from there going a bit deep inside of those capabilities to look at the yeah, even uh deeper what what's there and what should be there.
Sounds like the vision that was lacking before, right?
Yeah, okay.
Definitely.
This was the sort of a north star of what do we have and uh where are we zooming up next uh to improve and move forward, yeah.
From from a business perspective, okay.
Um also you mentioned listening sessions.
Yes, so roughly at this time, uh as Guru mentioned, they they did some of this homework, started seeing, but then we and we decided together on when Nick and I came in to which of these capabilities, domains, we can call them different things, but let's say which which of these should we start and would be more important for you to start getting uh really deeper and understanding what's there and which team should you have there, what's what systems are there.
Um so we came to one of the domains that was around uh uh core charging, uh which is very important for uh uh EV charging company, right?
Um and then so Nick and I what we did was this idea of okay, uh Guru told me a bit uh and and the other people that were sort of starting with us, uh, told us a bit of the story, but we also wanted to listen to everyone that was working on that area.
So this were these listening uh sessions, we're listening to the teams that were working on that part, to the people that were doing the network operations, the people that were doing sales and marketing, etc.
etc.
And basically there we just we were like, okay, what what are the main pain points you see?
What are the systems you are already interacting with, which teams do you work with?
Um a lot of different questions to just sense make what what's here, right?
What uh what and the goal was to because we knew that we we we needed to have deeper dives and we wanted to have a better idea of what are the big pains that we have so that we model uh we go into a more focused sessions and we don't just bring our uh like the default uh session and um um yeah and and uh ineffective session in in a sense.
Okay, so uh and I took a note that it was about 15 listening sessions.
So what would you listen to?
So these were uh, for example, teams that were working there.
I don't know, uh so with all of the team you would interview all of the team.
Yes, in some cases, all of the team.
Uh I think in this case it was all of the teams, and then yes.
And uh we also had PMs that necessarily doesn't wasn't necessarily at this point connected to uh the teams in a way.
So that was uh some other sessions, I believe.
And then you mentioned people if we separated at that time uh product was uh working in a sort of uh the product and teams were not necessarily working every day together, engineering teams.
So we had sessions with uh one and then with the other, so everyone could be very uh just open and candid to to not trying to please the other.
So this was uh trick that we used, yes.
And then the open questions, as you mentioned, um with okay, with the pain points and so we we tried to sort of see what are the big hotspots around all of these these conversations, yes.
And um any more tips how to do these listening sessions?
Yes, so listen.
Okay, yeah.
Don't uh so that was one of the principles Nick and I said.
We were there to listen.
We were weren't there to please people and give opinions at this moment, right?
So we were really trying to have very open, open-ended questions, not directing people to certain areas.
So these are very important because um yeah, you want to get as much signal as you can, not uh not sort of already trying to bias people towards something.
Yeah.
And yeah, I have to admit that's the reason why I'm asking.
I think it's a it's a great technique.
I'm using it myself also, uh in particular if you're an external person to get to understand what's what's going on.
Yes, and uh and I have to admit I do it slightly different.
So I do one-on-ones um with key players, but I mean I would therefore I can never talk to you.
We did a few one-on-ones.
Yes, yeah, yes, yes, I think this was dependent on it like what uh what part of the organization were you talking to, and uh who uh wanted to take part in this and who did this.
Sometimes availability of people that there were a lot of uh things going on, yeah.
Yeah.
And this is also when you uh founded this architecture modernization enabling team, right?
And I think you're m a member of that team.
Yeah.
Yes.
So what's that team and why is it there?
How is it useful?
You can start.
Uh yeah, so so what's a bit like what you're saying as an external coming into an organization.
Um even if you have if you even if you are good at what you are doing, uh you you don't have the um the knowledge, the the depth and also the the credibility with with people in an organization to have actually drive profound change.
So what Nick and I started uh we did this with multiple clients and uh with the with Circle K we sort of we even ended up writing uh an article to sort of bring it together.
We we can share it later.
But the key idea is um we there is a big change happening who would be the people from different functions that could help this um kick starting of modernization, particularly that part uh successful.
How can we start get things moving?
Um so this is basically after after those listening sessions, I think during probably um yeah, Guru was a key key person, but we had a few other people, so guru more from product uh but we had people from uh uh architecture, people from engineering uh management, right?
So the person managing the teams, uh Ian as uh director of uh technology and product, re also providing like the uh executive support for this.
So this is a very I think it's a very it has shown to be very uh effective way to to get a group that really can actually uh help facilitate uh proper change.
So what does that team usually do?
What's what's on the agenda?
Uh very different things every week, but uh it's uh typically the goal was um try to look at that bigger picture of all of those capabilities and for example help okay.
First we'll focus here, and then what do we need to do?
We need to organize these workshops.
We mentioned a few.
Uh we take lead on doing that, on facilitating them.
Um you start seeing some things coming up, like I don't know.
Um, we don't have enough people on a team.
Um they may be also drivers to actually get priority for that to happen.
Um there are there is a wide range of of things.
Can be also coaching, uh, for example, coaching teams that need help on something.
I I did that a few times, for example, facilitating worldly mapping sessions.
So that was not something that the organization knew, so you sort of go and try to help upskilling on that thing.
Uh but it's it varies a lot to be honest.
Yeah, but I think it makes very much uh sense to use it as a tool when you have externals coming in um to also have the internal ownership and then also enable the organization to uh learn things and take uh ownership to these toolboxes and can kind of utilize this also later and not kind of have externals coming in, do something and live, and then you have learned nothing.
But by this uh we also were tightly involved with what happened, but I think also, as you pointed to um there was some sort of tool for us to ensure also we were able to prioritize this work internally, given that we had product architect and engineering managers in this group.
It was uh kind of a good group to also see okay, do we have any um priorities outside the transformation uh topics we're working on that is in conflict and where we need to really help uh people and clear their agendas for us to be able to move this forward?
Because I think that was one of the questions that many people asked us yesterday after the talk was like, how did you have time to do these things?
And that comes down to prioritization, right?
You're not able to do changes if you're not prioritizing actually uh spending time on doing the required step to do so, then you will just go on doing business as usual until forever.
So I think this was also a very useful tool to enable uh that um and it also was something we explicitly mentioned several times in the internal communication, so people were aware of it, and then you also know the organization, and people can come to you, or you can be available for people in the organization that can where I do have to reach out to them, like what is what is this?
I don't know about this thing.
Can you tell me a bit before I go into that conversation?
So yeah.
So um, I mean, first of all, one thing that that uh I understand or that that I got is um it's a good idea to have that team with external and internal people, sort of to to mix it and to facilitate uh the interchange of knowledge and communication and so on.
Okay.
Yeah.
Um the other thing that I'm wondering, so I my understanding of the original enabling team and team topologies is more this coaching thing and skills built up and what you seem to describe as it seems to have some some management impact like okay so there is one team and they don't have enough people or we need to prioritize stuff that looks it sounds like project management to me.
So the enabling team is a very um broad uh concept that typically people associate it as a um a person or a team that helps another one upskill on on right scale this is a very common um say uh case but I've used it in many other things and I think the same basic traits apply and and the thing is they should help on upskilling or addressing a missing capability.
And in this case I think what the Amet the architectural modernization enabling team was doing is addressing a sort of a uh um a capability that's not yet there right this uh being uh being um um having clear boundaries uh having so it's it's a way to uh if you look at the not just the team but the interaction mode which is facilitating it it it also gives you some uh idea of what we were actually doing right we were facilitating the modernization um yeah so um but I use just as a sort of a side note I use in uh enabling teams for example also for maybe for your audience very importantly to express how uh i think many architects should behave they they they should if there are conditions they should behave on helping their teams up skill and address something and then sort of not be so much on the on on like driving decision if they are able to do it okay uh yeah so but this maybe it would take us out of the and we didn't use this team to drive decisions or take decisions or do prioritization but if we needed it kind of people in this team were aware and could facilitate also the process of that happening um where it should happen in the organization so I think that was more my point point earlier.
Oh I see okay so so that makes sense thanks for clearing that up and then I misunderstood that there was also senior management on that in that team yes it was it was but then I mean they can just make the decisions right no they would just facilitate okay in this case uh Jan was the the person there he it was just uh one of the the the say the the drivers of of the modernization and he was very also important because he was connecting to say to the management team and it could also feed them with uh like what's going on and um also making sure that we had the space to make this work happen right so is that a general advice that you would give like to have it uh to have that those kind of senior management persons on on an enabling team i i would give that advice if this person doesn't come in with uh the mindset you shared which is uh he or she comes in and is decided he or she is deciding that I wouldn't I wouldn't advise uh um if if they are just sort of uh taking over all of the the things but having the management support and like uh this and sponsorship on these things it's uh uh it's uh it's a uh make it or break it right so if if you don't get that it it I I think I I would uh dare to say that this is going to be very hard to this these bigger changes right to to make them happen.
Yeah it's just that um I mean at the at the end of that your talk there was this question about the priority that you also touched on and I think what what uh you just mentioned about the architecture enabling team seems uh architecture modernization enabling team seems to be one part of that that solution sort of yes okay yeah um the other thing that I wanted to talk about so um what you mentioned is um that there are actually three techniques techniques that you're that you were using like the domain job design team topologies and wardly mapping um so what's the relation between those i mean i mean first of all maybe um no so what's the relation between those uh three techniques yeah so these three techniques tend to show up uh uh in many of these journeys and then susanna kaiser is uh even wrote a book about this because it it seems to be uh a very regular pattern right that we that we uh see um in organizations that want to change and and basically you can see domain driven designers helping you to understand your business your domains and uh the their nature right is this a thing a core is this supporting domain is this a generic domain so how could could for example you approach them in terms of sourcing um so this was a very so we used for example event storming and and other and other techniques to to start to doing a lot of that understanding deep understanding um team topologies as we probably were already talking a bit is to start understanding what sorts of teams we have how do they interact um using that language and worldly mapping was for us a very it just clicked very well with many people too because we had a lot of discussions on uh build versus buy how shall we do that and um we used worldly mapping just to start depicting what does this mean in your domain and you it's not a a binary thing so certain things inside maybe you can just uh leverage from a partner said so other things are more you should own and um we had so we talk about in in the talk there were certain capabilities that were uh you were leveraging from external platforms but uh it they were core domains um and uh Michael Plut actually had a talk yesterday on that which is that it was somewhere owned somewhere outside and they wanted to change it and they couldn't do it very well so this was clearly something we want one of uh the the the product teams streamline teams to own and evolve so this was just uh helped a lot on this yeah basically setting uh what we were going in in earlier like a division for what what where should things be and how should we also in terms of principles right how how do we treat these different things that exist in the in the organization yeah anything else so I mean, I have the impression, but I might be wrong that uh there are quite a few organizations that say okay, we're going to do team topologies because uh that's a great way to organize our teams.
And now what what what you're saying in a way is that you actually applied three different techniques, yeah.
Um and that that there is a that there's a huge uh synergy between them.
So does it make sense to do team topologies on its own?
No, well I um so I I do a lot of trainings around team topology, and we in every training we try to understand what what are the capabilities you have, and this is we can try to do some of that uh independent service heuristics very high level, but if you really want to understand leveraging things such as domain-driven design or worldly mapping, um this is um tends to be like very complementary and you should not just say, Oh, I have uh these streamaligned teams, they own something, but you don't have a very clear idea of why what that means, right?
So uh yeah, I I think people should really uh sort of cherry pick what works for them.
As I said earlier, like the worldly mapping.
There are some other tech, for example, Nick Tune has this score in charts.
I'm not sure if you heard about it, but it also allows you to see uh a bit of the nature of the things you have, the capabilities you have, and maybe you that's enough.
But in in our case, worldly mapping really helped a lot.
And people clicked with it.
And sometimes I think this is also uh seeing what works for this particular um context is um is very important.
Yeah.
Just maybe a few additions.
So the core domain is the one important domain that you would have in a project, so that is why probably so on a lot of it.
What are the things as a business that you should really own and basically typically gives you the money?
Uh or uh and the others are more as the other says supporting is things you need like to work as a business and maybe some generic, right?
So you maybe you need some CRM or some um sending emails.
Uh right, you don't want to event sending emails.
And uh core domain charts is this idea where you have the complexity and the the the value generation on the excellent one.
So you can try based on that see a bit on where the different things are and uh and get an idea of what uh yeah yeah uh of your landscape.
And uh Simon, I mean if uh concerning water mappings we had a session with uh Simon Wardley and also after another one um uh last year with uh Markus Hara, so the one about with Simon Wadi was actually in this very room.
Oh cool.
So um there if you want to have more information about that you could definitely watch that.
Um other thing that I would like to talk about.
So I think it was in that phase where you were talking about how you did that large pr uh workshop, and I think it was an event storming, and then you would do the next workshop, and then you would do small workshops.
So, how long did it take you to actually come up with these twelve core capabilities to get a good idea about what you want to do and uh to to create that let's say vision?
You want to go?
Yeah, I think the twelve capabilities we had from the um beginning, and then we started um with the first workshop after we've been I don't know how many months we used before we it was two to three months of preparation.
I mean it was 15 sessions of listening there, and there was uh a lot of work going into the preparations as well.
Um, and then so that was the first workshop, and then I uh we had a lot of work in also after that workshop with the worldly mapping, but also in ensuring we had some common language uh to talk about uh different concepts that that at a point were new to us, so it was a lot of work also going into that part.
Um so and then we focused a bit on uh the afterwork from that workshop.
We left with some clear action points, but those action points was kind of promising uh that we were executing on the next step, and uh it was a lot of work ahead of us when I left that room.
So I think it was six months before we did the next one, which was the big one that Eduardo referred to in the talk yesterday on the customer domain.
So it wasn't uh workshop every week, uh, because both the the work afterwards and the preparation into especially these two, I think these were the two biggest we had, um, were also a very extensive work both beforehand and afterwards that needed uh uh efforts and uh and focus.
Yeah.
But so if we look so we talked in roughly this is a multiple multiple year, we show like a timeline of eight years.
Obviously, this is a smaller uh time window we are talking about now, but I think in in those months so some of the teams were starting already to um this is not like we after half a year something happened there was a lot of small things happening trying to get teams to start getting closer to those capabilities that we started seeing on those uh um deep dive sessions like three days with I probably almost 30 people uh on on the first workshop uh and then what we did and this is uh maybe an interesting one that we talk about is this it was a bigger workshop where we started noticing we and this is goes into our point of the vision we actually should start understanding what are all of our customers what are all the experiences they have and um this was a a picture that didn't exist uh and I think many people had different versions of it and um uh yeah and and this was really um a very important moment to put even more a bit more framing on that sketch of vision that we were starting to create um and from there, I think I don't remember exactly the times, but maybe you can give some idea.
But it was probably in in the coming months we started getting those groupings coming together and there has been a work of um a lot of work on refactoring to actually start getting the teams to own clear uh services.
I think that was what I wanted to say that once we saw that we had qualified a candidate for a domain and we'd done the worldly mapping what we tried to do was to get a team started on that as soon as possible to kind of start for that team to start owning their domain and to do the development within that.
And then I also think the architects there did a very good job in making a refactoring plan.
So it was kind of a vision from like here we are now and now that we've learned that our domains also now group product level looks approximately like this we have kind of a vision that we're working towards which is this and then the first step we should take is doing this.
So I think that plan also came out after that second workshop even though we didn't at that point have all the answers so this was also an evolving document talking about like if visions are useful or not I but I think this was then something to stretch for and gave some people a bit clarity in like where what are we moving towards?
Um so I think that was also a very uh important step that happened after those kind of decisions were taken, which also was not taken by the EMET so it was not a decision team, but it was facilitated by the Eduardo and one other from the AMET team, the process of figuring out these domains, but then it was the people working with these things that were a part of actually seeing okay, where is the natural uh split in these different domains and these different groups uh of domains.
Okay.
And I I I think that's one of the reasons why why and I enjoy these case studies because it actually gives gives a glimpse about uh how difficult this all is and how long how much time it takes, and you know, usually if you talk about team topologies and so on, it's just a few concepts and it's like okay, this is how it's done, uh and it's it's it's obvious, isn't it?
Um which leads to the question so why does it take so long?
Yeah, so I think our all uh hour here with you it shows why it takes so long.
It's um in in and in this case, so e mobility is a startup, right?
So you don't have the legacy of an enterprise.
So in this is a very interesting uh nuance, right?
But even with that context, um it takes long because these applications were all all intertangled.
People there was no clarity, that vision that we came into wasn't there.
Um and we didn't go too much there, but um a very important step here was also, and we talk about that uh on on the talk, which is the people side of things, right?
So you had product uh management in in Norway, you had engineering in in Warsaw.
There is not nothing wrong with that, but at the start of that change, they were working rather on on their own, right?
And we are trying to move into a model that we just talked about, that idea where actually these people are working together and and for people that has spent some time working with teams, you know that this is not an overnight thing, and uh so I think this and the refactoring work that Guru is talking about, right?
So uh we understand these are the important boundaries, but and we show that on our talk things are still intertangled.
This is just a nice picture.
Things need to be to be worked out, and this is where the a lot of the work the work that takes time uh happens, right?
And I also think the full transformation takes time, but what I also think is important if someone is embarking on this journey is to uh figure out where you can start seeing the first signs of improvements and success, because I think that's important for the people that are a part of actually driving this change, doing this change, affected by the change, and obviously also the stakeholders around to kind of get the buy-in for the kind of continuation of this uh journey.
So I think that was also something that we did a lot, was that now we see okay, this is working or this happened because we did this step in the transformation.
Then we were very explicit in kind of showing that uh and mentioning that and talking about that with people in the organization.
Yes.
What I wanted to say.
We there was a lot of sharing uh how are we moving forward and and people when people see things they they tend to to move sort of go more, right?
Uh believe it in a sense, right?
Yeah.
So I have one final question, and I have to admit that I didn't mention it before, so I'm not sure whether it's a question that that uh that um that it's a good question.
But we are at the dawn of the AI age, right?
So how is AI going to change all of this?
So what would be different what what's gonna be different about about this story?
To be honest, at this moment in time, I think not a lot of this journey would have been different with what we have today.
Um I've discussed this with a few people.
I think in order for you to leverage AI well, you need to be on this sort of having teams that own certain things and are able to work on them.
And in order for you to get into that, you need to do your homework, which is this work that was well was very intensive and uh so a lot of the companies that think that AI will solve that for you.
I think this is uh a major um yeah, issue to to say it lightly.
Um but for the refactoring work, for example, maybe there.
I think there will be definitely certain help and opportunities to accelerate some of that work.
But the more organizational uh that part I I don't think at uh where we are today with the AI we have today.
Uh anything?
Yeah, okay.
Anything to add?
Any any other ideas?
Uh no, I mean I haven't tried, but I could have tried to ask AI uh how should we organize our domain and see if it's anything similar to what we have.
But I tend to agree with the Dodo here that I think uh a part of the learnings that we gained throughout this journey is also kind of understanding our organization better, the ways of working and this whole social technical architecture, and also the fact that we now I think have a more common language to talk about these things which we lacked before, which I also think has been a very important thing.
And I don't think you can get that by reading it.
I think you need to experience and feel it to be able to really get there.
So there's something here that you also need to take part in the experience to actually uh succeed in some of these steps, I believe.
Yeah, okay.
So thanks a lot.
Thanks for taking the time.
Enjoy the rest of the conference.
Thank you so much.
Uh yeah, hope to see you soon.
Thank you.
See you soon.
Thank you.
Bye.