Hi everyone. My name is Patrick Akio and if you're interested in tech leadership, this episode is for you. We cover the managerial path versus the individual contributor path and what that path actually looks like from a technical perspective. How to adopt new technologies in bigger organizations, get buy in
and get things done. Both the pros of the new technologies as well as the downsides and what they could be. Joining me today in sharing his stories is Raresh Mirika, Senior Staff Engineer over at Molly. And I love the perspective he brings and the stories he shares. So enjoy. This morning I saw a post on LinkedIn and it was funny because it was about LinkedIn. Now there's a little small tab that says videos and this person was thoroughly against it.
Based on research that has been done, platform like Instagram and TikTok and short form video content or image content leads to endless scrolling, which is not good for the human brain. So then I'm wondering, is LinkedIn really incentivized to keep people on their platform and that's why they added video or do they plan to do some good with it? I feel like for bigger companies that's always this discussion point, right? What is the purpose and is it in
the end good for people or not? I doubt anyone ask themselves if they're doing any good with it. It's really I've noticed also a few, let's say social features on LinkedIn lately. It's it has become a a new social platform, a new social media platform. I've read recently an article by Bruce Schneider from the security expert Bruce Schneider, and his point there was that the biggest successful companies out there on the Internet are all culture companies.
They are not providing a service or selling wares or right they are. What they are selling is culture. So you're talking about the YouTube, Twitter, Facebook slash Meta, everything Meta does, and now LinkedIn. And in fact, they're because culture has a wide appeal. So you get a lot of attention in eye bolts and you get a lot of engagement, which then of course you you monetize through ads, which is the the de facto way of monetizing anything on the Internet.
So everyone that is in a position to pivot into that that direction. They will do so. Probably will because it's going to, it's going to be profitable for them. Interesting. Interesting because what LinkedIn, what was LinkedIn selling the other day? They were selling the recruitment services, let's say, right? They were selling tools for recruiters.
They were selling this notion that, OK, you can reach talent and get talent into your organization, which is a valuable thing, but that's like the size of that market. It's finite. It's peanuts compared to the the culture space. Yeah, that's fair. I wonder what it's in part to be within such an organization like you. You've been in way bigger
organizations than I have. I work in consultancy and I go more in and out of organizations, but for example, booking, I was listening to this podcast and there was a guy on the X Friedman show, Peter Levels. I think he's a Dutch guy. He does a lot of indie startups and he was also talking about booking. The booking was there to solve a problem and now it's grown to
this scale, right? In the end it's also a bit slower as a total, but every part of it is like optimized and AB tested for conversion, which I think in and of its own from an outside perspective is insane. What was it like kind of working on that platform from your perspective? That's very interesting.
First off, it's the only very large company that I've ever worked for and that I know from from the inside and I've worked for it for 8 1/2 years and I could say I worked for three companies in this time because the company has evolved a lot. When I joined, it was about 300 people in tech or so, and when I left it was 2 1/2 thousand people. It's an insane growth and booking obviously very
successful, world renowned. If you look at the oral history of booking, you read a little bit a little bit about it. It's actually on the Internet and it's told by people who were in leadership at those times. That's cool. It's it's really cool. Then you you learn that it's success is owned to a few key ingredients, a few decisions, and that's of course snowballed into a massive thing. So one of them was what you're talking about, this hyper
optimization thing. So at some point in the history of booking, someone decided to lead the company from a commercial product and tech perspective, not directly through let's say experts, leadership or you know, consensually, democratically or whatnot, but through a tool. Yeah. And data. Data, yes. So you use data 1st and prove that your decision is in fact commercially successful.
And so the teams, most vast majority of teams and, and engineers within within booking used this tool to show that the changes that they are making are beneficial to the company. That's that's one thing. So that's gave everyone a date, a data, validated, a scientifically proven kind of
trajectory. And the second is take your hands off the steering wheel, meaning that I as an engineer could decide for a good portion of my tenure in the company could decide to go out there and change something that you as a customer would see on my own. Oh, OK. Completely autonomously, of course. I mean, I'm a back end developer. I would need a designer. I would have to convince one of my designer colleagues to support me, one copywriter colleague to support me, etcetera.
So we would make a an autonomous team, yeah, if we if we wanted to. For bottom up. Bottom up, we had an idea. We said OK, we think that if we add this button here it would convert better or. No, no product person that makes the decision or. No, that was not required. OK, It would have been smart of me to enlist the product person to help me with the product task, but I could take ownership of that and I could be my own
product person. And then I would actually implement all of this, deploy it, test it for a couple of weeks and show with data that my idea is legit. OK. And we're talking about regular ideas, not things that could be affected by, you know, regulatory. Yeah. Ohh. There were some huge changes that were done this back in the day. There were some huge changes that were done in the day, but we're we're talking really bad back in the day. Yeah. And those had immense impact.
Like now they would be in total over the years they would be worth stupid amounts of of revenue. Was it incentivized to do this or was it more the culture and. Kind of it's a mix. OK. So for the for a good part of of my tenure there, if you were successful from so if you did things right and you, you clearly benefited the company, you would definitely recognise this in terms of pay for performance.
Good stuff. Yeah. Now this has changed and this has changed throughout the industry over the last let's say 7-8, seven years. And there is, I would say less of a, of a, how to say this, less emphasis on pay for performance and there is much more pays pay in general in in general in industry. OK. So less peaks basically. Sorry, less peaks. Less peaks, yes, and less discretion from a, from a manager.
Of course, when you're running a three 100% team and you need to allocate individual bonuses and you know everybody, everyone by name and reputation, it's one thing. When you're running a 2000 person organization and you're trying to do the same thing, it's much more difficult. Yeah, that's why you mentioned I worked for three different types of organisations. OK. And I'm assuming then the second type was kind of somewhere in between. Yeah, yeah, yeah.
It was very, very fast growing. And that meant that there was a lot of a lot of change all the time and a lot of uncertainty all the time and a lot of communication channels breaking down and being recreated in different ways and so on. So there's, so there was a lot of a transition period.
Interesting from your side, Why? Why did you always because I know you never left, let's say hands on work or you're always more so involved where things are being built rather than high over managers would be. Why'd you choose that path within this org and also still continuing? Well, I generally believe that the managers, the managers have
a tough job. So the, the managers, they need to make sure that the team is happy, that they are working well together, that roadblocks are being eliminated, that the paperwork is being done and so on. And that's just not my not my expertise and not my thing right. Ultimately, And then there's not enough time to keep on doing the technical work.
You cannot be a good I, I, I cannot be maybe some people can I cannot be a good technical contributor and at the same time take care of the team and the the people where right. So for there, there are teams in which the, the, the manager there, there's ATL, for example, a team lead and they have very limited people responsibilities and they basically approve holidays and make sure to have one on ones and things like
that. But they also have a, a technical responsibility in the team that works some of the time. But it's again, a misalignment of incentives because I, as a individual contributor, as an engineer, I can work on my career all the time. So I'm delivering products, I'm expanding my skills. I'm making sure that they have a big network of a support network around me. And that helps me promote, that helps me in my career. Yeah.
Depth. Yeah. If I take on the the TL role now, my mindspace, yeah, is occupied also by that. But now I'm working on two paths. So I could promote from, let's say an engineer to a senior engineer if I kept on going on the technical side. Or I could invest more on the management side and then grow from a team lead to, I don't know, manager of software development or a director or what not. So someone responsible for
multiple teams. Yeah. So this means that now I have to make a personal choice and to invest more of my time and energy in one of these paths. So it's kind of a A robbery. You, you give me this, this, this responsibilities as manager, then it's in my best interest to immediately drop all of my technical responsibilities. Yeah, because that's how I could accelerate my growth on the management track. That's the new path. That's the new path.
And that that makes, I think it makes total sense for the individual now from the from the company's perspective, of course, that means that you lose 1 headcount effectively. So you either compensate for that or you try to trick the person into taking on this, this role that's kind of a from a career growth perspective is at a disadvantage, but they feel 2 roles for you as an employer. That's great from an efficiency, cost efficiency perspective. Cost efficiency, yeah.
Yeah, but it's, it's a short, it's a short term thing like no, but people who are very talented in either of these tracks, right, they, I think they will perceive it as a bad deal. OK, interesting. Like I, I'm contrasting this towards my own experience because right now like I'm in a consultancy company and we're experimenting with this team lead structure. So part of my time is allocated towards one on ones, indeed more so personal happiness for
consultants. And I don't have any insights into what type of client work they do. So this is more so the people management role. And then I have my client work and I said yes to this because I'm kind of torn, right? I do see these as two separate career tracks and I agree with you that there's going to be a decision on. I don't think this in between stage is good. It's healthy. I do think it's good for me to gain this experience and then see what I want to do from that aspect.
But yeah, I do realize that if you have this mindset of OK, I already know what I want to do, then it's a bad deal to split your time because split focus doesn't work. Oh, if you if you want to try it out, then it's great, especially in like if you're fortunate to be in a very fast growing company, then you are in a place where you can try out the management track. And if you like it and you get hooked on it, then you have a an elevator ride because more teams
are being formed all the time. You have priority. You have a place to be 1 the the leader of one team. But then you know that three teams are going to be formed next quarter and they're going to pick to lead those three teams the person who has most experience, which is you now having 4 the total of four months of experience, you're the the best person we have. Yeah. But of course, with those four months of leadership experience also comes maybe four years of tenure in the company, of
course. So then that's a huge opportunity for people wanting to jump into, into management. So and people, I've seen people jump into not, not the teal, but even the director level. Yeah. Straight from engineering because based on lots of tenure and a little bit of trial, of course here and there, yeah. Interesting. And for you then this you already knew that this kind of people management track was not for you. No, it's why you decided not to do that. It was not appealing.
And so the, the direct people management was not appealing at all. And the paperwork, I'm just not equipped to do that. I would fail at it horribly.
So, and I, I always had this, the autonomy that I needed to do my work and work on my projects that I didn't really need that lever that management gives you, which is, I mean, of course you decide where resources are, are allocated and you can give teams direction and so on. I never needed that because I could already do that through influence. So there, there was no, no appeal. Nobody ever stopped me from doing what I, what I thought
was, was right. They, sometimes they had difficulty being convinced and I needed to put in more effort. But that's fine. That just validates the idea. That's OK. But having this massive resource, so you have a a whole structure of manage managers and teams and so on that works. And then you come in and you influence that structure to into a certain direction.
That's a huge boost of productivity for me because I don't have to actually think too much about, you know, their, their happiness and environment and so on. There are it's handled. It's handled. Yes, it's provided as a service. Yeah, perfect. Interesting. What is this career path? So are we talking about the management track?
And I know traditionally I have a good view of that specifically, but I'm curious from your perspective, what is this career track, let's say with depth and also more technical leadership then look like because there are skills that overlap I feel like. Yeah, it depends a lot on what you on what you want to do and the context, right. Because there are a lot of, let's say traditional individual
contributor careers. You see them more in specialized domains like for example security and networking, I think where you have very, very, very strong experts. So they they learn, they apply, they apply things at a higher and higher scale. But it's as you say more depth, it's less new initiatives and trying things out. It's more like, OK at this level, at this stage of our company or our our organization, we need to have this level of maturity of these solutions and so on.
Yeah. And those are usually the areas right security. Those are usually, yeah, exactly. These are traditional areas. Things are quite well settled and they're very, very demanding in terms of quality. Yeah, but the innovation space is smaller, Yeah, unless you're at a very big Corp and you're, you know, rolling your own software defined networks like at Google. So then but. It's trail blazing. Then it's very different, Yeah.
And but then if you're in product development or I was more in infrastructure, but at the at the edge between infrastructure and applications. OK, so close. So close, closer to the application side, but I was also database administrator. But as a database administrator, of course you're interacting directly with the application. Yeah, it's gonna have huge impact. Especially from a reliability perspective, you can have huge
impact. Yeah. So then you can take this path of becoming an expert, then you become a database engineer or security architect, etcetera. Or you can go for more breadth. Breadth could mean business acumen. So you're an application engineer, but you know very well the business, the industry. And then of course you can contribute from a directly
commercial perspective. So you're now finding solutions to business problems or you're finding that there's new technology and then you you use your own creativity to apply it to a certain business direction. So that's very, very lucrative. For example, in in my previous job, this was the case for a data science and machine learning or you can try to introduce new technology. So, so this is basically opening
up new avenues for the company. So you can it could be based on hype like now with AI, everybody's trying to find a, a problem for the, the new AI tools that are available. Oh yeah, sometimes successfully. And then the skills that you need to grow are very much more people skills because you need to influence people. You need to convince people to help you. You need to convince people that
it's a good idea. You need to make a very good compelling argument about about the the ideas that you have and so on. And then yeah, it kind of blends it a little bit with with people management because like 80% of what we do is dealing with other people past if you're a small start up of a few individuals, then most of the time you spend
coding and building products. Yeah, when you're in a large company, most of the time you're trying to stay out of other people's ways and try to influence or make make room for the thing that you need to. Accomplish still make it happen. Yeah, still make it happen. That's the most, most part of the job, the coding. It's a small part of the job. That's considered the easy part, right?
The hard part is to arrange all of the elements in such a way that outcomes a product that's still usable for the for the customer. And your team gets what they need and the other teams get what they need because the relationships between teams matter a lot. So you cannot make sure that it happens for you at the expense of someone else. Yeah, usually that's really bad for. Usually, yes, yes, I think I think of this from my own perspective.
And this year I made a decision to take up an assignment as product manager, product owner, product manager, the roles are kind of interchangeable at this org. They say Product Owner is more technical, which I think is pretty funny, but in any case. And it's mainly because of that autonomy and decision making power that you mentioned, right?
If I had that more as an engineer, then maybe I wouldn't have switched to this role to see what it would look like to be fully responsible or more responsible than I was previously. And now I notice indeed, skills like communication, getting by and solving people problems, those are things I excel more and more at just by virtue of doing it more often, right? That's the experience I gain here. And I definitely miss the
implementation side. So for me now with this learning, I feel like the ideal role would be to be more of a product engineer where you have that business acumen and you're also there with a certain level of autonomy and business power or decision making power to actually drive change and also implement it. And then still the implementation is like this, I don't know, this fulfilment, which is more personal, where I actually feel like I contribute
and not just kind of overarchingly see and plan and prioritise and other people contribute. Like I feel like I'm not doing as much of the work as other people. But then people appreciate that you are in this position. That's, that's kind of your role, right? You are the orchestrator. So that's how I now see my path towards the future.
Have you ever been in a position where you drove change within the organization just by virtue of you having that autonomy and decision making power from your position? Yeah. So I on a number of occasions I've autonomously or bottom up introduced technology, usually within a group of people. So we decided to try something out. OK. So based on based on what? Just based on what was new or what? Based on what was new and what was what was interesting to us and based on opportunities that
already existed in the company. So, for example, around 2016 to 2017 had booking there. There was a lot of data available for data science purposes. Yeah, but it was exploited in a quite naive way, let's say. So traditional querying and reporting of it. And there was no strong tool for doing data science. Yeah, at the time. So a colleague of mine and myself, we found this, it was back then a relatively new project called Apache Spark. Oh yeah, it is, yeah.
And and we decided to just try it out. So being engineers, it was trivial for me to just get the library, install it and connect it to the cluster and run some, some jobs on it and see what it spits out. So for me it was trivial. Yeah. For the 100 or so data scientists around, this was earth shattering. Yeah, right. Yeah. They, they had no, no skills, no knowledge, no access, no, no way. They couldn't make it happen. They couldn't make it happen.
So then we decided, OK, this is interesting. Of course I'm an engineer, I can query data, but ultimately, how useful am I going to be, right? I'm not going to be of of much use because I'm not a data scientist. Not compared to the hundreds of data. Scientists. So we made the decision and a an informal deal with two of our colleagues, data scientists that we will support this project. So the installation upgrades, making everything work fine, we will support it.
And they will have to train and get all of the scientists to use it. Yeah. And that happened. And then within about a year or so, we formed, we, we collected other teams that also had similar initiatives. So one of them had an an initiative in deep learning with image, image tagging. And another team had another initiative in data science
proper. And we created a a track, so a collection of teams under one leadership to provide machine learning services to the to the greater organization. Yeah, to these balloons a lot over over the years, but it basically started with with two people saying OK, it would be really cool if we could use this new tool. I mean we are data rich, we have we are compute capacity rich. We can make something out of it. We can definitely experiment with it on company money and time.
So why not? And then signing up more people to actually use it. And because without signing up the data scientists, you don't have a business case, right? You just have a toy tool that you can you can use and, and show off, but you don't have a business case. You're not actually delivering value.
Yeah. But by enlisting these people and organizing, organizing them a little bit and organizing trainings and offering these resources, then basically you are reshaping a large organization and how they how they work every day. Interesting and. I mean, my contribution to this was just the pushing the the kick in the butt that it needed. And then of course, it's snowballed and a lot more people were engaged.
I mean, you had the right skills to get it up and running and then the that probably that people side of it, that business acumen, that's what got people buy in. Towards a vision I was able to convince. So that's the thing, a lot of people have the skills. If you, if you ask them, make this work on this computer, they are much better suited than I am.
What I brought to the table or the the the the critical skill that I have that helps me do this kind of job is convincing other people to help me. It's it works very, very, very. I can. See that smile? It works very well. It was. It works scary well, Yeah. And of course, I, I sell a story in which you are, you are going to gain out of this, right? So this is the story that if you do this, you train these people, you are going to be at the forefront of this new
technology. So you will be well known in this community, which is obviously beneficial to you. There's a lot of credit here. There's I'm not doing this for my own, my own credit or gain. So you're the front person for this stuff. But obviously it's a win win situation. And yeah, it's it works. Convincing. People 80% of the time, it works 100% of the time. Yeah, yeah. Convincing people is a powerful skill and I feel like it might be underestimated. Like I I like the art of having
a discussion. I, I was very stubborn. I think early in career I still think I am stubborn, but I've learned to be flexible, right? I can be convinced. Let's just have a good conversation and see what the arguments are. And I feel like that flexibility and still persuasion, power like story and a vision that still all will contribute towards persuading someone.
Especially people with let's say that don't have the skills to get something up and running from an engineering perspective like data science or people that are completely non-technical but do have business acumen. From a business side, I think it's very powerful from an individual contributor standpoint, especially when you have that let's say decision making power or autonomy to make those decisions.
But before we go into more how you did it specifically, I'm interested in the environment that cultivates that because you said, OK, we had an idea more so up and coming technology with a vision and with the environment that we have, we could see this, right? And we can make the decision to do this experiment. All of that just makes it seem like you woke up, had this idea, did it. But there needs to be time. There needs to be an an environment to be able to do so, right?
Yeah, obviously, no, I mean, I did wake up and I just did it. But what I, what I'm not factoring in is that like the other 10 years of organization building that I, I was on the shoulders of others when I did that, right. So I, I kind of landed on the shoulders of others. I also participated in building things. But yes, it's true, there is a special kind of environment that allows these things to happen. And it's an environment where bottom up solutions and initiatives are appreciated.
At the very least they're not hindered. It's an environment where all ideas and all perspectives are at the very least welcome. But also quite a lot of constructive criticism is like, yeah, the some, some vigorous conversations happen all the time. Yeah, but a productive 1. Most of them. So even even though when even though the conversations can become a little bit emotional, it's very important that there's a lot of psychological safety. Yeah.
So even if the ideas are criticized ruthlessly, it's very important that at the end of the day, we have trust in each other that we want the best on a personal level, we want the best for each other, right? And because in a very fast growing organization, for example, that trust gets eroded. You have teams that are very far away from one another and they don't see each other's perspectives. And you also have engineers with very little tenure and so no
track record between each other. And it's very difficult to establish that those relationships. So if you have a more of a hacker ethos with a small team that have been together for a little while and they have a, a very good goal in mind, right? They, they are all aligned towards a, towards a larger goal, then it's possible to have these vigorous conversations on topic, even though, I mean, we're computer nerds, we fight over crazy stuff, right?
Like which editor is the best? So of course you, you do do that, but that does not lead to judgement for the other person. So that's, that's very important. So having this this high degree of psychological safety is very important. Then of course, having a talented team helps a lot. And here The thing is that it's usually a strategic kind of a strategic decision. If you build your company with a strong focus on in sourcing things, then you have more work to do for experts in different
fields. OK. If you choose to externalize, for example, you choose to host on cloud, then you have no reason why you would have a six person networking team. Yeah. Doesn't make sense. Yeah. So you don't have those skills. You don't have those skills at all anymore. So you you have no, no reason to employ those people. You're robbing yourself of a, of a talent pool that could be a multidisciplinary talent pool that could help you in other areas of, of your company,
right? So many companies choose to externalize a lot of of their, yeah, their skills in the end. And so they, they invest more in industry expertise, but they rub themselves over this multidisciplinary, right. So they, they, they don't hire, you know, physicists, mathematician, chemists. I worked in a team. So I, I worked in a team with two surgeons, OK.
So I was the, I, I was the safest person in the office because I literally had, yeah, two medical professionals that were both software developers now, OK, on either side. And of course, they bring a different perspective to things. Interesting. That's phenomenal. I mean, I from from my side, I love working in the cloud. It's because me as an individual, I have less total cost of ownership, right. I don't have to think about things like storage, networking, scalability, elasticity.
It's all out-of-the-box there. And I think for I think the majority of organisations that just makes sense indeed. And when you get to a point scale wise and where you can do more and can afford to because you just have I think the capital to do so, bring that back and indeed kind of internalize that knowledge, then possibilities open up.
But it's a, it's a bigger risk as well at the end of the day because a lot of things have to come together in the right way to actually execute or be able to execute on the benefit there, which I think makes. Sense yeah, it's important to be successful first, right. So once you are successful, but then you still have to have the right ideas.
So even though you're making lots of revenue, you still have to have the right ideas and recognize that OK, from here to the next step, we need to change a bit. It's not enough to find the the widgets to sell and be successful in selling that one widget. We now have to create this new organization that innovates and invents and so on that goes beyond the pre made building blocks, the Lego stats, the let's say that the SAS space and the cloud space offers us. Yeah.
Do you think it's the right ideas or also just the ability to experiment with many ideas in a fast-paced environment? But just that, just the idea that you need to create that freedom for yourself, that's in itself, that's difficult learning to have right? Because The thing is, as an organization, you learn how to be successful in your own paradigm to change an organization, that's a a different skill. And usually usually organizations resist this. Yeah, it's very long process to
change an organization. Yeah, that's why I'm so fascinated by this environment where things, ideas pop up bottom up, right. It's not often that I hear that, I hear preach and ideas that this is what we want. But to be able to have that I think is a different ball game from an from an individual contributor side. Do you get time for that or how is this facilitated, let's say
by the, by the environment? Yeah, well, I prefer and in in my case, it's also an internal perspective within my, within my career generally it's yeah, I I could just take time and do it right. So there's no, there's no risk. But internally in my head, there is risk, right? Because I am taking time. I, I am held accountable for what I did with that time. Yeah, or I could be, I could be wasting time and even worse, I could be wasting other people's time. That's, that's another topic.
So if you create an environment where individuals are allowed to do this, but they're not, let's say they're incentivized, but it's not advertised that they should do this, Yeah, Then you have self selection. So a few who are risk taking believe in their idea and they think internally that they need to work hard to make it happen. They will show up, right?
They they will see the door. They're like, OK, interesting, yeah, let's see what's behind door #1 oh, wait, there is a void here, I can build my own thing. OK, fine. Do that. Then from externally you monitor and you, you look at it, you say, OK, they're onto something. OK, fuel the fire a little bit. Yeah. Or give them a little bit of coaching. If they're causing a mess, which I've I've done in the past, of course they're causing causing a
mess. OK, let's clean the mess around them a little bit and help them put a bit of structure. Like for example, in the story about machine learning, there was at some point a lot of structure was put together to make things efficient and orderly. And so that people are no longer confused about who's running what and why, which it was the case before. And there's only a, a small number of initiatives that are actually going to going to happen like this at at the
larger scale. At the smaller scale, if we're talking about experimentation, AB testing and having bottom up product ideas, then that can happen within the team. So within the regular conversations, products to engineers and so on, you need to really listen to what everyone is talking about. And you really need to ask everyone, OK, what do you think about this and so on. And then, then you're going to have seeds from that. And of course not everyone is going to go out and pitch their
idea. But if you can extract the idea as a product owner or product manager and, and always start from the perspective of everyone has valuable ideas and we should really analyse each one of them with equal merit, then you're going to get. OK, well, actually that's a good point. OK, let's put it in the next print or the one after that. Yeah. And that's how you get, you extract bottom up ideas and you
get to the implementation. And people are very, very happy to discover that 2, two weeks later, they're working on something that they just blurted out in the last brainstorming session. They're really proud about that and excited to work on it. And of course that is becomes a flywheel of motivation and and performance of the teams. Yeah, absolutely. I I love that perspective and
insight. I'm also wondering when it comes to those bigger, let's say, structural changes, especially when it comes to new tooling and technology adoption. It's fine if the tooling at the end of the day has that longevity that you aim for, right? But with new technology, they pop up sometimes like mushroom
like. And if you choose to adopt it, especially with an organization and at the end of the day, something better pops up or something just actually doesn't work out towards the vision that you had, it can have pretty severe consequences as well. Is there any experience you've had with, let's say, advocating for a new adoption of a technology where things didn't end up the way you want it to? Yeah, yeah. In fact, I have an example of
that. So also also a long time ago, a few colleagues of mine and myself, we started playing with containerized infrastructure. So we got a hold of something called Mesos. I think it became later on Apache Mesos. And it's a, it's an old orchestrator, a bit more visual, a bit more like VM Ware, let's say. Yeah, it, it was OK. Obviously it, it was far less powerful than what Kubernetes is now. But this was pre Kubernetes, yeah. And we thought, OK, this is
interesting. This is a way for us to run, well initially toy workloads on a, on a cluster. So we set up a cluster. We started playing with it. I started researching a little bit about, OK, what is contain containerisation? What is it good for? Why this new paradigm? I mean, obviously I understand why this would be useful in a, let's say, virtualized environment, like in a cloud environment or Lambda, OK, you can run tons of things over so much metal.
So it's efficient. It's, it's an efficiency thing. But beyond the efficiency thing, what I found was that it allows the developer to self-serve to hardware resources just like in
a cloud environment. Obviously we were on an on Prem environment managed servers managed by ourselves, but still from the application developer to the servers, there was a long chain of communication, approvals, budgeting, planning set up and so on. So it was, it was very difficult for for an application engineer to create a new flavour of application. It was very, very easy for them to scale up an application or down or what not. That was relatively easy. But for them to create a new
flavour that is very difficult. And there was a, there was a, an appetite within the organization for being able to spin up new Java services, for example, so and the new toy services and so on. Yeah. So I thought, OK, this is this is quite interesting. So this actually allows us to put effectively an API in front of limited hardware capacity and then offer this as a service to application engineers and then they self-serve and host their
applications within this. So this is a paradigm shift now where I my mistake was not adopting this initiative as my own and dedicating my my whole time to it because I was engaged with something else at the time. But what I did in what I thought was support to the the existing team was to explain this idea and paradigm in a blog post. OK, yeah, medium sized blog post internal to say, OK, this is a new way of thinking about this.
You can, we can offer you this and you will get this thing, this API and this world where you can expand and install your applications and offer them to our customers. Ultimately, yeah, of course, on the backdrop of experimentation and everything that will happen anyway. So I, I posted this and well, left for holiday after a a period of time. This caught people's attention and it caught management's attention.
OK, Of course. I think the the back story is that people in in the application space, they were very thirsty for this and they pushed management into, well, maybe this is a good idea. Could you just make it happen? Yeah, this is what we need. They were very, very thirsty for this, this degree of freedom from the infrastructure
perspective. Nobody really was aware or cared about this much because of course, they were still doing their thing that they they knew they needed to do for years. And so this perfect storm happened where management decided to, well, yeah, make a run for it. And they put together a number of teams with very little guidance in the end because we didn't know what we even wanted.
This is a yeah, blue ocean idea put together these these teams gave them the mandate to. Yeah, just build it, whatever it is. Yeah, and they, they really, really struggled, right. So they, they got between a rock and a hard place. They got between excited and eager management and thirsty and yeah, eager also users, client users, yeah, internal users. They were really between, between a rock and a hard place. And it was not a pretty, pretty
picture. A lot of people ultimately did not appreciate my efforts to popularize this idea. OK. And yeah, I think ultimately, yeah, it's a, it's a, it's a big mistake of, of mine to, to have try to popularize an idea without giving the necessary support or guidance or, or toning down the, the expectations of people around me. I can see that learning because I mean, you said one of your strength is that persuasiveness, right?
So you probably saw the appetite for it, which is then absolutely leverage that you're going to use to get an idea through and you wholeheartedly believed in that vision, I'm assuming? Yeah, no, of course I of course I believe it's useful, but I mean, I didn't think they were going to take it this far. I I thought that they. I didn't know.
I didn't think anything later on, I thought I Oh my God, like I would have expected you to be more reasonable, reasonable about things like you cannot expect everything to just show up. This is brand new, Like Kubernetes didn't exist. Yeah, so, right. But that's that's hindsight. And in the end, it doesn't matter because I'm responsible for what I think and what I say and what I do. The reactions of other people, I shouldn't have expected them to react in a particular way.
I I should have made sure that they understand. OK, this is just experimentation. We just try things out. This is a possibility. This is why it's worthwhile our time. But don't get too excited. But I didn't do that, of course, and that was a huge mistake. Yeah, Yeah. I appreciate you sharing that learning. I I can definitely see how that can escalate quickly, right. And eagerness from both side management and from a user base and a team in the middle puts basically a high make pressure
environment. Yeah, really at play there. Yeah. And I, I, I'm really, I'm really sorry about it, really, because I it's the, it's the worst thing. Like if I cause an outage that many times, if I, if I cause a technical problem, yeah, that's, that doesn't really hurt anyone. Well, in my current job it might, but in my previous job, it didn't. It just meant a bit of loss of revenue. Yeah, and that's OK. That's part of the that's part of the rules of the game. It's still a terrible feeling
from your perspective, yeah. It's a terrible somewhat exciting yes, it it no, it, it is a bad it is a bad feeling. It depends on it depends on what happened right. But when you heard people, people that you have to show up and look them in the eye the next day, but anyone really strangers as well, then it really hurts. Then you really, you really get put down a bit.
You, you get humbled. Yeah. But things, I mean, from my perspective, I'm an outside perspective, it feels like you have a big sense of ownership because to attribute that to like you starting a flame and then other people really fanning this flame, like as a collective fault. I feel like also within that organization, if the idea and also the execution turn out to be right, then everyone will be celebrating, right? But it's because it went this way that that's the learning
there. Yeah, of course, but that, that's the case for, for everything like the, the all, all accidents have good intentions. Like unless you're, yeah, OK, we, we're not going to talk about people who intentionally cause harm, right. But every time that you do cause harm inadvertently, of course, you have to take responsibility for that.
Even even if, for example, it's an, it's an incident, we do postmortems for incidents and it's very, very important to take responsibility for it. That doesn't mean that you need to be punished for it. You're, you're punishing yourself well enough by just saying, OK, I, I'm definitely going to try not to do that again. That's, that's enough. But it's really important to get the learnings because otherwise anything is excusable.
Then any kind of risk taking activity becomes excusable through this lens of saying, well, but if it turned out all right, then everybody would have been happy. Well, but then I can push it really far right with the risk taking. And that's that's where you get into breaking the law for the benefit of profits, for example, because you go, oh, but I mean, obviously if we can skirt this regulation and become successful, then everybody's
going to be happy. Well, yes, but that's not the right thing to do. And you should have learned that a few steps prior. Yeah, Yeah. I really like that perspective. I've seen things when an incident happens, happening twofold, like you describe it, where people really take to heart those learnings. And also we accept that mistakes happen and we move on, right? Or where all of a sudden we say, OK, our risk appetite might have been too broad and then processes come in place.
And then all of a sudden that autonomy and decision making power gets taken away. And even then, like it can happen with reason or it can happen completely the other way where all of a sudden you're like, OK, we can't do anything anymore. And I see organizations lean more and more towards sometimes taking away or putting in processes too much or too quickly. And then when processes are just too much, you lose this kind of experimentation or that freedom and autonomy.
And yeah, I think it has to be a trade off, right? Not every company is bank. So the risk appetite can vary and you need to make a conscious decision and what to adopt process wise and how freedom or how autonomous people can be.
Indeed. But there is, I think there is a modern tendency towards safety through internal rules, yeah, rather than safety through, through inter, through incentives and this taking responsibility and acting as an individual in the best interest of the organization. Yeah, this is I think also because or, or one of the one of the contributing factors is that individuals feel more safe, psychologically safe if it's rules based, The other way is
much more personal. And it's easy to perceive this responsibility that falls on you in a, in a difficult, difficult way. Right. So it's a, it's a way of protecting engineers, protecting people from fall fallout. Yeah. And that allows you to have a larger, less experienced organization with less friction with less people work inside that organization because everything is laid out.
And you cannot cause an incident because there are all of these rules in place that prevent you from causing that incident. Right? Yeah. So this means that you're excused from explaining yourself. Why did you do from A to M that caused the incident? Because you should stop at B. Yeah, that's the process. Yeah. There's a control there that that stops you. Now, of course, this has a cost to agility and so on. And within an organization, you need to find the balance between
putting these controls in place. I mean, I work now in a regulated entity, so we have to have these controls. Yeah. Yeah. So there's. But The thing is that the controls need to provide the safety, a real safety, not the safety that the auditor sees and they check the box. No. So the control has to provide
real safety. And at the same time, the control has to have a very good story for how the agility of the team is preserved and or what measures we took internally to make sure that the agility of the team is preserved. Because if you just slap on controls over a system that was not meant to have them, for example, you commit code straight to the straight to the repository and deploy straight to production and there is no control. That's what start-ups routinely do.
Then every engineer is empowered to build a feature and deploy it and test it in production with some users and roll it back. OK, Now you become regulated entity, for example, and you need to slap on a control you need to have for ICE principle, for example, and you need to have some change management for production. You can no longer create production database tables directly. Yeah, OK. Now as an engineer, I can only test on my local machine, so I have no way to test anymore.
Now the company is losing agility. Yeah. It's. Very obvious. So we need to invest in mitigating that loss. I it's very important not to skirt the regulation. So don't create the control just for show, but mitigate the the impact and well creates pre production environments or create a way for engineers to test changes potentially in production but without full deployment. So divorce deployment from release with feature flags or experimentation.
So you need to do these investments in order to regain the agility. And then at the end of the story, if you're successful, then you're going to have the cake and eat it too. Yeah, it's going to cost. Yeah, that's the best part. I feel like with that mindset, because controls are easy, right? You slap a control on it, but that can have tremendous side effect, not just in way of working and productivity and agility, but also sense of fulfilment and honestly just
happiness, right? If you work in the sandbox environment as an individual, doesn't feel as good as when you can experiment more so with actual users, right? They say that when this chain of you solving something and then it actually landing to the end user is very long, then that usually correlates with people kind of losing sense of what they're doing. And then also, I thought it was interesting that you mentioned this feeling of doing the best
for the organization. That's something that I felt very strongly like I started out in operations and when I heard from honesty, my product manager, whomever we needed to do something and I thought it genuinely didn't make sense. Like I could not just stop there and do it. Basically it was it was always bothering me. So I escalated or I would make sure that the right people would be at the table to have that discussion regardless on if I
was right or wrong. But I need to be convinced that this is indeed the right thing for the organization. I've realized in practice that not everyone thinks like that and therefore some controls are are better in place.
But I think it's very dangerous also when people of, let's say higher decision making power or levels of autonomy, you don't have the best of the company like at at their heart and you see strange decisions being made, especially when you're from that role of individual contributor. Yeah, no, that's, yeah, that is absolutely true. Yeah, yeah, yeah. You, you don't want to see that no at all. And it's, it's, it's extremely
damaging. As so when we're talking about the, the population of individual contributors that are exposed to decisions by, by senior leadership that don't make sense, the the feeling of demotivation is very, very intense. Yeah, yeah. It's it's a situation that you want to avoid as much as
possible. And here like two things to avoid that would be A to B. It's very important to be able to explain and to answer any question about a decision, high level decision, especially strategic decision and be open about it and be able to explain to everyone involved why you chose that it could. I'm OK even with explanations that are not maybe so objective. Yeah, right. What you want to hear? Yeah, Yeah, that's, that's OK, as long as you're open to explaining it and you're,
you're, you're clear about. It and then we can disagree and commit. Yeah. Then we disagree and commit. Yeah, yeah. And because you can make an argument, especially in technology, you can make an argument for either or. Yeah, it's subjective. You choose between cloud providers. It's very easy to choose either, either or any one of them Is, is reasonable, right? Obviously large successful companies use all, all of them,
right? So if you choose between one, one or the other, then you, you should be able to say, well, it's because of of this reason or this technical reason or this business strategic reason or this financial reason or. What or what? Because if not, then it's not a credible, Yeah, what else decision, right. Yeah. And the, the, the side, the, the, the, the downfall of that is that a lot of a lot of people that are witness to that, they're going to be extremely demotivated. So yeah.
Avoid. Yeah, I, I agree. I I was wondering how to prevent that. And I agree that when it happens, the communication and the clarity is like paramount. Without it, you're going to lose a lot of trust and a lot of motivation there. But I'm wondering from your perspective then also what you've seen does, let's say a higher leadership people that are not on this technical leadership path, but more on the
traditional managerial path. Do they need to have any experience with software engineering Or what have you seen with people that have had that experience versus the people that don't have any experience? Well, I've seen great managers in both sides of the camp, right? So I've seen great managers that come from very different backgrounds that cannot code to save their life. Yeah, they are still, you know, they're they're still productive with the computer, right?
We're not talking about people who are not fit in in that space, right, But they, they are not software engineers, but they're great managers. They are very much people oriented or, or business savvy. They're smart people. They're very, very successful as well. And of course there are engineers who chose the, the management path And well, by the time that you see them as directors or VPS or whatnot, of course, many of them have not
touched code in a long time. So you might see them as rusty. Some of them, if you look in their background have contributed to interesting pieces of Internet infrastructure. Yeah, So, so right. So it's a mixed, it's a mixed pool. But I, I don't think that it's necessary for a, a manager in, in the IT industry to have a software development or IT background necessarily at all. As long as they're passionate
about what they're doing. And yeah, they, they are, they are a good fit for the organization. That's that also matters a lot because a manager in to give an example, Amazon infamous management culture example in Amazon is not going to be fit in Spotify, neither the other way
around. But they are individually very successful in their own organisations as long as they are a good fit for their it's it's the same same thing for developers, for software engineers, for any other employee, if you're a good fit for the organization, even though from the outside it might look like, OK, that organization, I never want to work there, there's still thousands of people working in that organization and many of them being very successful. So there is no reason to throw
rocks at them. It's just, yeah, everybody likes their their own game. Yeah, I mean they also help form that, right? Even even if you are new and you join the leadership team immediately, it helps form part of now the new organization. So that's why if you do a complete swap initially, then those organizations don't make sense with those leadership teams. But I think if you would do it gradually, then the organization will change. Yeah. But there's a strong yeah, there's a strong organ
rejection. Exactly. If it's a brief match, yeah. If it's like DNA doesn't blend, then yeah. Yeah, it doesn't work. There is a strong organ rejection and yeah, it's very difficult to to navigate this. Well, organisations do need to evolve, but people within the organisations have their own ideas about the direction that they would prefer to evolve. And sometimes it doesn't match with with what happens in reality. That's fair.
So if you're, if you're talking about should we hire a new leadership from a particular background or from a particular company because we want to be more like that, You can. Yeah. That there's a responsibility on both sides to make that transition smooth. And there's also responsibility on your side to explain internally in your organization why it's a beneficial shift towards a more like that. If you try to do this in a covert way or or without any planning at all, then I predict
sparks. Oh yeah, I from history and experience, I, I felt some sparks indeed. I really enjoyed this conversation. And I must say, before we round off, is there anything you still want to share? We talked about technical perspective, leadership, I think driving ideas, getting by in on the people side as well as the technical side.
Yeah, maybe if you, if you find yourself in a position of influence or leadership in a company, I think the best thing you can do to serve your your company is to promote systems and rules and incentive structures that you can easily explain to someone without them needing to be in the room when
the decision is being made. So if you, if you can make it so that you can explain the rules of the game to someone outside of the room and then they can work it out to OK, if this is how decisions are being made, then I'm confident that they're made that they are solid, even though I don't know the arguments because of reasons. Yeah, I'm not Privy to those arguments, but I know that the employees perspectives were taking into account or right what whatever it matters to
them. Then you're going to have a much easier time with convincing people to to row in in the in the the right direction. Interesting. That really hits home because I, I feel like when decisions were made and I don't know what process or what led to that decision, yeah, that's when I feel pain and when I see friction around the extra critical. But when I do trust the process, it's different.
Yeah. So it's very important that the process is credible because people are, especially in in medium large organizations, people are not Privy to a lot of the details of the decisions. So a good example is promotion processes. A promotion process that is manager discretion is not really a credible system, no, because there is all sorts of incentives, right? The managers are incentivized to have their their reports happy.
And so there is an incentive to promote early to give an example, right, all sorts of things. So if you set up a system where the process is credible, then you're going to have a much, much easier time to explain the the outcome. Yeah, yeah, Love that. All right, we're going to round it off here. Thank you so much for listening. If you're still here, leave a like, leave a comment, let us know what you thought and we'll see you on the next one.