Anyways, good morning and good afternoon to anyone. My name is Geo. I'm head of engineering at OLX and I'm very, very happy to be here today.So, first of all, thanks for hopping in um for the session where I will attempt to take you through the area that I'm very, very passionate about and that OLX has given me the chance of actually uh pushing the agenda for. We will have, as I said, time for questions and you will be able to find my contact information on this slide. So just do reach out to me even after the session. If you, if you still want to talk Tech excellence, I could talk about it for hours or days even. So let's start with something that hopefully smells and looks familiar to most of us. And for that, I was thinking last night, what should I do? What should I do? And I thought memes, that's what we need to do. How many times have you been told in a meeting or in a work setting that everything is just fine when actually you're getting pretty toasty, a toasty heat around you. So you maybe are in a situation where there's clearly a burning issue that you need to solve something. It's something is evidently not working.

But actually at times it feels more comforting for others or even to yourself to ignore it and assuming that it will go away or that maybe Jim at some point sitting in the corner with his like pastel green shirt will pick this up and do something about it maybe. But anyways, this is fine. This meme I think is quite well used in the, in our industry. What about uh this situation where maybe the the burning issue is still burning and the response you get to to this is, oh, but we have stand up, you have constant gratuitous mentioning of agile and maybe Scrum or even Kanban as a solution that will, you know, we'll fix the fire, we'll put the fire out, you know, ref referencing frameworks, relying on certifications, you know, pointing and linking to Manifestos.

Sure, this will save us. And you know, we never really need to do anything else about it because we are agile. And usually uh this is my face when I hear that because I'm thinking really is a word really gonna solve all our problems is is really gonna go away. Then you get to the situation where you feel like a little bit like Bernie. And this meme is one of my favorite ones that after you've been told that stand ups will save us and you, you're thinking actually stand ups, I don't think will save us right now. You get told that actually, the only way of solving this problem is by further isolating the team away, making sure they're not distracted and they're protected from the business, uh that is constantly interrupting their flow and that they are constantly asking for things. And actually the team should be fully autonomous and they should be able to do everything they want all the time when they want. And the rest of the business needs to follow. As long as we have strong team commitments, we can go fast. And if we go fast, the business is happy, you know, a whole series of simplifications about how we need to solve problems.

And whilst the fire keeps on burning and we rush to put the efforts to put it out, we don't really notice what's really happening behind this, this famous memos for this year. You know, the the ship is blocking flow and we have still a bunch of people waiting for things to happen, but we can't really see the big, the big picture. We can't really see the connection of this and this is exactly why we need to talk about tech excellence today. Now, it's already too late because good intentions and just hiring top talent alone is not going to drive your organization to the goals that you want to, the aspirations you're after. And the things that actually are going to make a difference in how tech is excellent or how tech works in your organization is nested under other departments, other categories. So hr culture ops, it's maybe nested on change management. And if we don't pick and pick these things up and turn them into something that really works for your tech and product departments, then we're just, you know, sitting here looking at the ship blocking the flow and not really doing anything truly useful for it.

Now, let me start you off with a little bit of what tech excellence is. So tech excellence is basically operational excellence. But in tech um operational excellence relies on the idea that we should have a mindset that embraces principles and tools to make sure we're sustainably improving our organization all the time. The thinking is that by optimizing single operations of a team, the whole organi organization can benefit from this and we can therefore achieve competitive advantage in the market. So in operational excellence, we tend to talk about three areas or three buckets. One is about culture.

So changing the the the the sort of the moral compass of how teams and people make decisions, alignment, making sure we're actually all pointing towards the same objective. And the third one is about continuous improvement. So relentlessly asking yourself, is there, is there space for an improvement?

Will the improvement deliver the extra value that I need? Does this make sense? Is this really working now? Thinking about this, moving over to tech excellence. Well, it's, it's, as I said, fairly the same rather than talking about those three blocks, we talk about people, systems and processes and by you by working on these three blocks or these three breaks, let's say, I like to think of them as bricks. We're introducing operational excellence in our organization. The principles we're relying on here is abstraction, automation, self enablement so that these things together will be able to drive continuous improvement in the performance of the individual teams, the individual people and also the overall company.

How does there is, as I said, these areas that uh these three areas, I like to think of them as bricks. I like to think of them as bricks that I can sort of in a, in a sort of in a Tetris kind of way stack up and organize and build what is needed to trigger the improvement in an organization. So sometimes you will need more systems work, sometimes you'll need more process work, sometimes you will only need people work. That's actually what is going to drive the biggest game for, for tech excellence in the organization a little bit about how we drive the improvement.

So given the complexity of tech excellence where we're talking about, you know, uh people um process and systems, we have to accept the fact that this is not about shipping code fast, right? It's about changing behaviors, complex behaviors, behaviors. That are attached to a sense of identity, to sense of value, to sense of location. So this is actually more of an anthropological or even psychological exercise than one would ever think when you sign up to working in tech. And because of the complexity of changing behaviors, we need to leverage what we already know about the creation of good habits and the and the Decommissioning of bad habits. So you will see that improvements stick in your organization. Once you will have, you will have that proof once you recognize that there's a new heuristic in your organization. So I know I've introduced lots of concepts here. So I'm gonna take a little bit of time of explaining this often. We start with routines. So the routine is something that requires planning. It's, it's a stand up, for instance, it's a stand up that's booked in your calendar. You know, you have to go there, you know that if you're in the office, you're going to that corner at 10 a.m. and you know what you have to say and you also have full expectation of what people are going to say in that stand up. So it's a routine, it's well structured. Now, a routine in terms of comfort is quite comforting because there's this reciprocity.

You, you go to the same place, you go, you talk about the same things and the same structure, what I did today, what I'm doing tomorrow. And you also are getting exactly the same back from the peers in your team. So it's highly comforting in terms of how sticky a routine is, it's not very, necessarily very sticky. So if at some point, you stopped putting a stand up in a calendar or if at some point, for instance, a pandemic hit and you could no longer go into that corner in the office to do your stand up, you would see that there would be some changes into how consistent you are with the, with the contents of your stand up or the content, the quality of the routine and also the way you're sticking to the routine.

So that's why routine is useful to keep, to keep things going. But it's not necessarily driving or changing behaviors after the routine, what we talk about is a habit. So in terms, habits really require less cognitive load. So a routine requires you to remember, go, go into the calendar. A habit is something that you're, you're, um, you're trying to pick up, you are intentionally trying to develop. But at the same time, it's not very comforting. It's quite discomforting because it's usually going against the grain and also it's quite dry. So it's, it's quite hard to make it sticky. It's a habit. You're still developing this habit. You're, it still feels very uncomfortable for you to do. So, an idea of, of this, um an example of this could be, you know, the good habit of uh communicating, maybe uh some new RFC S. So I will actually use RFC S. So a good habit of communicating RFC S, it's something that you have to remember to do and maybe you need to do it in a particular way and maybe the routine might help with that, but it still feels like you're, you're forcing yourself to do something. Now, what I, when we talk about tech excellence, we really want to stop talking about routines and habits and we want to talk about more about rituals and heuristics. So let me talk a little bit about rituals.

A ritual is something that comes out of the um the work that was done around the, the, the habit loop. So the idea is that you can create a ritual by um instigating some cues into in having cues that will develop the new habits. The ritual is a habit with intent. The ritual is, is a habit with purpose where you understand that actually communicating your RFC is not just communicating RFC, it's about, you know, uh having uh you know, catching really radiating the RFC or the work you did to everyone else.

And therefore, there's an intent and purpose of learning and growth even that is not enough in ex in tech excellence. So just understanding the purpose of a habit is really not enough. What we need to do is develop heuristics and heuristics are fast, fast ways of getting rituals sticky a heuristic is really sticky because not only does it deliver the intent and the purpose that you need the rich that you want the ritual to do, but it actually becomes, it actually makes that ritual or that action really, really quick because you found different ways of doing it naturally.

So you could think of a heuristic as almost a natural response to a series of events that at the back of your head triggers a certain behavior. And that's when you're getting to tech accidents. And this is why it's so, so hard at OLX. So what we doing, as I said, habits is not the end game, but the reality is that we have to go through habits before we even get to ritual of heuristics. And oe right now, we're developing new habits and we're developing habits in the three areas or the free bricks that I mentioned earlier. The first break being people we call it engineering s and the area or this break is really dedicated to the smooth running of engineering.

What uh engineering ups looks looks at doing at OLX is for instance, uh making sure that we are always looking at the performance of our team from an angle of um highly performing teams. So we rely on Dora, uh which is some research was done in the past by um it revolution at looking at how many times do, how many kind of, how many bugs do we get? Into our systems. How fast, how, how quickly does it take us to solve those bugs? Um So that's, that's where the engineering s the smooth running of engineering. The second break which I referred to earlier was systems. And with systems how we call systems, this is all about our principal engineers, our principal engineers are dedicated to scaling our architecture by deepening the expertise that we need in that particular architecture or in those systems. So um a key example of this would be um the use of Ad Rs. So, AD Rs are architectural decision records that we recently introduced as a, as a way of really structuring decision making in the same way, regardless of who you are, regardless of where you sit or regardless even of what you're working on.

And our principal engineers are making sure that these Ad Rs are happening and the they're happening, pointing towards the same alignment and objective that the rest of the organization has. The third break is process. And again, at OLX, we talk about delivery practices. We know that if we just stick and use Agile Kanban, whatever it is and stick with that and assume that everything is fine, we know it's not going to be fine because things are constantly changing. And um our partners in the rest of the organization need things at different times and for different reasons. So what we'd like to think is that in our process, brick, we're constantly looking to iterate to support a growing business or even to support a growing team. Um If maybe you started by doing a stand up uh in, in person, in a, in a, in a, in an office, you now need to start thinking about how are you going to scale that stand up for um a team members that are not sitting next to you, let alone maybe on your same time zone. So this is really it, I really wanted to spend a little bit more time with the question. So I'm gonna stop here. But this is what we do at E and you really, really ought to talk about tech excellence at your organization.

Eight. Thank you so much. Thank you so much, Joan. That was a fantastic start of the day. You were very uh you shared so many insights with that. That was great. Awesome. I saw many people were reacting and we even have two questions. Uh So the question number one, how do you predict that process needs evolving slash

change? How do I predict that a process needs evolving? Is that right? So, uh well, processes always need evolving simply because the process has to support the people that are working on something, which means what we need to be doing is understand the needs of the people and not the individuals, but the people working on a piece of work and then adapting the process to match that.

So it's not about how do I know that a process needs evolving. It's more uh making peace of the fact that a process always needs evolving. And I know it's very frustrating because once you do something you kind of want to move on to something else, what I would suggest in this case, when you're doing process changes is make a change and just commit with the rest of the rest of the teams around you that you're going to make this uh change stick for at least X amount of months or X amount of, of um maybe even six months or half a year, depending on the size of the organization, on the appetite the organization has for change on even everything else that is happening around you, you really need to be realistic about how long you want a test to iterate to, to, to stick for.

So at OLX, for instance, I've worked out that our time for change or for adoption of new things is pretty much six months. So I've realized that I am not going to change large processes uh more than every six months?

Great. It was a great answer. Uh Does engineering include uh does engineering include include also the design

process? Yes. So when, when we think of so in some cases of tech excellence, at least the OLX, we think about only engineers because we know that they are the largest, the largest number of people contributing towards the delivery of um of a customer value of, of a product. But of course, there are key points in time where engineering is completely useless without design or even without research. So um these moments in time we recognize are happening very much around the delivery practice. And this is why we have this third block of process really dedicated at OLX to delivery. So for instance, in my job, day to day, I try and look at the the delivery pain points that are happening within teams within larger squads. And I try and reach out for partners in crime in the other functions and, and uh departments. One thing for sure with tech excellence is that it's called tech excellence, but it's not only tech and in fact, I don't, it doesn't really matter whether you're an amazing technician.

What matters is that you need to be really amazing at putting yourself in, in difficult situations and being bold and courageous in pushing that change. You're a change agent, you're not a technician.

Great. That's, that's a great point. Thank you so much, Joanna. That was a fantastic session and thanks for taking the questions from the audience. Stay with us. Uh We'd love to have you at the networking, stay with us for the sessions. X also has a booth. So make sure to drop. Why say hi if you want to work with amazing people like Joanna, say hi. Say thanks for supporting the Global Conference. Thank you so much, Jana for this fantastic start of the day on tech excellence. It was super useful for many of us. Fantastic. Thank you. Thank you very much.

Thank you. Thank you, Ana. Thank you everyone. Bye bye.