Transcript
Vanessa Formicola: I'm Vanessa Formicola. My pronouns are she and her. I'll be talking about holistic engineering or the practice of factoring in your technical decisions, designs, strategies, all the non-technical factors that are actually forces that influence your organic socio-technical problem space. As much as you can see in this canyon how natural forces have influenced the shape of the earth, so you can see the color. You can see all the different layers.
In the same way, if you look from this perspective, you will be able to see how forces independent from your control have actually designed some of your software and your architecture. This is a brief overview of what we'll be talking about. I'll just give you a little background about myself and introduce you to some of the issues that I've seen in the wild in projects. I'll talk through the concept of holistic engineering. Then we'll talk a little bit about what we can do about it, what I personally try to do about it in projects.
In my career, I've worn many different hats. I call myself software engineer, wherever I am. I've been called architect, been tech lead. I've been an engineering manager that was a more managerial role, principal engineer, and especially a consultant. These different roles, independently from the company I worked in, the domain I worked in, the tech stack, like a completely diverse group of people. What I found out is that actually you see patterns of behaviors that happen over and over in your technology, independently from everything else. It's interesting to actually point out some of these things.
Issues Observed in the Wild
In general, and clearly this is a small overview of what project problems can happen, but it's interesting to walk us through. Have you ever had a project that was late? Have you never had a project that was late? This is like a problem of our business. It's very hard to have perfect alignment with the deadlines, and, potentially, better way of estimating is not necessarily the way forward. Another thing that really bugs me is when at the end of the project, after so much strategy, so much design, we end up with something completely different for not good reasons. Not because we're evolving the architecture, but more because some funding was cut, some other problem was there, or there was such a misunderstanding that at some point, you just have to deal with what you have.
In my opinion, some of these things happen because we live in our own sandbox. As technologists, and so many other disciplines do this too, we look at our problem space from our perspective, from the perspective of our responsibilities, and we rarely manage or have the opportunity to look at the full picture as well as we could. I'll go through three examples of patterns that I've seen. I'm sure you've probably seen them in some company project, but there are many more that one can look at that again are examples of non-technical forces that have shaped quite at low level your code and your architecture. I call phenomenon an event or a situation that everybody recognizes it exists, but people might have different opinions of why that happens. I call these the phenomenons in the wild, like the patterns that I see.
The same for your natural forces, which generally are forces that influence your path in a way or another, and you have to find ways to either accept it, mitigate it, or solve it. In this case with lava, I think it's going to be a bit harder, so it's probably an accept.
Shared kitchen sink, so this is the first example that I'll be talking about. For who's not from an English-speaking country, there's an idiom that says everything but the kitchen sink, which means you've stuffed all sorts of things inside your bag or inside your suitcase, the only thing you forgot is your kitchen sink. The phenomenon that I see in projects, and this I've seen almost in every company I've ever worked in, is a utilities library. Some people call it common. Some people call it the name of the company. I'm sure names are not the point in this. There's a library that is used by all the services of your company where all your developers from all the different teams are adding small little features with the intent to help each other. What are the issues with this? The first issue is that if you have a library that everybody contributes to, first of all, if there is an issue in that library, all the services that are consuming it might be part of the biggest blast radius that you can imagine if something goes wrong.
Another issue is that if multiple people from different teams constantly add small little features, you end up with a service that is very big, and that at some point, nobody will know anymore what's there. Even if people with good intentions would like to refactor or consolidate the feature, eventually this is not going to be possible. The bigger it becomes, and the more people collaborate on it, the more it's going to become difficult for people to refactor it and actually make it more efficient and more flexible. Clearly, that's going to make it more complex, and then it's going to make it more buggy, and then generally whenever there's complexity it's not going to be well tested.
How has this come about? In my opinion, two of the main forces that cause this phenomenon to happen is what you see behind me. One is whatever is your people management process reward system: whether it is your career framework, whether it is bonuses, whether it is review cycles. However you're actually evaluating your people is sometimes giving the wrong signal on what they're supposed to do, and it shows directly. Very often, this is designed by HR. Sometimes this is designed by senior leadership, usually non-hands-on leadership anymore. Usually, there's something that, although sensible, has bad consequences, something like this. An engineer is as senior as the area of impact that they manage to impact. Let's say if something that you've done covers the entire company, is a level of maturity.
If it's two teams, it's a different level of maturity. If it's your own team, it's a smaller level of maturity. Although conceptually that's not wrong, what happens is that people find ways to game the system and add functionality in a service that is shared by all, so that they can write in their review or whatever process you have that they have contributed to something for the entire company, and have already a mechanism to do that. Another one is usually when there is poor planning or delivery pressure. Somebody that comes in and says, we need this by tomorrow. We need this next week.
Then developers in the team will have no choice than use the delivery mechanism that they already have, which is this library that's already there that will very easily be used by people. What you can see here are two forces that have actually shaped in many companies the presence of a library. The decisions behind it are not technical whatsoever. The decisions are made by different departments for different reasons, but have a very direct influence on the code that you have.
Let's try the next one. This one to me, it's about identity crisis, and, generally, separation of concerns. Usually, the phenomenon, you can see through all these examples. You can see that you have a very similar library to what I mentioned before. It's just that it has domain classes. Usually, these domain classes are to be considered the entire domain of the entire company. Instead of making the assumption like many DDD practitioners would do that, given your entire domain, you will have subdomains and different areas, and you will probably have different representations of very important entities. They make an assumption that the same group of entities, the same domain is exactly the same for the entire company, for all the services in your company. Then this is enforced through a library with your domain classes. What usually happens is these domain classes become huge because the representation from different domains is all stuffed into one class. It becomes more difficult to manage. Also, you have all the problems that we mentioned before.
Another tale of this phenomenon is when you see that multiple people will talk about the same thing with different names. That usually is a good tale that there are different representations or different perceptions of the same entity in your system. It should make you think. Again, as mentioned before, there are all the issues of the shared library. I think in this specific case, the biggest risk is your bugs. If human beings don't understand each other, your software will never correctly do what you expect it to do.
Then, it's the usual. The more complex, so the bigger classes, the bigger dependencies, the less you will find testing and the more likelihood of general bugs. How does this come around? In my opinion, one of the main reasons why this comes around is when the product org itself is not mature enough to have developed the practice of truly fully understanding the domain or knowing how to communicate it between each other and to others. Unfortunately, that happens. It could be that they don't appreciate the practice. It could be that they're more junior. Just whatever human reason. If the product org themselves don't have the understanding and the communication skills to actually map the product and the subdomains, and so on, it's going to be almost impossible for your engineering department to be able to represent that in your code.
Another tell, in my opinion, of a decision that actually causes your software to look differently, is when you don't have a business analyst in your team. A business analyst is a job role whose main responsibility is to be the bridge between a requirement and the team. Surely, they have a lot more responsibilities, but at the end of the day, they are full-time responsible to make sure that all your requirements don't overlap, that all the details are there, that nothing is missed. I mention this because not that many teams have this role, and every time we didn't have this role, what I've noticed is that a couple of people in the team will take that responsibility and do this as a secondary responsibility, and the result will never be the same. Because when it's a secondary responsibility for people, they simply won't have the time to dedicate to actually map and model and find everything. It's not their fault, but that's a decision that when your leadership, whoever is making staffing for the team does, they're actually causing some problems in your code and poor design of your domain.
Then, the third one that you can see, in my opinion, is the strongest one, and this is by how your organization is designed, the domain has not been mapped to your teams. This could be even very simple cases. For example, you have only two services in one programming language, let's say in Java, you have a different programming language for the rest of the teams, and you decide to put those services in the same team. Which sounds sensible from a resource logistic perspective, but from a domain management perspective, you might have not put together the right domains. When that happens, your team will look at the world from their perspective, from their team, and think that that's one domain, and will design that in that way. Whether it's a product org, whether it's your project management, whether it is the alignment of the company, none of these are technical people, developers, architects, people who make, usually, design, architectural, and code decision. They're actually influencing such strong forces how your code will look like.
Then, third pattern, I call this the Cirque du Soleil coding. Cirque du Soleil is a group of artists and acrobats, they're quite popular, and they've been around for 20 years. They're famous for being very skilled in their acrobatic performance. If you ever open the code base, and look for a very simple feature, and found that all the possible design patterns have been fit in, every single feature of the library was fit in, and 20 different libraries were fit in, that's probably an example of what I call Cirque du Soleil coding. That means, to me, that somebody has put a lot of effort in showcasing a range of skills in any functionality without necessarily thinking of what was the simplest option. Clear risk of this is the risk with over-engineering. I spent more, it's going to cost more to debug, it's going to cost more to maintain. Clearly, complexity will take us, again, to bugs and poor testing.
In general, one thing that really concerns me is the culture of coolness. I am cooler, I'm a better developer if I use every tool in my box for every single feature instead of the simplest possible thing for what I'm doing. We tend to reward that. We go back to the career framework on whatever rewarding mechanism you have for your company. Usually, there will be something that says, practitioner is very skilled in the tech stack of the company, something like that. When this is badly interpreted or when people have to showcase their skills in an organization that maybe doesn't fully understand some aspects of this, people will have to showcase ranges so they can present PRs, and say, look, I can do this, because you can see in this PR, which is a lot more difficult to dilute all of this in 20 different PRs. Again, this is probably HR that is influencing negatively the design of your code.
Another aspect that I've noticed as a pattern is when very influential people in the company promote a behavior or a specific library, a specific language, and with good intention, maybe they're just saying, I think this is valuable. People take it as everything you'll do from now on has to be that. Again, that's culture and that happens. I've seen it done from senior leadership. I've seen it done from principal engineers who enforce their opinions through PRs. Again, not necessarily negative in itself, but we need to be aware of certain behaviors.
Then, in general, again, one of the things that worries me the most is toxic culture. When the culture is toxic, you will see that people feel the need to constantly demonstrate and to over-engineer and to constantly prove and showcase, and that's how you end up with such complex code bases. Again, third example, all forces that have nothing to do with our craft, nothing to do with how you design code, nothing to do with how you design architecture, all human processes from potentially different departments, all different reasons.
In my opinion, the issue is that we close our eyes, ears, and we don't speak about lots of the problems and dynamics that we see that are outside our responsibilities. We behave like the little monkeys. I will use these words to try and help me develop this concept with you. This is Jung, a famous philosopher. What he says is, "When an inner situation is not made conscious, it appears outside as fate". How we can relate this to our own projects is we're almost very often aware of some of the human dynamics and problematics in our company, things that are dysfunctional, and when our project is late, when a project has a problem, doesn't go in the right direction, we say it was fate. How could I possibly know that so-and-so would quit? How could I possibly know that these two people didn't get along? How could I possibly know that there would have been that impact on my project? Very often, we claim this as fate when actually the where tells, it's just that we didn't think that it's something that concerns us.
Again, I'll use the words of Gloria Steinem. She's a writer, journalist, and activist from the United States, and she says that the truth will set you free, but first it will piss you off. That is because most of the time, we are aware of what's going on, but we decide that it's too petty to factor it in into our technical decision. It's too petty to actually factor in that our stakeholders don't get along. It's too petty to factor in that our career framework is messing with our process. It's so petty and so on, and we decide that this is outside of our professionalism. Then, the results are something that we have to deal with because they show up in our code.
What do we do about it? In my opinion, we start looking at the problem holistically. Holistic is something whose parts represent the entire organism, and you can't really operate with it without looking at things as a whole. I particularly like when we think about it in terms of holistic medicine. When people are treated in holistic medicine, we don't only look at their illnesses and symptoms. We look at the environment in which the person got ill and what are all the other factors that influence the reason why that person has an illness. How does this translate to engineering? If we look at holistic engineering as the practice of when we do our technical design, we consider among the factors, not only the things that we would do usually, but also all the other non-technical forces that will be influencing your system anyhow. We admit to them, we can look at our problem as one organic system and influence, to some extent, various parts of the system. Very often, when we look at our problem space, we think, that's my project, big or small.
My project is just a small piece within the organization, within the world. Actually, the forces that influence my project are way wider than what is the first look, scope of my project. My project will probably be influenced by many things around the world and various other aspects. In my opinion, these are the dimensions of a holistic approach. You want to look at external forces and you want to look at the internal forces, and the dynamic between these. Although these will have different weights, they might have all an impact on your project, to some extent. The external forces are the one that you see in green.
For example, world events. I am sure that many of you, let's say you're building an e-commerce or something like that, will have considerations about your ability to support a holiday period. How many of you are actually thinking about elections? How many of you are actually thinking of how certain laws will actually influence the future of your project, especially in the timeframe of your project, if you have a bigger strategical project? It's very similar for business trends. If you don't have a level of understanding of where your product sits within the context of the business, it's going to be very difficult to understand which parts are moving and which parts are not, which parts will be changed more likely and which not. What could completely disrupt your market? Also, what could completely destroy your product? Where you want to put more focus, because a mistake in your product in a certain place will destroy your product. Very similar for technical trends. It can be even simple things, but I think that's more common within a business that we would look at that.
Then, there are the internal forces. One thing that I want to point out on this one is, although we have the triad, so the people, the product, and engineering, all of this sits on top of an organization. The organization was there before you joined, very likely, and will be there after you join. It's an organism that exists before you come into the organism. Although I am a firm believer that we can try and change things and we can mitigate problems, I think we also need to be aware that whatever we built is influenced by what we're building on top of. That is going to be a very important element.
Things you want to think about, and clearly these could be many. You want to think about what's the actual, for example, information structure. How do things get done? Who speaks to who to get things done, which often is very different than your hierarchy. You want to think about what processes would stop you. For example, I worked once in a company that needed 20 people, including the CTO, to make a decision for a release. What processes will actually influence your project going forward? Your rewarding system, your career process, your bonuses, those will influence your workforce, a specific point in time in your project more than you probably notice, very often.
Let's go to the triad. The product. Everybody is probably looking at me and thinking, lavaless, of course, the product. I understand the product. How am I building the software? Very often what happens, though, is that we don't have the time or we simply haven't had the chance to look at further than the products for our single project and have a better understanding of the full product strategy and mission of the company. If we don't understand where the product is going, it's going to be very difficult to make decisions about what will stay the same, where you need to invest more, and what will change more likely. That is going to influence your technical decision significantly. Also, having a look at things like marketing actually very often might help you prevent issues going forward. People. When I consider people in this context, I'm not considering how many Java devs I have, how many senior devs I have. I'm considering, what are the key characteristics of my main players in this project?
I'm thinking about, how am I analyzing the group of people? What am I analyzing the group of people on? How similar is this to actually the analysis I would do on the tech? For example, I try and think of, how would the people benefit from this project? Will they not benefit from this project? Sometimes you have to ask people to do a project that wasn't in their career plans. Also, to the extent of how much you can, you want to make sure that you understand, what are the key life changes that are happening to people? It could be that people are breaking up. There are people who are moving houses. There are people who are having children. There are people who are flight risks. There are people who have all sorts of problems in their lives because they're human. Having an understanding of that is going to help you put in place mitigations that otherwise you probably would have not considered.
Then we go to engineering. When we go to engineering, like in this context, I won't discuss like the conventional things that we will consider, what architecture patterns and so on. I think where I want to put my attention for you is, how much is what we're designing now aligned with the technical strategy for a company? Is there a strategy for the company? Do we know where we want to go to? Do we know how close what we're doing is getting us to where we want to be? Then there are some key points that I think are places where as technology, sometimes, these are causes of problems in our project. If you don't have a deep understanding and also a lot of intellectual honesty about the quality of your path to production and your observability and maturity, what you will find is you'll design something that actually is more mature than what your company can deal with. Very few companies want to accept this.
If you can't release very often, or if you can't roll back very quickly, or if you are not set up for a certain type of architecture, you can't afford that architecture. Another aspect that I think we should consider as early as we possibly could, are security and privacy. I found that very often, these are blockers for projects and they arrive at the end of the project. If we design for these things at the beginning, we don't have this problem. We don't have to find additional funding. We don't have delays. Very hard because nobody wants to talk about it at the start, but also very important.
Another aspect that I found can actually cause issues in your project is the alignment with the communities. I don't think that all projects should fully be aligned, but it's very important to understand where the communities within the company are going. If you differ, in what direction and why? Try and bring people on board. Again, with the review process and all the things I mentioned before. If they are focused in one direction and you bring in the group to another, you're going to have problems. Again, another understanding. Honesty towards the skill set and maturity available of the individuals that you're working with. I think very often we measure within the context and we do the best we can, but I think understanding where skills are missing or maturity are missing when you are designing an architecture will actually allow you to have a better likelihood of success if you're honest about the maturity of the people you're actually working with.
Then, these last three. Clearly, these could be millions. I think very often when we design and we design on a beautiful diagram and we have conversations, at the best of our efforts, we still have no idea, service by service, what's the quality of that code? How legacy it is compared to each other. How spread the domain is for all of those. How well tested it is. How consistent the test strategy is for all of those. Those are elements that will make it or break it when you decide to change one service or another, and they are completely independent from the structure of your architecture. They're information of a single code base, and understanding whether it would take a month or a week to make the change that seems trivial on paper is actually going to make a difference for your project.
Then, for me, the Sacro Graal is always the alignment. When you pick up any design, are you actually aware if your organization has everything aligned? If your teams are aligned with your software, with your architecture, with your domain? This doesn't happen as often as we would like to, and I think we talk about it consistently. We've all read "Accelerate" that tell us to improve the performance of the company. We want to have independent architectures. We've read our DDD practices that tell us that we want to align our architecture with our domain. "Team Topologies" that tell us that we want to align all the three together: our organization, our tech, and our domain.
That doesn't happen as often as I'd like to see, and that is going to be one of the biggest blockers for your ability to independently deliver what you need to deliver. Having an understanding of that before you make a decision towards one type of architecture over another will have an impact. In general, the best solution is not the solution for that state of the art today, the best solution is the solution with the people you have and the situation you have, with the problems that you have that is actually taking you a step forward. We still try and move forward. This is a recap. Our dimensions and our triad live on top of the organization, but we also have external forces.
What Do We Do Now?
What do we do about it? First of all, you want to identify your forces, like we were talking about, about the layers and the impact on your software. Identify where in your organizations, because everybody has some dysfunction somewhere, identify where the issues are. What are the forces that are actually pushing people in a direction towards another, so you can either try and fix it or mitigate it somehow, or at the very least, factor it in. How do we do this? You want to make the implicit explicit. All these topics that we've discussed and many more that might be very specific to your company, you want to make sure that they go from a conversation that happens over coffee with your colleagues to something concrete.
Model, map, prototype, visualize, just move the conversation from, this is dysfunctional, to a diagram that shows, for example, how the communication patterns between people are compared to the actual hierarchy, for example, or whatever is the specific of your dysfunction. Like making things visible, making artifacts out of whatever problem that is, is going to help other people see what you see. You have to bring other people on board and show them what you have noticed. I'm sure most people already know, but they haven't qualified it as a variable.
Then, what you want to do is to socialize the information. I mean exactly not only the stakeholders. You want to make sure that this information becomes public knowledge for the wider organization, for the organism. You want to change the information structure of the organism because that's going to help you win your battles. If something becomes a fact, our path to production is not very good, we can do better. It's going to be an opportunity for not only you, but for others to also try and improve things.
Now that you actually have socialized all this information, that you have all these models and prototypes, you can more easily justify factoring in some of these problems. Then that's exactly the point in which you say, ok, so I'm looking at this holistically, I'm going to factor in all these other forces in my system, and how? When we get to the how, how do we do that? Conventionally, I will always do two designs. I will have one design which is for the future, which I could call North Star Architecture, I could call many things. The intention is not to be idealistic, but to be what I would do today if these other forces didn't exist. The architecture that I would put in place with the state of the art, in the more or less the current social situation, in relationship with the technical strategy of the company, assuming there's one in place. Then I build something that I can do today with the workforce that I have today, with the situation that I have today.
Then this opens the conversation of, why can't I have the skyrocket? This is exactly the perfect position to say, I would really like to build a skyrocket, but within the context of this problem, that problem, that other problem. This is the situation of what we have. If we want to deliver something now, we need to try and build the best bicycle we possibly can. That doesn't mean that evolving a feature is not a good idea. It means that you want to make sure that the reason why you can't start with something, or the reason why you shouldn't start with a more complex system, is because there are other dysfunctions. It opens the conversation for you to discuss whether you should fix these dysfunctions before you start the project, or find some mitigations, or simply accept that this is the level of maturity of your company and find fundings other ways.
One of the most important steps in this is not only to do the now and later, is to have an understanding of what happens in the middle. I'm not suggesting that you do all the stages of design in between, because that will change. To have some level of understanding, even prototyping discussions, that this could be done in three milestones, and this is how it could look like, is going to actually give people the perception that this is not like, I really wish I could do this, but I'm doing that. It's like, we are evolving, and this is where we can afford now. If we invest in this and this and that, we could get to this. It's important, because we have to convince people and try and keep this idea on, otherwise we always end up with what we didn't want at the start.
How do we do this? Something that is very important to refresh people's memory is to actually have things documented. ADRs is a good method. I use also something that I call Social Decision Record, which is an equivalent thing within a management process. I'll talk about it a little bit more now. One tool that I find very useful is the Architectural Advisory Forum. It's a process that will allow people to have the right conversations at the right time around the decisions that are made. It will help you facilitate and rationalize some of the more complex conversations that you want to have, and potentially introduce also conversations that are not only technical.
When we talk about SDRs, it's a small tool that I use in projects, so as much as you would decide, I'm using this database over another database in your technical project. You would also make decisions about the team shape, the domain that it owns, who would work on it, what responsibilities you have, and so on. I record this in Social Decision Records. They have exactly the same structure as an ADR. They usually have a companion ADR that's usually some strategical project, and some human decisions, and I note that there. I found that very useful in my projects because people forget the human elements of those decisions and interactions. I've mentioned lots of things, and I know I haven't been able to do all those things in all the projects for sure. Our job is the art of balance. Whatever we do, we're always going to have to sacrifice something and not be able to cover everything, so I empathize with that.
Key Takeaways
These to me are the most important concepts throughout all of this. Whatever you do, there are going to be consequences in your code base that are not made by technical people, and there are going to be forces that actually shape your code. You're going to have to pay the consequences. You either find a way to manage it, or you're just going to be a victim of the circumstances. Another one is to make the implicit explicit. If things are just discussed over coffee, they're not going to be solved in any way. You have to find a way to make it visible to everybody else, so explicit. Then, in general, you have to look at your problems outside of tech, and put together all the other forces that will influence your tech with a holistic approach. Like looking at your system as one organic socio-technical system, and not just from your tech perspective.
Resources
A couple of resources that I mentioned. These are the books, "Accelerate", "Team Topologies", "Facilitating Software Architecture", and "Domain-Driven Design".
Questions and Answers
Participant 1: Just a question about making the implicit explicit. You mentioned making maps of dysfunctions within the organization and so on, and then socializing that. I can think of a few things, and hopefully everyone can, and it's not just me. There are some dysfunctions that are deeply personal, and these people don't get on, or these people are difficult to work with, and socializing that fact. Although it is known in the coffee chats and everything else that, yes, this team is horrific to work with. Spreading that around the organization is politically difficult. What's your advice then?
Vanessa Formicola: First of all, I don't think that everything can be socialized to the same extent. You want to make it as wide as you possibly can. When it's particularly sensitive in that case, I would look at the reasons why that team is so toxic. Maybe there is something in the reasoning behind the toxicity of the team that can be discussed at the level of reshuffling around the group, with the right department. Maybe the group where you try and make the implicit explicit is smaller. It's not the entire organization, whether it is VP of engineering, whoever is shuffling around, but understanding why. For example, I've seen teams being very bitter because they've been given leftover tasks by all the other teams, for whatever reason, for like years, and they're very bitter, and nobody wants to work with them, but maybe they have a reason. I think going and digging in on why there's a behavior that is dysfunctional is where sometimes the non-politically correct can be turned into, we have a pattern of treating this team this way. Wouldn't they be more performant if we did this and this and that? Unfortunately, there's not one solution.
Participant 2: I particularly like the focusing on where you are now and where you want to get, because in my experience, organizational change is slower than software change, so hoping to make that, it's going to take time. In particular, though, I'm really interested in maybe techniques for trying to encourage the organization to help share and make sure that those long-term product goals, that long-term product strategy is shared, and that engineering teams are involved in that discussion. Because in my experience, just as engineering decisions are product decisions, product decisions are engineering decisions, and trying to get that two-way conversation is vital, but sometimes tricky.
Vanessa Formicola: I think this is the age-old question, how can we both be successful? The truth is, if we're not both successful, neither of the two is successful, so we either find a way of working together or we don't. I think it ends up, again, in the toolbox of human relationships. Where is the issue? At which level? Who in your organization, let's say, in your department, can help you bridge that gap? Is it at team level? Is it at VP level? Where is the issue? Also, there could be other areas, for example, talks, what I was talking about, for example, changing the information structure of the organization, of the organism.
For example, if you talk a lot about your team topologies, your domain-driven design, all the good practices, and you make very clear that there's no good engineering if you can't model your product, you're actually making everybody aware of this, and you're putting indirect pressure on the ability to do this. None of these are like one silver bullet solution, but there's a lot that can be done by informing people of how difficult our position is. I don't think many people intentionally try and put obstacles in other people's work. They just have different experiences. According to your problem, you can act on the society, on the organism, but you probably want to look at the org, too, and see who could be an ally, and see where the partnership has broken, at what level.
Participant 3: If the not-so-helpful behavior is coming from top-down, from the senior leadership, what can someone under them do in order to move it into a healthier direction?
Vanessa Formicola: It's a very difficult one. If I wanted to be funny, I would say change organization, but I'm not. There are many things you can try before that. I think sometimes, and that doesn't always happen, you're allowed a certain level of freedom without the team. You can try and build an ecosystem in your team that is so successful, that you can use an example and say, if we do these things in other teams, they will be as successful, and then you bring that.
If you're left enough space, let's say you have three months to do your project without too much influence from whatever toxic behavior is coming from senior leadership, then you can use that as a showcase, and it's very difficult to refute proof of success. That's one way. There is trying to convince individuals themselves, and then seeing at what level you can leverage that, whether it is people at the same level, whether it is direct one-to-ones. Again, the human aspect. There are multiple ways, but it's clearly a difficult issue. We always have to convince our superiors, our peers. I think when you have the chance to demonstrate with facts, that's easier to bring as an argument. I have found some projects where I had the space to be hidden for three months with my team and deliver results, and then use that as leverage. I was very lucky that I worked in an organization like Thoughtworks, where I had my superiors that would shield us, so we could demonstrate things. That doesn't happen in every organization where you get the chance to do that. You will have to go slowly and find smaller things to showcase and build your credit in that way.
Participant 4: Could you give an example of SDRs, because we know about ADRs. We also have project decisions, they are descriptions of roles and responsibilities. As an SDR, in which situation would you want to have one?
Vanessa Formicola: I've used that when I lent a developer to another team or other department for three months. Those were the conditions. Or when there was a collaboration between two teams. For example, we needed resources, like people helping us with a specialistic skill, or we were handing over somebody, and we needed 10% of their time, or something like that. Whatever are relationships that would make or break your project, like you've promised that you'll give me back the developer in three months. You promised 10% of support to the team, although you moved to the other team. For example, we had features that were shared, and we defined things like joint test strategy, and the domains of how we were going to collaborate between the two teams.
For example, my team had a stronger, larger group of QAs, so there was going to be some steps in the inner sources process of the two teams. Things that are non-technical decisions, but have technical impact on team, individuals, and so on. I have a blog post on it, on Medium, if you want to have a look. I found them very useful, because for the same reason by which you go back to ADRs, and you check what you've decided, and why, you do the same for your SDRs, and you say, we'd agreed that. That's what we agreed. The condition's not there anymore. It has exactly the same usage as ADRs, it's just that we always forget that there are so many other decisions than just our technology, when we build a project.
Participant 5: If you're in an organization that doesn't really have a technology mindset, they're not thinking about the landscape of software, and just technology in general. How do you, as a people leader, or an individual contributor, start socializing those kinds of ideas so that leadership sees, these are good ideas, and could help us move faster and scale?
Vanessa Formicola: If one works in an organization that is not very engineering excellence focused, so they don't really understand the value of improving certain things, how do we convince the organization to invest more in that?
It depends on at what level you want to convince people. Is it convincing everybody from the ground, or is it senior leadership that is more resistant? I think, in general, what you want to do is to show, as much as you can, so it could be talks, it could be little meetups, is to try and build the hype within the group. All leadership, at the end of the day, responds to majority and discontent of a group of people. If a group of people is truly convinced that there needs to be a change, there are so many little changes that happen within the context of a team that never goes through the full leadership.
Small behaviors that people have. I think for the smaller things, for the wider things, it's important to consider how to change hearts and minds in a group. You also want to make sure that you get support from people who have more influence, and that can actually help you change things quicker. Because doing it from the ground up is usually very good, and it will last longer, but it will take ages. If you want to accelerate the process, you also need allies at some level of leadership and see who can help you, and who you can convince, one-to-one level. Maybe choose a small battle where you can show the win, see if you can have a team, like a smaller team, that can showcase that that works, and then try and seed that. There are many processes that can help you with that. Again, I think it's an issue that we all have, and according to how much we are allowed, we can showcase as much as we are allowed. We have to move through that, and try and persevere where we can.
See more presentations with transcripts