7: Ep. 7 | Decision making

Erika (00:00) Hey everybody. Welcome to the Overcommitted podcast where we talk about our commits and our commitments and some stuff in between. I’m your host Erica and I’m joined by my fellow code enthusiasts, Brittany, Bethany and John. We are a crew of software engineers at GitHub.

and we first connected as an onboarding group in the same team and quickly discovered our shared passion for learning and building cool stuff. So even though we’ve scattered across different teams, we still come together regularly and geek out about technology and share what we’re learning and explore our life as developers. So for you, whether you’re committing code or…

Committing to new challenges, we are so glad you’re here. So let’s dive into today’s topic, which is decision-making as an individual and a team.

We know that in the world of software, making smart choices is super important. It touches everything from how we work together to what we tackle first, prioritization or how we build things in our architecture, how we deal with bumps along the road, risk management, or keeping everyone in the loop, those stakeholders and stakeholder management.

And we also know that getting these areas right means smoother workflows and the feeling of focusing on what’s really mattering most, building solid foundations for our systems and staying ahead of potential problems. But given the pace and pressure of development, the number of decisions we make on a daily basis can feel absolutely overwhelming. So one way to

Think about decision making is to introduce some models or frameworks. And we’re going to talk about some of those today and how we might use them, where they might be appropriate, where they might be better left to the side. So these models and frameworks vary based on the level of team involvement, the speed that you’re operating at, your

data reliance or availability of your data and also the roles and the clarity of roles on your team. And can include anything from choosing a leader to decide, requiring absolute consensus or gathering

conclusive, comprehensive data to support a direction or delegating the decision to a separate team. So the first question for the group is to describe any decision-making models that you use or that your team uses to help you in your work.

Jonathan Tamsut (02:29) I can start. So I think that maybe this is a good baseline. think very often I feel overwhelmed and maybe a little I panic or just feel like, you know, there’s just so many available options and I can convince myself that it doesn’t really matter. You know, I’m trying to think of an example like, you know, if I’m working on a project.

what I start first, you know, and I can just feel overwhelmed and I sort of arbitrarily choose and, you know, that’s kind of just a response to just feeling totally overwhelmed. So I think, you said, there’s, you know, there’s definitely information fatigue. There’s a cost to even grappling with decisions. And I think, yeah, that’s definitely something I have in my back pocket. Just make a choice arbitrarily. And as long as it’s…

You know, you can back out of it if it’s just absolutely the wrong thing. You can just, you know, you just get going.

Erika (03:26) I could identify with that. Like the choices, choose a direction and see where it takes you. Yeah. And you mentioned some of the reasons for that, feeling fatigued or overwhelmed or like a lot of times we have these time pressures and like we’re getting a lot of…

Jonathan Tamsut (03:27) Hehe.

Erika (03:43) messaging from our stakeholders that needs to be done yesterday and so make this decision as fast as possible. So yeah, there’s definitely that inclination to make any decision. And I guess sort of the model in that scenario could be described as the leader decides model where you’re delegating yourself as the leader and

Jonathan Tamsut (04:05) Mm-hmm.

Erika (04:07) You make a decision, you see where it goes, and it’s totally valid.

Jonathan Tamsut (04:11) I also think sometimes people delude themselves into thinking they’re making a really well-informed, thoughtful decision, but it’s like, there’s so much complexity here. It’s like, is it really even possible to really, everything, I think one thing is like an engineering, everything is trade-offs. it’s like, often I think people who, I think to an extent, or I’ve seen this,

is people who have quote unquote good decision making are just people who make decisions and then kind of advocate for their decisions. And then people who are perceived as having bad decision making will make a decision and then like openly question whether that was a good decision and be intellectually honest. So yeah.

Bethany (04:49) I am very much an indecisive person. And so I always really struggled with this. you’re just, mean, going back to our conversation on imposter syndromes felt almost like, like I was like, well, what if I make the wrong decision? And so hung up over that. And so one thing that actually helped me was when I read Clean Architecture, there was,

a big message there about trying to postpone any technical decisions or choices to the very last minute possible. But it was helpful to be like, OK, prioritize focusing on core business requirements and then decide on the technical things later. As engineers, love bike shedding, as they call it, on a lot of small things that don’t actually meaningfully move the product in a

great direction anyways. And so that always helped me with how to decide or like when to decide, make decisions. And the second thing is that I always try to optimize for reversal. So what is the easiest decision to like go back out of, which I think John, you kind of mentioned in your decision making process, which I definitely resonate with. I think final two is that there are a few like,

Context of decision-making so like you can make slow decisions or fast decisions effectively. So My decision-making I think is different in say an incident response situation versus a I’m writing an ADR or I am working on a feature that has more time because in a In a incident situation, you have to kind of make fast decisions to meaningfully move get out of that situation. So

It’s all about kind of evaluating what our options are in that scenario and what we need to do. So I think there it’s helpful to just like list out literally all the knowns and then try to say, okay, we haven’t done this. This will help us the most now. And so go after that.

Brittany Ellich (06:38) Yeah, one thing that comes to mind, speaking of…

just making the decision is the concept that I learned of. think it’s from Amazon. They do the one way versus two way door decisions where a one way door decision is really hard to reverse. And so those ones you want to try to avoid that type of a decision if you can. But if it’s a two way door decision, just like make a decision and move forward with it and you can adjust as needed because you know, it’s easy to reverse and easy to undo. And sometimes just getting the decision out the door and starting to act on it is

more important than waffling back and forth if you don’t really have much to compare the options.

Erika (07:14) Yeah, think another element here is having that data and knowing what you’re comparing against or knowing what you’re going for. And it’s a little bit freeing for me to think that you can make a decision without having all of the data. I definitely fall prey to the analysis paralysis and like…

I can’t take any action until I know everything that there is to know. And sometimes it’s like frankly not available or it’s going to take more time to get to the point of fully understanding the problem before try something, see if it works. So yeah, think like knowing that about myself is probably helpful in my own decision-making process.

When I approached Decisions as a team, you were kind of mentioning this to Bethany with the incident commands and the incident decision-making. And we were talking about that a previous week about collaboration on incidents versus collaboration in project work and how it’s a really sneaky way to really reflect the dev lifecycle and a really condensed experience.

And yeah, it calls to mind too, this sort of like undervaluation, I think, of clearly defined roles in team decision making. And when I’ve been on incident calls that have gone really well, people know what they’re doing. They know who’s making the final decision. People know who’s investigating, who’s supporting. know, so I think that that can then…

be taken back into project work or project planning and like used in those sort of slower decision contexts too of let’s take the time to identify who’s who. If we are using a leader to decide who’s that leader and then what is everyone else doing aside from commenting on your architecture decision review, you know, like if you need support like.

identify those people and what they’re doing. So I think that’s a really good call out.

Cool, so another very specific use case for decisions is prioritization. And so let’s talk about that for a little bit. When you are prioritizing work, what do you use to decide what’s the most important and what to leave behind?

Jonathan Tamsut (09:31) So I worked at a startup and we failed. By fail, I mean we basically ran out of funding and had to fire everyone. And it’s interesting because I feel like prioritization is a lot easier when you know what to do, what’s most important. Oftentimes it’s kind of just difficult to even answer that first question.

Like what are the tools I’m using to evaluate the importance of something? So like in the context of this startup, like we just didn’t really know what customers wanted and we never found product market fit. And we had ideas and we tried to validate what had just never happened. And maybe it’s possible that like there just wasn’t ever gonna be product market fit in sort of the space we were working in. Yeah, I mean, I think prioritization is super, super important. And I think when you work at a big tech company where

There are just so many competing interests. You learn the importance of prioritization and what it gives you is focus, which is just so important.

Erika (10:28) So I did look up some frameworks that teams do use for prioritization because I also feel the same way. One of the frameworks that I have used before most often was on this list and that’s the must have, should have, could have and won’t have, where you look at a list of features and tag them as things that…

are required for ship, nice to haves or like cut line. But I’ve always found that to be very subjective and arbitrary. And I almost feel like I need like a pre framework to get to that point. So some other frameworks that people use are this idea of reach, impact, confidence and effort.

understanding for each item, like how many users will it affect? Will they even notice? Will it meaningfully impact their experience? How confident are you in the delivery? And then what’s the level of effort for that feature? There’s something called the, I don’t know if I’m going to say this right, the Kano model, Kano, K-A-N-O, which…

like you were saying, specifically focuses on customer satisfaction. There’s cost of delay, which is focused on the economic impact of prioritizing or deprioritizing a feature and uses return on investment metrics. And then there’s value versus effort, which uses a two by two matrix where one matrix, one.

Axis is value, the other is effort, and you place items along that matrix using those two guiding principles. And then there’s also weighted scoring, where you identify your own criteria and then assign weights to different issues. So yeah.

Jonathan Tamsut (12:09) And I think, know, like, there’s no, like, I feel like there’s a, like, I always end up in the sort of a philosophical sort of hole where I try, I mean, I try not to because I think if you get too philosophical, you won’t be productive. But it’s like, you know, same, same ultimate as a quote, it’s like the most important thing is deciding what to work on because, you know, it’s like the startup, like if you’re working on a set of features,

really, really hard and you’re executing really, really well, but they’re just not features customers want, you’ll fail. it’s sort of like, know, yeah, I do agree. Like, you know, I think, right, in hierarchical corporate structures, sort of these deeper questions get handed down, like priorities get handed down, but like, you know, it’s like central to decision making. I’m always just like, well, why are we even working on this? Like, how do we want to shape the world? What world do we want to live in? And I think…

I think those are the questions that are just interesting to me, but also I don’t know the answers to.

Erika (13:04) I’m laughing because I’m not at all shocked that you fall into philosophical rabbit hole all the time.

Brittany Ellich (13:10) Very classic, John. ⁓ I like the idea of exploring some of those other models that you talked about, Erica. I also use, I think I’ve called it the Moscow.

Erika (13:12) Yeah.

Brittany Ellich (13:21) ones in the past, must, should, could, won’t, but that doesn’t necessarily take into account things like the effort to complete things. I have found, especially at GitHub, one of the things that I was a little bit frustrated on early on at GitHub is I feel like we don’t have a ton of process and that’s…

part of the magic of why things happen. Like it’s very low process and there’s a lot of trust put in engineers, you know, to prioritize things. And early on I found that really frustrating and now I think I’ve finally found the groove maybe just with, you know, with the team that I’m on. I think I’ve got some really good.

product managers to let me know, like, okay, these are the things that customers care about. So think that helps a lot. But I still use that must should could won’t matrix now. I think I saw Belinda using it and she did a great job on a project that I was on and I was like, wow, this is perfect. But I find most of the time we can only really prioritize the musts and some of the shoulds. And usually the must is like, what do you need to have to like get through this critical path of this feature?

get to a should but could and won’t just means that they’re probably not going to end up happening. So I think that you know keeping in mind that that effort is probably helpful because I feel like that’s missing from that matrix but is helpful.

Erika (14:32) Yeah, I feel the same way. think the Moscow method is very helpful as a communication tool, but maybe sometimes lacks, like I said, the…

like the information that goes into it. And sometimes it’s a product decision that’ll say, like you said, the customer needs these. These are the features that we won’t ship with or ship without. But sometimes you as an engineer are asked to prioritize. And in that case, you have to take in mind some of those other factors. So yeah, I’m also interested in especially the…

Reach, the acronym is RICE, the Reach Impact, I can’t remember the rest of the letters now. Reach Impact Conference Effort, thank you. That one, and then the two by two matrix with effort and value. So I think I might try out some of those in my prioritization.

Jonathan Tamsut (15:12) Effort. ⁓ Confidence effort.

And well, this, I find this interesting, but this may be derailing the topic. Feel free to bat me down here. But I feel like the social dynamics of decision-making is also just really interesting. You know, a lot of times in a hierarchy, people’s opinions and input is not weighted equally. And for a variety of reasons.

And I think I always find that interesting. There’s also, and you know, people get incredibly emotional in the process of decision making. There’s, you know, I would argue maybe we all do, right? We all want some level of validation. And it’s also just like hard. It’s, it is hard just proposing something and then having people in a totally like respectful and objective way just be like.

I know, no, no, this is wrong, this is wrong, this is wrong, and make valid points. There always is a part of me that’s like, God, this hurts. And I know I shouldn’t be, because it’s just like, this is sort of like civil discourse. But yeah, think that’s, and you know, people’s egos certainly are involved in a lot of these decision-making processes.

Erika (16:32) Yeah, it calls to mind something else I was hearing about, like the use of AI in software development and the idea that, like…

One thing that’s really important in this phase of AI adoption is recognizing your own role in using the AI assistants and recognizing that your taste is actually really a valuable piece of the puzzle. And if you’re using AI assistant, like,

It’s kind of a coworker, it’s kind of a collaborator, but like, I mean, people have wonderful, wonderfully creative descriptions of the personality traits of AI coding assistants. yeah, like knowing how to respond, like, do I reject or accept this? Like, how do I respond to you? Yeah, it’s not exactly what you’re talking about. I think you’re also talking about like hierarchy, but like…

Co-pilot doesn’t, co-pilot for example, like doesn’t even have a role on the team. And like maybe the point to this discussion is like, don’t elevate co-pilot to the, you know, level of CTO in your own life. Like recognize that like, okay, like I am still like in charge here and my role in that development life cycle is to like give you more guidance or like.

Jonathan Tamsut (17:42) Hmm.

Erika (17:53) make sure that I’m still thinking about like the output that you’re creating.

Jonathan Tamsut (17:57) Yeah, I also do. Yeah, I mean, and I think that’s actually really interesting. And like, certainly it’s like, it’s like, you know, what is AI good at? What is, what are humans good at? And I wonder if AI is just better at making objective decisions when, when given a collection of evidence. You know, it’s like, I haven’t really used AI for like decision making. Like here’s, here’s, here are all the countering points. Tell me what is best and, you know, and explain why. And I do wonder if like,

sort of a benevolent AI overlord decision maker is something that we’ll see more of and that’ll be useful.

Brittany Ellich (18:29) I think that kind of goes to what you were saying earlier, where sometimes it’s easier to just make a decision. And if you’re using an AI tool or just asking a friend, like, hey, which one of these would you choose? Either way, just having the decision made and then committing to it is usually the most difficult part, even if you already know all of the weight going into the different options.

Jonathan Tamsut (18:33) Mm-hmm.

Erika (18:47) Sure.

Well, I have one more question for the group before we move on to the ending segment. And this is about a very specific decision.

context, but it seems pretty relevant in a lot of projects, a lot of engineering teams use architecture decision records or ADRs. And I’m curious what our experience has been with those. Have you found them helpful? If so, in what contexts? And yeah, what…

what do you find most valuable in that process, if anything?

Bethany (19:21) I think at GitHub, I mean actually not just GitHub, I think every company I’ve worked at has used ADRs not quite correctly. It’s very interesting, I feel like ADRs often get turned into…

not necessarily a decision record, but a pre-decision record where you’re actually architect, like mapping out the architecture of what you’re actually wanting to build and getting consensus around that and then committing that as your like decision record. But in general, I love ADRs. makes me, it’s almost like writing a pro con list for developing, I think. So thinking of all the…

solutions to solving a thing or architecting a thing and then just putting it on paper trying to defend each one as much as possible and then choosing what seems best or has the least impact or whatnot. So I really enjoy them. I do think as part of a process for engineering it’s been a little difficult to insert into like a team flow because it’s like

does this require an ADR or does it not require an ADR? And then you get a bunch of opinions on that or ADRs that are just kind of stalled because there’s not consensus on what is being decided and stuff. So I’m interested to hear your takes on ADRs as well.

Jonathan Tamsut (20:38) And Bethany, so you said people use them incorrectly. do you just mean that they should be more like showing the decision making process as opposed to just like an artifact of the final conclusion? that what you basically meant?

Bethany (20:54) yes, and I guess I didn’t mean incorrectly. I don’t think there’s necessarily a correct versus incorrect, but I think, at the end of the day, an ADR should just serve to say, Hey, this is why we made a decision. And here is the context around that decision. If anybody is coming back and saying, why was, this happen? But to be honest, I don’t notice many people go back to ADRs. Most of the

Jonathan Tamsut (20:58) Okay.

Bethany (21:16) activity around an ADR seems to be like before it’s merged. And I think that’s the interesting part that it doesn’t seem to really, at least in my experience, serve as something to reflect on, but rather it’s something, it’s like an architecture design pretty much. And so I know on my team, there’s been a lot of suggestions for switching over to maybe an RFC, which is a request for comments prior to making an ADR or even getting to the

ADR stage. So it’s really nuanced because it’s just like a change of acronym it feels like, but it almost prioritizes, hey, this is just in the planning phases and I want people’s thoughts around this rather than, hey, I’ve decided this so I want to merge this, which I think, John, to your point about people feeling very emotional about decisions, it’s easier to say, hey, I want.

your comments on this or your feedback on this to make folks feel involved in that over ending decision rather than, I’ve made this decision and now I need your approval on it effectively.

Jonathan Tamsut (22:16) Yeah, and I feel like one concrete example of where this tension arises is ADR addendums. There’s been times where during the project you realize your approach won’t work. Do you write an addendum? And sometimes it feels silly because you’re like, we all kind of understand what we’re going to do, but maybe to a future reader, having that addendum will be useful.

Erika (22:37) Yeah, I definitely don’t share your love of writing ADRs. And I’m probably part of the problem of people who like want to get started and would rather write code than write documents. But I definitely agree that I think given the right scope and the right like purpose, they can be super helpful. I think in my mind like

something else that I’ve seen to sort of like support ADRs as something like a pre-retro, like thinking of all the things that could go wrong as an outcome and then like going back and architecting for those. Because yeah, I think like a lot of times you want to capture what’s known and that’s actually not the most interesting part. Like the most interesting thing that you can capture is like,

Okay, but how are we handling these edge cases and what is still unknown? what are, yeah, it’s like valid to call out. These are actually things that we still need to figure out. So recognizing those as well.

Jonathan Tamsut (23:33) By the should we define what an ADR is to people?

Brittany Ellich (23:38) Probably

Erika (23:38) Would

Brittany Ellich (23:38) a good call.

Erika (23:43) you like to do that, John?

Jonathan Tamsut (23:44) Yes, so an ADR stands for architecture decision record and I mean as we’ve kind of discussed maybe there’s not a concrete definition but it’s essentially a document that is iteratively created before sort of the initial phases of a project that outline the architecture of the project and it could have

multiple possible architectures and kind of compare and contrast them and ultimately make a decision on what architecture is the best and list other things like context and mitigating circumstances and observability, et cetera. And they’re kind of just like the bedrock of how projects, engineering projects are trying to get hub. For large engineering projects, we typically started with creating an ADR and there’s a feedback process and then it’s finalized.

Brittany Ellich (24:28) I think too this might be a…

Artifact of the fact that like we don’t have a ton of process at github is it I think it sounds like a lot of teams use them for different things like For my team usually we create an ADR with a couple of different options and then we use that as a starting point for Hey, let’s talk about this and figure out what decision we should make so it’s really great for things where you’re trying to weigh the different options and decide on a decision and then folks comment on the document and then you know, save the the document and What decision came out?

of the discussion around it into that ADR. And I actually refer back to them pretty frequently just because I feel like they’re pretty helpful for seeing, okay, yes, this is why we made this decision and why we opted against this other option. And I think that is a really great background usually because just like gathering the background knowledge of like where the system is today and making sure that that’s present in the document is helpful. I also feel like this is just one of the areas where engineers are.

like most likely to actually document things. Which, you know, everything’s pretty, you know, comically under-documented in general, pretty much everywhere I’ve always worked. So having something is usually better than nothing, better than trying to just, you know, struggle through reading the code base and figuring out where things are at. So I personally like them.

Bethany (25:49) I’m curious, how do you just read through all the ADRs that you know of, or how do you map a decision to maybe some code you have questions about, or does your team have a process for that?

Brittany Ellich (26:02) Yeah, so if I’m researching a new space, I’ll usually search our shared repository or use our knowledge base. Knowledge bases are our thing, right, Bethany? Yeah, they’re, okay, cool. Yeah, we have a shared repo where we keep all of our docs for like all of our team and we have a knowledge base. So I’ll go in and ask.

copilot and attach the knowledge base and be like, hey, what are all the relevant documents related to this? And it usually also turns up some ADRs. So if I’m curious about why something exists, then usually I’m only doing that if I’m trying to figure out a new space. They’re not necessarily as useful otherwise, but I think it’s really helpful for getting onboarded and getting up to speed in a new area of the code base or on a new team.

Bethany (26:46) Yeah, I can definitely see AI being really good for searching through ADRs and kind of parsing through those and showing, flagging the relevant ADRs. That’s cool. Thanks.

Jonathan Tamsut (26:56) Yeah.

Erika (26:57) but also somewhat dangerous

if you’re getting outdated information and it doesn’t tag it as something that’s been overwritten.

Brittany Ellich (27:03) Yeah, mean, that pays, that I think exists regardless of whether or not there is an AI tool being used. I think you always have to read any documentation with, you know, a mind on when was this written and is this still accurate? You know, if it’s two years old, then, you know, read it with some heavy skepticism, but there’s usually still some relevant information, hopefully. If there isn’t, then you’re probably working in an area that changes very quickly.

Erika (27:15) Yeah.

Brittany Ellich (27:27) So good luck documenting anything.

Jonathan Tamsut (27:29) Hmm.

Erika (27:30) Thank you all so much for sharing your thoughts and experiences and opinions. To wrap us up today, I have some developer jokes, which are most often found in written form on the internet. But I’m going to read them out loud today in my best comedic voice. And I’m expecting some serious groans, but I…

Jonathan Tamsut (27:47) Am I allowed to audibly groan? that…

Erika (27:54) I think they’re fun anyway. I know it was Mother’s Day yesterday, but these are kind of dad joke, dad joke adjacent. All right, and we’ll see if anybody can get the answers to these. All right, the first one is, what’s the second movie about a database engineer called? Jonathan?

Jonathan Tamsut (28:09) Yeah, as the database engineer, I should get this.

Erika (28:11) It’s called the sequel.

Jonathan Tamsut (28:14) Oh, that’s

great. I’m going to I’m going to take I’m going to bring that to my team.

Brittany Ellich (28:15) Ugh.

Erika (28:18) It’s okay, I’ve got another one for you to redeem yourself. Why did the SQL developer leave the no SQL bar?

Bethany (28:27) because there was no tables.

Jonathan Tamsut (28:28) ⁓

Erika (28:29) Yeah!

Jonathan Tamsut (28:30) that’s so good!

Erika (28:33) Okay, okay. Why did the computer keep sneezing?

Jonathan Tamsut (28:33) You

Brittany Ellich (28:37) Is that a virus? Nice.

Bethany (28:37) virus?

Erika (28:38) Yeah.

Jonathan Tamsut (28:39) and

Erika (28:43) Okay. And Brittany, this one’s for you. What did the proud React component say to its child?

Brittany Ellich (28:48) I don’t know.

Erika (28:49) I’ve got to give you props.

Brittany Ellich (28:50) I like that one. That was good.

Erika (28:52) That’s all I’ve got for now.

Jonathan Tamsut (28:54) I-

Brittany Ellich (28:54) I am

Bethany (28:54) Does

Brittany Ellich (28:55) so grateful.

Bethany (28:55) your network? I sure hope it does.

Erika (28:57) If you’ve got any good jokes, listeners, send them in and we can include them in a future episode.

Jonathan Tamsut (29:03) Yeah, was, Nikki and I were trying to come up with a term for like our fans, like what our fan name, fan name should be. And we, yeah, just our parents. But our parents are

Brittany Ellich (29:11) I think it’s just our parents.

Erika (29:12) Yeah, at this point.

Bethany (29:15) Shout out mom, shout out dad.

Erika (29:17) Well, for all you fans, thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky, our social media app of choice, and most of all, share with your friends. Until next week, bye-bye.