The Human Systems around our Technical Systems
with Jason Gallaugher
Jason Gallaugher is a long time engineer and engineering leader who now works as a consultant and coach helping technology organizations become high leverage.
This was a great conversation about human systems. How so often we over-focus on the technical systems we can build or put into place without considering the importance of how we organize our work, our interactions with each other, and how we use those technical systems to create a human outcome.
In the second half of the conversation, we got into the topics of the different types of organizational cultures, missionary vs mercenary mindsets, and how important it is as a leader to understand the context you're operating in.
What do you mean by 'the human systems that surround the technical systems'?
You know, there's the technical systems that we all know fairly well, as far as like the work we do. People with engineering backgrounds, people that build... that includes a lot of different people within the organization. Salespeople build, Marketing people build... that world is one where the feedback loops are pretty tight.
If I speak about a developer and what I used to do... if you fix the bug, you get instant feedback. You have a general idea at the end of the week, all the different things you did, how you added value and what that meant.
But that's not the only system that's at work. It's an important system, but not THE system at work. There is this other system that's in plain sight, but I think we don't spend enough time talking about, which is the dynamic system of humans in the organization and in the company that have to collaborate and interact together to do work.
And this system is very different from the other systems we might work with, whether they're financial or engineering, in that it's subject to unpredictability at times, it's subject to a lot of complexity in terms of the communication paths and people's behaviors, people's habits... telling stories, explaining narratives. There's just a lot that surrounds it.
There's been a lot of people Conway, for example, that has talked about the interaction between software architectures and the organizations that produce them and how communication paths are mirrored within the things that we build. So there's a lot of different literature about how those systems interact. But yeah, there's this big, really important people system that I think that, especially as technical people are people in the tech industry we're not as comfortable working with or talking about.
When you say this human system is "here in plain sight" -- do you think we can all see it but choose to not talk about it, or do we need to do work even to start to see and understand it?
I think we all see it per se. I think learning to influence it, learning to shape it, learning to work within it effectively towards ends like telling the story of what your team is doing, or, advancing your own career or organizing a whole group of different people as an executive towards one end... Notions like motivation. There's a lot of fairly abstract or complicated concepts around it. I think we all see it. I think we all know it's there. But I think there's a lot of fear and anxiety around what to do with it, how to influence, how to tell your own story.
And I think we have a lot of personal barriers perhaps that prevent us from participating within that system as fully as we want to. Butit's all very understandable. These are all things that... especially in all of our academic careers, there's not a whole lot of time spent discussing.
And I think maybe it seems like dark arts at times, but yeah, I think largely it's just fear and discomfort. And not fear because of lack of knowledge, but also sort of our inherent feeling that these things are unpredictable, that we're not sure what's going to happen. We're not sure how it's going to work. I think we're inherently uncomfortable with working with chaotic systems. So I think, yeah, all of those things maybe prevent us from participating fully within that context.
How can you create more predictability within a human system?
I think the one notion I usually go to is that of a feedback loop, which is a critical part of explaining these types of systems and how systems feedback onto themselves to generate different types of behavior.
The biggest tactic that helps bring some level of order, at least observability that's reasonable to these types of systems, even if you can't look several steps ahead is the notion of where your feedback loops are.
There's a lot of different, very tangible feedback loops that exist within an organization. Examples of feedback loops within the human domain that are that are interesting are things like conversation. And these seem sort of trite in a sense, but it's true.
We talk about it in tech as a one on one meeting, or channels and forums for ideas to be exchanged. And those are opportunities to ask questions about what people's state of minds are allowing you to make some reasonable opinions on where people's heads are at what you think they're going to do next, how you might need to help them. At a group level, there's all sorts of interesting tactics like retrospectives.
I don't come into this with a real hard line on process, just that, having some observability in some process, feedback loops in the system are critically important in terms of predicting where the team might go next. Well, we've done these things, these things are working really well. We really wish we could do these other things. And, you know, it's important now. So we take these improvements seriously as we go week to week, month to month.
And you can start to understand through that where the system might go and how you might nudge it in a direction you might want to send it, which is another important concept that I won't go too deep into right now, but the notion thatone should act as if one doesn't necessarily have complete control over that system, rather than implying that, you know, instantaneous and dramatic change can be can be implemented with a group of people in a system like this. So I'll talk about nudges a lot.
But if you talk about those different ideas, you can start understanding where the system is and where it's going. And I think that the guiding principle here is leaving yourself as a leader, leaving the organization open to possibility. Knowing that this is the system underpinning what we're talking about, that you're not ignoring the fact that some unpredictable things could happen. How would we react to that? And do we have some basic mechanisms and principles in place to allow us to reasonably respond to that rather than continually being surprised when things act chaotically, when you think they're going to be a very predictable linear sequencing of operations around activities like delivery or collaboration.
How do you anticipate areas of potential chaos, and how do you set up the organization so that it's able to adapt to those?
Just like anything I'll keep drawing these analogs back to things like software architecture. These are principles that work well in other types of systems as well, like not going too far, or not making too many assumptions at one time that may prove to be false and end up constraining you further in the future than you thought.
But from an opening possibilities standpoint its less about predicting than being open to things not going the way you think they're going to go. And this touches on concepts of the act of creativity and the act of inspiration.
Engineers and tech organizations and business organizations are inevitably as full of creatives as any other organization and that's how the mindset works, but remaining open to possibility allows for the system to optimize the answer.
Rather than someone that's inherently flawed, like any leader, like myself, to make broad claims of whether or not something is optimal or not. It's more about setting up the appropriate constraints, allowing the team, the people to react according to what they know, given that they're closer to the right information. And this gets into notions of autonomy and ownership. But it's allowing the system itself to react to change, coming from other systems, coming from within, rather than setting up a rigid strategy, which can take the form of a leader micromanaging or a group of people not feeling that they can respond or that it's gone off script and I don't know what to do.
So yeah, it's really just a notion of embracing the fact that maybe it won't go the way you think it will. And if that inevitably happens, whether by degree, small degree or large degree, that, you know, the system and the people within it will be able to react that appropriately rather than remain stubborn against what your previous assumptions were, fail to recognize the change or the reality of the situation, not bring their full selves or full creativity to the problem solving because they think they're working in a different system than they really are.
So yeah, to me, it's about remaining open to the fact that the chaos will happen. And it's really about how you react to it rather than how you attempt to control it for whatever reason at the outset.
What's an example of changing the system to create better results?
I can think of one example, and it kind of actually... the process can operate in both directions. You can go from the business constraint to the behaviors and back the other way. This one sort of operated in the reverse way. That's maybe a good illustration of how you can play with these different systems in different orders.
I was running P&L responsibility for an organization. And I think the biggest thing you want to do within a services organization is prevent escapes. And what I mean by an escape is a project that doesn't go well to the point where you are actually losing money quite significantly against that contract and against that particular gig.
And in general, I think what I've seen in that kind of vertical and the way of working is that most projects have outcomes in states that are largely clustered within some level of profitability. They're kind of around the middle. But every so often you get a black swan event, you get an outlier as far as it's negative implication or how badly it's going for various different reasons. That's always a struggle in any services organization I've been in.
And I think one of the biggest things that we saw is that we were observing in different projects that maybe despite everyone's best intentions and the right cultural factors there, that the results sometimes weren't happening or teams weren't responding fast enough to the right business stimuli.
And this is a situation we have a lot of different simultaneous teams working on separate contracts all at the same time. So as an executive, you're looking across all of these checking their health. You've got some wonderful ops and delivery people that are providing all sorts of context to this, but you're looking across the organization and the dynamic behaviorally to this, given that we want to eliminate these black swan events, is to figure out why they're happening in the first place and how do we prevent them?
And what we tied this to is that... it either resulted from poor initial conditions, which was not really relevant because we can work on kind of how we negotiate these deals. But the other one was teams weren't reacting fast enough or the feedback loop, as far as adjusting team size approach, changing requirements, constraints, other parts of the system that the team needed to work on... these things weren't happening fast enough.
Tying up a lot of conversation into a nutshell, the round trip to affect change within that context was up to somebody like me sitting in the VP chair and then back down to the team to say, "yes, you can do that, yes, that's a good idea," or "by the way, you're trending non-profitable right now, what are you gonna do about it?" Was problematic in a very long feedback loop.
So what we decided to do is we had all the model kind of at the top level... make sure that on a real time basis, each one of these teams had a view into their own profitability. So they can make decisions on a daily basis based on things that would steer them towards profitability, because that was our clear mission as the business. And they can change the behaviors accordingly.
So this was a situation where just giving the right context to those teams actually shifted the behaviors in the right direction. And it was a question of transparency around that.
And the result of that was that we, we removed those black swans. We suddenly had better profitability from these projects because the people closest to the action that could influence the behaviors of the rest of the team better were actually equipped with the right information and context to do that.
Instead of being forced to work in a rigid way in a very linear way, according to some other model of how that work should probably go. And going up to somebody like me to ask me if I thought something was a good idea or asking me what I thought about how the project was going right now, we just concentrated that context within the team itself.
And just that notion of visibility coupled with what had already existed as far as people's extreme accountability they felt already around the outcome of their project produced the right behaviors in terms of adjusting right away. Not coming to me for permission for these things, obviously keeping us informed of things, but introducing a bunch more dynamic behaviors around making the broader project a success.
So again another very concrete example of how transparency and maybe uncomfortable transparency from a business standpoint for some organizations at the team level actually produces better results for the entire company because you're giving those people the ability to navigate that dynamic system.