Engineered for Change with Andrea Valenti

Transcript

Andrea: they are obviously large shifts, but they become some sort of irrelevant to an extent because we get so used to change the scenario of our focus and our organization that those shifts are not so big anymore because we get continuously to do this.

Ivo: Welcome to Link and Think, where we talk about systems and technologies. I'm your host, Ivo Velitchkov, and my guest today is Andrea Valenti, senior director at Trimble. Ciao, Andrea.

Andrea: Ciao, Ivo!

Ivo: With Andrea we met for the first time about decades ago in Brussels. He was learning to play saxophone. I was learning to play the bass. So we were joined by another friend, a drummer, who was the only advanced musician among us. And we attempted some jazz standards. Then I think we lost contact for a while. later on, it turned out that we have other interests in common, specifically in social systems. It even turned out that we were influenced by the same thinkers, especially Nicholas Luhmann. Then Andrea moved to the States. And recently we had a catch-up call where I learned some amazing things. He had been doing at Trimble, which I found unique and worth spreading. And that's what we will try to do today. Basically, from what I understood, while other organizations were struggling to transform from A to B Andrea created in his sub-organizations something that transformed into a constantly transforming one. Where others complain about change resistance, he made change an essential characteristics of operations. Am I putting it right or?

Andrea: No, he's absolutely right. The organization I'm working with is very dynamic with a lot of acquisitions and activities. So we are confronted with a lot of different cultures and different groups to be coordinated. So we realized at a certain point that it was very reactive and difficult to adapt to the changes without being prepared for them.

And that we required a continuous adaptation. So build like a practice of being, know, capable to adapt to change at the moment you come. Otherwise, the other way around is, was very, very painful. were losing people, obviously we were losing focus and we, our execution was not able to come to place in a timely manner because you're not ready. That's most of it. You're not prepared to handle the change. You have to reflect on it. And there are a lot of prerequisites that need to be there.

A lot of organizations like to move personnel around where actually the focus might be. And then it's like catapulting people in the middle of nowhere and they are totally lost. we build up a process in which people were actually used to move around and they were actually driving in a setup of this.

Ivo: Let's start by you telling us a bit about yourself, how you ended up in your current role, and maybe then about the company, because maybe some of our listeners don't know about it. And then we move on to the situation before this change started.

Andrea: Absolutely. But first off, I still play saxophone.

Ivo: great. Yeah. I do not as much as before because recently when I started my nomadic life, I had to leave my band, with which I played for more than six years. But I still do play

Andrea: So I don't know if you still play the bass, but I try to.

What were the we played, recall? We tried and attempted once.

Ivo: I think it was John Coltrane Equinox. I'm not 100 % sure, but this is if memory serves.

Andrea: Yeah, it's Equinox, fantastic.

Yes, correct, fantastic memory, now I forgot. I still don't play it properly though.

Ivo: haven't attempted it since so.

Andrea: Okay, at least I don't feel so guilty. So, okay, I'm Andrea Valenti, I'm Italian of origin. I've been living in Belgium for 12 years in Bruxelles, where I actually met Ivo. And well, I guess that my, the line of my career was the organizational challenges. that all that is the connection dots within all my opportunities and works.

So I have been working initially in a small aerospace contractor and I was the first Sysadmin. Then I become, I worked with WKTS, I worked at Scroovert at the time. And I started one of the first team of infrastructure and it keeps happening that I have been challenged by a situation where, or the team was to be built or to be recovered. that kept happening for whatever reason. The hiring manager sees something in me of masochism that like this kind of context. Or there is a burnout team that actually on emergency restaffing, or there is a very difficult or challenging acquisition, they come my way. So that's a bit the reason why I keep getting opportunities is to restructure and rebuild teams, most of it. As a side effect, apparently, but because the job is still operation or DevOps or site reliability engineering.

Ivo: Well...so you never get bored.

Andrea: Yeah, I don't know if I would be super happy in a totally flat situation where everything is working perfectly outside the fact that it is hard that you can find such a place. There is obviously nothing that is working perfectly for long enough.

Ivo: Can you now tell us a bit about Trimble and then about the situation before the thing which we started here to call fluid reliability started. I don't know how you call it, a practice, a framework, but anyway, we'll come to that point now about the larger context, the organization.

Andrea: Yep. Sure.

Trimble is a very large organization. It's a global organization, a leader in construction and transportation. Obviously, there are more endeavors, but it's a very large organization that has those. The organization grew from the hardware, especially in, you may be thinking transportation, fleet management of long house, the device that Trimble developed and installed into the tracks for all the plethora of needs of transportation or all the tooling and equipment required for a construction site. On top of that, the organization start to develop software. And so that is the liaison, is this kind of hybrid life between a lot of hardware and a lot of software that get connected to work together. That is actually the key factor.

I myself am in a subdivision that is actually dedicated to construction. We are a SaaS multi-tenant software, primarily. And it's a little franchise of a applications that cover from the owner, from the architect, from the contractor, every single aspect of the life cycle of construction.

Ivo: Yeah, and what was the situation that I think was in place five years ago, if I recall well, and that sort of provoked the change that you introduced,

Andrea: We have been through, as I said at the beginning, is a very dynamic organization. So we went through many organizational changes. So when I joined a specific organization that had its own challenges of the operational capacity, and it's not unlikely that through transform, it was going transformed by the engineering and then by the product team, but the operational part was left behind, right?

So that I intervene in that moment. As from that moment, rebuilding that team, a lot of organizational changes, mergers, de coupling of organization happen more or less every two years. So I can be confronted to getting a new team from a different culture, merging the teams, or sometimes de coupling a team because that team was going to another merger within the organization because it was like a period in which the scope of those franchise was defined and therefore there was a lot of change in that sense. So every two years I got confronted with a change. So in every single place I had to confront with a lot of culture limitation, both in the definition of the job, what the SRE or the operation or the DevOps need to be doing in an organization.

And, their capacity to relate to the other teams and then obviously within the merger themselves. So thanks to this experience, because nothing happened, you know, super by accident. I start to develop an approach to be able to confront those situations. And I started to grow the idea that, even within a less dynamic place, a change is inevitable. And if you really want to operate fast environment, you need to prepare your culture upfront and the mechanism and the organization how actually it can navigate those waters because they are very, very difficult waters most of the time. So that's a bit of context for where it all happened.

Ivo: Does it mean that, and this is something I didn't quite grasp last time we talked, does it mean that whatever you saw that you had to do in sort of a project manner every two years as a transformation, you wanted to become available and running all the time, so these kind of bigger shifts could

Andrea: Mm-hmm.

Ivo: sort of yield most smoothly in that.

Andrea: Yeah, absolutely. Those, they are, they should, they are obviously large shifts, but they become some sort of irrelevant to an extent because we get so used to change the scenario of our focus and our organization that those shifts are not so big anymore because we get continuously to do this.

The idea is based on the fact that we, first off, to rebuild the culture, had to start to, it's a word that everybody uses, to cross pollinate, right? That is what is everybody's mouth. It's funny because the cross pollination, once analyzed a bit more, is different in how it is. It can be within two flowers. It can be within the same flower and can be within flowers of the same branch. So it is everything and nothing. And the funny thing is that we start to take inspiration from that for everything, right? So we can rotate personnel within the same team, between teams of the same domain, or in between domains. And they need to coexist continuously. So a person can experience multiple things. And that helps us, for example, to be ready to move around people. It's not uncommon that the vision of a specific year can be a bit fuzzy, right? An organization has certain challenges in determining what a vision for a full year might be, because then there are changes in the field, there's changes in the market, and we have seen now many changes in the marketing anyways in the last year. So the shift is changing and...what is usually asked is to reorganize the parliament to focus on something else. And usually you hear the noise of the cranking of it, right? That nobody is able to refocus, to move personnel anywhere because it's too impacting. You have to prepare the personnel. They have to be understanding what change is and they have to be ready for that. We start to...consider that as a dangerous problem that we want to address. And we start to have this significant rotation. also, it has been for a certain period a way to counterbalance the remote work. So it does also this other aspect, because remote work, especially in engineering, become a very selfish activity and it becomes totally disconnected of what you're trying to do. Right. So you get this list of tasks you have to do in your room. You go one by one, you actually do 10, 20, and you don't even know what you actually have achieved and you haven't interacted with almost anybody. So you went down this tunnel vision of operation that you have to do something without any context. That was a dangerous logic, especially for operation, because we touch critical systems. you're having somebody completely narrow minded, down a tunnel of nonsense, it can be dangerous taking down systems or making mistakes in customer data. don't want that. And still it's the connection with the purpose, why we are doing certain things. So the rotation and the cross-pollination help to provide context to these people because they now start to see not just their own area of work, but the area of work of everybody else.

And by working on their activity, not only they bring fresh eyes to their work, but at the same time, they start to build a relationship that make them understanding the other team. Cause there is nothing like, you know, uh, suffering with somebody else to understand what, why they do certain things. Now, especially in engineering, there were, there is a lot of religion, uh, in which, you my way is the way, you know, or there is some sort of strong belief that that technology and that implementation is good and that is totally wrong because of a lot of reasons. then realized, most of us realized that even though that is not the best technology ever, it was really fitting in that situation by working with the situation. So the correlation with why somebody use a tool and not is discovered only if you actually.

So we force this discover to make team being able to speak together. So I'm speaking without any structure, that was there.

Ivo: Can you describe more concretely this rotation, how it happens currently? Maybe if it's interesting also how it was introduced and then evolved, but let's start with how it currently happens when it's already something that evolved to a stable state.

Andrea: Yes.

To do that, I have to make a little step back because it's based on analysis of the work breakdown.

Ivo: Yeah, maybe actually you can make two steps back and explain what is a site through liability engineering in general and how it is different or the same in your organization, how it is different to DevOps or other things people can be familiar with. And then from this broad context about your specific rotation.

Andrea: Absolutely.

Well, it's a very difficult definition as all the definition of in technology, especially because I see it as an evolution of the same to an extent, right? With obviously a twist and we can start from the original evolution that is addressing operational challenges with software, with a project that is more engineering than anything. So it's funny though because

To this definition, I recall my first times as a Sysamin in a Linux world, and we never thought that doing it manually was a good thing. to get into the job, you had to be able to program the factor. That is actually the standard of an SRE. You really have to have not a very fluent development background, but is absolutely welcome. In my team, there are many with a development background or ex-developer. Well, they're still developers, actually.

And as an evolution in a way of what was the DevOps or the agile system administrator concept that is now the continuous evolution of our job to keep system up and running. Now, the method is more software and engineering than in any other case, but

Ivo: How does it feel to be such a person? Because when you're a developer, you create something and then people use it. And in this case, you do the same kind of work only to keep things going.

Andrea: Yeah. Yeah. Well, but that's a bit of a shift. We start to look at what we do as a product or what we offer. Right. So infrastructure is becoming some sort of product to an extent, but it's, yeah, it's painful because it's not a popular position. It's not a very sexy position to an extent because we are known only when there is a major outage. our capacity is to be less visible as possible. means that everything is working smoothly. But unfortunately, the moment you speak with us is because only something goes wrong. So we have this kind of, know, relational issue with everybody that we have presented only in a negative situation. But yeah, most of the people that are in this job, they like it to an extent. It's very high responsibility set because again, after us, there is nobody fixing it And he has that like of intervention mode. So it's not uncommon. Then some of us like the adrenaline of an incident to an extent. The need of intervening and coordinating is also an incredible amount of fun because suddenly you can coordinate whoever. You become the incident commander.

And then everybody else during your day by day is of hierarchy higher is now at your disposal.

So it has that twist of misfits in a way. And it's growing into a more organized. The funny thing is that that's bit of the work we have been doing is to reprofile ourselves in a more structured way. Because even though we might be exciting and excitable during certain situations, we don't want to live in a continuous mindset of problems.

There are the two phases of the job is yes, it's cool when there is once in a lifetime problem or that you can recover from by the way, because all the time you have this kind of sense, but you don't want to live in a continuous firefighting mode. And we have to work out to limit that size at max. And that's why I was thinking about speaking about the work breakdown, because we tend to have like two main macro categories, a lot of the volatile unplanned that we cannot plan for and we have to contain, but we can't really control. We can control indirectly by all the method and mitigation we can put in place to ensure that chaos is not, and entropy is not arising our word day so frequently. And then there is like the most scheduled part in which we do the project. Most of, some of them are for delivery, but some of them are to contain and to ensure that entropy is not creeping out the volatile part because we can't control it, so we really have to build a lot of mitigations and anticipation and a way of working that is not actually affecting. A good example that links that to the rotation is the concept of gatekeeping. That is like a shield in front of an engineer that defines on the day to day the front desk to the rest and the back end of our organization.

It is meant to be very fast. It is meant to resolve all the little things that come out without disrupting the structure of projects or the most scheduled activity we have in place. And that is a rotation because it's a very painful week for everybody. It's a weekly base today. It's a very painful week because you get harassed by the full organization on every possible need from reset my password or restart that thing. Why this is not working where is this information and worse actually, but I cannot disclose but there are all tiny chores that are really annoying, very disruptive in terms of context switch or mood switch, right? Because of that can't to So we rotate personnel. Everybody has to see what it is. It has the twofold reason is one,

Every share the pain is a key factor in a team. We all have to share that amount of pain. We also all need to understand what is our problem. So then when we go to the more scheduled part, we can connect what we need to do to avoid our next duty to be much less painful. So automation improvements that are required to limit and control that part.

And the third part is that you work with all the rest of the organization and within your colleagues. So in this specific week, we are moving now finally after some time from three individual gatekeepers. It's to give you the idea how we actually keep evolving on the concept. So we are like three different groups having their own gatekeeping. Because there is a domain knowledge that is linked to the specific application, right?

That the full goal we have is to break that knowledge to an extent, at least for the most trivial part, because if you go to a very high level of architecture, or we go deeper in the knowledge pit, and then it's difficult to really all of us being equal in the knowledge, but in the most trivial part, we all have to be able to handle it. So from three different groups doing their own rotation, now we are forcing one unique rotation. So everybody will be able to answer all the questions for all the application we are actually handling. as the advantage, the first one, I'm building the next larger rotation this way, because that is becoming the pillar for me and for the organization to start to move this personnel across the application. Because now we make a base of knowledge. Everybody knows.

Even by osmosis is enough to look at what it is, the day to day life of another group. It can be enough by osmosis. I don't really need that they operate. They need to see and live that to understand. And after a few months, usually start to click and they start to operate. And after a few months, actually, as everybody else said, they become totally movable items or person in this case, obviously, but from a conceptual point of view, everybody can work everywhere. Usually engineers are very happy on this because they are not stuck in that application. They can see other things. It's very enriching. You see different ways, different technology continuously. So I tend to have a very little attrition because they are very enriched by this. Even though they have to do the week. It's an horrible week anyhow. But we cannot have two people suffering for the rest of the group.

So now we are moving from three different ones into one. For me, it's also, as a director, it's very beneficial because I will be able to slim the amount of people doing gatekeepers because now I have to have some sort of pairing mode because I cannot let one person doing gatekeeping and try to jam the window, right? I need at least two that make a lot of numbers if you scale multiple applications with two people. So as soon as this pick up, I'm going to half the personnel that are working on the gatekeeper and making this rotation continuously. That is a challenge per se because then open the concept of how we can maintain knowledge within a continuously rotating group. Because that is the concept of now what is the challenging pairing on development how you keep the work content flowing while changing the people that are operating it.

Ivo: How do you manage the risk associated with gatekeeping? Because gatekeeping would normally bring bottlenecks and will slow down the resolution time and for you it seems that it has the opposite effect. How come?

Andrea: We determine what is the real scope. So it has to be anything that needs to be executed quickly, expedited, or that is small enough to be performed within such a team. Everything bigger needs to go through a different process. Usually we challenge a lot. Also, we build up a knowledge and a culture in which we challenge the requirements. And this, for example, a very disruptive, seems crazy, but is a very disrupting action by itself, challenging requirement is very unsettling in the organizations because everybody come from the perspective that a hierarchy is there to execute the best option all the time. We reject that concept. We want to understand with the requirement and with the person that is the requester, if that is really the thing that needs to be done. Because again, we are the last stand production availability so we feel that we have to ask why you do this because it

Ivo: Does that happen with that are more on the how level instead of just being only at the what level? Is that the case where you reject them?

Andrea: No, no, it's also the what or the why even. Because the moment you go poking the requirement, it's really hard to detach the how from the what and the why. mean, we are speaking about the execution moment, right? So the how can be totally applicable to the what and the why if I understand it. But most of the time, not most of the time, sometimes...we detect and we discover a detachment. We are doing something in a specific way for no apparent reason, and that will not bring the resolution of what we are trying to do. That's why it's important for us to ensure, because we are already not very popular as a team, if we start to execute stuff that they don't deliver the appropriate resolution to a specific why.

We tend to be put under the bus. Well, it's not because it's because the execution was the issue. How many times we heard the execution is the problem, but sometimes it's the connection with the execution to the reason of the execution. It's not just the execution. But it's difficult to show it after when the thing is not delivered. The problem is arising is very hard to have a conversation on listen, but you asked this. I have done it. The result is this.

That's because why you ask it is too late. You can't have that conversation. The heat of the moment, the failure and everything is not possible to have. We have to anticipate that necessarily. But even with the idea of delivering the thing, if we really want to deliver something, we have to be sure we properly understood why they're trying to do something. Obviously, most of the case with very small task is very evident.

But even within specific tasks, they show the background of a very big improvement for the organization that needs to happen. I can't go into details, but habits in an organization tend to build up over time, and they get detached from what they are trying to do. Especially when you start to shift in focus, now those habits keep happening, your goal is another one, and those are at the treatment of your new goal, but you can't connect them.

A very good example can be data ownership, right, in general. But this is not in my organization, it's in the industry. A lot of group, they want to monetize data, But they have a lot of practices in place in which the data is given for free. You can't have those coexisting. If you want to do this, you have to start to limit the other in a way or to mitigate the other. You have to have a plan. I'm not saying I like the...

Ivo: That happens every way,

Andrea: The idea. But I'm saying just to show that the disconnection between practices and a new goal and they don't work together. Actually one against the other. So we challenged them.

Ivo: What comes your way apart from accidents and requirements?

Andrea: All the implementation, a lot of customer activity. Being a SaaS organization, we do lot of migrations between solutions. the full real ability realm that is huge, all the maintenance, improvement, architecture, staying up to date with the technology, trying to find ways to operate that are faster and cheaper all the time in a way, or more scalable, if not cheaper.

And all the compliance, the execution of the compliance, tend to come to us, a lot of cybersecurity, execution of the mitigation or the being in those situations which we have to intervene.

Yeah, that's most of it. That's most of it. Projects in general, there might be of any kind of shape and form because from this span a lot of innovation improvement, need to be happening. Most of those organizations, they have like a very dated way of working some of them and we have to renovate and improve them and bring them to modernity.

Ivo: Yeah, can you tell then a bit more about this cross-pollination which you described as a sort of a fractal?

Andrea: Yes, it's having multiple aspects. And a funny aspect of this is that it's also not only in term of rotation, but in term of hiring strategy. So the hiring itself is part of this. Obviously, there is the full rotation in which I try to rotate personnel across projects. We discussed about the gatekeeping that was the most trivial set of work even though it's very challenging mentally. But then we start to build a higher level of rotation that is based on micro teams. There are teams of three people, four people max, not duos. They have to have a majority in it, right? The building is like, they're good Durkheim studies on duality and democracy and majority, right? So you have to have at least three.

And we assign them epics and larger projects. They become totally independent in everything. So we, as a team, we have cadences in which we meet, we review the activity, we clean the backlog, we do everything. So we give updates, we do reports. Within the micro team, they are totally on their own. They decide their own cadence. They decide how to meet. They decide the kind of reporting, given that keep the stakeholder satisfied, at least the one that has an influence, by this step, to them to choose how and what. And they work together in a specific epic. We then rotate after X amount of time. We rotate some out of the micro team, and we put new people in, keeping one person at least to keep the history, the knowledge of what has been done, and to help the new to get on board.

So we keep also rotating through projects. you don't get assigned a project forever. You get assigned a period of that project. And then you rotate to another project. If you want to stay, mean, again, there is a lot of autonomy also in deciding the rotation. If somebody is really interested in the specific, we have no easy to rotate, to leave that person. If there are two, we leave two and we rotate one. We cannot allow them to continue forever, the three or four of them we are open to accommodate. Sometimes, know, somebody is super excited about a specific one. We don't want to make any unnecessary cruelty on the person. usually they rotate. They rotate. And we have this logic. So the project themselves, they are kept over time by different people. There is a limitation of skill set, though. And that's why we have this rotation of gatekeeping and other rotation is to start to feed knowledge to enlarge larger rotation on that. Other way of pollination that is within another tree, right? Because this is only all within the same flower or within the same branch. Now, with other plants is more difficult because then we tap into the why being ready to adapt or change is important in a large organization. My challenge to... to do this with the LAR, the other groups is that they are not prepared or structured to host somebody from my team and give somebody of their team to me. And that is the challenge, right? Because then, or we create holes in other organization. So I take a person from an organization, they are not able to rotate around. So I am actually creating a performance role in that thing. Or they cannot counterpart, so I just giving people away for the sake of keeping the rotation or having them in the future. And that is getting complicated because I'm outside the realm of my deliverables, right? What we do there is try to be more ad hoc and more opportunistic. And then when we have a project that makes sense between two groups, we do that. I force that to happen. But it's more opportunistic when you go outside. I balance this by hiring them.

The team is getting a bit of an appeal from my domain again, and we have been able to attract a lot of people and personnel from other groups. Actually, we have been growing only primarily by referral or by internal acquisition, and we have like only 20 % of market search that we need to keep the thing fresh and to get more fresh blood and fresh eyes to see how things are. But it's not like... more than 20 % in which we go in the market. All the rest are referrals from colleagues are working in the team. So ex former colleagues coming and applying. And it's a good 30 % or something. And the others are internal personnel coming. The funny thing, or the interesting thing is that the internal personnel come from other divisions. So what I cannot do by interacting with the other division, I can embed in the team. I'm getting personal data, working at another group and that make a bridge of knowledge and bridge of relationship with that team. And it's cool because then we can grow on projects, we have like connections and membranes with them. It's also more fascinating when I can... offer a position from somebody that is not from the same realm. So technical support or professional services. Because I need in a team like the SRE, I need many skills, not just vertical hard coding of infrastructure code in multiple languages and conjugation. I need also some more soft. So those are fantastic bridges for projects in which then suddenly two friction groups, they're working much better because I hire somebody from that group. And those person become like cultural bridges in which they allow my team to understand why they're yelling at you. That's so bad in this context because, and to explain to the other team why we are pushing back so much on that specific thing that we're apparently willing to give our life to not make that happen. And it build up an execution performance over time because now we get rid of a lot of unnecessary discussions and frustration. And we try to have like this very focused conversation wanting to happen with what we can do together. Right? So not what should be done. Cause we have most probably two different opinions on the topic, what should be done. We can shift a bit, not all the time can start to shift to what can be done. And again, it opened the creativity because then the two teams, they are open more to the others if they start to really work together. But it's hard when the conflict priorities are in place. This is a cultural now. So those cultural agents that we place in the team, they help tremendously. So it's a sort of rotation anyway, because it's very purposeful.

It's not easy to do it, especially in a large organization, to have an early career program or a talent program, right? Because again, we are creating holes in an organization to get people of a specific quality out, because there is not a structure to replace them. And ourself, we have to find a very hard balance in which we have to take a deep of knowledge for, because we are not hiring a full... experience SRE, we are hiring somebody from a technical support. The gap is on us to fill. We don't hire a person that is prepared. So it's a bit of an investment that usually pay off tremendously because it gives mobility within the organization. And you can change work within the organization. So you give a lot of morale. The person that come on board is absolutely driven. We had to provide some mitigation for that. So our way to approach this is we

We don't want the person to be overwhelmed by starting in the new job. So we start like three quarters ahead of the hiring date to get the person as a share. It's a sort of rotation, right? So I'm getting fractalized there. They start rotating our team. And they start to, we agree with the counterpart that we are going to make the person working only on activity that benefit liaison between the two groups. So whatever is between the two groups, that is the scope why this person will work for us to improve that connection and help the person to translate his knowledge into ours and ours into theirs and join without the overwhelming sense I don't know how to do a job. Most of the, I am very pleased when they actually very candidly say, well, it was not that hard. Well, it's just three quarters we are doing this. So it's not the first, it's not really your first day. It's the first day because now you are fully responsible for before obviously we shield the person because it's a matter of responsibility from the day of hiring. Now is all your problem, but it's the same job that he was doing or she was doing from a couple of quarters at least. So they are not getting overwhelmed. it just, it's a, it's just a the correction of how to handle the cultural transition. So it's another aspect of pollination in a way. But now the full point of the proposition is I'd like to see how we can actually expand it to a larger rotation, a certain point. How we can, as an organization, not create holes to each other's, but be ready to move people around. Because it's not evident.

Ivo: That's a question I'm going to ask in a few minutes, but before that, you said at the beginning that you had a merger of some kind of major disturbance every two years. And I'm sure you had those in the last five years as well. So how did it feel differently now when you have this fluid new operation, when such a big change happened, how it felt?

Andrea: I would say the pain is the same, so the pain doesn't diminish. And we have some sort of repetitive brain injury of doing the same thing again when we take a deep. But the problem I had with that is every time I had to step back in maturity and handle less maturity, I was suddenly interrupting a maturity work of a certain quality.

After a no, you you go through this maturity, grow at a certain point, everything start to flow. You have been optimizing, innovating, cyclically over time. Now you start to flow and you find yourself, okay, now I'm going to do this project finally. Cause certain advanced project you can do a certain level of maturity. can't be willing to do advanced project right from the get go. If you don't have the prerequisite in place. So you build up, you build up, you prepare everything. So you're now you're ready.

And now suddenly you have this low maturity coming into that doesn't allow you to continue the high maturity because you have to take care of the low maturity group to be back to speed because it's a drug in a way. Culturally is a drug because the team now forgot to deal with very immature situation. Now he has to be back into. So there is some sort of dysfunctional situation which are very efficient and working team need to be confronted.

What I want to say, there is no way to isolate them performantly. I know that a lot of conversation I had, why you don't isolate them and keep flowing because we become at that level of maturity, not by isolating ourselves. So it's counterintuitive for me. I don't think we'll last. That team in that moment will not last forever. So isolating them is just like a flower going to lose all the petals at a certain point. I need to find a way to reignite and reach that work is really, it's not self-sufficient, the performance team. You still have to work with them, on them, and they have to change. So we have to go to the low maturity team. So we have to put the high maturity project aside for a second and go back to base one. Where is your visibility? Where is your money?

Where is the first gate key? Where is the documentation? Let's build it again. So we rebuild the app. So by doing it multiple times, what I can say is not less painful. I can go back to what I'm doing much faster.

And that is the advantage for me because I'm also passionate about what I'm trying to do. So I have a very beautiful, no, just standard that I have to play. Unfortunately, now that my new mate, he doesn't have an embouchure and everything is weak and squeaking all the time. You know what? Let's work on long tones again for quite some time and then we can go back because I really want to finish Echinox playing.

So the time that this person goes back to speed and I can go back practicing economics again is the value I find in this. Because it goes faster. There was like recently an acquisition. were able to, at the beginning we were spending a couple of years. Now we were able to spend six, eight months to go more or less the same.

Also because now the organization and the cultural organization is present. So the first time was two years, also because there was nothing around. Now there is like this kind of pressure and the rotation help a lot of pressure. Then you get somebody with a different expectation that is not willing to compromise on everything. It helps a lot to get rid of very, very bad habits quickly.

Ivo: Does it create a feeling of all this constant change that people need to learn all the time. when you then have feedback from how people felt before and after this new way of working. So how this constant learning feels overall as organizational learning. In what way it is different than what it used to be before.

Andrea: Most of those, now my team members are coming from places where they were somehow stuck in a position. Because in a small group, you end up being stuck in a role.

Ivo: Now it's the other extreme.

Andrea: Now is it, is they, they, some of them, they balance better. So it's also up to them is a, don't force it too much. Right. Well, we do, we do force a certain point. is a moment in which if you can't really stay in the rotation because you really want to, have, we have to have a conversation, because we believe that is foundational. Now we can balance it. but the person has to rotate. And if we, if that person keep coming back to the whole bar bits, we really take a decision to move that person to a different place. Because we need that to take... There is also another side of things. If you look at the innovation of a process, I need people rotating because I don't need the same person with the same set of belief and culture to tune to a process. I need the process to be continuously challenged.

And then continuously is not every day. I mean, there is also an amount of things we can do. We have a focus of changing the way we work every quarter. It doesn't mean we change everything every quarter. There might be a focus on something because it's still an incremental work. In a year, we change a lot. In a quarter, we change not as much as in a year. In two years, most probably we have changed the full set of things, because we went through A to Z to an extent. Some we just confirm. We are not obsessed with the change, per se. We are obsessed for the habit of not looking at what is something. So if something is properly working, there is all the time a reason to have a conversation on our process. I really have never, ever found something that was really perfect. Because again, we forget that there is a context shift as well. So the process or the activity can be perfect in a vacuum or in the previous context, but the context change is that delivering the same now that we have to do something else.

If you look at the process, yes. If you look at the context, now there is a mismatch. You're doing something that doesn't bring water to the main river, because now you have to bring water to another river.

Ivo: To what extend this new method of work is suitable only for your line of business inside your organization? To what extent you can replicate it to other divisions? And then the other question would be, do you see it working in other kinds of organizations? Of course, not just by copying it. It should be adapted always, but overall, what is the replication potential of this method?

Andrea: This is a difficult question, Ivo. So I think within the same organization, what we are trying to do with the TRIMBLE is to propose this to other departments that are not under my supervision. So to see how this can scale. We are still within the same realm of work. So there's the redevelopment of infrastructure. Given that most of what I have taken as inspiration, are like sociological or sociology of groups concepts. I do believe that some of them can be applied to other contexts. because in effect, it just happened for me to apply my passion of sociological study to what I do. It's not the other way around. If I would have done something else, most probably I would apply the same principle to my day-to-day realm. So...

I wouldn't say it's connected so hard except by life. That is this the job I have and this is where I had the opportunity to practice or to try to develop something is what I do. But I don't see it so much correlated. Obviously there are some important caveats in where you have to have a certificate. You have to have a definitive size.

A team of two is going to be already doing this. Most probably a team of three is most probably already doing this.

within themselves, but again, within the same flower, but not with the other flower because there is no other flower. So, you you have to have the kind of population of flower to cross pollinate. And the other thing is the verticality of domain knowledge. Depending how vertical is the domain knowledge, it might be more difficult to, but that's why we broke it down. Is the rotation of gatekeeping is the rotation of what everybody can do.

The rotation on the microtheming is more driven by knowledge. So they're not equal because they cannot rotate as fast. The idea is that by building the geek keeping knowledge across, I'm building up. And by doing the microtheming, I'm building up over time. hopefully at a certain point, I will have a faster rotation in the microtheming, but they will never have the same speed on the two rotations. By nature, they have to be different.

This can apply to other places where there is a very vertical knowledge domain in which the rotation can still exist, but it has to be slower or longer because now the knowledge is the issue. So that's what I would foresee in a different context, for example. But most of this can be adapted. Well, the idea of adaptation is the foundational part. So I would say I wouldn't believe that it is an adaptable method if it cannot adapt itself in a way.

Ivo: Unfortunately, we are reaching the end of our conversation. have two more questions with which to finish. One is, so I think you covered a lot of ground, but was it anything that you find valuable and there was so far no opportunity to share in this talk?

Andrea: I would say another interesting thing that we are now reflecting because most of this is, I'm passionate about this because for us it's also a reflection of how we work, So the main focus and the main passion come stem from that. We have been a Kanban team from the beginning. That is not a process that is very well known, that is very driven towards efficiency and flow of work, right? And the amount of work you can carry at any given time. there are as a built-in sense of focus. But over time, we ended up detaching the throughput from the value of what we were doing. So why now that we are looking at is how we actually start to deliver the sense of value to the teams.

Now we were speaking about the micro teams, how they know that doing three phases of a project or a hundred tasks is doing anything at all. So we are trying to shift to the sense of what we are trying to achieve, right? So especially because if we want to have like autonomous team, their Northstar is going to be the intent. I want to achieve that. I actually don't care how, that's all your problem, guys and ladies.

But that's the shift you are trying to do. So we are changing a lot of our metrics, measurements from a purely throughput oriented concept to a value oriented concept. It's very hard because most of our reporting upstream are based on throughput. But we feel that that metric has literally little to no sense for the team deliverables. Because again, I don't care if you do five phases of project. Phase one has to have a meaning. As a good example, most of the project were break down by phase one, phase two, phase three, and then project is complete. It was very hard to determine what did we achieve by phase one. And it has to be tangible. It's not just like half of a bridge. I can't use it. It has to be tangible, something that I can use.

They can see and they can validate is useful in a way or the other. So instead of breaking down project based on throughput, you're trying to break them down based on deliverables, so value deliverables in a way, something that is presentable.

Ivo: That reminds me of something I noticed last time about having open epics. Is it related to this value driven instead of...

Andrea: It can be, it can be. What we want to do ourselves is more on the, we rotate a team and when that activity is finished, there has to be something tangible that is deliverable that they can see, touch and showcase to us.

Usually it's difficult to show cast, you know. 20 tickets, 20 tickets. What does it mean? I don't know.

Maybe there are 20 tickets that we're going to be harvest down the road in other, and you need other 40 to harvest any value. But then we have a, we have a problem of intent and purpose with the team, especially if we start to rotate. Then we, we need a way that the rotation is not totally oblivious, right? That you just get in this kind of washing machine and you get out of what have I done? I don't know. I have been in three projects. I didn't know what to do, how they are useful to anybody. So when you get out of the washing machine, you get with a specific set of clothes clean. That's what I washed.

Ivo: Yeah, well, and what's next?

Andrea: we don't know? Alright, Ivo.

Ivo: Isn't anything that your retrospective show that it's still not working so well and next you are going to address that.

Andrea: Oh yeah.

There are plenty of items. I guess that is the inevitable of everything. And that's why we keep reflecting on the items is exactly because we have plenty of items to fix. We will have most probably forever. So we want to iterate over those and address them. what I can say, well, today we are really focusing on this value deliverable of the metrics because he has a large impact.

Also culturally, we have to, or organizationally, we shifting from a throughput-oriented organization. How many things have you done? 10, 15. Two, what have you done? Well, I washed those clothes. Not 10 clothes, I don't know, washed 10 socks. I don't care, I don't need them. I have them. It's a large shift, especially in relationship with the others. Because then it's becoming... a lot of work to be done, how to both reassure people that the work is done alongside to help them to see that the value is what counts. Because there is this kind of an honest connect sometime that we have to make quantity work for the sake of making quantity work without and forgetting what we're trying to achieve. So that's the next focus. That is not evident especially in reporting and relationship with the other departments.

Ivo: Thanks so much. Was a great story. Thanks a lot.

Andrea: Thank you, Ivo.