This text was generated using AI and might contain mistakes. Found a mistake? Edit at GitHub
Okay, so welcome to another episode of Software-Architektur im Stream.
Again, live from Agile meetsArchitecture.
So thanks for providing the space.
And today we are going to talk about a talk that we had yesterday here at the conference.
So do you want to introduce yourself, Guro, first?
Yeah, so my name is Guro Størdal.
I’ve been working in CircleK for the past five years within a team that’s called Immobilti.
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 for those five years.
Yeah, and do you want to introduce yourself?
Sure, sure.
So my name is Eduardo De Silva.
I’m currently an independent consultant.
I’ve actually been for the past four or five years.
Before that, I did a lot of different things, academic, software engineer, software architect.
And yeah, and for our context, so I’ve been working with CircleK and Guro for the past two and a half years.
And that was our story yesterday at the conference.
Yeah, I think it was really a great presentation about that case study, because it actually talks about what happens out there in real life.
So do you want to say a few words about CircleK first?
Yeah, so CircleK is a Canadian fuel retailer, has more than 17,000 stores globally.
And this Immobilti team I mentioned is a global function that is supporting the work that’s going on for EV charging in all the business units.
For now, that’s the strongest footprint for the EV charging is in Scandinavia and the rest of Europe.
So that’s really where we’re focusing.
It has been a journey of growth from a small scale up in the beginning, a handful of people, I think there were four or five that started.
And now kind of a proper organization with 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 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 fuel volumes.
But already at that time, kind of the predictions were there.
It was national incentive schemes in Norway that really put fire to the new car sales of EV, which meant for a fuel retailer that you need to look into, okay, where is the opportunities?
Is this something we’re going to do?
Or is this not really something that fit our business model?
So this was a bit how it started, exploration, learnings, figuring out if this is a space where CircleK can succeed, and we’ve been trying and failing over these years, trying different products as well, like does this really make sense or not?
I mean, we was at the point also electricity provider into people’s homes.
So we have been trying and learning and figuring out where we could really make a difference, which I think now also business wise, we have kind of a viable product out there that is fitting the market needs.
And maybe just one comment from my side.
I think it was around that time when I spent my vacation in Norway, and it was very obvious that there was a lot of EVs in Norway.
Very different.
Yeah, it’s very, very different already by that time.
And there were a lot of German cars that I’ve never seen in Germany, like the E-Up!, which I never saw here.
So it’s obviously an interesting market that you’re a part of, and quite a change.
So from the organizational standpoint, you said yesterday there was one stream-aligned team?
Yes, yes.
So basically what, as Guro was mentioning, this was just a group of five or six people from sales and marketing.
You need some people more on operations because you are actually deploying things around chargers.
And the way we show this on our talk is to basically using Team Topology’s language, which is you have a stream-aligned team.
I call it the startup stream-aligned team, just because they were really focused on basically validating the product market fit as a startup, so validating if it makes sense.
And they also had basically all the necessary skills to start doing that.
And what we also went a bit into is that they didn’t have engineers because there were some platforms they could leverage to do those first experiments.
So this is basically how the Team Topology looked like at that time.
So with the goal of validation and that platform team that would be external and that one stream-aligned team, how is Team Topology useful in that context?
I think in this case it’s mostly, so they were not, at that time Team Topology didn’t even exist, right?
But we used it more as a way to show that there was a team really with a clear mission 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, they are just using most of the things white label and out of the shelf, not making big changes to validate, to achieve their mission, right?
So in this case, it’s more like we use Team Topology as a way to express and many people today are sort of understanding these basic concepts to express this snapshot in time they had.
And I think that’s actually a good point, right?
To have a shared vocabulary and sort of like the pattern languages that we also have, that provide a shared vocabulary.
And once you see, I saw the slides that you presented, it was very obvious what it means, right?
Because there is a stream-aligned team, so you know what that is, there is access service, you know what that is, and so on.
And then I think the next step is, or anything to add to this 2018 phase?
So that was really, I think was roughly around that date, the starting and then this was really I think that focus on validating and, yeah, and this was Norway as a lab.
So as you were sharing, not only they are using Norway as a lab, but like the German cars are probably doing the same.
And then things started to just go up, right?
To go into other opportunities from there.
Yeah, and that’s the next step.
So that’s 2021.
I took as a note.
So what happened then?
I think we had 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 things were happening in the right direction and aligned and collaboration was good.
And then we were growing very rapidly.
I joined the company around this time and I think people were just adding up new task and starting to do their things within their different domains or focus areas.
And then in addition, I think a similar point, we started to grow our engineering teams as well, which I think you pointed to in one of your slides yesterday.
Yeah.
So that was when that platform that we started talking about, it wasn’t any more suitable to satisfy all the needs that you were having from the market, right?
So you wanted to expand.
So initially it was mostly B2C, right?
Normal people charging their cars, but then they also started seeing the opportunity of actually businesses, right?
They are extremely interesting to also be clients.
And then you need new features and they were not necessarily there on that initial platform.
And also the, I think around that time, growth to Sweden and Denmark, right?
So expanding.
So I think we highlighted the, you started having like product management, product design skill and engineers to actually start building up these more custom experiences and capabilities that were needed.
And this, yeah.
So this started making that small team, actually not anymore a small team, but a group of people working on many things, right?
Because that’s sort of the phase of, let’s keep on building stuff.
And on the platform side here, we saw that this white label solution we’ve been using, weren’t able, I think it was a decent driver experience yesterday.
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 customer experience, which I think at this point in time in the whole industry, it was really happening.
People started building their own apps and it was this app explosion in the market.
And we also took then ownership to this customer front ends and started to take some more ownership to some of the components that we used to do a white label for.
We started building some of these things ourselves, which also caused that we had to re-platform to a new kind of backend or platform service that had some of these core charging platform capabilities in the same point before we scaled to the Scandinavian, other Scandinavian countries.
Yeah.
Which basically means that the platform team or the platform became more important or treated differently with different goals.
Before we dive deeper into the team topology stuff, I would like to say a few words about one comment that we have concerning the step before.
And that’s doing team topologies before team topologies.
And then there is a golden heart, I think it is.
The principles were always there.
Would you agree?
One hundred percent.
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 good model that allowed to represent typical types of teams we see around.
And very importantly, the interaction side of team topologies, like how these teams interact, right?
Teams don’t exist in isolation.
But even though we now represent this with this team topology phrases, at that point, that was not a vocabulary we used.
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 them to start using these terms just to be explicit on that.
Exactly.
Yeah.
So my understanding is that team topologies actually says these are magnets.
These are like the goals that teams should evolve towards.
And if you say or if that LinkedIn user says that the principles were always there, then those magnets should always have been there.
And I’m not sure whether that’s actually true.
I think it’s true, to be honest.
I think it’s true.
I think if you look at some, for example, I had the fortune to work on a great company with a lot of good principles.
And we basically had the streamline teams.
We call them product teams.
We had very clear platforms.
They were really listening to what the streamline teams needed.
We had like these, we used to call them task forces.
They sort of the enabling team.
So I think it’s, we were sort of companies that were more explicit thinking about good practices.
They were sort of already doing a lot of this.
And yeah.
Okay.
I think it’s, yeah.
But we use many different names for this, right?
Feature teams, scrum teams, product teams, all sorts of things.
Yeah.
Yeah.
It sounds like patterns all over again, right?
Where we are basically discovering what is going on and then we coin some terms for it.
Many people use the term that team topologies just is like a pattern, a set of patterns to describe these typical types of teams and interactions.
Yeah.
Right.
During that period, or when you were talking about that period, you mentioned undefined teams.
And I understand, I mean, if you look at team topologies, there are streamline teams which do the changes and 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 sounds like, well, we don’t know what these people are doing.
It doesn’t fit to any pattern.
So how is it any good to have that term?
Yes.
So the undefined team types and undefined interactions.
So I didn’t say on my introduction, but I’m one of the team topologies valid practitioners.
So we are roughly six, seven people that work a lot with Manuel and Matthew.
And one of the things we started after the book came out is that sometimes teams are in certain, 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 is that?
And so we came up with this idea of this is undefined.
And as you said, it could be that they probably are closer to a streamline team, but maybe they, for example, are, you have multiple teams that are owning something and they are always intertangled to do that work.
So they don’t have like clear end-to-end ownership.
So we try to use this also as a way to see where you are and then, okay, what may be improvement things that you could do to actually become a more, say, rounded streamline team or a more rounded platform.
And so on our talk, we were trying to leverage that because as Guro was saying, on that phase of expanding a lot of the teams there was so much going on and so much to do that the teams were sort of evolving rather organically and particularly the engineering teams, they were sort of trying to get things done and just building up things on the same systems or rather intertangled.
So we modeled them as these undefined team types with the undefined interactions, which is continuously having to coordinate, to talk with each other, which sounds like a good thing to talk with each other, but we know that you don’t want to be all the time talking, right?
Right.
So this is roughly the idea of using these modeling elements to capture those things that probably are not setting up the organization for what team topologies would call the fast flow of value creation, right?
So, yeah.
So it sounds like that this is something, I think that’s what you said, that there is room for improvement because they are undefined, so they are not conforming to one of the topologies, so you need to work on it.
Exactly, yes.
The other thing that I found interesting is that, and I think in a way we started to discuss it, is that you said that at that point the system was a big ball of mud and that was because there was a lack of vision.
So did I get that correctly?
How are these two things, the big ball of mud and the lack of vision, related?
I think Eduardo started to touch a bit on this when things are evolving organically based on the requests coming in, the things that we want to do and then the work is a bit entangled and a lot of the things we had wanted to do was touching the same part of the architecture and you get a lot of dependencies and the engineers did their very best to solve all the kind of incoming requests in what we wanted to do from the product side in terms of features which also were not aligned, so you had some product people that had focus on something and then you had teams that wasn’t necessarily mapped towards the product in that sense, so you didn’t have one vision that the engineers could follow to understand like okay what are we, we’re doing this thing, I get this kind of list of requests but I don’t really see like where it is heading for the longer term, so it’s like then it’s also difficult to take the right decisions in terms of how do we 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 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 to kind of please my stakeholders in a way, yeah.
So that vision, if it had been there, what would it have been like, I mean like a document, what would the document say, some visualization or any idea?
To be honest, I think the phase they were going through they didn’t have enough to define that vision, so they were probably just on that phase of trying to figure out what still made sense, they needed more people and I think naturally what happened is that the vision started emerging from the pain and the learnings, but unfortunately you also build up a bit of this in order to go fast and sort of experiment a lot of things, you neglected a bit of more what probably your audience would look into like more the architecture, a clear architecture, thinking where are we going, are we placing things in the right places, yeah, but yeah, that’s sort of, I think it’s very important to understand them, this was not like a well-established organization, it’s sort of, as we were saying, a startup trying to grow and to establish a bit themselves.
And we started to develop more and more on our own platform compared to also using the platform that we sourced, which also then lacked this platform vision, as I was pointing to yesterday, because we didn’t really know where the boundary were in terms of what we should do or where we should ask the vendor and how if the vendor weren’t responding as we expected, then what is the steps we are taking, because where do we want to go with this, which things do we need to take ownership to, what should we do ourselves, where should we source, and these things were, they were not, we hadn’t explored and we hadn’t kind of anchored and assessed that part.
I mean, the impression that I get from what you’re saying is that this, I even get the impression that that vision emerged once you had all these operational things to cope with and you couldn’t have had it beforehand.
I wasn’t there, but I think they were learning, they were learning and you can carve out, so Simon Wardley is very known for that, like you can carve out a vision, right?
So ask his strategy generator to create one and that happy thing, but I think they were just trying to learn what made sense or not.
I think later on the presentation we started and I think this was what actually happened, that the sort of you start saying, okay, we can’t scale, we actually need now to take a step back and bring that vision element that you were alluding to.
I think the learning and the experimentation was really what we wanted to do in this phase as well, so it was happening, but we also over time and things started growing, it goes from kind of being learnings also into pain points in a way and at some point 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, and maybe that’s invitable, I mean that’s what I’m basically trying to, or the impression that I get.
And famously our former counselor Schmidt said that people who have visions should go and see the doctor, and yeah, whatever.
Yeah.
Okay, so anything else for that phase?
No, I think we touched it.
Okay, so the next phase, I wrote down the years 2022 to 2024, so what did you do during that phase?
I think this was roughly when the points that we were sort of starting coming into that that Guro is talking about, right, so, okay, market fit seems to be there, B2B, we are starting to serve B2B customers, we start expanding to Sweden and Denmark, right?
But all of these things that we were doing to cope with that are now rather intertangled, so the big ball of mud thing.
And we talked about this idea of a burning platform, so we said, okay, he 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, if we can’t move fast?
So this was when, well, when you took a sort of step back and started doing some of that understanding of what do we have, what should we own, what should we leverage from partners?
Yeah, so maybe you can talk a bit about that Guro, because you were there.
Yeah, I think as I also mentioned yesterday, there was several things we started to see that we wanted to do, and one of those points was to start looking into a platform strategy.
So how do we want to be able to serve these countries at scale going forward?
Where we found these 12 capabilities that we need in a platform to be operating in this industry, and that was a bit how things started.
And then we also saw that we needed to address like how do we actually fill these capabilities with the people and architecture that can make it happen?
And we saw kind of the mismatch between how it currently looked like and what it kind of should be.
And that was the point where we reached out also to Nick Thune and Eduardo to get help in that next phase.
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 just before I came in, what Guro and other people were doing, they did value stream mapping.
So this is a way for you to understand sort of what are the activities you do, and then you start seeing, okay, what are roughly boundaries of things that we have?
And this was that initial idea of those 12 capabilities, right?
So we saw these, and independent service heuristics is sort of a technique that Matthew and Manuel from 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.
So what’s – you can check them on Team Topologies’ GitHub.
There is like – this is basically, I think, eight questions.
I always forget, seven or eight sort of dimensions.
And you try to – for each capability that were identified in some way, so value stream mapping, event storming, whatever 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, some of the questions is, could this be deployed as an independent service that you could offer to someone?
Like externally and then buy as a service?
Imagine having – could this be provided as a website to customers?
Do you have a clear customer that was using this?
Could you, for example, manage costs of this thing?
How do 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 good to be independent capabilities.
So this is – this is – it seems like a checklist that you can run those core capabilities through?
Yes, it’s a checklist.
And what was the result like?
How was it useful?
No, I think you did it.
Yeah, so we had different candidates that we run through this checklist.
And what we started to see was that some were clearer and some were a bit more fussy for the answer was yes or no to those questions.
So I think we used that when we embarked on that journey of starting to mapping out the domains together with Eduardo and Niken to – we started with the ones that we were more confident in.
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 the next step of our mapping.
Okay, so you’re basically – so it seems what you’re saying is you did a value stream mapping then you figured out which are the ones who are truly independent service – independent in terms of independent service heuristics and then you started working on them in more detail.
Yes, yes.
Okay.
Yeah.
What’s the reason behind that?
I mean obviously an alternative would be to get to a list of truly independent services first before you do the next step.
But they didn’t have any of that.
They had no – the services were just some monoliths with a lot of things intertangled and they wanted to understand what are – say more like the business capabilities that as a mobility they should have.
And then they started sort of looking at all of the different activities, workflows and things and trying to see what are these essential capabilities that they need.
In some of them they already had some application services, in others no, in others they were all these external platforms.
So that is a way for you to start seeing, okay, 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 deeper what’s there and what should be there.
Sounds like the vision that was lacking before, right?
Yeah.
Definitely.
This was the sort of a North Star of what do we have and where are we zooming up next to improve and move forward, yeah.
From a business perspective, okay.
Also you mentioned listening sessions.
Yes.
So roughly at this time, as Guro mentioned, 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 of these should we start and would be more important for you to start getting really deeper and understanding what’s there and which team should you have there, what systems are there.
So we came to one of the domains that was around the core charging, which is very important for an EV charging company, right?
And then, so Nick and I, what we did was this idea of, okay, Guro told me a bit and the other people that were sort of starting with us told us a bit of the story, but we also wanted to listen to everyone that was working on that area.
So these listening sessions were 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, et cetera, et cetera.
And basically there we just, we were like, okay, what are the main pain points you see?
What are the systems you are already interacting with?
Which teams do you work with?
A lot of different questions to just sense, make what’s here, right?
And the goal was to, because we knew that 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, we go into a more focused sessions and we don’t just bring our like default session and ineffective session in a sense.
Okay.
So, and I took a note that it was about 15 listening sessions.
So what would you listen to?
So these were, for example, teams that were working there.
I don’t know.
So with all of the team, you would interview all of the team?
Yes.
In some cases, all of the team.
I think in this case, it was all of the teams and then we also had PMs that wasn’t necessarily at this point connected to the teams in a way.
So that was some other sessions, I believe.
And then you mentioned people.
Exactly.
So we separated at that time, product was working in a sort of, the product and teams were not necessarily working every day together, engineering teams.
So we had sessions with one and then with the other.
So everyone could be very, just open and candid to not trying to please the other.
So this was a trick that we used, yes.
And then the open questions, as you mentioned, with, okay, with the pain points and so on.
Yes.
So we tried to sort of see what are the big hotspots around all of these conversations.
Yes.
And any more tips how to do these listening sessions?
Yes.
Don’t listen.
Okay.
Yeah.
Don’t.
So that was one of the principles Nick and I set.
We were there to listen.
We 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, yeah, you want to get as much signal as you can, not sort of already trying to bias people towards something.
Yeah.
And I have to admit, that’s the reason why I’m asking.
I think it’s a great technique.
I’m using it myself also, in particular, if you’re an external person to get to understand what’s going on.
Yes.
Yes.
Yes.
It’s slightly different.
So I do one-on-ones with key players, but, I mean, therefore, I can never talk to everyone.
We did a few one-on-ones.
Yes.
Yes.
Yes.
I think this must depend a bit like what part of the organization were you talking to and who wanted to take part in this and who didn’t.
Sometimes availability of people.
Yeah.
There were a lot of things going on.
Yeah.
And this is also when you founded this architectural modernization enabling team, right?
And I think you’re a member of that team?
Yeah.
Yes.
So what’s that team and why is it there?
How is it useful?
You can start.
Yeah.
So what’s a bit like what you’re saying as an external coming into an organization, even if you are good at what you are doing, you don’t have the knowledge, the depth, and also the credibility with people in an organization to actually drive profound change.
So what Nick and I started, we did this with multiple clients and with Circle K, we sort of even ended up writing an article to sort of bring it together.
We can share it later.
But the key idea is there is a big change happening who would be the people from different functions that could help this kickstarting of modernization, particularly that part successful.
How can we start get things moving?
So this is basically after those listening sessions, I think during probably, yeah, Guro was a key person, but we had a few other people.
So Guro more from products, we had people from architecture, people from engineering management, right?
So the person managing the teams, Ian as director of technology and product, also providing like the executive support for this.
So this is a very, I think it’s a very, it has shown to be very effective way to get a group that really can actually help facilitate proper change.
What does that team usually do?
What’s on the agenda?
Very different things every week, but it’s typically the goal was 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, we take lead on doing that, on facilitating them.
You start seeing some things coming up, like, I don’t know, we don’t have enough people on a team.
They may be also drivers to actually get priority for that to happen.
There is a wide range of things.
Can be also coaching, for example, coaching teams that need help on something.
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.
But it varies a lot, to be honest.
But I think it makes very much sense to use it as a tool when you have externals coming in to also have the internal ownership and then also enable the organization to learn things and take ownership to these toolboxes and can kind of utilize this also later and not kind of have externals coming in, do something and leave.
Then you have learned nothing.
But by this, we also were tightly involved with what happened.
But I think also, as you pointed to, it 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 kind of a good group to also see, okay, do we have any priorities outside the transformation topics we’re working on that is in conflict and where we need to really help 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 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 that.
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 reach out to them like, what is this?
I don’t know about this thing.
Can you tell me a bit before I go into that conversation?
So, I mean, first of all, one thing that I understand or that I got is it’s a good idea to have that team with external and internal people sort of to mix it and to facilitate the interchange of knowledge and communication and so on.
The other thing that I’m wondering, so my understanding of the original enabling team and team topologies is more this coaching thing and skills build up and what you seem to describe seems to have some management impact.
Like, okay, so there is one team and they don’t have enough people or we need to prioritize stuff.
That sounds like project management to me.
The enabling team is a very broad concept.
Typically, people associate it as a person or a team that helps another one upskill on a skill.
This is a very common case, but I’ve used it in many other things and I think the same basic traits apply.
And the thing is they should help on upskilling or addressing a missing capability.
And in this case, I think what the AMET, the Architecture Modernization Enabling Team was doing is addressing sort of a capability that’s not yet there, right?
This being, having clear boundaries, having, so it’s a way to, if you look at the, not just the team but the interaction mode, which is facilitating, it also gives you some idea of what we were actually doing, right?
We were facilitating the modernization.
Yeah, so, but I use just as a sort of a side note, I use enabling teams, for example, also for maybe for your audience, very importantly, to express how I think many architects should behave.
They should, if there are conditions, they should behave on helping their teams upskill and address something and then sort of not be so much on the, on like driving decision, if they are able to do it, okay.
Yeah, so, but this may be, it will take us out of it.
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, where it should happen in the organization.
So, I think that was my point earlier.
Oh, I see.
Okay, 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.
Yes, it was.
But then, I mean, they can’t just make the decisions, right?
No.
They were just facilitating.
In this case, Jan was the person there.
He was just one of the, say, the drivers of the organization.
And he was very also important because he was connecting to, say, to the management team and he could also feed them with like what’s going on and also making sure that we had space to make this work happen, right?
So, is that a general advice that you would give, like to have those kind of senior management persons on an enabling team?
I would give that advice if this person doesn’t come in with the mindset you shared, which is he or she comes in and he or she is deciding.
I wouldn’t advise if they are just sort of taking over all of the things.
But having the management support and like this and sponsorship on these things, it’s a make it or break it, right?
So, if you don’t get that, I think I would dare to say that this is going to be very hard to – these bigger changes, right?
To make them happen.
It’s just that, I mean, at the end of your talk, there was this question about the priority that you also touched on.
And I think what you just mentioned about the architectural modernization enabling team seems to be one part of that solution sort of.
Yes.
Okay.
The other thing that I wanted to talk about, so what you mentioned is that there are actually three techniques that you were using, like domain-driven design, team topologies, and world team mapping.
So, what’s the relation between those?
I mean, first of all, maybe – so, what’s the relation between those three techniques?
Yeah.
So, these three techniques tend to show up in many of these journeys.
And then Susanna Kaiser even wrote a book about this because it seems to be a very regular pattern, right?
That we see in organizations that want to change.
And basically, you can see domain-driven design as helping you to understand your business, your domains, and their nature, right?
Is this a thing, a core?
Is this a supporting domain?
Is this a generic domain?
So, how could, for example, you approach them in terms of sourcing?
So, this was a very – so, we used, for example, event-storming and other techniques to start doing a lot of that understanding, deep understanding.
Team topologies, as we probably were already talking a bit, is to start understanding what sorts of teams we have, how do they interact 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 build versus buy.
How shall we do that?
And we used worldly mapping just to start depicting what does this mean in your domain.
And it’s not a binary thing, so certain things inside, maybe you can just leverage from a partner.
So, other things are more you should own.
And we had – so, we talk about, in the talk, there were certain capabilities that were – you were leveraging from external platforms, but they were core domains.
And Michael Ploot actually had a talk yesterday on that, which is – 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 the product teams, streamline teams, to own and evolve.
So, this was just – helped a lot on this, yeah, basically setting what we were going in earlier, like a division for what – where should things be and how should we – also in terms of principles, right?
How do we treat these different things that exist in the organization?
Yeah.
Anything else?
So, I mean, I have the impression, but I might be wrong, that there are quite a few organizations that say, okay, we are going to do team topologies because that’s a great way to organize our teams.
And now what you’re saying in a way is that you actually apply three different techniques and that there is a huge synergy between them.
So, does it make sense to do team topologies on its own?
No.
So, I do a lot of trainings around team topologies, and we, in every training, we try to understand what are the capabilities you have.
And this is – we can try to do some of that independent service heuristics very high level, but if you really want to understand leveraging things such as domain-driven design or worldly mapping, this tends to be like very complementary, and you should not just say, oh, I have this streamlined team, they own something, but you don’t have a very clear idea of what that means, right?
So, yeah, I think people should really sort of cherry-pick what works for them.
As I said earlier, like the worldly mapping, there are some other tech – for example, Nicktoon has this core domain charts.
I’m not sure if you heard about it, but it also allows you to see a bit of the nature of the things you have, the capabilities you have, and maybe that’s enough.
But in our case, worldly mapping really helps a lot, and people clicked with it, and sometimes I think this is also seeing what works for this particular context 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 you probably didn’t want to outsource it.
What are the things as a business that you should really own, and basically typically gives you the money, and the others are more, as the others say, supporting these things you need to work as a business, and maybe some generic, right?
So, maybe you need some CRM or some sending emails, right?
You don’t want to invent sending email.
And core domain charts is this idea where you have the complexity and the value generation.
Exactly.
So, you can try, based on that, see a bit on where the different things are, and get an idea of your landscape.
Concerning worldly mappings, we had a session with Simon Wortley, and also another one last year with Markus Harald.
So, the one with Simon Wortley was actually in this very room.
Oh, cool.
So, if you want to have more information about that, you could definitely watch that.
One 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 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 12 core capabilities to get a good idea about what you want to do, and to create that, let’s say, vision?
You want to go?
I think the 12 capabilities we had from the beginning, and then we started with the first workshop after we had been, I don’t know how many months we used before.
It was two to three months of preparation.
Two to three months.
I mean, it was 15 sessions of listening there, and there was a lot of work going into the preparations as well.
And then, so that was the first workshop, and then we had a lot of work in those after that workshop with the worldly mapping, but also in ensuring we had some common language to talk about different concepts that at that point were new to us.
So, it was a lot of work also going into that part.
And then we focused a bit on the after work from that workshop.
We left with some clear action points, but those action points was kind of promising that we were executing on the next step, and it was a lot of work ahead of us when we 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 a workshop every week, because both the work afterwards and the preparation into, especially these two, I think these were the two biggest we had, were also very extensive work both beforehand and afterwards that needed efforts and focus.
Yeah.
So, if we look, so we talked in roughly, this is a multiple year, we show like a timeline of 80 years.
Obviously, this is a smaller time window we are talking about now.
But I think in those months, so some of the teams were starting already to, 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 deep dive sessions.
Like three days, probably almost 30 people on the first workshop.
And then what we did, and this is maybe an interesting one that we talk about is this, it was a bigger workshop where we started noticing we, and this goes into our point of division, we actually should start understanding what are all of our customers, what are all the experiences they have.
And this was a picture that didn’t exist.
I think many people had different versions of it.
And yeah, and this was really a very important moment to put even more, a bit more framing on that sketch of vision that we were starting to create.
And from there, I think, I don’t remember exactly the times, but maybe you can give some idea, but it was probably in the coming months, we started getting those groupings coming together.
And there has been a work of, a lot of work on refactoring to actually start getting the teams to own clear 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 on a 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.
But I think this was then something to stretch for and gave some people a bit clarity in like, what are we moving towards?
So I think that was also a very 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 Eduardo and one other from the EMET 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 split in these different domains and these different groups of domains?
And I think that’s one of the reasons why I enjoy these case studies, because it actually gives a glimpse about how difficult this all is and how much time it takes.
And 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.
And it’s obvious, isn’t it?
Which leads to the question, so why does it take so long?
Yeah, so I think our here with you shows why it takes so long.
And in this case, so e-mobility is a startup, right?
So you don’t have the legacy of an enterprise.
So this is a very interesting nuance, right?
But even with that context, it takes long because these applications were all intertangled.
There was no clarity, that vision that we came into wasn’t there.
And we didn’t go too much there, but a very important step here was also, and we talk about that on the talk, which is the people side of things, right?
So you had product management in Norway, you had engineering in Warsaw.
So there is nothing wrong with that.
But at the start of that change, they were working rather 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 for people that has spent some time working with teams, you know that this is not an overnight thing.
And so I think this and the refactoring work that Guro is talking about, right?
So we understand these are the important boundaries.
And we show that on our talk.
Things are still intertangled.
This is just a nice picture.
Things need to be worked out.
And this is where a lot of the work that takes time 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 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 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 and mentioning that and talking about that with people in the organization.
That’s what I wanted to say.
There was a lot of sharing.
How are we moving forward?
When people see things, they tend to sort of go more, right?
Believe it in a sense.
Yeah.
So 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 is 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’s going to be different 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.
I have 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 to get into that, you need to do your homework, which is this work that was very intensive.
And so a lot of the companies that think that AI will solve that for you, I think this is a major issue, to say it lightly.
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 part, I don’t think where we are today with AI we have today.
Anything to add?
Any other ideas?
No, I mean, I haven’t tried, but I could have tried to ask AI how should we organize our domain and see if it’s anything similar to what we have.
But I tend to agree with Eduardo here that I think a part of the learnings that we gain 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 succeed in some of these steps, I believe.
Okay.
So, thanks a lot.
Thanks a lot for taking the time.
Enjoy the rest of the conference.
Thank you so much.
Hope to see you soon.
Thank you.
Thank you.
Bye.