Show Notes
Let’s imagine that you are just taking on an engineering organization. Maybe it is new to you or maybe it is completely new. What should you do to set yourself up for success? What are some of the important, or critical, aspects to think through, write down, nail down, or get agreement on?
In a five-part series, Mon-Chaio and Andy look back over the long, and sometimes rambling, episodes of The TTL Podcast and try to condense them down to something more digestible. In episode one you learned about defining your cultural and structural north star and in episode two, hiring strategy, clarity of tasks and boundary, and explicit intentionality. Episode three covered building your team fabric and leads us into this episode: providing just the right amount and type of guidance to ensure your organization runs smoothly.
References:
- The Art of Action – https://www.stephenbungay.com/Books.ink
Transcript
Ep 025 – Smooth Operation (Building Your Engineering Organization – Part 4 of 5)
Andy: Welcome to part four of our series on building up an engineering organization. So far we’ve covered working out our North Star, bringing people in and building the fabric of a highly performing team. Now we’re at the point where we have a team, or several teams, beavering away at making software, and you need to find ways to steer the teams, identify and handle problems, and continue to improve how things work, which is both technical and social.
If you’re adopting an existing technical org, this is in fact where you’ll probably start, and if you’re building a new org, you’ll end up at this point much faster than you might expect.
As a software developer, I took the position that maintenance starts as soon as you have a line of code running in production.
And the goal is to get to that point as quickly as possible. Maintenance is an indication that the software is valuable. Rarely will you get change requests for something that people don’t care about. So how does this connect to smooth operation of a team? Well, as soon as you have two people working together to achieve a goal, you have a team.
As soon as you have a team, you want to pay attention to how it’s working, and reinforce what is working, and address what isn’t.
A small part of this is just sitting and thinking about how things are going. I say small, but thinking about things is really important. It lays our groundwork for what you do next. On this show, we talk about the importance of using models and theories to guide what we do, and this is no exception.
One such model is BART, Boundary, Authority, Role, and Task, which we talked about in Episode 1. Another is Forming, Storming, Norming, Performing. And then there’s the Explore, Expand, Extract. And there’s many more that we’re going to get to over the years of doing this. Each one gives you a different way of looking at a situation and produces a different set of questions to ask about it.
Let’s listen to a segment of the BART episode where we applied the model to a specific situation and how it spurred conversation.
Clip from BART on Boundaries and Confusion
And the commercial system, the business system, which then, as you said, they kind of got combined, but when that com combination happened, there was never any clear discussion about, okay, what are the boundaries now? Are you completely combined? Are you really just the same group now? Mm-hmm. Are you just collaborating on this one little piece?
Mm-hmm. Is that your only overlap? Mm-hmm. And because those boundaries weren’t ever discussed, neither side neither of these original orgs that we now know. Don’t know what state they’re really in. Are they one org? Are they not? It’s unclear. Mm-hmm. Didn’t know if they, if they were sharing authority, if one had authority over the other, or vice versa.
Mm-hmm. And so if I recall correctly, a lot of these bugs were kind of coming from the team saying, no, look, that’s still not our priority. Go away and work on it yourself. Is that, is that right? Or am I misremembering? I don’t know if that’s, Exactly right. But other than what you just said around go away and work on it yourselves, that’s not our priority.
I agree with everything else. Let me sort of throw another wrench into the work, something we haven’t discussed. Yep. At one point, the consumer org was approached and said, look like we’re going to the consumer org. We’re going to the consumer world with this desktop application. Like, don’t you think that, you know, it fits into your world.
And the consumer org, or the mobile org basically said the mobile consumer focused org said, that’s interesting, but we don’t really care. You have no users. You have a lot of complexity. You know, building desktop apps requires building its own, you know, built system, for example requires its own debugging system with memory management and whatnot.
I mean, there’s just like, those use cases that you have are interesting, but like, we’re really busy with big numbers right now. Right. Basically that’s really cool, but we don’t wanna do it. Mm-hmm. However, that, what that org did care about was interoperability, right. So, If a feature shows up on the mobile app, it’s a very jarring experience for it to be completely missing on the desktop app.
Oh, interesting. Or if a bug is fixed on the mobile, on the mobile side you know, oh man, this button doesn’t turn red when it’s supposed to. It’s really supposed to turn red. It needs also needs to be fixed on the desktop side. To your point around boundaries, you are right. That the boundaries were, you know, the, the mobile side basically said, look, the boundaries are separate.
Right? We’re separate boundaries. I don’t care about your thing. But interestingly enough, when we get to the A, the authority, they certainly thought that they had some authority. That’s what I was thinking. Right. But if you then go to the t, the task mm-hmm. They’ve rejected the task. Mm-hmm. They, they have, it sounds like explicitly said, that’s not our task, but they want the authority.
End Clip from BART on Boundaries and Confusion
Andy: What we heard in that clip was an engagement with the dynamics of the team through the lens of the BART model. And it also showed the value of having someone to bounce the ideas off of, as you try to fit the model in different ways and check hypotheses that the model raises. Once you’ve done some thinking about what’s going on, it’s time to get out of your head and move out into the world.
Because so far, you just have some mostly untested ideas to go off of. What you need to do next is go out into the world and check things. A bit like testing a hypothesis. You need to go and talk to people. Look for evidence to disprove or support your ideas. Change your thinking. You need to go and see.
We spoke about the importance of this in Episode 4, Delegation.
Clip from Delegation on Gemba Walks and Briefings
Mon-Chaio: I think that concept of gemba walking to where things are happening is so, so important. I think a lot of even a lot of leaders who are pretty hands-on end up not going there.
Andy: Yeah
Mon-Chaio: you know, I I once had someone tell me like, you can’t tell my boss to go attend a standup to figure out what’s going on.
They’re too busy. my point was, well then it must not be important enough for them to dig into that granular level of detail. Right. So I think to me getting back to the question or bringing it back towards delegation, I think this has a good tie in on, you know, once you delegate, how do you make sure things are on track? Right. And I think it’s, To me, it’s a bit of a mix. But maybe I’ll start off by asking you, how do you think about that when you delegate? How do you make sure things are on track?
Andy: I think it’s a, it’s a combination of these things.
It’s that continual briefing and back briefing. So you’re hearing what are the updates? What’s the change situation? Where are we now?
And it’s doing the gemba walks, it’s going and watching the actual situation, the actual state using that as a way of understanding those back briefings.
I’m getting with a bit more context because. Because you can think, actually, I can think of it as one of the things you’re trying to deal with is the curse of knowledge in the other direction. So the back briefing from the briefing was to deal with the curse of knowledge. So you need to think about, okay, when you get that back briefing, how do you deal with the curse of knowledge from the other side?
And one way of doing it is to go and have other information and then try to fit this information together and ask questions and be like, but you’re saying that, I was just watching this the other day though.
Mon-Chaio: Yeah, I agree. And I also think that it’s quite a mix. I think you know, for me, in terms of AAA orgs, I tend to think about, you know, obviously the briefing part is really the OKRs, right? Or the goals that you’re trying to meet for the quarter or the half or whatever. And I think in the past processes that have worked for me is, again, a mix of both.
So, I would like to have every two week or every three week status updates we call those, you could call those briefing back briefing, where we get into a room with the leaders of each, you know, each aaa org and say, look, these are the goals as we’ve espoused them. What is the progress towards these goals?
Are you still confident in making these goals? And again, the intention obviously is to make sure things are up to date, but it’s also to get any information back that makes us realize as leaders that, oh, we haven’t communicated correctly.
But what I think is critical in this area is it is critical to not. To me anyway, to not have all this extra work that people end up doing. Oh, you have to prepare a one page writeup for every single project. And then you have to send those out for comment before our meeting. And then I’m gonna like talk about, oh, you know, I don’t think that you should be talking to this customer or you know, whatnot.
That is something that I personally disagree with. And so it should be lightweight. And so people should come having to do very little prep. And it should be more of a discussion around, are these goals getting met
End Clip from Delegation on Gemba Walks and Briefings
Andy: And that clip ties nicely into what to do with all this information you’ve gathered. These mental models of how the organization works and lessons you’ve learned from going and seeing. You now need to take action to make changes. One of the first things to do is work out what is the brief you want to put out there.
Stephen Bungay gave us specific directions about how to formulate a good brief in his book, The Art of Action. I’ll read you about a page and a half description.
Quote from The Art of Action
Andy: If Peter Drucker first urged managers to manage by objectives, von Moltke could be said to have led with directives. We can take over his principles in formulating strategic intent at the highest level. Such a statement needs to contain the following.
An account of the situation. Bringing out the essential features which bear on the course of action to be taken. It is useful to cover the state of knowledge, distinguishing what is known, what is probable but uncertain, and what is not known but could be relevant.
The description of the situation should make clear what the implications are for what the organization has to do. It may be appropriate to include an end state if this is quite distant. For example, “become the market leader in domestic boilers generating returns of x percent.”
Next, a short statement of the overall intent. This is classically stated as a task plus a purpose. In other words, what we need to achieve now and why. For example, strengthen service to the installer in order to gain market share. This will represent a step toward the overall end state. Given all the possible goals, objectives, initiatives, and priorities one could and does have, this is the real focus, the thing that lends coherence to all the others.
Achieving it defines success. It answers the question everyone in the organization can and should ask of their leaders, the one which is hardest to answer. The question was once succinctly formulated by the Spice Girls. “Tell me what you want, what you really, really want.”
Next you need an extrapolation of the more specific tasks implied by the intent.
These will have to be turned into responsibilities for the next level in the organization, and will thus define their role in making the strategy happen. At the strategic level, typically, therefore that of the board or of the executive committee of a business unit, these will probably be themes or priorities which involve different contributions from several organizational units.
It will be the job of the directors or senior executives to work them through and turn them into projects for their direct reports. At this level as at each subsequent one, one should try to define the main effort. And finally, it should give any further guidance about boundaries, in particular, the constraints to be observed, and indicate future decisions which may have to be taken.
This helps people to think ahead and warns them of things on the horizon which they may not be aware. Constraints do not only define boundaries, but help to clarify what is wanted by making explicit what was not wanted. They may take the form of what have been called anti goals. That is, “whatever you do, do not allow this to happen.”
End Quote from The Art of Action
Andy: Okay, so in that description, we heard not only direction, but also boundaries, authority, and task. And the briefing and backbriefing process is so powerful because it is both steering and sensing at the same time. The backbriefing gives you as a leader insight into how things are working and how people are thinking about their goals.
An example of this might be a CTO getting their teams working on a new product that will have both a mobile and web interface, and these need to stay in feature parity with each other. The further context of the company is that they have a technical strategy to consolidate how currency conversions are done.
The briefing from the CTO should contain all of this information, and they should then pay attention to where those elements show up in the back briefing. . Let’s take a listen to this in the delegation episode.
Clip from Delegation on Backbriefing
Andy: The person delegating, which is what they’re doing, they’re delegating all of this decision making, which is what you’re often doing when you’re delegating.
They pass down and they say, okay, tell me how you’re thinking about this and what you might do.
And if they come back with something completely insane, that doesn’t at all match what the command structure thought that they were asking for. And let’s talk about this some more because that’s, not what we thought we asked for.
forth a bit. And it’s to get to that common understanding, that alignment on approach or alignment on goal, and the necessity for like, when are you gonna need to check in so that we can.
Command other units to do the appropriate things and, and get that information go on. And so it would be that kind of whole thing. And what they did was they essentially pushed decision making, which the French army hadn’t done. They pushed decision making all the way down into their, like, individual squads or something.
And so it was kind of in a way like organized chaos.
The individual Prussian Army units would suddenly change approach because the battlefield situation changed. And they had all been trained on, well, we’ve been given the overall goal, so we’re just gonna work towards it. But all through that they would of course be communicating back up and communicating back down, but they wouldn’t get stuck on it.
End Clip from Delegation on Backbriefing
Andy: As you’re doing the Gemba walks and briefings, you’ll learn things you didn’t expect. If you ask good questions. Because good questions are how you learn about the team. Mon Chaio had a good tip for asking questions that keep you away from solutionizing and open to new information. I’ll let him tell you.
Clip from Vacationcast on AWE Questions
One thing that really stuck with me was the author talking about the AWE question, A-W-E, AWE question, and that is an acronym for “and what else?” It really does fill two roles. It allows you to ask them for more information instead of immediately jumping to a solution.
Mon-Chaio: But it also allows you to not fill silences with solutions, right? I think one you could let the silence be, but also you can just say “and what else?” to elicit more responses from the person that you’re talking to, which I think is something that I try to do a lot and I think is very valuable. So I’m glad he called it out and I’m glad he gave it this acronym, which actually makes it really easy for me to remember and makes it easy to talk about as well.
End Clip from Vacationcast
Andy: And another model that I use for thinking about what makes a good question is that good questions come from the difference between what I believe What I have observed and what model I think is in play. Good questions uncover and seek to explain differences. You might have expected when I started off this episode and said I would be going over how to steer and improve teams, that I would have brought up metrics.
And yet, I haven’t so far. And that’s because metrics are not the top of the funnel for improvement. They can be vitally important, and because of the comfort that many of us get from the numbers, they can be misleading.
Let’s dip into a discussion about this that we had in Episode 16, Developer Productivity.
Clip from Developer Productivity on the tie between metrics and models
Mon-Chaio: At the team level, I think those Dora and space metrics work really, really well. Right. They’re about what are the processes and flow of what you’re creating? And can we continue to improve them? Where are the bottlenecks? Where can we continue to improve them? I think that’s very perfect. And so have metrics around that sort of stuff and use them as continuous improvement levers.
Right. This is, I think, where those dashboards fit in really well. Look. My flow dashboard shows me that there’s a red flow in between requirements and development, and that number has been going up and up and up for months, the time between requirements and writing code. You still have to dig into it. Yes, but go dig into it, right?
You have these systems that you trust to produce software, optimize them and use the metrics to figure out how can I optimize them? How can I get them better at the team level? Then when I think about the systems level, I think that is the difficult question to answer. So you have the individuals, are they doing everything they can and I optimize?
You say, okay, my AAA manager does that at the systems level. Does my process and team, are they optimized? Right? Am I optimizing my process or am I optimizing my flow? Am I optimizing my value chain? Okay, that’s great. The systems question though becomes, am I optimizing my organization? Which gets back to the question we touched at the almost the very beginning of this episode.
I’m spending six million dollars a month on my engineering organization. Can I get more from them? Or could I, or are they, compared to their peers in industry, producing much less than they could? Even as I optimize for everything else, right? Because we know, let’s say, for example, you have a very archaic software development methodology like Waterfall.
You can optimize Waterfall as much as you want, but there’s a certain limit on that process and flow. So how do you know when you’re in the wrong process? How do you know when you’re in the wrong flow? That’s that systems level optimization.
Andy: Mmm.
Mon-Chaio: That’s just a much trickier question to answer.
Andy: I think actually there’s a, there’s a key to this, and we talked about this a little bit when we were preparing. Which you were just talking about at the system level, you are within a paradigm of working. You’re within a model of working. Metrics are designed about measuring parts of a model that is currently in place.
The metrics can’t tell you what model to shift to to get completely better. They can tell you a bit of where there’s bottlenecks and whether or not things are matching up. That’s about it. So if you’re actually trying to fully optimize, there’s not a consistent set of drop in metrics that are just going to tell you the answer.
Because that is impossible. The metrics can only work from a particular model. Likewise, if you take a whole bunch of Agile metrics, and you just apply them to a waterfall model organization, they’re gonna tell you absurd things about what to do. And they probably won’t work too well. Some of them might work just fine.
Some of, some of those practices, some of those changes will just make things better, but they’re going to tell you all sorts of stuff that your organizational structure, your system will just fight against because they’re telling you stuff about a different system that doesn’t exist.
Mon-Chaio: I love that insight, and it’s rare that I hear something that sort of makes me really dig in and think for the first time, often. And Andy, this was one of them. I really like the fact that Mod yes, metrics measure what’s inside the model. They can’t tell you to move to a different model.
End Clip from Developer Productivity on the tie between metrics and models
Andy: MEtrics are valuable, but they can’t substitute for the experiential, qualitative data that gives you a new understanding of the world. And metrics are very passive. We want active engagement whenever possible.
But to ensure smooth operation, you need to also give teams and individuals leeway to do things different from what you might think. The briefing and backbriefing are one way to achieve that. And in episode 13 on the feedback fallacy, we talked about another method that is more one on one.
Clip from Feedback Fallacy on sharing your experience
Mon-Chaio: I agree. I do think that, and this is something I’ve started applying. This was actually the first thing when I read the article the first time that I took away from it. You know how you read and you take away a little bit more every time. But the first tactic I took away from it, I actually really do like, and there’s this, it’s that concept of tell people about your experience.
Andy: Oh, absolutely. Yes.
Mon-Chaio: Instead of telling them what they should do, especially in, to your point, the Cynefin complex domains or chaotic domains.
Andy: Because you can’t tell them what to do. You can’t tell them what to do. You can tell them techniques that have worked for you and they can try to replicate.
Mon-Chaio: Mm-hmm. Absolutely. It’s funny, I have this really strong manager that I mentor. She’s great. I love her. And one of the things she told me is that she was very, very uncomfortable in those types of conversations with me because she just wanted me to tell her how to solve her problem. That’s why she was coming to me, for me to tell her how to solve her problem.
And when I gave her frameworks and things I tried in the past, she didn’t feel like that was concrete enough for her. The funny thing is we had her and her husband and her kids over for dinner just last week and she’s mentioning that, yeah, now she’s doing the same thing with her directs as she grows.
But it is uncomfortable and I think it can be uncomfortable for feedback receivers, especially those that are looking for an answer to be told by the feedback giver, look, I don’t have an answer for you. Here are some of the things that have worked for me in the past given the situations that were similar to yours, but it is not your situation and I’m not living in your situation and I can’t really tell you what to do.
End Clip from Feedback Fallacy on sharing your experience
Andy: I’ve sometimes felt when I first heard many of these suggestions about how to support others that I was being told to withhold myself from situations. But over the years, I’ve learned that I was wrong. It isn’t to withhold myself, but to give space for others to be there and allow myself to add instead of overpower or overshadow.
Everything that I’ve gone over here is how to guide your teams to smooth operation by adding and not overpowering. Use models to clarify your thinking, and find questions to ask. Go and see. To learn and answer those questions. Make your intent clear in briefings, and check for understanding in back briefings.
Ask good questions. Use metrics judiciously. And use your own experience to guide others without commanding them.
Andy: I have to say that I’ve found putting together these recap episodes both more difficult than I expected and more rewarding than I expected.
They have been more difficult because I’ve learned how much Mon Chaio and I can jump from topic to topic, which makes finding succinct clips very difficult. But also, rewarding, because it has given me a reason to reflect on what we’ve talked about and learned so far. If you have liked any of this, please like, subscribe, and comment on whatever podcasting platform you use.
That would give us feedback we need to continue the smooth operation of this podcast, and help it reach others who it could help. And if you want to get in touch with us, please email hosts at thettlpodcast. com Until next time, be kind and stay curious.