Human Skills 023: Teams as Complex Systems
with Paulo André
Paulo André has worked as an engineer, manager, director, and VP of Engineering before becoming a leadership coach. He has experience working with small teams, and building scalable organizations. And he is an incredibly clear communicator and thinker.
This was one of those interviews where I wanted to clip almost every section. We talked about values, the leader/leader model, organic metaphors for organizations, and more. I highly recommend listening to the entire interview. But the biggest theme in our conversation was around feedback and complex systems. How to set up feedback loops at different scales of an organization, why feedback is necessary to improve a complex system, and why every team is complex and how we can deal with that.
What types of systems do you set up for feedback loops as a director or VP?
Well, I think a very important one is what we commonly call like pulse checks. Engagement surveys and that sort of thing, which to be honest, I think these days get a bit of a bad rep and there's some survey fatigue, if you will.
And I can totally understand where that comes from. I've seen that done well and I've seen that done poorly as with anything else. What I learned, and what I seen working in my teams is you need to create an actual loop.
So when we talk about feedback, do we have a feedback loop? Do whatever we hear get fed back into the system? In other words, are we actually using this information, this signal, and feeding it back into the system to improve it? Are we changing as a result of having this conversation ongoing?
And where I see it done poorly is just this idea that, "OK, here's the whatever app we use for this. Give us your feedback." And then it's like people feel like they're shooting their feedback into a black hole or something of that kind, which is very demotivating as you can imagine.
I think it's the responsibility of leadership to establish that loop and to make sure that people understand how is that being used, what transformation, what change that is leading to.
One thing that I have to say since we're talking about this, that I pride myself looking back in my career, is that when I was a VP of engineering, I was able to establish... this feedback loop to a point where we had 100% response rate to these surveys. And I was very proud of that because I really wanted everyone to be invested in improving things and feeling like they did have a say and an impact in how we shape the organization. And so that was very gratifying.
So that's definitely one way that I think leaders can leverage much better than I think we're doing in general in the industry to improve their teams and their organizations.
What would you do to help people see where their feedback is going?
The first thing is to make the implicit explicit and just set the right expectations. We're doing this not just because it's something we're supposed to do, or just checking some box. We're doing this because we want to improve the way we work.
And this was something that was always very clear with every team that I joined. I certainly was not perfect at it, but I had the intention of always having a continuously improving organization. So that means that we need to learn. Hopefully every day, maybe every week at least, we need to keep improving things.
How do we improve? Well, the only way to improve a complex system is through feedback. And so I would try to connect these dots for people and create that awareness that we're doing this for a reason. Not just because it's fancy or it's what you're supposed to do, but because we need to collect this information so that we have a chance of saying, okay, what is most important here? What is the one thing that we can... tweak or change or improve that gets us to a better place as an entire team or organization.
So just setting those expectations, creating awareness and kind of creating a bit of inspiration around this, I think definitely helped create that activating energy, if you will, that got the ball rolling.
Then the question to your point is how do you keep the ball rolling? And so I would, for example, leverage all hands meetings and something that I used to do that I called the top-of-mind email where I would share regularly with the team on a weekly basis. What were my priorities, what was I seeing, et cetera, et cetera. And I would leverage, especially the all-hands meetings, where I would have a couple of slides that would summarize what I was seeing on the back end of the tool that we were using and what insights we were getting from that.
And then there would be a little bit of Q&A, and people would express whatever questions or suggestions or insights that they would have. And they would see then, OK, what are the actions that we're taking from here?
And then I would announce what those actions were. Obviously, they were articulated with my engineering leadership team, and we would try to collect as much feedback from other sources as well throughout the line. But ultimately, awareness, and then exposure, and then action. so that we see, okay, this is actually leading us somewhere.
What do you mean by a 'complex system' and how do you think about that?
I think one thing that really helps wrap our minds around this is something that is called the Cynefin framework that was created by Dave Snowden a while back. And basically Snowden is telling us that there are certain situations or problems in the world that are simple. Some of them are complicated. Some of them are complex and some are just downright chaotic.
And this distinction really matters because the way you tackle a simple versus a complicated versus a complex or a chaotic problem really is different. And I'll give a couple of examples.
When a problem is very simple, like I don't know, something at your house where it's completely predictable how to put up a fixture or something like that, there's a best practice for that. And usually it's not that hard.
When you have a complicated system, in that case, there are some good practices, usually requiring expertise. So for example, putting a budget together is something that I probably wouldn't do a very good job at, but a good CFO or a good accountant, they will know the tips and tricks and the techniques and so on and the good practices to put something like that together. But there's multiple ways of doing it competently.
When it comes to a complex system, then we have a different situation altogether. Because there's no necessarily good practice. Why? Because cause and effect cannot be predicted in a complex system. You can only see it after the fact, which means you need to run an experiment or multiple experiments to see what happens out there. And this is where the feedback comes in. And this is where something called safe-to-fail experiments come in.
So for example, to put this in more tangible terms, let's say a retrospective of an Agile team. A team of people is always going to be a complex system because it's the interaction between the parts, in this case people, it's the relationships and the way the information flows and how we work together that is going to dictate the results and the outcomes that emerge from those relationships.
But you cannot predict them beforehand just the same way that you cannot predict how traffic is going to flow. But we do things when we create certain constraints and we experiment with certain things.
I'll give you a quick example here in the city that I live in, Berlin, Germany. There's this huge street, one of the best known shopping streets in Berlin, that was closed off to traffic for two years or something like that. And I learned recently that there was actually an experiment to see how traffic would flow elsewhere in the city as a consequence of that street being just for walking only.
That's an example where we cannot predict, because how can we predict the behavior of people, right? But what we can do is that we can run that experiment and then we can look back and see what did we learn from this? Does it make sense to continue or not?
And so this is a very long way of saying that when you try to solve a complex problem as if it was complicated, you run into problems. Because the system, the complex system is not amenable to control and to prediction.
What are some patterns that show up regularly in the complex systems that are teams and organizations?
One pattern that immediately comes to mind, and I wrote in my newsletter recently about this, this individual Deming, Dr. Deming, who is known for what's called statistical process control, which is a bit of a mouthful.
And that was basically how he helped the United States win the Second World War, because the United States just completely out-manufactured in quantity and quality everybody else. But he also helped rebuild Japan after the war with the exact same method.
And a big part of that is what's called the PDSA cycle. Plan, do, study, act. And this concept is very simple. Plan something, do it, then study what happens and then act on that... as in, is that part of your process from now on or not.
And so you have this continuous improvement loop that is familiar to anyone that is into Kaizen and those sorts of approaches from the Japanese and Toyota being like maybe the most well-known example of that and the primary one. But ultimately that PDSA, that's essentially what you have with a retrospective, for example, an agile retrospective.
And so this is where I sometimes get a little bit upset. Maybe that's the right word. When I see teams that do retrospectives, but what they ultimately are doing is a box checking exercise because they're sort of blindly following some sort of a framework. Might be the start stop, continue might be the four L's might be whatever other esoteric framework there is.
But they are losing sight of the fact that the whole purpose of this is to iterate on the team itself and on its process of work... and then end up getting to the end of the retrospective either with nothing to show for it other than a good feeling, maybe, or with a long list of action points, because we're trying to please everybody and contemplate everybody's ideas. And then none of this actually gets tackled, and we perpetuate the cycle from that point on.
So back to your question, what is the pattern? Well, the pattern should be to have that continuous improvement loop and to use an engineering analogy that is familiar to both of us, I like to use semantic versionings, like your team is versioned.
Your team is like 1.5.6 right now, whatever that means. We don't want to go to version two in one shot, but we also don't want to stay stuck in 1.5.6. What is the .7 that gets us to a better place through the process of continuous improvement and leveraging retrospectives?
I think that's a good mental model to think and to kind of like go back to your question about what's the pattern. That would be one pattern of continuous improvement that I would be looking at, which, again, respects the complexity of the system. Because we're not saying this is going to work... we're saying this is our best shot as far as we can tell with information that we have. And then we're going to see what happens in two weeks later. We're going to reflect on that as a team.
What are other core principals of complex systems you have uncovered?
Well, one thing I would point out, and maybe this is coming back to the idea of mistreating complex systems as complicated and the attendant consequences of that, is that when you make that mistake and there's that confusion, and I think there's a big one that happens in most companies just by virtue of the way companies work and how they're organized, that ends up creating a lot of lack of success to begin with business-wise, but then in the process of that outcome, a lot of burnout and disengagement and people being unhappy and so on.
So maybe it's worth us exploring a little bit what I call the great disconnect, maybe in a grandiose way, but what I mean by that, right? And it's intimately connected to these aspects of complexity.
Long story short, the idea, and I realized that because when I was a VP of engineering, that's when I got the in a leadership team and reporting to a CEO that was not technical and being exposed to board meetings and meeting investors and understanding that, quote unquote, the game that was being played there was not necessarily the same game that was being played then in the teams that are building the product on the day to day. So that's where the disconnect lies.
And what I realized is that at that level, everyone is, typically in venture capital-backed companies, looking to the next milestone. How do we grow from here? How do we grow? What's the next milestone? How do we unlock the next funding round, et cetera, et cetera. Maybe that died down a little bit these days by virtue of the consequences. Maybe not, but definitely the game.
Let's examine what are the consequences of that game, because at that level of executives and leadership teams and boards and investors, what we're seeking, because we're constantly looking at the future and codifying what that future must look like in the form of a budget that has forecasts, that has all sorts of predictions... We need predictability. We want certainty. We want to make sure that we drive towards a certain outcome.
The problem is, what do you have, let's say as a CEO, what do you have to bring this reality about to make it real? Again, like you and I were talking about, we have a complex system made up of those humans that are unique and snowflakes and have ambitions and worries and fears and anxieties and all sorts of things. So. Here's the conundrum, right? The great disconnect that I was talking about.
You are seeking predictability and certainty through a complex system, which is not amenable to control, is not predictable where behavior emerges, and so on and so forth. And so when we think about it and we look at OKRs that pretty much everyone in a company is exposed to in some way, what we don't see is how those OKRs eventually ladder up to the company's OKRs and then they connect with the budget that then connects with some promises and things that must happen.
And so a lot of that pressure gets downloaded throughout the organization. And it tends to be about "we need to meet this target, we need to do this, we need to do that, we need to reach this and that," and ultimately creates a lot of silos because everyone is really trying to move their metric when the reality is that there's a ton of dependencies. And one thing we know is that often we cannot optimize both the local, so for example, the team and the global, which is the company.
So there's an inherent tension that kind of comes because of this disconnect, essentially, or at least partially explained by it, that creates a lot of problems on the day to day and a lot of changes in direction and a lot of bureaucracy that tries to kind of keep things in place just enough when the reality is that it's very unpredictable behavior emerges and we're back to all the tools that we were talking about, experiment, learn, experiment, learn, continuous improvement, et cetera, et cetera.
Resources that came up in the conversation
Turn the Ship Around by Captain David Marquet.
The 7 Habits of Highly Effective People by Stephen Covey