About this talk
In this talk, Oscar discusses the challenges of implementing change within large organizations, focusing on how engineers can take their ideas beyond their teams. He emphasizes the delicate balance between standardization and team autonomy, noting that while standardization can drive consistency and efficiency, it can also stifle innovation. Oscar provides insights from his 17 years in the industry, sharing effective strategies for fostering collaboration and participation among engineers. He highlights the importance of organizational clarity, understanding team competencies, and recognizing diverse communication preferences. By illustrating these points with real-world experiences, particularly around microservice architectures, he offers actionable advice for leaders to support their teams in navigating the complexities of organizational change.
Full transcript
Yeah. Shall I get started? All right. Welcome everybody. I hope you're having a great day at Dev World. I've definitely already seen a lot of talks that gave me a lot of inspiration and energy. My name is Oscar and for the next 30 minutes, we are going to talk about change. Change in large organizations. Because as engineers or people in the tech industry, we're constantly learning and
reinventing ourselves. We apply critical thinking, creative problem solving to do things better, faster, cheaper, or maybe even all of the above. And a lot of the changes or ideas that pop into our head every day, they apply to our specific team, a problem that we're solving. So, we can actually do that fairly quickly in an environment that we trust, that we know. But what if you have
an idea that doesn't just solve a problem for your team, but for maybe eight or 10 or 20 teams or whole divisions? How do you take those types of ideas forward in a large organization? Now, after running around those large organizations for about 17 years, I've definitely seen my fair share of things and done my fair share of things that are really, really ineffective and didn't move
the needle much. But luckily, the more times you do a certain thing, the better you get at it. So, I also learned a couple things that do work really well. And I've seen also other people do things that work really well. So, let's talk about those. But we have to start with the fact why is changing large organizations difficult. Right? If you look at a at a
small organization, ideas and thoughts, they move without friction. But there's a couple of things that make it more difficult in a large organization. First of all is that large organizations always have to do a delicate balancing act between standardization on the one hand and the autonomy for teams to build software in the way that they want to, right? Then that balancing act makes total sense because standardization
in itself has a lot of benefits as well. If you solve a problem once, you do it very consistently. You hire or attract talent that actually solve that problem really well because that is what their core expertise is. But of course, the main benefit is that you don't have 15 to 20 teams running around the organization all trying to solve the same problem. They can focus on
problems that are unique to the reason that their team exists. But if you take standardization too far, you end up limiting flexibility. Uh you stifle innovation at the and at at the end of the day, you create stagnation. Now, luckily, a lot of large organizations are moving away from this centralized imposed standardization model to actually developing building blocks that teams want to use because they are good.
So, we often call those golden paths or paved roads. We have a bunch of different names for them. And you typically create an engineering enablement division to actually support all those building blocks. And that creates a second challenge, collaboration in large organizations, especially across divisions. It doesn't happen on its own, right? You have to invest a lot of time and effort and energy to actually make that
work. You have to introduce people. You have to create success stories, but you have to keep fueling it. It doesn't happen on its own. And the third uh thing that large organization typically struggle with is the way that they facilitate participation by engineers is largely based on very traditional approaches. It's all synchronous which unfortunately means that it's usually quite biased towards outspoken engineers that have an opinion
ready within 3 seconds. Right? Think of the typical special interest group. You have a bimonthly meeting. The agenda is fully packed because it doesn't happen that often. You have high-speed presentations, questions, discussions going all over the place. So an outspoken engineer can thrive in those environments, but a more introspective engineer that actually likes to sit with a problem for longer is typically not able to participate to
the same extent. Does that mean that special interest group meetings are bad? No, it doesn't. But it does mean that in order to really make sure that your entire engineering community is able to participate, you need a larger set of structures in place that caters to So, as a leader, there's a lot that you can actually do to help your team in this space be more effective
and do things on their own. But first, let's look at an example of such a change that I'm currently involved with. Now, by a raise of hands, who thinks setting boundaries for services or microservices difficult? Thank god I'm not alone. Um, well, even if you start from a blank sheet of paper, it is really difficult to set boundaries and they keep evolving over time as well. So
you need to be um yeah you need to be aware that you're not going to get it right the first time and the what is right is also shifting but many large companies like Albertine that have been around for a lot of years they don't have the blank sheet of paper they have 20-year-old IT systems that aren't built for the challenges of today our master data backbone
is a great example that was in place well before we went online as Albertine well before we introduced home shopping well before we introduced hand scanners in the stores. So our company changed but those IT systems remained and of course we solved that just like the rest of the world does. We built a service layer uh around those systems. We give that service layer a local set
of data to deal with the the the scale that we need spiky traffic that we need especially during Easter and Christmas can be uh quite quite messy. Um but you get better at a certain architecture over time. So fast forward a couple years when I joined as an engineering manager my engineers came to me and said Oscar those microser that we built they are really in need
of a um yeah a redefinition and it didn't took me long to figure out why because they weren't just decomposed based on the business domains that we support which is quite typical in a microser architecture but they were additionally decomposed based on their technical responsibility. So each microser in reality was multiple physically separated components. One was responsible for accepting and persisting updates from that master data backbone
and another one was responsible for serving out requests to our website, our app and all our other consumers. And we have a lot of different consumers. Now um as good as we are at building microser today, four years ago we it was just a new architecture to us, new technology stack. So we really wanted to isolate uh failures in our system and to make sure that our
APIs are always up even though our internal landscape can be a bit finicky. So that was one of the core um design principles. Nowadays our engineers and there's a couple of them in the audience they built amazing microser and they don't really need to rely on physical boundaries alone to achieve that type of failure isolation. But that comes after years of experience new patterns and better technologies.
And I think this is a great example of how different types of things that happen can change how you build software. External things can change like the introduction of online, but also internal circumstances change because the moment you start with a new architecture, you're not going to instantly be amazing. It's going to take a couple years, but once you get better at it, you find better way
better ways to do something. So if you if you just keep doing things the way you initially did them, it's not going to be great. And I think this is a typical struggle for large organizations is how do you help engineers move the needle and how to do things better and differently. Now as a leader I'm an engineering manager myself but we have different types of leaders
in our community of course there's a couple of really critical things that you have to do. First of all is you need to create organizational clarity which is a very fuzzy term for how well do your engineers actually understand the organization and that's not only the strategy right where do we want to get and how we want to get there but also all the structures and processes
that we have in place to actually achieve a strategy and all the roles that we built around it right so how does the company actually work now it doesn't take many corporate meetings to start waving around the strategy right we talk about it all the time So everyone understands the strategy but the layer beneath it those processes and those structures often unfortunately don't get the same type
of attention in terms of how well we document them and how well we explain it to engineers as part of their onboarding. So many engineers and large organizations will feel absolutely lost if you as a leader don't support filling in those organizational gaps. Right? If you just say let's leave it up to the community and then three months later you're disappointed that there's no participation yet then
you have only yourself to blame. Right? So as leaders it's really important that you create that organizational clarity. The second thing that is really important is that you actually look at the competence of your team. I hope as a leader you have regular check-ins with them. So you know them very well. You are what their current strengths are and what their natural tendencies and behaviors tend to
be. But a lot of times we focus too much on the hard skills especially in early stages of a developer's career right it's what technology do you need to learn to be better at your job but we don't really focus on the nontechnical skills that help an engineers build great ideas. So as a leader, you also have to sit down with engineers and explain that there there
are certain skills that can help them articulate their ideas better to a larger amount of stakeholders to look at a problem from different angles to tie it to business value. Um and all these things that that can help you from having a great idea on paper to actually getting it done in a large organization. And you as an leader should help them uh in building those skills.
you should support them and you should encourage them and on a team level you need to set some guidelines together with the team like if we have a great idea how will we communicate it to the rest of the organization now and finally as a leader you also have the responsibility on a team level to recognize the the thing I talked about earlier not all engineers think
and prefer to work in exactly the same way one engineer might like to call you and bounce ideas IDs off of you and that's the way that they thrive other people want to sit with a challenge, think about it and come prepared to a meeting with a good story. So you also need to on a team level to think about structures how you can support different engineers
to participate basically on the same way. And a very unfortunate thing that I found throughout the years is you also have to battle a very drilled conception that the only way to participate in this space is by being visible. Right? If you're not the one presenting, there's there's no goal for you to actually join. And just like a Hollywood movie is not just made by the actors,
right? You have a whole group of people working together. It's the same with building great ideas. If you don't like presenting, doesn't mean that you can't contribute in this space. And but the tricky thing is if you historically never got the recognition for those activities which is unfortunately in many large organizations it's all about visibility then it's very difficult to motivate people to get into contributing again.
So you you need to actively recognize that this is the reality that we live in and actually make sure that you appreciate engineers for any activity that they do and also make sure that you spread the message to the broader organization that not just the guy or girl presenting an idea was amazing but the whole team came together and each individually contributed certain things. If you do
all these three things, you're not only a great leader, you also help your team build ideas in a much better way because a they feel motivated to participate. They understand the organization well enough that they know where to go and they have learned the skills or are actively learning the skills on how to be better. there's still a process that you need to follow and of course
how much time you invest in this greatly depends on the scope of your idea, how many teams are involved, the amount of stakeholders that you need to convince. So you can spend anywhere from a week until months in this process. Uh it it highly depends but it starts with actually testing if your idea is viable, right? Do we actually want to spend our time and attention on
this specific problem? The second one is building a good story around it. And the third one is gathering support in the organization to actually get the idea off the ground because that doesn't happen on its own. Now, there's 10,000 things that you can do to test the viability of an idea, but there's three things that I always want to do, and that is first understand the historical
context. How did the current solution come into place? Why did it come into place? Who was involved? And what trade-offs were made at the time? Then reason about what actually changed to make room for your idea as an improvement upon that solution. Was it an internal circumstance that we just got better at dealing with a certain kind of problem? Was it that when implementing the previous did
a bit of an oopsie and we missed some drawbacks and that we're now really struggling with the results of that? or did a new tool hit the market that just makes solving this idea 10,000 times more easy? Being able to articulate both of these things clearly in a conversation when discussing your idea will take you from, oh, here's just another person with a new idea to an
intelligent sparring partner that knows their and that will make all the difference. So spend time actually figuring that out. Now the second thing is when you actually create a new solution, we tend to kind of yeah let's say rush the design process right and you really want to battle test your design early and a great way that you can actually do that is with a workshop technique
called riskstorming. I always do this with my teams. You basically put your idea on a flip over or a whiteboard. Every engineers can put stickies on every single thing that they think is a bit icky or worries them. You talk about all of those things. You categorize them in their likelihood of impact and their likelihood of occurrence of the impact and the likelihood of occurrence, sorry. And
then put actions on it, right? Some you can maybe even solve, some you'll just have to mitigate. And the worst type is just having to accept some of them. But at least you know, right? So spend a couple of iterations in this phase. And then finally, build a working version. Because as easy as your idea may sound, every single time that you actually build a working version,
you will encounter little nitty-gritty things that you don't find on paper. So build a working version. And where you spend the time building that working version will highly depend. For example, in my space, resilience is everything. So I will find the thinnest functional slice that I can possibly find, implement that, but also make sure that there's enough non-functionals implemented to give my stakeholders the confidence that this
isn't just Oscar trying to new cool new things, but this is actually going to work in production. Of course, if you're in a completely different space, non-functionals may be not that relevant for you. So then you actually want to flip it around, right? Don't do too much nonfunctionals. Do what actually matters to your stakeholders. Now once you've done these three things I think in general you'll have
a really good idea if your if your idea you have a good idea if your idea is good enough um you can do more right you can also look at the best practices out in the industry you can look at the adoption effort for teams on how to actually implement your idea and things you can do to even reduce that but it kind of depends on how
far you want to take it but these three things I think are really really fundamental Now once you've hit the stage where you actually build a story, be aware that communication is very organization specific and audience specific. So if you understand which people you want to reach with your idea and hopefully typically you do, try to sit in in one or two meetings where you're not the
one presenting so that you can observe how do they behave, what resonates with them, what annoys them, how do they document decisions, how do they communicate? Because the more you can tailor to their reality, the lower the chances is that they get distracted by how you're trying to tell something and listen to your actual core message. Right? And for a good example, if you are sitting in
a session and someone visibly gets annoyed when he's interrupted and you know when you're presenting an idea, as excited as you are, hold yourself back a bit and don't interrupt that person. Right? At the end of the day, this is a very human game. So the more you understand who's sitting across from you and their preferences, the more effective that you will be. Now, of course, any
good idea also has some details and a high level uh story line, but please always start at the high level story line. And the reason that I say this is the a common mistake I see is for an idea, we build one story for everyone. And that is typically not doing an idea justice because you have different stakeholders that have different worries, different needs and different dreams.
So if you can create one highle story but underneath that a couple of stories where you where you put different accents on different details, you will often be much more effective while still being consistent in the core message that you try to communicate to all of those people. And finally, once you document this, please, please, please be sure to also document your decision-m principles because when someone
looks at your idea, it is so infinitely helpful for them to understand your mental model throughout the whole process, how you made ideas or how you made choices and how you how you evaluated trade-offs. It will make all the difference and in any conversation you have, it will be a gamecher. Now, once you've reached this point, you're almost there. The only thing you still need to do
is actually go out in the community and gather support. Now, if this is a completely new thing to you, start small. Find a couple of engineers that your team already works with quite a lot, right? That are relatively safe space. Uh especially if they are also suffering from the problem that your solution is potentially going to improve or even completely fix. So get that first couple iterations
in on your idea, right? Gather their feedback, improve upon the idea, but at some point, what you really want to do is two things. You want to find engineers in the community with a lot of informal authority. And what I mean by that is not authority that they're a staff engineer or an engineering manager, but they gathered respect in the community for what they did for the
community, who they helped, and who they supported. These are often really vital voices in the community that even though they're not formally the decision maker can make a day andight difference for Now once you found those and also uh presented your idea to them, another good thing that you can do and that I really recommend is involving deep thinkers, right? those introspective engineers that don't always speak
up as as the first ones during a large meeting, but that often have amazing ideas and try to find them outside of your own team. And the reason for that is that deep thinkers that have a different problem space are the most likely to get you fundamentally new perspectives on your idea. And those engineers will be a little bit more difficult to find typically because they're not
the loudest outspoken ones. What typically doesn't work well is trying to individually reach out to people either by calling them or via teams because you don't have a trust relationship with those people. What works way better typically, at least in my experience, is trying to gather a group of managers, pitch your idea to them and ask for their support to find people that can really help you
take it to the next level. Then those managers can go to their team, introduce your problem, get them warmed up to the fact that it's an exciting problem, but also warm them up to the fact that this could be a great opportunity for them to contribute outside of their own team in a way that is not standing on a so box and presenting because that is often
not the where these engineers want to add value in the organization. And I'm generalizing a little bit. It's not that black and white, but typically that is what I found. Now once you have a good group of these introspective engineers and deep thinkers together please don't organize a physical session right I know we all love to go to the office and everything needs to be in person
for it to provide value please don't do that it's much better to do a virtual session it feels much safer and it's much easier to accommodate for everyone to actually join rather than having to go all the way to the bloody office specifically for your session so you just lower the threshold in many different ways. inside of those sessions, you can organize these in thousand different ways,
but there's two really different two really important things that I found work really well. When you deal with deep thinkers, give them actual time to think in the session. Of course, you just share the materials up front so they can do research and come prepared, but also in the session itself, make sure that you just block at least like five to eight minutes of thinking. The meeting
will be completely silent. You might be super uncomfortable because it's new and different to you. But this is where the actual magic happens. And then you have only one final challenge to take and that is that even though their manager introduced them to you, the psychological safety for them to give you their brutally honest opinion is still not very high. So if you start calling out people
and say, "What's your opinion?" you're not going to get it right. It's much better to break out into breakouts and have two or three engineers or at least a larger group give them time to work on one response together. And what this achieves is you don't tie an opinion to an individual. So it creates 10 20 times the actually be honest even though you're still building a
relationship with them. You don't know that's a great way to get input from that group of people. Now anyone you talk to, whether it's that uh engineer that's the superstar in the community or that is the deep thinker, please always promise and actually do get back to them what you did with their input, where you took the idea and whether it succeeded. Because at the end of
the day, we're all humans. We invest time to help you and we want to know what did it achieve. even if it didn't achieve what you wanted, their opinion is still appreciated and you paid them their respect by letting them know what you did with their work. Really, really important. If you don't do that and you keep repeating not doing that, then next time they're not going
to want to help you, right? Because they have no idea what you actually did with their work. Now once you actually gathered the support from the community in this way both influential people and the deep thinkers by that time you should have a story that almost no one is going to say no to and of course that's still possible right it's still big new ideas are always
a bit difficult but this way you did everything that you possibly could to make your idea great before bringing it into the large Now how decisions are made is very specific to organizations. So I'm not going to talk about that or escalating if you don't agree because yeah that's very very nuanced and specific. So this was actually my talk for today for all of you. I hope
that you got some little tips and tricks out of this. I hope that if you are a leader that you actually make the time to help your team build strong ideas because we do all this time for developer experience and we always focus on the tools that we use and the fact that they can have long work blocks and both of those are important but if your
if your engineers don't feel like they can take their idea into the larger organization and have your support you're not going to have the happiest of engineers. So this is a really important topic. So, thank you all for listening to my talk today. I hope you get something from it that you can apply immediately and have a great day.
