 Okay, hello everybody. I hope this works. I often get really nervous when I hold these things. It makes me feel like a rock star, that's for sure, but let's see how that works. Okay, hello once again. I'm Mark, engineer manager at STRV and I'm very thankful for you here because I'm gonna talk about code as culture, which is a topic that touches organization structure, team structure and stuff like that. I always tend to get very excited when I get to get a chance to talk about these things. I often talk too much, so we are gonna be victims of it today. Let's see how that works out. So why am I gonna discuss it? Why am I gonna talk about code as culture? Why am I gonna even talk about organization structures when we tend to get the standardized ones, right? So in my opinion, code is often viewed as sort of an artifact, sort of split, separated and divorced from social and cultural context and that is a real shame. I think that the code somehow reflects the organization structure and personalities of engineers who created it. So engineers, in my opinion, are like artists. The technologies that they use, these are their color palettes and the code is sort of their brush and I believe that every artist sort of reflects himself in his painting and I think that it's the same for engineers. So what can we do for them to make their reflections a little bit easier, right? Let's start from scratch. Let's start with an org chart. I'm pretty sure you're familiar with this. It's a pretty standard org chart. At the top there is a, let's see, if the point works, cool. At the top there's CEO, CTOs, then there are some head of departments and later some engineering managers and their teams. Pretty standard structure. I'm asking what is the org chart for? So you can say that it's a single view of the teams in the organization and the people. It's sort of a hierarchical structure, right, for the purpose of reporting and it facilitates compliance. Cool. But if I look at the org chart, can I really at least know what the company is doing? Can I know what the company is working on? What the engineers do? Hardly, at least not this kind of org chart. So what is it really for? Well, to submit vacation requests. That's all it is good for at this point. Fair, I assume. So I have three issues mainly with the org chart. People communicate horizontally. Issue number one. You know, if we have the backend engineering structured vertically, what is it for? Well, the product that they create is not just backend. It's backend plus front end plus mobile plus QA. People communicate horizontally. The products are horizontal. Why do we have vertical structures? Issue number two. People don't restrict their communication to those lines in the org chart. They just communicate with whoever whoever whoever whatever they want with. And they always choose the line or the path of least effort. And the issue number three, it doesn't represent the actual work that gets done. Matthew Skelton, the author of team topologies, by the way, great book, wrote that organizations that rely too heavily on org charts often fail to create the necessary conditions to embrace innovation. Well, how do we then create the conditions to embrace innovation? How do we support these artists in the team? Well, number one, think team first. The principles of team first thinking just very briefly, because this is a complex topic. Firstly, the team is the smallest delivery unit in your organization, not individual, the team. And as such, your organization should always assign work to the teams, not individuals. Then focus on team dynamics. Instead of focusing on individual engineers in your team, build psychological safety, environment trust, and optimize the performance of the team. You see, there has been a long running research made by Google called project Aristotle. And they actually found that neither skill, not a specific personality, matters to the performance of the team. What matters effectively are factors such as friendship, curiously enough. And the common denominator of success in those teams was equality in distribution of conversational and third thinking, meaning how much do I get to say in the team? How much other people respect me? Those were the performance factors, not how much I know or how much this guy knows. Also, respect the size of the team, and there are some limits we're going to get to them, and respect the limits of individual mental capacity, known as the cognitive load. So the team size, how do we respect the team size? What does it even mean? Well, the limits are derived from evolutionary biology. There is a limit called Dunbar's number, and Mr. Dunbar, he described multiple limits based on the level of relationship and trust that we can build with people. According to this theory, one person can trust at most 15 people deeply, and of those 15 people, we can only have deep interpersonal relationship and trust with five of them. So there is this magic number, seven to nine people, that is considered to be the good standard of a size of the team. And if you talk to managers, they intuitively get it. They tell you, I think that 10 people is optimal for me. Some tell you 15 is okay. Some extremists tell you, I can manage 20, that's fine. But intuitively, they oscillate around those 10 people. Fun fact, Amazon is known to limit the size of its team to the size that can be fed by two pizzas. Also, good metrics, fine by me. So is there everything there is to it? Just think team first, and we're going to design a great organization structure? Well, let's see. So this is the structure that I presented earlier on the org chart. There is back and front and DevOps and QA in this organization, and we split it into three units. Simple enough, those units can be anything from individuals to teams. Those units work on product A, B, and C. A5 units, B4 units, C also for units. There's also times on separation, where those units below the line are in US East 1. Those are remote, and these eight units up there are in EU Central 1. So this organization design really that simple. We just followed the team first thinking the units are small enough, and they have separate products to work on, sort of. So is it really that simple? Well, let's see. I mentioned that people follow communication patterns. We're all humans. So what happens if we specifically trace those communication paths? Well, for EU Central 1, if we just connect the people that have to talk to each other because they are on the same project, just because they are on the same project, it can look like this. And we can already see that this poor guy is sort of starting to hit it. So this poor guy as well. And that's just one time zone. Let's add the second one. And it kind of gets creepy because those people are starting to swamp this beck and guy. And this DevOps guy really doesn't know where his head is. But the thing is that we follow the path of the least effort. So what probably happens is that those communication paths in real life simply doesn't happen. Because what those engineers, those remotes in US East 1 can do instead is that they will talk to the DevOps and QA in their time zone. Notice these are not even in their projects. They don't work on the same product. But why wouldn't I talk to this person? He's allocated only on 50%. He's got the time, right? What this poor guy can do on the right down there. Similarly in the EU time zone, I can talk to these people. They don't have anything to do work on. So new communication paths are created. And also, since the teams are structured vertically, these people that don't work on the same project either, but both are front engineers in the same team, they start to talk to each other again. And these communication patterns have sort of unexpected consequences. Let's talk about what consequences. Okay, I see people nodding and laughing. So who here heard of Conway's law? Cool, 20% of people. Very good. So Conway's law states exactly this. Organizations are constrained to produce systems which are copies of the communication structure of those organizations. In other words, the communication structure gets cemented in the way these people develop the products. It was outlined in 1968. A lot has happened since then. Containers, microservices, all of it. And it still matters. Because a product's architecture, according to this law, tends to mirror the structure of the organization. And if we want our organization to explore or adopt certain engineering patterns, we have to reshape the organization to remove those obstructions. Simple example. Now, this is a little bit better, right? There are two horizontal teams, team A, team B. There's two full stack developers in each of them. And there is a database administrator that works on those two teams and operation engineers as well. According to the Conway's law, what do you think would happen? Well, there will be probably one repository containing backend and frontend. There would be shared database. Because why not? Why wouldn't I just make my effort easier and create a shared database for those two products if I'm working on two of them, on both of them. And there will be shared infrastructure. That's the path of least effort. Do we want this kind of architecture? Maybe, but likely not. Now here, it gets even trickier. And what could happen here, this was a little bit tricky, but something like this can happen. So there will be shared or loosely, sorry, tightly coupled product A and product B on the backend side, on the frontend side. Probably, there will also share infra, but in this, I should point here, right? Why didn't you tell me? Peract Bay, A and B coupled tightly on the backend, on the frontend, they will share CICD, some automation with both of these products. And there will be even shared infrastructure. And down here, the situation would be similar. And if you remember, there were engineers that were unallocated to their project. Now, imagine what would happen if those engineers were allocated to a product D. It would get exponentially more complicated, just because of the way we structure the teams. So if we think of software architecture as a standalone concept that can be designed in isolation, well, we're fundamentally wrong. So what can we do with it? Now let's try code first thinking. We can combine the principles of think first, a team first thinking with the approach to software architecture itself. We can design teams that are specialized according to their responsibilities in the SDL cycle and the way they collaborate with others. And we can also define these teams as aligned with the Conway's law to match the desired product architecture they are supposed to produce. In a code first thinking, we also respect the team size, just like we mentioned before. But now the team size should be established together with the size of the product. In other words, that since the team should take full ownership of the product, the full product should also be sized accordingly. Fun fact, there are squads. Maybe some of you heard about the Spotify model from 2012. So in their model of organization structure, they have squads as a basic development unit and these are of size of six people and a squad by definition from the perspective of Spotify is a mini startup. So the product scope matches the size of six people. That's how big their products or small their products are. So what kind of team types should we introduce here? We already know that back end department, front end department, that is pretty standard, not good. So what kind of team types? Well, topologically, we can have four fundamental team types and we call them streamlined type enabling subsystem or complicated subsystem team and platform team. Let's take a closer look. So this is how they should interact and you will soon see why. So the streamlined type, that's the primary type in our organization. We have multiple of these. There are disjoint coexist in parallel, consist of journalists and specialists and these are the teams that focus on a single business domain. In code first thinking, this business domain could for example be owning a single product or a set of features. These teams define a single API. These themes aim to produce a steady flow of delivery and they deliver end to end from software design through quality and user experience. The enabling teams are purely specialists in a given technical or product domain and what's curious about these teams, they should aim for their own extinction. The key to successful enabling team is for them to not be needed anymore. So there are calls to action when needed. They enable teams goals by enabling certain functionality and they always support the streamlined team. In fact, the whole purpose of this structure is to have the streamlined team in the center and all of the teams just making their lives easier, reducing the cognitive load of this team. Most importantly, there shouldn't be any permanent dependency on the enabling team. In code first thinking, again, what you can imagine the code, the enabling team to do, well for example set up a skeleton for a deployment or an API service or just provide a guide about best practices or integrate once with a third party service. They just pass over the knowledge how to do that to the team and are done with it. The subsystem team is sort of similar, but this one is persistent. It consists also of specialists in a particular subsystem, but these are also responsible for maintaining it as opposed to the enabling team. Examples, video processing codec, mathematical models, reporting systems, real-time trade reconciliation algorithm, those are very, very special domains and require high level of expertise. The streamlined teams could do that, but it will require a lot of effort and a lot of time. Instead, it is offloaded to the subsystem team. And the last one, platform teams. These are very similar again, but this time to the streamlined teams, but their whole purpose is to support the streamlined team by providing sort of a self-service API for the platform. So in this case, they, even though the streamlined team has the full ownership of building, running, and fixing the application, the platform, the infrastructure that they are building it on, this is the responsibility of the platform team. And their focus should always be usability and reliability. This can be, for example, platform as a service for the streamlined team delivering networking capabilities, providing maintenance and maintenance certificates, as easy as possible for the streamlined team. Those platform teams are complicated, and there is, it's called fractal topology, where the platform teams themselves can be sort of split into streamlined and subsystem and platform teams all over again. So this is it. And an example of tasks that are assigned to those teams, again, teams, not individuals. Platform team can maintain public infrastructure and provide an infrastructure as a code deployment template. The streamlined team implements the business logic of the application. The enabling team once set up a skeleton for the deployment, and the complicated subsystem team designs and maintains a real time reporting system. Those are examples of the tasks. Okay, now back to the org chart. This is a little bit of a different one, but similar. Made it a little bit easier for you. So we have back and front end QA data science DevOps. This is the do and Android and iOS. The product is this. We should create a complex backend API that consists of user administration, three real-time recommendation engines, content management system, and payment system. We should have a distributed persistent storage. There will be AI models for the recommendation system, for the recommendation engine, some ETL pipeline, web-based admin, and mobile Android and iOS applications. There is estimated headcount of 25 engineers, split into eight backend guys, two data science, two DevOps, four front-end engineers, two plus two mobiles, that is, two iOS, two Android, and five QA. This is the estimated headcount. The task distribution. So backend, create API, data science, implement the predictive model, front-end, obvious, Android, iOS, obvious, DevOps, these poor guys have really a lot to do because they have to create the storage for the backend services infrastructure, blah, blah, blah, a lot to do and don't even get me started on the QA. So what do you think the issues are? Well, the DevOps engineers, I like this. This is fine. I can do that. And the resulting architecture, what do you think the architectural components will look like, given the organization structure that I just presented? So likely, there will be a shared infrastructure because the DevOps guys are just, you know, we just need to make it happen somehow and that's it. Shared database, because the backend engineers are in a single team, it is likely that the one single team will create a shared database and a monolithic API here. Conway is long, remember. There will be data science pipeline because there are just two data science engineers. That's not much for the whole project. So I would assume they will have a lot to do as well, especially given that they have to create the predictive algorithms and three recommendation systems to feed into this backend service. And likely, the DevOps guys won't really assist much, won't really be much of an assistance to the data science guys. So probably just one data science pipeline here. Since mobile department is also not split into 100 and iOS, perhaps we can also, but this is a pure speculation, there could also be cross-platform mobile application. So if this was your desired architecture, fine. Okay. But what if it was supposed to look like this instead? Meaning separate infrastructures, single-purpose database, specialized microservices, gateway, three recommendations models built on three different pipelines, data store that is separated for the data sense input and to separate mobile applications. What if I told you that this is what it should look like? Well, perhaps we, based on these expectations, these expectations, can design the teams to produce this desired architecture. And we do that by calling an Uno reverse and apply what's called a reverse conways maneuver. I know it sounds like a masterful military strategy of moving some worship 180 degrees per second. Luckily, it's not that complicated because all it says is instead of thinking teams first and architecture second, think architecture first and teams second. If that reminds you of code first thinking that I presented good, because that's exactly that. So step one, identify the stream aligned teams. These are the products that we have to build. Literally, real-time recommendations, payments, CMS, user administration, Android app, iOS app, web app, stream aligned teams, the business domains. Identify the complicated subsystem team, the predictive modeling, definitely. And it will be connected to the real-time recommendations because they have to work in close collaboration. But it is a part of a complicated subsystem team. Now, identify the enabling team. Well, DevOps. We have to somehow make lives for the DevOps team easier. And we can do that by turning them into enabling team whose purpose is basically to just hand over the knowledge that they have. And we can do that. We can let them hand over the knowledge to the back and centric team because they have very close relationship to DevOps already. So why not turn the team into enabling team? But notice we only have five QAs available, not good for a team of size of 20 minus the QA. Well, what we can do here is we can turn some of the members of the QA into enabling team as well because what we need is the QAs to be permanent members of Android, iOS, and web where they have to provide day-to-day basis feedback by testing their applications but not necessarily to the back and centric part. Because there, we can just hand over the knowledge of setting up the automation testing, the CINCD, why not? We can hand it over to the back end and be done with it and focus the rest of the efforts to the data science, let's say, or to the mobile applications. And lastly, the platform team. In this case, this is tricky, but it's probably going to be identical with the DevOps enabling team. Or it can also be the data science engineers building the data pipelines. So I'm just going to put it here knowing that I'm not really sure what the platform team would be here, but probably would have a significant overlap with the enabling team. Okay, so what to do with the org chart now? Let's not do anything with it. It's still reasonable to keep it at this point for the compliance purposes, aka the vacations, requests, and reporting. And continuing this further would require transformational change. So it falls into the scope of change management. Yeah, you don't want to get me started on that. That's a difficult topic, but since we already have this, we can, at least with high level of anticipation, expect that we will be much closer to the architecture itself. And then it's up to the competence of the management to see whether they can actually support this kind of architecture or not, organizational architecture, and whether they need transformational change aka change management to completely restructure the organization. But this is the first step. So recap. So recap, code, let's not just look at the code as a technical artifact, because it does reflect organizational structure. Let's just don't rely on the org charts instead leave the distribution and control of work to the teams and think in teams first manner, form a good team by establishing psychological safety and focus here on encouraging a culture on dependent off dependability and mutual respect, optimized for the team size, optimized for the cognitive load, respect Conway's law, because it tells us how organizations produce code. And when designing organization structure, just think team first and code first. In a code first organization design teams define a team as API that's the topic that I didn't touch by it's a contract for communication. Those teams are split according to their to the teams API that provide. They are called stream aligned, enabling subsystem and platform. The stream aligned focused completely on the business logic enabling they aim for extinction, complicated subsystem team of specialized experts platform platform team. They should always aim to maximize collaboration. And you can design those teams by going backwards by applying the reverse Conway's maneuver and proceeding from the desired software architecture to the organization structure. And just know that like code no organization structure is perfect. Just make sure that it doesn't get in the way of the culture you want to build. With that, thank you so much. I hope that this at least gives at least gives you the idea of what you can do with your organization. It's a complex topic. It's complicated to force these changes. But perhaps you can do that with your organization as well. Thank you. I know here's place for questions. Cool. Okay. Yeah. So roughly, so what's the solution? How to split up the org chart? Yeah. Yeah. Okay. So the question is I have floating managers all around after I split the org chart. What do I do with them? That's the transformational change part. So typically splitting it's kind of funny. But when I sort of went through a transformational change of an organization, when you split into smaller teams, typically smaller, because the departments are 30 people 40 people and you split into much smaller teams. It's going to present some management overhead. The more teams you have to manage, the more managerial tasks it requires. And then you're going to get into, okay, how many people can these managers really manage? How many, how many teams can these managers really manage? Those are two different questions, by the way. And when you present the engineering managers with the issue at hand, so I know you just had 40, 20, okay, be realistic, 20 people in your team. Instead, could you manage four teams of five people? They will probably tell you yes. So as long as you are able to sort of fit into this amount of people that they are accustomed to, it's not that big of a change for them, if you know what I mean. So that's one thing. Then what typically happens is that you have to add, unfortunately, you have to add one layer on top of it. You no longer have just engineering managers that synchronize all these teams, you're probably going to have team leans. And that's a wonderful opportunity to identify talented individuals that can lead those teams. Ideally within the engineers, you don't want to introduce another management layer. You want to introduce sort of a leadership structure within the team. So ideally you want the teams to be self-organized, but still identify the individuals that can help the self-organization. So that's sort of another thing. And we can move on, but hopefully that at least tells you a little bit of it.