Transcript
Vanessa Formicola: I'm Vanessa Formicola. My pronouns are she and her. Today I'll be talking about how it is and what it is to be a socio-technical staff-plus engineer in these days of change, how organizational culture, how culture in general, how architecture, all the different variables of our system, how they're intertwined, and how they impact the work that we do. The hypothesis today throughout my talk is going to be that today as staff-plus socio-technical engineers, we need to be able to stop thinking of ourselves as the builders of something, or as the gardener that picks which plant we want in a garden, and start thinking more about how to be the landscape architect that actually understands the conditions to grow certain technologies, certain processes, certain techniques. The same way as you can see, like the greenhouse in this picture, we need to be the kind of people who understands how to build the greenhouse a lot more than what kinds of plants we want to put inside of it.
Let me give you a bit of an overview about myself so we can understand where some of these ideas come from. I call myself these days a socio-technical architect. Sometimes I call myself something else. What I'm trying to say is that I operate within the intersection of technology, organization, and often, people management too. These days, when we talk about these aspects, it's important to try and understand, and I want to build on what Yinka said before, on how certain patterns we carry on seeing in organizations over and over. Over my career, I have worked in companies which had completely different size and scale and level of maturity. From big corporates to startups, companies in completely different domains and different tech stacks. Think of health tech, think of retail, think of fintech, think of government charities, completely different with different tech stacks. Over this period of time, and also in different roles, whether it's purely leadership or more technical, what I found is that these patterns keep coming up over and over independently from technology, independently from size. There are some foundational problems that we try and solve in our business that carry on appearing.
Wishful Design
What is one of the main things that I believe we do as staff-plus engineers that potentially is something that keeps repeating and has some issues? How many of you are staff-plus engineers? How many of you are technical leaders with people management responsibilities? How many of you have a hybrid role where you take care of both? Wishful design. As architects, staff-plus engineers, whatever title you have in your organization and you're designing projects and technologies, we tend to try and design the perfect architecture. Within whatever context we are, we try and build this beautiful tropical lush garden, potentially without understanding perfectly whether we're trying to build this within a northern European garden, southern European, central European garden or some other location. What we do, what we feel that that's the best way of representing our skill set, representing the benefit of the company, is to think about what would be the best-case scenario?
What would be the technology that everybody's using today? What is the best outcome? How we would like this company to be, how we would like it to look like. We tend to try and design things that are more wishful than concrete. That's why sometimes we don't have the results that we expect. A subset of this is when we pick a technology. Everybody decides that that technology is a must, that every company needs to have it. From that point on, everybody will use that technology. You try and put this tropical plant in the context that necessarily wasn't built for it or that doesn't yet have the condition to be built for it. Very often, the definition of our job is to make those decisions, to bring the company in that direction. How do we fill the gap for that?
What you see here is an example of a banana tree in a northern European garden. What you can see here is that this banana tree is still alive, but it's not really giving you the result that you expect it to give. What you would like is probably fruit. You would like to see the tree in full bloom. The result of this is usually what happens when you try and put a technology that in itself could be ok, but you haven't actually controlled the conditions for that technology or process or technique to flourish within the context. You end up with these results where it's very hard to attack the choice you made, but still you're not getting the value of the investment you made. Another scenario is where there is a different change of climate, and by that I mean conditions. You pick a technology again.
These are palm trees under snow. They work ok while you are in spring and summer during that environment, and then what happens next is that it snows. Whether the weather changes, whether there is a change of political powers, whether it is simply that your company has a certain cycle, and within that cycle, that technology doesn't work anymore. This is something that maybe you could have foreseen. Then we have the case in which you were actually successful. Instead of designing the entire lush garden, you pick little plants, you do little experiments, you implement in small places here and there. Then what happens is that people start using it in places where you didn't expect it to, where all the conditions were correct, and even too much of a good thing doesn't quite work correctly.
The World We're Engineering In
What's the problem with that? Because that very often seems to be the limit of the responsibilities of people, how people feel they have made the right technical decisions. This is where we start discussing what are the other conditions that influence your project? Why did a good decision not return on the investment that you thought there was? In my opinion, it's because we're not really understanding properly the world in which we're engineering in. What is the context for the work that we're doing? When I talk about the world we engineer in, it's not like a casual choice of words. I don't only mean your organization, your problem space, your team, your department, I mean the actual world. The actual world and all the functions and variables that will actually impact your decision, and especially your project over a period of time, because what we want is not just to pick the right technology, processes, tool, it's for that transformation of utilization of that technology to actually work.
If we keep our eyes on the prize and we say we are trying to produce wine, and it could be non-alcoholic wine, it could be grape juice, you can think of it as the grapes. The objective that we have is to build the product, to sell the product. A complex product like wine, I'll use wine as a generic term for the rest of the talk, has a lot more complexity than just the choice of grapes, of the vines that you use, which would be your technology. We tend to decide the technology and think that that technology is going to bring you all the way. Actually, our goal is to make sure that we understand the complexity of how through the technology we get to the product. What are we usually missing or we're not doing enough of? We're not considering the other variables in your wine production, in your delivery of your technology transformation, which are the organization on top of which you're building your vines, so your soil, and the climate that is influencing your vines, the growth of your grapes. We always focus on which grapes, so which technology, which teams, and how you work with those, forgetting a lot of the conditions on which we build. Let's try and discuss those.
Let's start from your organization. Your organization is the ground on which you build. If you want to make sure that you can grow what you would like to grow, so that specific type of wine, which is very different than just the grapes, the technologies you picked, you need to actually get your hands dirty and understand on top of which soil you're building. One of the key things that you want to take into consideration is your reward system. This is a generic term to talk about everything that you do to actually grow your system. Whether it is your bonuses, whether it is annual year review, whether it's your career framework, growth framework, all the system of practices that you do put in place to try and grow your workforce and to give appropriate incentive has a massive impact on how people will behave and how people will take on whatever kind of technology transformation you're trying to do.
Understanding what system you're building on top and what kind of ground, what kind of soil you will find when you try and move in a direction or another, is very important. Also, it's an indication that potentially there's some work you can do to influence that. Another aspect is culture. Culture influences the way people work and the decisions that people make a lot. Especially when you're talking about any kind of transformation, any kind of introducing new technology, new practices, you will find that people need a certain level of trust to get on board to make those changes. When you do that, what you need to understand is whether the roots of your change, the roots of trust throughout this process can actually take place. Understanding the culture and how that will impact positively or negatively your project is going to be fundamental. Another aspect is leadership.
Remember you're building on top of an organization. If your leadership is divided, if your leadership has internal wars, if you're having a reorg every five minutes, you're not building on solid ground. It's very difficult to plan long term, and you don't know what are the consequences of that. Understanding what are the dynamics there is going to be very important to understand what kinds of risks you can take, and try and mitigate what potentially could go wrong over a period of time.
Then, one of the things that we do the most as staff-plus engineers in general, as technical leaders, we underestimate how not mature the company we work in is. Usually, we always think that our company is super mature, that everything is going well, surely, we can also do these things. What we don't understand is that maturity enables complexity. If your company is not mature enough, they won't be able to handle certain kind of transformation or certain kinds of technologies that you really want to implement. The usual situation is where we are commissioned to redesign everything and to build everything to the top of the market. What we don't understand and what is very difficult to communicate is how that could go wrong based on the foundation in which you're building. These are key things for your organization. Another thing that we have to think about is climate.
What are the forces that are impacting your delivery, your transformation, that you have not necessarily accounted for? This is a picture of London during a pandemic. I'm sure many cities look like that. It looks like a post-apocalyptic reality. There was nobody walking the street. I believe all of us have gone through this experience. Putting aside the incredible human tragedy that that has been for so many people, this has also revolutionized from a professional perspective the way we work. We've learned that we can work remotely. We learned to develop new skills. We learned to actually work in different ways or reapply some techniques in different ways. This was a massive shift in the way we work. Understanding that some global events that can disrupt things can happen, and understand how to build resiliency in our system in a way that we could, to some level, shift, pivot, and work around it, it's important.
Because the world around us is going to impact our project too. Another aspect, and this is very contemporary, is the actual geopolitical tensions and wars. According to where your product actually is, you will most likely be very impacted by a change of government or a change of legislation. I, for example, have worked in both health tech and fintech, and I found myself quite a few times in a situation where the possibility of one leader over another or a law changing had massive impact in how we needed to deal with tech and how we needed to pivot our project or do some remediation according to the situation. Having an understanding of those dynamics is also very important if you want to mitigate some of these problems.
I don't know who's familiar with the concept of digital sovereignty. These days in Europe, we're talking about this a lot. This is something that many countries in Europe are doing at the moment. They are deciding that, for security reasons, they want to not use conventional cloud providers and other tools, and build their own within the country for all software or processes that are particularly sensitive. This probably would enlarge to more things and more companies would do this. This is a massive shift in the way we work. Many of us have worked mainly with main cloud providers, and I won't name within the context of this, and having an understanding of the fact that actually the market, and especially in Europe, is moving in that direction is a clear representation of the fact that we are changing the way we work according to how the political climate is moving in a direction or another.
At the level of seniority that we're talking about in this conversation, we need to have an understanding of how the market is shifting and why. Another expectation is ethical technology and ethical products. Clearly what's appropriate, what's ethical is different in different countries. It is different in different points in time. It can be different also within the context of your business. However, having an understanding of what's considered ok today or not might have a massive impact on the success of your project or whether your project will be cancelled or not. This is a semi-recent example from 2012. I think most people have used a Bic pen. They've been around for 100 years. The pen has looked the same for quite a period of time. In 2012, they decided to build a pen for women. It was round and it was pink. The internet didn't want to see it.
There was a massive backlash and they weren't able to produce it anymore. What I want to put into context for this, and with the caveat that I'm not in favor of putting fake perceptions of gender based on colors on any product, that when this happened, there were many products that were doing this. Also, to this day, we're still gendering children's clothes, children's toys. This is not something that's gone away. In any case, for them, because the climate had changed and they were on the verge of this, they had a massive backlash for that. Understanding in what world you're building your product, your technology, however you are supporting this, it's very important because these are the things that will derail your project or change your project. Then AI, of course, it's not a surprise. These days, we are talking about AI in every single conference. We're talking about AI in every coffee shop.
We're talking, with our colleagues, about AI at any point. AI has started to, at least, revolutionize the way we work. We are investing so much in understanding how more we can leverage it. What we need to understand also, though, is how we as staff-plus engineers, technical leaders, what do we bring in the table in a context where the promise, let's say, of AI is actually what people promised you.
What Is Uniquely Human in Complex Systems?
Let's try and explore what we bring to the table as humans, as skilled professionals. Let's try and break this down. Although, and this is a disclaimer, clearly AI keeps evolving, and I'm sure that in time some of these things at some level might be achieved. What we are considering right now, we are considering things that are intrinsically human. What you see here in the picture is a picture of somebody playing jazz. You have to imagine you're a jazz band. If you're familiar with it, you know that they will have some common goals, some common directions, but they will actually improvise a lot, building on each other. The way in which humans collaborate based on a common direction, the way in which they can pick up on signals of improvisation and pivot, and actually build on each other. Think of the general philosophy of "yes, and," it's a uniquely human perspective of being able to pick those weak signals and to be able to go with it.
To improvise within structure, staying within structure, but dynamically move, is something that particularly people can do, humans can do very well. It's a very important skill when you are brainstorming and collaborating as a group. Another aspect which is connected to this is understanding weak signals. You can see how here, like the sailor will adjust the sail, we are able to pick up on, for example, how people feel when we walk in a room. We walk in a room and we can perceive, especially if we know people, if they had a bad day, if they're not in the right mood for that conversation, if they had a fight. Or if you walked into a room and somebody just had a fight, or any kind of human signal that you perceive that is going to be very difficult for a machine to pick up. Having that level of understanding to pivot on your choices and pick up weak signals from the rooms, it's something that we bring to the table, especially as senior participants, decisions that we're participants to a meeting, when decisions we make have high stakes, it's very important to be able to pick up what's going on in the room.
Then, as humans, we are really good at understanding how to teach each other and develop others. Teaching is a lot more than providing information. Teaching is about showing the way, understanding what that person can understand at that point in time, changing ways in which we communicate according to the day, according to the mood, according to the level of seniority. There are many aspects that are intrinsically human in a relationship that are very effective when we teach. The way in which we grow others has a lot to do with trust and the kind of relationship and role modeling. Those are things that are specifically, particularly good done from humans. Then we start talking about value-based systems. We never have a map of where we need to go. We don't have a deterministic way of saying we go from here to there. Within context whether it's cultural, period of time, your organization, you tend to have a value-based system.
We value this in this company. We value that in that company. There are some concepts, even very often different than what we say publicly as the values of your company. You tend to make decisions within that context involuntarily. Even if you're not formally doing that, there is a context in which you tend to understand what's good or bad and what could work and what couldn't work. That level of uncertainty is also very difficult when you have to work with something semi-deterministic. Then one of the most important qualities is the fact that we can reframe the questions that people ask us. I've been a consultant for many years, and 99% of the time, people would ask me for something when they actually wanted something else. My first job was always to understand the difference between what people ask and what people actually need. The journey and the bridge between understanding and helping them understand that what they ask is not what they actually want.
Now, when we talk about the skills of a staff-plus socio-technical engineer, we need to be able to understand that gap and be able to reframe problems. Understand that sometimes we don't have all the variables of our problems, but understand whether reframing the problem or actually repositioning the perspective actually is part of the solution. These are things that are particularly good performed by human beings that we need to consider.
Holistic Engineering
What do we do next then? How do we approach this? How do we work in a world in which we want to value these and value all of these conditions? How do we work in that? I call the practice holistic engineering. I call the practice holistic engineering because I consider in the way in which I develop, I evolve, I make decisions for technology, I involve as many elements as I can of the socio-technical system in which I'm working. I look at it as one organic system, and I try and solve for that instead of for the slice of tech that is just a small component of it. We talk about holistic because we are looking at it in context, especially like we do for holistic medicine, for example, where we're not actually just curing the illness and the symptoms, we are looking at the environment in which certain illnesses appeared.
In the same way, we can look at engineering. These are the dimensions that I call of holistic engineering. As you can see, they map back to some of the conversations that we just had. There are external forces, and those were your climate, so things like world events that we discussed, for example, the pandemic, or your business trends, like changing what's considered appropriate and ethical, and your tech trends like AI. Of course, you can find a million of these things. The point is we can't just consider that there's going to be Black Friday, you're going to have more traffic. You have to consider there are lots of other variables that can actually fail your project. Then you have your internal forces. Your internal forces are your organization, and then the variables inside. Your organizations are what I've been describing as the soil in your wine production.
Let's talk a little bit more about these variables one-to-one, the internal ones. When we look at organization, and of course, the organization lives within a bigger context, you still have to understand the microcosms of your organization. Remember, you're building on top of it. That doesn't mean that you can't try and mitigate it, that you can't try and improve it, but your organization was there before you joined, it will likely be there after you leave. You have to understand that it's a living function, and that whatever you do, you have to build the conditions to be able to achieve the objective that you want. Things that are very important when you try and understand your organizations are things like your reward system, like I mentioned before, but also your power structure that usually has nothing to do, or little to do with your org chart, your communication structure.
Understand how the information flows, understand how power flows. Those are elements that are very important to be able to make decision and understand how likely are you to be able to succeed in your project. Other aspects that are important is understanding where you have blockers, where you have risks, many aspects that are specific culturally to your organizations, because that's what you're going to have to build on top. Another aspect, clearly, is your product. People will say, Vanessa, of course, I'm building for this company, why would I not know my product? Unfortunately, I've noticed in many companies, not all companies have maybe a product vision, or they have a 5-year articulated strategy, and even the ones they have, usually it's not as well circulated or people don't know it. Wherever you want to look at putting the attention, usually we don't have that good understanding strategically where the product is going.
Why that's important is not just because you are building for it, it's because understanding where your product is positioned and where it's going is going to help you understand what parts of your architecture can be more static and what parts of your architecture need to evolve very quickly. For example, when I worked in health tech, we modeled some biological processes while we also had features, functionality that we offered to our users. Biological processes, although can change with new discovery, they change very rarely. The way you architect for that is different. Instead, features on top of those biological processes and services vary at a very different speed than some other things. Having a true, deep understanding of your product helps you make tradeoffs on where to invest and how to invest at different points in time.
Then we have the people. This is not about how many Java devs I have, how many senior devs I have. This is about what's actually happening and what can go wrong in the continuity of work of your key players. That means trying to understand who's getting divorced, understand who has an elderly parent who's moving house? Who has a problem in their life, and understand how to mitigate and support them, whether it's flexibility, whether it is adding more people, whether it's sharing the knowledge, understanding actually how the risk the human elements can bring to the system should be managed with the same accuracy that we try and manage for our tech problems. If people are fundamental to your process, you have to try and build mitigations around it to support them, to make sure that you can still benefit from their skills and their expertise within context.
As staff-plus engineers, that is something that we rarely get to do. Then we have engineering. This talk is not about all the best practices in software engineering. I want to point out a couple of things that I see people missing very often in this context. One of those, for me, is the lack of attention, or enough, or at the right point in time, of security and privacy. If we want to be cynical, I can say, to try and convince you, that security and privacy can stop your project at any time. Let's say this is not your main concern, but delivering your project will be. If I don't want to be cynical and talk about professionalism, I would say that's a core skill for any technologist, whether you're a leader, whether you're an IC, or not. I want to add a third dimension, which is ethical.
Meaning, when you take care of security and privacy, you're actually protecting your users. You're protecting human beings from all the consequences of having their data leaked and how they could be used, not even considering the damage to your company. Having that perspective of how important those aspects are of your job is essential to be able to predict some problems. Another thing that I see people dismissing, more often than not, is especially when you're an architect or a more senior technical leader, you make decisions based on models on your diagrams, which it's the only way in which we can simplify some of those realities. Very often, those realities do not contain the information of the problems that each service usually has. For example, we make a decision on an architecture diagram, we decide that one service should be changed over another, because it makes sense for the flow, for the project that we're doing.
What we are dismissing is how legacy that service is, how many tests it has, how difficult is it actually to change. The level of complexity of change in a diagram is very difficult than the one in real life. Very rarely, we are measuring, we're putting a metric around that when we make decisions architecturally. Bridging that gap between the actual problems of who's changing the code every day and the strategical view is very important and often missed. Third, and again, I'm not going to list all best practices, one of the things that truly can mess up the delivery of your project, is whether you have understood or not whether your organization has aligned their domain, their teams, and their tech. If you have a big transformation in place and you don't know whether you already have some organizational constraints that do not allow for flow, you can build the perfect view and decision-making throughout all of these variables that I mentioned, but you're still going to have an organizational blocker to the flow of your project. That is going to impact the speed and the likelihood of completion of that project. These are things to keep in mind.
The Socio-Technical Staff-Plus Engineer
Now let's go to the good part. What does it mean then to be a socio-technical staff engineer, a holistic engineer these days? What does it look like? First of all, you have to try and think of yourself as the landscape gardener, the architect of the system. Your main job is not to pick which technology you want to build, it's to build the conditions for whichever choice of technology, process, tool to thrive. That is the key thing. That is shifting logic a little bit. You want to make sure that you're actually interpreting the system correctly. I talked a lot about the soil, about the microsystems in your organization. Being the person that actually translates this, that picks up on problems and deficiencies and dynamics that will influence your project, but that are not commonly known or people dismisses because they're not purely technical, is going to be a big asset for you and is going to help your project be more predictable.
Then what you want to think about is to actually grow the system. Clearly you want to get your hands dirty and try and improve things on the ground. It depends on what's the problem, but you want to actively, not just from a purely theoretical strategic perspective, be part of the transformation so you can pick up on more of these forces and these problems. Then, never underestimate the power of growing people. Coaching people and being a role model for people is going to make your job so much easier, and also, it's a fundamental part of what you do. There are organizations where a tech role means to interact less with other human beings. I don't think that's feasible in this day and age, and I'm not sure it ever was. When we are starting to look at problems holistically in a socio-technical way, actually growing individuals, training people is not just a line manager responsibility, it's very much one of your responsibilities.
The 5 Core Principles
What are the core principles that I can suggest to be a socio-technical staff-plus engineer? First principle, so clearly to approach your problems holistically, this is what I've been talking about up to now. Don't close yourself to just tech. Even if things are officially not in your job description, know that you won't be able to do your job properly if you don't take those into consideration too. You want to make sure that you keep your head in the game and you remember that you're not picking the vines, the grape, the way you cultivate the wine. You're trying to sell the wine. That doesn't mean that you compromise on your technical abilities, it means that when you make priorities, when you understand your goal, when you move from levels of responsibility, you have to keep your eyes on the prize. Then you want to make sure that you still are upholding the responsibility of the technical person in the room.
Within all this conversation where I'm telling you to focus on the other things, I don't want you to think that I wouldn't want you to keep hold of all the best practices, all the things that make specifically your skillset. Somebody has to protect those in those rooms, and somebody has to make sure that those are things that are considered normal, not gold plating or nice-to-haves. Good technical practices, good architecture, resiliency, everything that you can think of and it makes sense in your system has to be protected and it has to be protected by you. Then we go back to people and relationship, because this is not just about your politics or allies, enemies in organization. This is about how much you actually invest in growing people, in changing the system, in making sure that people, after you invested in growing them in a certain direction, would make the decisions that are aligned for the growth of your projects and not that would go in a different direction.
Then we have the fifth one, and I think nowadays is more important than ever to discuss how practicing ethical engineering is important. Doctors make an oath when they become doctors to do no harm, and that is something that they carry through as an ethical guide throughout everything they do in their job. We as technologists are at the forefront of most of the technological innovation. We are in every business. We are everywhere in the world. If we step up and think about the impact of our choices on the world, think about what it means for an organization to have a data leak, not just because of the business but also because of the impact on the individuals, what it means for people to have private data be leaked, what it means for an algorithm to be biased, discriminating people. If we start thinking ourselves as the guardians, as individuals that are actually trying to protect each other, this is going to put a different emphasis on why we do certain things and why it's not just technology.
What Does It Mean in Practice?
What does it mean in practice, people ask me. First and foremost, you have to accept that your scope is much bigger than what you think is your job description. In this new world, but this has been true for quite some time, your scope is not technical, not when you're a senior leader in a technical role, when you're a staff-plus engineer, when you're in any technical leadership role. Your job, your solution problem is in the intersection of organizational change because otherwise you won't be able to even get your technology through. Your people, like growing humans, whether it is understanding what humans you need, understanding how to support them, understand how to grow them, and the technical space. That's where you will find your place. Whenever you're making decisions, you have to move yourself from what you've been told is your scope and try and sit in the middle of the problem for your own interest even.
The other aspect is to understand the whole system, and what I'm trying to say with this is clearly no individual can know every detail of everything that's going on in your company. You have to build systems around so that you can create that tree of knowledge in your organization so that the right group of people can make decisions having covered the corners of your problem. If you strategically are making decisions which are global for the company, you need to have some simulation, some form of modeling of the problems of what's important at that level of abstraction. It doesn't mean that you have to make all decisions. It means that the knowledge has to be correct based off the kind of scope of decisions you're making, or you have to build the right group of people to have that knowledge and cover it.
What we have next is to make the implicit explicit. I've talked so much in this talk and other talks about how there are so many other forces that impact the success of your project. One of the reasons why we don't usually factor in those forces is because they are not as visible. It's not the same as when we discuss which type of datastore you want to use. They are more things that you pick up from the environment and you have to give them the same respect that you would give other things. The way you do that is actually transforming that information, whether it is building a document, whether it is documenting the facts, whether it is diagrams, whatever form makes sense for the specific problem. You have to make the implicit explicit. Give it the same dignity as other choices that you make. Then you need to make sure that other people know that.
This can't be only something that you do yourself. You have to make sure that all that information is shared, that you're not the only person, and that is as wide as you possibly can. That people know that actually there is forces and dynamics that come from your reward process and that has an impact. The more people you have that know this, the more this becomes a legitimate variable in the choices of your system. You're also going to build community and maybe more people will think of solutions to solve those problems. Even recognizing that there are issues in certain areas is going to be essential for you to be able to actually use that information as a variable. Then we go back to coaching people, growing people. As a staff-plus socio-technical engineer, growing people needs to be as important to you as speaking technology. People are going to make decisions, you're not going to make all the decisions, and you want to make sure that the system that you're growing has the right direction, has the right knowledge.
You do that by growing individuals, growing people. Then you want to make sure that you've built a vision for your company, according to whatever scope you're working in. This is a quite sophisticated greenhouse building in glass. You want to make sure that people can rally around a dream, an idea. It doesn't mean that you will necessarily be able to do all of that, but you need to help define a direction. That can change. Over a period of time, it probably will change. What you want is that when you're not there and people need to make a tradeoff for smaller projects, for much less impact than the entire organization landscape planning, people have a direction, a North Star of where to go. That's part of your job and your responsibility. At the same way as you can do macro, you should be able to do micro. You should be able to maybe start with a small piece and build your little greenhouse around your conditions, and try and showcase that, and try and build momentum with that. That's also very useful. These are all aspects of what I would expect from a staff-plus socio-technical engineer these days.
Conclusions
These for me, if I were to leave you with three concepts, these would be the concepts. First and foremost, you are not designing in isolation. Nothing that you're designing, even just in your project in your company is just that. There's a bigger world and there's bigger dynamics that are impacting what we usually make, we use as variable of your decision process. Accept that so you can mitigate for it instead of being attached to the fact that is not technical. The second point for me is in such an accelerated environment where we're using all the technology and scientific innovation we can to make things quicker, you need to understand what's uniquely human, what uniquely comes from your experiences, from having understood patterns, from solving problems before, and use that to your advantage to fill the gap where there's problems. Last, I want to make sure that you think about designing the conditions for your transformations to work more than which technology you're using.
Many technologies can work in different contexts but the difference for success is who is actually designing the greenhouse to protect the choices you make. If you want to build a plan or a specific technology, you have to understand the soil and the climate and protect it. Build the conditions for whichever choice you make to grow, and that's why I see the socio-technical staff engineer as the architect of the greenhouse.
Questions and Answers
Participant 1: You have convinced us about this, then how do we go about convincing the people higher up that they can't just make organizational decisions without involving us, that they shouldn't change the processes without involving us, and so on? Do you have any clever experience in that?
Vanessa Formicola: This is a very difficult problem. Also, it's very different in every company you go. It depends what kind of representative, if any, you have in the right room. Let's say an extended leadership team or not. The goal is to have a representative in that group. There are many ways you can go around it to try and build towards that point. What's important is to start building those relationships and to build and collect that data so that you can say how that influences. For example, you're running a project and then your project is derailed by one of these variables that are technically outside of your domain, building data and evidence of the fact that that was the reason, it's very important to be able to maybe have you or somebody in your team participate, for example, in the redesign of the career framework. It's a common one where techies are not as often involved as they should, but actually has an impact.
Or when you're redesigning the structure of teams, of which services go to which teams. What you want to do is to try and be included in those conversations. I understand that's very difficult and that's why we're talking about this. One thing is to understand the problem, the other is to solve it. This is about organizational change. If we're not part of the organizational change, we're not talking about organizational change, we're never going to be invited in the room. If I were to give one, this is quick and clear, it's not going to solve nobody's problem, but having somebody in this, with this mindset, sitting in an extended leadership team would be a really good step to represent that, as a starter.
Participant 2: In one of the slides, we talked about implicit versus explicit and we talked about how companies, like there's a lot of discussion around technical decisions that are made. What are some of the implicit variables that you think should be made explicit, and in your experience, how do they benefit the overall project execution?
Vanessa Formicola: So many. Let's start with this. Usually, the most uncomfortable parts are the things that already exist and that they're considered outside of your domain. I have found, for example, that whenever there's a review process, whatever is the month in which you're doing review process, people go mad and they just do different kind of work and they have to demonstrate things. Knowing very closely how people change behavior according to that is very important. Knowing very well your product and understand which parts will have a change that will have a massive consequence. If I were to really simplify it, I would say, understand your product as best as you can and model it as best as you can so you can ask questions on where there is a discrepancy. The second for me would be, make sure that you understand where the right subdomain belongs to the right team, and whether there is team, tech, and product alignment.
Those are the key things. The most controversial is your review process, how bonuses or other forms impact negatively how people behave and what culture is. Then you need to build a lot more examples and talk to HR and talk to whoever is that. There are many variables. I think those are the ones that tend to be more at reach and more concrete than others.
Participant 3: You said about how it's important to get to know the organizational conditions. We have to understand where we are and what is the condition right now. One big question is always the culture. How do you measure culture? I will challenge you with this question. You could talk all day about this. How do you measure the organizational maturity?
Vanessa Formicola: Those are really difficult questions because there's no one answer for everybody, and it's very non-deterministic. What you want to understand is what's important and what has failed your projects now, if I want to be very pragmatic. What is something that you've introduced recently that should have been a silver bullet to solve all your problems but actually didn't? Maybe there's nothing wrong with that technology. Go and investigate that and understand where there you had a failure of maturity, and how that manifests. You could also have a model of what you think good looks like and you can do a mapping between the two. It depends what kind of approach and what kind of scope you have. Super pragmatic approach for me is go and look at what's happening and see what blocked you. There's probably a tale and a teaching there about maturity. Probably it's going to give you a telltale of why people behave in a certain way and a trend of culture, so you can build evidence.
A more deterministic way would be to say, I think this is what maturity looks like. How distant are we from that? That is also very difficult and a bit like a blank statement because potentially there's different representations for that and different levels of maturity. I think according to the scope you have, you need to figure out what would build better evidence for you to do an experiment to do something different.
Participant 4: You talked about drawing on a trigram and then the people who actually make the change there's a big difference in that. At the same time, you also said that you build a replica of your entire organization into smaller in each team so that you have the right decision-making possible with the right data. That's my interpretation. How you build that, is that a process you want to define or you are talking about named individuals who should be doing that role?
Vanessa Formicola: How do we build that collective knowledge so that we can make those decisions? It depends on the context in which you're working. How you're distributed and how complex it is distributed. I can't say it's one per team or a specific person in a team or a specific domain. It depends on how much information can one person hold and how you can cover ground, and what groups of people you can put together. For example, you might have three, four macro areas of your product and maybe you need three people in one and four in the other. I can't give you a deterministic way. What you want to make sure is that there is a tree of information, so that if you have to make that decision or if you have to facilitate people making that decision, you know who's holding, who's actually making it their job to make sure they're up to date with that information.
This doesn't mean all single details. It doesn't mean that you're going to ask like, if it was a machine, what's the answer to this? Putting responsibility into people, distributing how the knowledge is, is a good way of collaborating, and say, this is important for us. No one human being can know all of this. Let's make sure that we have covered the responsibilities so that we can make good decisions together.
See more presentations with transcripts
