[0:18]Wow, that's a cool intro and every speaker will say that, right? But it's really cool. So, who thank you for being here first of all, because it's a very ambitious program. So many great speakers, so I really appreciate that you're here. Um, who has already heard of social depth? Any hands? Oh, cool. It is improving. That's a good thing. Um, who has already heard of technical depth? Everybody. Yes. And that's expected, right? So, um, social depth is a very new topic. It's something that's very unspoken of, very unheard of and actually what I'm I'm going to share is, well, what the current state of thinking is on social debt, where we are and why it really should matter that you're aware of this concept and that you are learning about this concept. So that's my objective for today. Um, because it actually influences your team's success and I'm going to show you how. Um, so first let's start with a story. So in 2014, I was looking, I was working at a very traditional insurance company and I was looking at all these cool companies and I thought, well, I want to go there as well. Because all these companies have one thing in common, everybody is so happy who works there. Not through all the time, I guess, but at that stage, 2014, because they were doing innovative things and the way they were doing that, led to having so much more value, so much more productiveness, uh and in the end, so much more happiness for everybody who was working on these projects. So, at that stage I thought, well, uh let's see where it takes us. So we started doing a greenfield rebuild of our full insurance uh uh administration. Because it had such great stories, happy developers, much higher quality, much more value, better collaboration, higher speed of change and yay, revenue increase, so it should also be the best way for the CEO to go. So, um, we thought, well, cool, we're going to do a whole greenfield rebuild and then we're going to be this unicorn company, just like all these high performance in the market. So what we did is uh we did the whole insurance uh uh scope to micro services. So everything went into micro services, front end, back end, all the batches, all the reports, all the integration. Um, we did full CICD, which was half a job back in 2014. So everything with full automated testing, everything. And then we thought, well, unicorns, success, cultural change, acceleration, we're there. Super cool. And um much to my surprise, it didn't work. Not at all. One of the biggest failing projects I worked in. Uh and it was on me, right? Um, uh because I really underestimated a lot of things that were influencing this company and this project. Um because one of the core concepts of this previous journey was that we were allowed to code go to production very early and to learn in production, how to get it right. And in this case, this company had already tried a rebuild for three times and communicated that to the customers. So they said, well, sorry, it's nice that you have this like this small component ready, but you cannot release that because our customers have massive expectations. And if this is what we're delivering, they will be massively disappointed. So we have to wait. I wasn't allowed to put anything in production. Um, the whole collaboration was broken because while the the some of the company was trying to do this whole greenfield rebuild, there was another part of the company still delivering value every day. And these these guys, there were no women in the team, they were called the dinosaurs, because they were all old and writing couple. And that did something to the way that the teams were collaborating. Because these people felt unacknowledged, unappreciated. Being called dinosaurs all the time, while they were actually the only ones making the company any money at that stage. So, there was a social thing going on, some kind of villainy that wasn't helpful. Because these guys were really not helping to integrate some of the new services that were being pushed out there with the old code base, because they were kind of fed up with it. Um, and um, so we had many deployments but no releases because we weren't allowed to put anything in, uh, like releasing to one of the customers because of this massive disappointment. And also, failure was really not an option. Because one of the two CEOs was brought into the company, taking the product that he built and let with him. So that was part of a merger. And we were actually replacing that product, because it was of bad quality. But this director was in a way influencing like, no, I don't want you to replace it, because that will be um, well, basically, my loss of value. What I brought to the company will be deprecated. So, a lot of social things were actually blocking us, um to do anything at all. So, that's when I found out, I really got the relationship wrong. I need water as well. Um, so it's not that you become a unicorn company when you do cool tech stuff. It's only a unicorn company that can do cool tech stuff. So then the question is, how to become a cool unicorn company? Because in the end, software is built by people.
[7:20]And this is something that Melvin Conway already understood in 1968. So, any organization, this is Conway's law, that designs a system will produce a design whose structure is a copy of the organization's communication structure. So, whenever you have, for instance, what I was uh discussing, like the whole sharing villainy, the dinosaurs against the new kids on the block. Um, when these people are not communicating, when these people are not working together, they are very unlikely to build any systems that actually integrate together. Because these people are not integrating. It is impossible to do so. And Melvin Conway already found that in 1968. So, the implications of Conway's law is actually that your system will inherit all your social dysfunctions. If you have an unclarity of structure between people, change in direction, social conflict, misalignment in teams, cultural fear or a lack of ownership. All these things will end up in your system. Your technical quality will be affected by your social quality. And this is what we call social debt. Social debt is the cumulative cost connected to adverse effects within a development community. And when we compare social depth to tech depth, which is, it's much well-known brother. So tech depth is really the work that's owed to the IT system. While social depth is the work that's owed to the IT team. It's similar. It's just different focus. Uh, there's code smells and social debt talks about community smells. So you can actually measure and identify them when you are aware of them. And you have to repay tech debt by investment in code, where you repay social debt naturally by investment in people and processes. So, um, I hope that makes sense. Time for my introduction. Uh, I'm Kim, mother of two. Um, I like traveling, so I love being in Krakow. Um, I like vintage shopping. Krakow has many, many vintage places, so um, that's awesome. Um, I'm a CTO at Schuberg Philis. Uh Schuberg Philis is an outsourcing company, so um, uh it's really different than contracting. We take care of mission critical problems for um companies that have uh that are important for the Netherlands, basically. So banks, energy, uh suppliers, uh big retail companies, uh so supermarkets, uh, uh railways, uh the ports. Um and it's really nice to work there because um when you are in a mission critical space, you get to build IT in the way that you actually want to. Uh because it matters so much in the core and the heart of the company that they actually have the time and space to allow to build it to perfection, which is something uh that really much um uh is something that I much appreciate. Um, so an introduction to social debt. As I said, I just want to make sure that everybody is aware of this. So, um, if you're here to get all the solutions, this is not the current state of thinking of social debt. This is really introductory. Um so I hope that you'll bear with me and that it's mainly focused on inspiration and to get your thinking flowing, basically. And I hope that does spark the start of change. I will explain something about the impact of social debt, the causes, how to identify them and how to repay them. Um, so impact. Well, in the end, human connections really matter. Because what was found in various articles and various scientific research is that social debt predicts technical debt. So there have been many investigations like, does the architecture predict it? Does the tech stack predict it? The quality of people, um, the, the, the, uh the age of the system. Uh, the uh, size of the projects that you're building. And all of these factors matter, but what was found in scientific research is that the one factor that matters even more than all these others is social debt. So this is why you should care. Um, and just an example to maybe get this more um, well, into real life examples. So for instance, we have a new guy on the team. And when he joined, we were totally under high work pressure. So everybody was running their ass off to get the work done and nobody was paying any attention to this new guy. And this is a community smell that's called newbie free riding. It's like here's confluence, there's Jira, good luck. This was your onboarding. And that's not okay, of course, because that leads to disengagement to depression. This guy was really feeling a solist in a new team where he was so much looking forward to join the team. Um and it was even worse because of course, it's not just the person that's very much disappointed. This is how it ends up in your tech stack. There will be no adherence to your architecture and process. Because this guy has no chance to actually live up to these standards because nobody shared them, nobody told them. So every little bit of code that he produced was of a different style, different quality. This is where you gain some tech depth. Lack of onboarding, very simple. Um another example is uh there was this company which was founded as a mission to, um, to deliver equality in the insurance market. In that stage, all the premiums in Holland were undisclosed. So, you would just go to a company, you would pay something, and you had no idea if this was a fair price. And this company was founded to change that. So they were publicly publicly exposing all the premiums of all the insurance companies. So their whole founding mission was about equality. And this kind of, um, ended up in their company as a car cultural caricature. Because equality became so important to them that also in their code, they would not allow any hierarchy. Everybody owned every repository. They had big mono repositories that were handling things that should have been separated in various libraries. So, this is a smell called a hyper community where the community starts to be a caricature of its cultural values. And that ended up to conformity and anchoring. So you could not defy like, hey, I I want actually to assign some ownership, maybe move to some inner source model or whatever. And that ended up into faulty software components because they had these big god classes handling everything. Um, they also lacked mandate. Nobody could say, I'm going to change the tech for this repository, because nobody had ownership on it. Nobody felt ownership on it. And it also led to to slowness, which is very natural. Um, this is one of my recent examples, uh bureaucracy driven design is what I call it. Um, uh, and it's the um, uh the smell is institutional isomorphism. Um, basically, this is a company that says, well, we have very strict organization. Um, it's a company that says, uh, we have agile in a company of 8,000 developers. So it's big. That means that everything has to follow some certain change approval flow. And when they went agile, um that meant that you had to put things on the backlog 12 months in advance. So there goes your agility down the drain, right? And these 12 months are blocking teams. So what are the teams doing in response? They are using config as code to actually deliver things that should have been code. Why? Because your configuration was allowed to change without the 12 month approval. So they had misdesign, simply because the company was driving them to work around it. So this is again something that ends up in your tech, which is a social issue. So, some just some other examples like, hey, did you ever work around an abstraction because it was too hard to do it the right thing? Did you ever just approve a PR because it was really complex and you were really busy? Uh maybe just approve it because the guy that or the girl that handed the PR to you was really hard to discuss any changes with, and you didn't want to have the conflict? Um, maybe refactor somebody's code without explaining why? Uh, not applying a refactoring because you don't want to have a discussion with the product owner and he says, well, no, just do the change, the functional change and don't do any refactoring. Or maybe not defy a proposed solution because it may affect your social position in the group. So these kind of examples are all social examples, that will affect the technical quality of your product. And in the end, that means it's always the organization, so we tend to focus a lot on the code. We tend to apply tech solutions for something that's actually a social problem. So let's do different. Um, let's see how you incur social debt. Um, and the question for me is basically, what kind of leader do you want to be? So in my humble opinion, everybody is a leader. Everybody is a leader in some area of this profession. Because maybe you have the most depth of knowledge on a certain piece of tech. Maybe because you have you're leading the process, you're leading collaboration, you're the most innovative mindset, you're the most um uh mentoring person, you're the most coaching person. So everybody has an area of expertise where you are leading the team. And then the question is, when you are leading a certain change, what kind of leader do you want to be? And um one of my colleagues compared it to a seagull. Um so there's many leaders who are like a seagull. They just fly over, drop their shit and move on. And that's not the way that leadership should be, right? And this because this is very hurtful. When you are a leader, a seagull leader, that means that you you leave people basically just hanging there. Because any change will have quite some effect. And this is the Ko-Ros change cycle. So whenever people are faced with change, they first start to deny it. Then they get angry, then they get depressed. And only after that, they are open to experiment, to accept it and to even commit to it. So if you are a seagull leader, you leave people there in denial. Not wanting to face any of the change. And then a few months later, you're going to say, well, this person is very reluctant to change and he's a bad performer. No, he's not a bad performer. You were a bad leader. So what kind of leader do you want to be? That's basically the question. Because every phase in this change cycle actually asks for a whole bunch of soft skills. And if you have, if you master these soft skills, that's when you are able to make sure that you don't incur social debt. So it's the lack of soft skills of leaders that leads to the concurrence of social depth. If you don't communicate clear why you want to change, people will deny. If you don't have empathy in the phase where people are struggling to accept the change, people will be angry or in fear. If you are not supporting teaching people when they are experimenting, people will get frustrated and stuck. So, um and of course, at the end you need to appreciate people. Because it's hard work to work through this change cycle. Um and there's a lot of these things. So there's a lot of people changes that actually lead to collaboration, communication or coaching gaps. Process changes that need attention to coordination or composition, team composition. Tech changes that lead to skill gaps and business changes that lead to context or culture gaps. Um, because these are the critical factors of teamwork.
[24:31]This is what you need to take care of as a leader and I think there's very little, very big lack of awareness on all these factors. Um, it's not just that you say, hey, we're going to change and this is what we're going to do. You need to make sure that you also think about, hey, how do we communicate between each other in this team? Um, what can people expect of that? Do we have the right setup of people, the right combination, when you have a combination of personalities? Do you actually have some kind of compatibility within these personalities? Um, are we coaching people in the right way? And the lack of that, um, is often the the the the way to incur social debt. Um, if you look at these factors, it's also very obvious that an agile transformation creates social debt. Because an agile transformation will change the communication, the context, the collaboration. The composition. So, it will change every one of these critical factors of teamwork. And if you don't guide that, that means that your agile transformation will be a big failure. Because people are lost in change. Um, the same goes for Scrum. So, Scrum has a very big effect of um exactly telling how things should be done. They're very process oriented. And this is called a community smell, it's called priggish members. These are pointlessly precise conformity to process. So you have to have a retrospective at the end of a sprint, always. And if you start defying that, people will get angry. This is really one of those community smells because that means that you're not allowed to think anymore what is the best way for our team to um perform in the current state. Um, while actually, if you look at the Scrum guide, the developers are always accountable for basically the quality of their product. And in reality, what I see in Scrum is that a lot of mandate is at the product owner and very little mandate is actually in the team. This is a social issue. Um, a DevOps transformation also needs this guidance, because if you think about it, in a DevOps transformation, there is change on every one of these factors. That's unavoidable. Because people who were not in the same team are going to start working together. And that's a big change. And an example of an insurance company in the Netherlands where there wasn't handled very well, is um, uh is a company that went to big DevOps. And in their big DevOps transformation, they thought it would be nice to make business in charge, fully in charge of priorities. No surprise, they never thought it would be a very good idea to prioritize any technical quality issues or any repayment of tech depth. So what they did is change was the absolute priority. And of course, because they want availability and because they want value delivered to the customer, the amount of change windows that the teams got, um actually went down from being able to push out change every day to one day per month on a Sunday from 7:00 to 10:00. That was the only change window they had. No surprise is that the quality of their tech was lacking. They couldn't do any life cycle management. They couldn't do any patching, they couldn't do any tech improvement. And that means they were completely stuck. And that's actually because there was insufficient guidance to basically, what's the collaboration model in our new way of working? So that's how you incur it. Um, how do you know you have it? How do you identify it? And this is the basically the cool thing. Um these community smells that I was talking about are actually your early warnings. So if you learn how to identify community smells, if you learn how to recognize them, that means that you can learn about you having social debt, a little bit earlier than when it's already there fully in your face. So that will be interesting. How do we actually identify and measure community smells? Um, well, there's two ways to do that basically. So one is, if this relationship between code smells and community smells is so tight as found in research, because community smells are social debt and leads to a lower technical quality, then it means that we can also use this relationship to point back. So what we can do is we can see what kind of tech depth do you have in your repositories. And from the combination of tech depth, derive that there's actually an underlying social issue. And there's uh there's some examples here. So, when you have a a combination of a certain um, uh tech depth, um, you can actually derive the fact that you have uh community smells, that you have social debt from the tech depth that you have.
[31:47]Another way to do it is, well, you can also directly observe community smells. And this is done with a technique called social network mapping. Because when there is something in this social network code going on, then it should also become observable. This is one example. There's the lone wolf effect, which is one of the community smells. The lone wolf effect basically is, um, that there's some people working in isolation. They're part of a team, but they're doing their own work, their own projects in isolation from the rest. That means that the technical quality will probably not adhere to the technical quality of the full team. Because this person is kind of doing his own thing, making his own decisions. And that's not, um, normally the way to actually have well-aligned, uh code. Um and the way to measure that is basically, in your repositories, you can actually see how many contributors are there. Um and in your social structures, such as Slack, email, you can actually see how much communication is there between people. And there's measurement systems that combine these pieces of information into observability of community smells. This is very new. Um and this is what it looks like. Um so you're able to to click on any one of these measurements and open the dashboard and show where you are in your team performance in comparison to other teams, where you don't know how to identify these other teams because it's um, uh we don't want this to be a managerial tool. We actually want every developer team to um or we trust every developer team to want to become better. And that means that when you have an idea of where you are, just as a ranking, so you can only identify yourself. Um and we don't give access to any of the managers. Um, then people can start um thinking about it, discussing it and start thinking, hey, how can I improve this? Um and that also comes with explanation, because just knowing the measurement is worth nothing, if you don't know how to act on it, how to improve it. So, for every one of these factors, we also say, hey, what are the engineering practices if you want to improve this measurement? How can you make it better? So this is this is one of the examples of the metric cards that we have attached to that.
[35:29]Um, if you want to do some further reading, um, social network mapping is still uh relatively new field, but there's a whole bunch of projects being um uh active on innovation on this part. Um and um uh very cool is that they're trying to actually identify social depth in open source communities, um which means that you're unable to talk to the open source community because those those that's not a team of people that you can actually can get in a room together. So they are they are basing that only on identifying community smells from the repositories, which is I think a very uh nice way for it. Um and the one thing I want to add is you have to repay as early as possible. Because um, uh social depth has a very progressive characteristic to it. So at the start, it can be solved by a conversation like, hey, sorry, I didn't really share the context well. Um, let me try better. You can share the context, no, no harm done. When you repeatedly fail to share context, it means that it becomes a pattern. And there's a community smell. If you continue, it will become a team level, uh, culture thing. And in the end, it will become ingrained in your culture and very hard to change. And a recent example that that we had was a team. So we work in customer teams. And a customer team is is the main unit of organization in our company. Um and in this one customer team, um there was uh sort of an uh deviation of this of this model. Uh because it started as three customer teams, though it had the same customer. And then the funny thing was that any one of these teams were choosing their own cloud. Of course, they choose three different ones. They were all choosing their own tech. So we had maximum um maximum variety. And then we thought, well, we made a mistake. We should not have made that three teams, so we're going to make it one. So the result, obviously, is that people say, yeah, good idea, as long as we use my tech. I'm not going to change. So there's massive conflict, there's massive people saying, hey, you need to use my solution. So this is called a community smell called solution defiance, where people are really polarized. They're not listening to each other, why one maybe is better than the other. They're not even open to allowing it to continue with different text stacks, but still working together. Because people now in a social depth way are kind of opponents and they're just defying each other's choices and each other's solutions. So this is the progressive effect of social depth, because we let this go on for two years before we started changing it. It is now very solid and very hard to change. So this is an introduction to social depth. Told you something about the impact, something about the causes, uh how to identify it, how to repay it. And what I hope as key takeaways, as I said, it's a very young topic. So that means that I hope that I brought some awareness of the concept of social depth. So that you leave here thinking, hey, whenever I see a technical issue, maybe I should pay attention whether there's a social issue underneath it. Um, it also means that I hope that you're you raised some more awareness on your position uh as a leader because each one of you is a leader and how to how to mentor change and how to master soft skills. I hope that you have some awareness on the critical team factors. Um, uh because you need to pay attention to all these factors in a combination. Um that you can start discussing and reflecting on social depth in your team and maybe um, but that's hoping for a lot. Um maybe you will try to start measuring and observing them from your repositories because I think that's where uh very cool solution is and where basically leadership becomes observable, which hasn't been the case up until now. Uh, and that's all I have. I even have time for questions.
