This is a transcript of episode 318 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
One guy you’ve never heard of kept the Apollo moonshot on track - by holding great meetings and taking super notes. Do your ADRs and Notion pages measure up?
Show links:
Listen to the episode on SoundCloud or Apple Podcasts.
Tindallgrams are Superlative ADRs
Listen to this section at 00:14
Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.
Jeffrey: Hi, Squirrel. Hey, Squirrel, I got a question. You sent me something earlier today with kind of a funny name, but it was really cool once I got into it. Tindallgrams.
Squirrel: Oh, yeah. Tindallgrams!
Jeffrey: How did you come across Tindallgrams? And I think this would be great for our audience.
Squirrel: I found them the place that you get all wonderful, exciting, technical sort of things, which is Hacker News, news.Ycombinator.com. And I trawl that all the time for interesting material. And boy, this was really interesting. So, let me tell you just a little bit and tell our listeners just a little bit about what these things are.
Squirrel: So there was a guy called Bill Tindall and he wrote things called Tindallgrams, and he wrote them as part of the Apollo missions to land somebody on the moon. And Mr. Tindall, I’m not sure if he’s still around, if he is, we’d love to have him on the podcast, but I suspect he’s no longer with us. But he seems to have been an amazing project manager, manager of people, negotiator and all around, friendly guy. He, would get called in, it seems like, any place or any time where the Apollo program had a really difficult decision, where they had something really tough to do and typically would have different people battling over it.
Squirrel: You know, the people who are building the LEM, the lunar module that would land on the moon, would be battling with the people building the rocket that was going to take off from Earth, and they’d be arguing about how much weight they could put in or what electrical system or something. And they’d call in Bill Tindall, and he’d hold a meeting, and then he’d write one of these Tindallgrams to record the meeting, and that would put an end to the discussion. It would solve the problem. And you can imagine how valuable that would be on an incredibly complicated program, like getting to the moon. People have written these down, people held on to them and photocopied them and put them in books and things. So, there’s a nice trove of them, which I think would be really interesting reading for anyone interested in writing better meetings, making scheduled deadlines, making difficult decisions. And, hey! That’s what we talk about!
Jeffrey: Yeah, absolutely! And the fact that it seems like this was really a step forward like this, these Tindallgrams didn’t just happen because he thought there would be a good idea, but actually the meetings that he was writing these notes for was filling a gap. And you could see then kind of the before and after, which is like beforehand, people would talk about problems and have questions, but there seemed to be like a lack of really making progress on those. And man, it just that description really hit home for me because how often I’ll come into a project and someone will raise a question and then several people have a different view on if that question had been answered before or not, and when was it answered. And ‘what? I thought we revisited that!’ And there wasn’t like a easy way to answer the question of like, ‘this is our view of the proper answer to that question.’ And so this idea of having this record is the first thing that stood out to me about the Tindallgrams.
Squirrel: That’s something that we often talk about, or at least I have people ask me about in terms of acronyms like ADR, Architectural Decision Record, I think it’s called-
Jeffrey: Yes.
Squirrel: -And other situations where people are building complicated software systems and they want to record what they did and why. And I think, of the different ones I’ve read, these are the best architectural design records, and they’re not about software architecture in most cases that I’ve read because they give you a real sense of what the room was like, what the issues were, who disagreed for what reason. There’s one I think we’ll look at in a little more detail. It’s the very first one in the pack that I sent to Jeffrey, and it’s all about two groups, one at MSC. I’m not sure where that is, but some part of the Apollo program and one at MIT, the Massachusetts Institute of Technology, obviously building some part of the system. And it starts by saying a flock of MSC people met with MIT people in Boston to discuss this topic. And the paragraph ends with a great sentence: my main purpose is to describe the situation as it exists on these important programs, it is not altogether a happy one.
Squirrel: So it makes it clear to you that these people have a very difficult problem to solve. They’re trying to work together on it and they may not agree. And that’s in fact exactly what happens in the whole rest of it. Whereas I have the sense that a lot of the architectural decision records that I read, that my clients bring me and so on, are much drier. They don’t capture much about the sort of disagreements and the differing views they more or less describe ‘here’s what we did do. Here’s what we decided on. We decided to use Google Cloud Platform over AWS for these four reasons.’ And that’s very helpful as a record of why we made the decision, but not about how we made the decision. And I think that’s an important part.
Record the Uncertainty, the Disagreements, the Reasoning
Listen to this section at 05:23
Jeffrey: Yeah. And that’s a really good point, because I think one thing that comes through in reading this is some of the uncertainty. And so like to use an example here, ‘MIT is still expressing concern over their ability to define, design and implement the concentric flight plan routines in time for including them in the AS-207/208 LEM programs.’ Okay, I don’t know what the LEM program was, but what’s clear there is that the fact that there was something that was unknown, the fact that there was a concern that was being raised, and that concern is recorded and that it’s still kind of indeterminate. So will they be able to deliver it or not? Don’t know. But they have concerns. However, they indicate they could continue with the development of the guidance system operational plan, blah blah blah. And so it goes on. You kind of get a holistic sense of what’s happening, not just that sort of dry fact. That’s something that really was different about it. It felt much more human in some ways than some of the things I might see distilled.
Squirrel: Indeed. And I’ll say a bit about what that program is and what the problem was, because it’s going to sound very familiar to lots of our listeners. And I think the solutions they came up with will sound eerily normal and familiar to us, whatever it is 60 years later. But I’ll say something else, which is that the fact that they were recording the disagreement and the nature of it would allow somebody later on to come along and say, ‘ah! They already considered this. This is something that we don’t have to look at again.’.
Squirrel: And sometimes I have people who tell me, ‘well, look, I just want to record what actually happened. And their model is something like the minutes of a meeting at a parish council or a government body or something like that. And the purpose of that is not to discuss, not to record so much the disagreements, but to record what the decisions were. And here, the disagreements are really valuable. And Tindall seems to really pull those out in a very helpful way. He’s really observing and telling the story of what happened at the meeting so that there’s a record for later, which seems really useful.
Squirrel: Let me describe, though, because our listeners will be interested, what they’re trying to do in this particular meeting is to delete programs from the software that’s going to be on the command module and the lunar module, the two pieces that are actually going to go to the moon. And, in the command module’s case, come back. I don’t know if you know about this, Jeffrey, but they had rope memory, which literally was made out of something that was like rope-
Jeffrey: Oh!
Squirrel: -And it had to be woven. There were human beings who, it wasn’t like you just, you know, type it in and it magically goes into the ram somewhere, they had to write down all the bytes and all the bits, and it had to be woven one direction to be a one and the other direction to be a zero, and you had to weave the rope in the right way.
Jeffrey: Wild!
Squirrel: So there was a very, very small amount of this memory. If you look, there’s about, 72K in the command service module, and, I can’t see for the LEM what it was, but this is minuscule! Millions and millions of times less than you have on your phone. On my desk, I probably have ten times that, from the computers and phone and other things that are sitting here. So it’s tiny, tiny memory and they’re trying to fit all kinds of required stuff. They have a bunch of requirements and they can’t fit them all in. Gee! Does that sound like a scrum planning meeting?
Jeffrey: Hahaha! It does!
Squirrel: Exactly. And the wonderful thing they did is that, they recorded all the things that they weren’t going to do, and the rules that they used. For instance, they said ‘if it has a human safety component, we’re not going to delete it because it might kill somebody. So we’re definitely not going to do that.’ But there are other super important things. And he goes through a list of different ones and he says, ‘well, this one actually, we can have the pilot do the calculations instead of the computer. But that might mean it’ll take some a little bit longer and we might actually screw up. There might be a risk. We might burn the engine too long.’.
Squirrel: Or there’s one here where there’s a requirement from headquarters, so there’s a capability to take over if the rocket guidance system fails. And NASA headquarters have said we have to have this. So Tindall records that ‘hey, we’re going to go try to find headquarters and shake them until they do something different.’ He puts it more nicely, but that’s essentially what he says. And again, this should sound very familiar to our listeners, where something comes in from some authoritative source and you say, ‘who ordered that? This doesn’t make any sense! And they don’t understand our constraints.’ So they’re they’re fighting exactly the same kinds of difficulties.
Squirrel: And there’s a number of other places. Where they’re describing what they will not do, why they’re not going to do it, and how they’re going to work around it, and this is a perfect example of what I call ‘disappointing people helpfully,’ because somebody who reads this memo might be saying, ‘oh my God, you’re going to take out the flight pad tests?! What a terrible idea! How will we know this thing works even before it gets off the ground?’ And then the next sentence says, ‘we’re not going to delete the test, but we’ll support them in another way. So we’ll do the test, but not inside this computer. We’re going to do them someplace else. And by the way, the thing that’s more important is human safety, and a few other things, whatever headquarters has told us to do, for example.’.
Squirrel: So that gives the message to whoever reads this. ‘We’re prioritizing this set of things over that set of things and where we can, like on flight pad tests, we’re going to skip over that. We’re going to find another workaround because it’s less important.’ And that’s so valuable for making sure that everyone across the organization understands the priorities.
Only Argue the Next Step
Listen to this section at 11:25
Jeffrey: That’s so good. And I think this captures something really interesting because I think what we’re seeing here is the record of something else that’s happening, which is how the group functioned. And I think there’s something that relates the two about the quality of this document and the quality of the group interactions. So let me just quote this. They’re talking about, ‘so thereafter they feel if they’ve not arrived at an acceptable solution, it may be necessary to drop these routines, which are considered mandatory by MSC from the AS-207/208 program.’ And this is the part that I think is interesting. ‘I personally have every intention of making sure that they are not dropped, but there seemed no need to argue this point at this time since it has no influence on the current course of action.’ And it’s that last part, that we’re not going to argue it because it has no influence on the current course of action.
Jeffrey: The last week, I was lamenting to people in a couple of different times, that I was in meetings where people were agreeing on the next step, but were still arguing because they had different reasons about why they should take that step-
Squirrel: Oh yeah.
Jeffrey: -Or about what would happen next. And this is a case where they’re documenting the disagreement, but also say we’re going to move on from that, because it doesn’t change what we’re going to do next. So I wonder about how that these things interacted, having this clear record of the decisions and the trade-offs and also the kind of environment that could say, ‘let’s not argue fruitlessly because we have fruitful things to argue about’ how those two things go together. And this is, of course, even before we get to your favorite paragraph.
Squirrel: Oh, yeah. Well, the final paragraph is most helpful and it has a political element and a humor element and a record element. I think we can focus on the last, but be entertained by the first two. So I’ll read it in full.
Squirrel: ‘At the conclusion of the discussions of the AS-504 programs, MIT agreed that there was nothing more MSC could do.’ You remember, there’s these two groups, MIT and MSC. They’re meeting together to try to hash this out. And Tindall obviously is playing broker here and he’s balancing them against each other and helping them in the meeting. ‘There’s nothing more MSC could do to enhance the schedule situation for the AS-504 program. That is, further deletions of the program requirements would not help in any way. This was stated and restated several times to ensure that MSC would not subsequently be notified that schedules could not be met, as a result of excessive demands by MSC in the area of program requirements.’
Squirrel: So what they’re saying is, ‘hang on, don’t tell us again that we’re holding up the program by not deleting enough stuff. We just met with you. We deleted a whole bunch of stuff, some of which was terribly painful and made it real difficult for us. But we made the hard decisions. And now you’ve told us that deleting more stuff won’t help. So stop telling us to delete stuff because we did it.’
Jeffrey: Yeah.
Squirrel: So, uh, I think that’s got clearly a political angle. Tindall does not want to hear this. It makes it very clear. And he says it again here so that everybody gets it. That’s what I call the broken record. You’ve got to say it many times until people say, ‘yeah Tindall we got it! We can’t delete anymore! But what else can we do that’s useful?’ But more importantly, it makes a record, it describes ‘we have decided this. It is a firm decision. We have it very clear that, we don’t need to look at deletion anymore. So let’s not do that!’
Squirrel: And I think it would a lot of our listeners would benefit tremendously, and their teams would benefit tremendously from saying, ‘look, we’re not going to look at single sign on anymore. We know that that doesn’t make people stop churning. So whether or not we have single sign on doesn’t matter. We’ve made the decision. It’s here in the record. And what we’re going to look at is other ways to reduce churn other than single sign on, because it doesn’t matter!’ And I can hear Tindall raise his voice just a little bit in that final paragraph, in I think an effective way.
Good Records Create a Narrative and Have an Outsized Impact
Listen to this section at 15:23
Jeffrey: I want to- So we’ve been talking about this and clearly we’re both fans of this newly discovered Tindallgrams. I wanted to just be really clear on what I think are the lessons for our listeners about this, because I think in this first example, what I see is someone who has taken the time to take two days of meetings with a flock of people, and he is documenting this over two days, into a document that’s about four pages, a typewritten memorandum. And the kind of leadership that that involves, because what he’s doing is he’s building alignment for the whole group about how they go forward.
Jeffrey: Now I’ve often talked to people and certainly at companies I’ve worked at, where we talk about compensation and how to give people feedback. We’ve used this impact model of assessment, and sometimes people aren’t clear to how to have more impact. But I think this is a great example of a nontraditional, non-obvious way that someone can have huge impact, which is to go through and be the person who’s helping to synthesize what a group has discussed into a way that’s consumable, both by them and others in the future. And so I think this kind of thing is fantastic and well worth the effort. And that’s the thing that sticks out to me, is we so rarely, and I’m including myself in this, take the kind of time and care that went into this, even on very important meetings, very important decisions and discussions. Instead maybe we have a shared document where we’ve taken sort of stream of consciousness notes, maybe we have a meeting recording, maybe a transcript. But to take the time-
Squirrel: Maybe we have ChatGPT do a summary. None of those have the same effect as a Tindallgrams.
Jeffrey: Exactly. That’s right. And so it may seem like, ‘well, is it really worth it to have someone go spend the time to really pull all this together? I think the answer is yes.’ And it’s not just me, but I look in the introduction to this document and something that stood out to me, and this is not at all surprising, was that former MSC director, Christopher Kraft, afterwards said ‘it would be difficult for me to find anyone who contributed more individually to the success of Apollo than Bill Tindall.’
Jeffrey: And now I’m not going to say he probably didn’t do this entirely through his Tindallgrams, but I think these Tindallgrams actually do help me see how this person, in their role of leading the discussions, documenting the results, helping people move methodically through the open issues, could have an amazing impact. So that’s something for people to, I think, consider. Are people putting the correct effort into recording their decisions, digesting them into a format that will be useful for everyone on the team and everyone in the organization at large? And certainly I’m looking at myself now, thinking about how I would need to change my habits to make something more like this part of my normal habits.
Squirrel: There we go. And I’ll just pull out two things as well that are key for me. One is Bill Tindall was not the mission director, super high honcho, person in charge of everything. Had an important executive role, it sounds like, I don’t know exactly what a director of Flight Operations does, but he’s not directing the entire program. He’s not building the rocket. He’s not at MIT, writing the computer programs. So he’s part of the process, but he’s a crucial cog. He’s producing outsized value for the role he’s playing. What’s on his business card isn’t defining what value he’s adding.
Squirrel: And that’s why I like the things like measuring impact and measuring business outcomes to judge what we prioritize, how we reward people, and so on. The idea that somehow you could measure by lines of code or function points or some other crazy thing, how much a developer is contributing. I think this illustrates the sort of, contribution that just absolutely doesn’t capture.
Jeffrey: Absolutely.
Squirrel: And the other thing that I just think is so valuable about this is what Tindall is doing, is creating a narrative. I always tell people if they’re going to try to read a board pack or a financial report or something like that, look at the balance sheet, see if you can understand it, but look for the words that are written at the bottom. ‘We’re going to run out of money in three months, if we don’t sell this new client.’ That really helps you where the raw numbers rarely do. Even if they’re red and there’s a scary graph and stuff like that, you can just tell the sort of thrust.
Squirrel: But when you read the narrative, when you get a story, it’s very clear. And you can tell there’s a story here in the one we took apart and there’s one in every one of these Tindallgrams. That in that case you have two sort of warring factions. They’ve come together. They’ve agreed to do as much as they can to delete stuff out of this incredibly constrained system, and there ain’t no more they can do, so stop bugging them about it. And that’s a narrative that you can take home, that you can use, that you can share with other people. And that kind of narrative provided not necessarily by a top leader, but someone who has the knowledge and the ability to create the story, can really unify a team and create a very valuable alignment. So I hope that our listeners will read some of these Tindallgrams and see what they can take from them.
Jeffrey: Absolutely.
Squirrel: So listeners, if you want to read some Tindallgrams, by all means go and look at, the link in the show notes, which will take you to many, many, very interesting examples. Keep in touch with us and come on over to the next edition of Troubleshooting Agile, which will be out next Wednesday. We’ll see you then. Thanks, Jeffrey.
Jeffrey: Thanks, Squirrel.