MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike, and I am hosting again today. With me, I have Dave Brady, Thomas Wilcox, Justin Ellis, Vivian Moore, and Kyle Archer. 


And I'm going to start by sharing, not a personal story, but one I read. Actually, I'm going to share two things. Well, first, a little bit of context before my story. We've been talking for several weeks now, several episodes. We're going to continue on our final, final episode talking about the NASA root cause analysis that they did─I think it was back in 2012─talking about things that led to some institutional failures that they needed to pivot from.


And I'm going to start by talking a little about the military. I've not served in the military, and, frankly, I haven't wanted to [chuckles]. That's a tough thing to do, you know, all of the risk that's associated with it, all of the risks of PTSD, and so on. But I give respect to anybody who has served, because, you know, that's a real thing.


The one thing that the military does do is they have a very rigid hierarchy, so everybody always knows who they report to, and that's pretty universal, I think, in militaries, you know, successful militaries. They have this rigid hierarchy. And so, there's this question: why do they have such a rigid hierarchy?


And rather than answering that question, I'm going to share another thing that I read, and it's brief. I read...I don't know if story is the right word. I did an analysis of counter-cultural communes back in their heyday, back in 1970s. The opposite of the military hierarchy, right? As far from it as you can get.


And in one of these particular communes, there was one where they said, "We're not going to have anybody married to each other, free love, you know, and everybody just be with whoever they want." And they interviewed somebody, and he said, "There is nothing more lonely than every night having to find a new partner," you know, like, begging them to spend the night with you. And I thought that was fascinating. 


In one case, you know, you have this rigid hierarchy with all the constraints and all of the potential downsides that come with that. It's hard to be in an environment with such a rigid hierarchy. I report to this person; I do what I'm told. But on the flip side, if you have no hierarchy and no commitments, it can be even more crushing. And almost all of those societies have fallen apart. They were experimental, and they fall apart because there is that lack of commitment. And the social structures just deteriorate, you know, you don't see very many.


There do exist some communes, but most of those experiments that happened in, like, '60s and '70s have fallen apart, and they don't exist anymore, or exist only at extremely small scale. And the ones that did tend to exist are those that look very hierarchical, much like monasteries, where you have people with a strong dedication to a cause, and, you know, single-minded, and not that kind of social conflict.


Once again, they've ended up looking more like the military, and that's fascinating. It says something about what is effective in running human structures. Also, my heart broke for that poor guy, the loneliness. He said, "There's nothing more lonely..." and you picture just kind of begging for somebody to care enough about you, and you have to do that every day.


Coming back [chuckles] to this NASA study --


JUSTIN: I was thinking of how you're going to relate that, you know, begging for somebody to relate to you at work, or something like that [laughs]. 


MIKE: No. So, NASA's final element in the root cause analysis...and I'm going to read this just straight verbatim from their report, because I think it's interesting.


They said, "The final root cause is closely related to the fourth and is driven by the technical and organizational complexity. Space systems are highly complex and very sensitive to small uncertainties. This complexity requires in-depth penetration and understanding, where small technical glitches result in major problems. The technical complexity leads one to think that the technical complexity must be matched with organizational complexity." 


I'm going to pause there for a second. So, they have this innate technical complexity, right? You're building a rocket. It's complicated. And you might think, "Okay, so my organizational structure needs to be complicated." You have 20 bosses, right?  And I go back to what they said, "We know that when managing the organizational complexity becomes as large as or larger effort than managing the technical, then the product success is in question. Simplicity is the pathway to product success, both technically and organizationally."


Now, we tend to focus a lot on technical simplicity. Well, we know the simplest solution that's almost certainly the best. But we don't always think about the organizational simplicity.


DAVE: Mike, I love that you hit on this. Last week, when I hosted when you were out, one of the things that I mentioned is that, at Microsoft, they did an in-depth longitudinal thing on, like, what's likely to cause a bug and how severe and difficult is it to fix? And the dominant variable was how far away in the organization the person who fixes it is from the person who wrote it, or the two modules that have to interact.


And they measured it by how many layers up the hierarchy you have to go to get to the common person to take you back down to approve this other person working on your thing, and it's exponential. Somebody on your team, pretty straightforward. Somebody on the next team over, kind of difficult. Somebody in the next department, very, very hard. And if it's in another business unit, forget about it. You might as well just open a ticket and pray.


MIKE: You're saying if you don't have that person that you know and trust and can rely on, things fall apart.


DAVE: Mm-hmm.


MIKE: It's fascinating to me how much human aspect there is to software engineering. We have talked about technical stuff. Sometimes we've gone deep into unit testing here, right? But here we come back, and this is going to be a very human-focused episode. We're talking about that idea of organizational complexity driving, as they said at NASA, product success. Product success is in question when your organizational complexity grows.


So, Dave, you mentioned the study at Microsoft [chuckles].


DAVE: Yeah, it's straight-up complexity and the hierarchy. And if you think about hierarchy like a snowflake or a star graph, it becomes fractal, right? You've got these two great big branches, and then lots of little medium branches, and then each one of those has fine branches. And by the time you're down four levels, it's just, like, fine little hairs. And when one little hair over here has a bug in some software written by a little hair over there [laughs] and you have to get the head brain completely involved in...


At CMM, we had that one route between engineering and the database team. You had to go to the C-suite because the DBA was...sorry, the VP...what are they called? CTO, that's the word, was a founder and owned part of the company. And so, the CEO had to be polite. He couldn't just go in and say, "Fix this, or give them what they need." It was like, "Well, I've got to go have an argument." So, you had to go all the way to the CEO, and it definitely impacted things. There was a lot of ceremony between engineering and database because there had to be. They were basically in a different company. They had completely different objectives.


JUSTIN: Wow. So, when you talk about organization, and I remember when I was at big organizations, it was organized like that, that there was a database team. There was a front-end team or a back-end team. And they often didn't play well together because they, frankly, had different objectives, and those objectives weren't necessarily product or customer-centric.


Some places I saw, they were like, "Oh, we're going to make, you know, our whole goal is to make our database normalized," or something like that, or optimize space, or optimize cost, or something like that. And that didn't seem to work out very well in those cases. There was a lot of bureaucracy, and that's where you're going up the chain and coming back down the other chain and trying to communicate and things like that.


Whereas other places I've seen that were very successful, and maybe this contributed to their success, but they owned a product or owned a feature in the product of the company. And their success was determined by how successful that product was. And that product was a vertical stack: frontend, backend, database, you know, even all the way back to backup, and everything else like that.


And so, all these people with different disciplines were all moving towards the same product, and their success was based on that product. And there was a leader who was leading that group: frontend, backend, database. And that person kind of had to have everything in their mind because they owned the entire stack.


And it seemed like those types of situations were less bureaucratic. You know, you could get answers from one person about that product. And so, the C-level, the CEO suite, they could go to that one person and say, "Hey, what's up with your product?" And that person knew exactly what was up with their product because they were focused on that product's success.


MIKE: That's interesting. We're actually doing some efforts at structuring our department in engineering to map into customer outcomes here at Upbound, and not just the same level across the whole Upbound group, for much of the same reason. We want to be focused on what matters to our customers, customers broadly. We work with customers and partners. Both of them are our customers. 


And the goal is to align those experiences, make it simpler. You go to one person, "Hey, what's going on with, you know, customer acquisition and, you know, with the customer application process? Is that working right?" You got one group that's all focused on that. That's what they care about. And we're very early in the process, but that's the goal.


I'm curious because I think that every set of lines you draw in an organization, you know, every way you divide it up is a different set of walls that isolate people from each other as well. Every inclusion is also an exclusion, so, you know, there's trade-offs with all of those. And it sounds like you saw a lot of success with that, Justin?


JUSTIN: Yeah, and I'm glad you mentioned those walls because you do want to take advantage of all the database people, like, working together in some sort of unified architecture. Like, you don't necessarily want, you know, different databases used in different parts of the organization because then you have unnecessary complexity that doesn't necessarily cross team borders. But sometimes you do want different...I don't know. You want that discussion. You want all the database guys talking to each other. 


And I think...I can't remember if Acima had this, but it was the guild structure, basically. All the database guys were part of a guild, and they got together once, you know, twice a month, or something like that, where they would talk about what was going on in the database. And there was a front-end guild, and all the front-end guys would get together and talk about, you know, the different architecture decisions. "Okay, today we're going to start using this new TypeScript library, and we want to use it across the organization, and here are the benefits, and here are the minuses," and things like that. 


And so, there was, like, this...not necessarily shadow but another structure that wasn't your manager structure, but it was a kind of professional structure where you can get together and talk about those things that...And you could present at it, and you can make proposals. And it was actually really kind of a fun way to be part of the company that was, like, outside of your product and, you know, grow professionally. So, it was kind of a cool side channel.


MIKE: It does sound fun. You know, it's great to be part of a thing. "Hey, I'm learning. I'm doing stuff together." Do you feel like...Well, and I think it's almost inevitably true. Do you feel like the structure and maintenance of the database suffered in that kind of environment compared to one where you have your...how do I put this? I'm thinking about the Soup Nazi from Seinfeld. You got that guy for the database, you know.


JUSTIN: [laughs]


MIKE: I don't want to make a Nazi comparison because...Nazis.


JUSTIN: [laughs]


DAVE: It's a...kids, that word did not used to be problematic [laughter]. It wasn't as awful. It used to be humorous [laughter]. The word used to not be problematic, not the actual people. 


MIKE: It's like, I think it's just pretty much always been a problem with Nazis [laughs]. 


DAVE: Mm-hmm. Fair. Fair.


MIKE: That idea of, you know, having somebody who militantly protects their domain means that's protected. But [chuckles]-–


JUSTIN: In my experience, it does depend on the leadership of those groups, you know, and depending on if they're a very strict leader or some...I don't know, it depends on their focus, right?


But the most success that I've seen is the second one, where you have groups focused on a product vertical and a guild that exists on the side, because it puts your focus on, hey, we need to, like, do stuff that makes the company money because we all want to get paid at the end of the day. And the better we can make the product, the more likely we'll get paid at the end of the day. Certainly not a guarantee, right [laughs]? 


But you get that focus of, you know, hey, what I'm doing has actual effect to customers and to the bottom line of the company. And I think that is actually a really good motivator for people. And that motivates me certainly, is like, hey, what I'm doing is making life better for my customers. It is resulting in a better bottom line for the company. And, hopefully, I will be recognized by my leadership team and, you know, paid better for X, Y, and Z reason. 


But, you know, that is a big motivator for me, and I think it's a big motivator for a lot of people, where they can do something that causes a direct effect. And you can see that, in my experience, if you're part of a product vertical and you're all pushing together as a team.


MIKE: Absolutely. I know I feel that way. It's different from saying, "Yeah, I think that my work helps customers," than saying, "I helped Jenny," right [laughter]? I talked to that...I know there's that person that I know. There's a person that I helped. And even if you're not working individually with those customers, you're talking to people who are talking to the customers, right, if you're focused that way. And it does, it changes the way you think about your job. I agree from my personal perspective.


JUSTIN: Yeah. So, going back to your complexity, initial complexity proposal, where NASA found that, like, the more simplified structure, I don't know which is better in terms of that. Is the product vertical more simple, or is, you know, all the database guys together more simple?


I think the product vertical is more...I don't know. It could get more complex because you can get siloed really easily on the product vertical. And you could go away from, like, what the company decides in terms of technology. And so, you got to be really careful, if you are going that product vertical focus, to have a strong guild system that you are all in agreement, or at least you're having very good discussions about what technology you want to implement at that company.


MIKE: Fascinatingly, I was having a conversation about team structure earlier today, and I pulled up a quote from a book about it. And I still got it up on my phone [chuckles]. Team Topologies. I love the book. It's been...I read it several years ago, and I go back to it all the time because, working with an engineering group, you think a lot about, well, how do we organize, and what are the pros and cons?


We could probably do a bunch of episodes talking about the content of that book. But, in particular, they talked about the kinds of team types that tend to form. And they call out that there's four kinds of teams that tend to effectively form, and they say something about how those should align. And this goes to this organizational complexity. I think it's probably worth reading. 


They say the four fundamental team topologies: streamlined: that is, like, these verticals we're talking about. Enabling: that is a team that's dedicated to helping out the other teams. Complicated subsystem: it's when you have a team that, you know, you've got that really messy old system [laughs] that you just have to manage independently because only a few people have the expertise. And platform: platform are thoughts that, you know, we have something that supports everybody else. We're the foundation everybody else builds on.


They say those four types should act as magnets for all team types. All teams should move toward one of these four magnetic poles. That is, we should prefer these types and aim to adopt the purpose, role, responsibility, and interaction behavior of these fundamental types for every team in our organization.


Simplifying the types of teams to just these four helps to reduce ambiguity within the organization. As was identified by Zhao Luo and colleagues in research published in 2018, "Reduced ambiguity around organizational roles is a key part of success in modern organizational design." See, that ties directly to what we're talking about here.


A large or mid-sized organization is likely to have one or more teams of each fundamental topology. Multiple stream-aligned teams are the starting point, but an organization may also have several platform teams, a few enabling teams for different purposes, perhaps one addressing CI/CD and a second addressing infrastructure architecture, and if strictly necessary, one or two complicated subsystem teams. 


That's what Team Topologies has to say about this. I would like to call out, you say, "Well, is that right?" Based on the research, and they said, "Well, yeah, you should have something like those vertical teams, and some other teams that support that. But the important thing is that you have clearly..." So, I'm going to repeat their quote here: "Reduced ambiguity around organizational roles is a key part of success in modern organization design." 


So, you clarify what the team is responsible for. You make sure that you have supportive teams supporting those verticals that are supporting the customer. And you make sure everybody knows what their role is, so it's unambiguous. That's their recommendation for reducing organizational complexity. So, there's a take. Thoughts?


DAVE: I have a thought, but it's a really weird fractal jump into software design, so I want to give people a chance to talk about teams for a minute, because it's going to be, "And then Dave took the podcast and departed the text [laughs]."


MIKE: Well, you haven't read the book, but the fundamental premise of the book is that you cannot separate organization from software design.


DAVE: Mm. Okay. Fair. Fair. Well, let's dive into it then a little bit. One of the things that I've been on about lately is something that I originally got from Katrina Owen and Sandi Metz, which is that good refactoring will reorganize your software around ideas. And then when you read the code, you can literally watch the idea moving through the codebase, which is great.


But by default, we tend to refactor to structure. We pull out, oh, this code is identical to that code. Let's extract it and put it in a method. Well, you just split an idea in half, and you put one half here, and you put the other half over there. And these two things get to use their half of that idea, but they get to share this idea, and it's lost. You've lost the idea.


Sandi Metz makes the radically heretical claim that nobody knows what maintainability is. Nobody has a good metric. You come up with a good metric for this, and you will eat rich in the software community forever because we still haven't solved it. And there's good money being made attempting it.


But she uses kind of an unmeasurable heuristic, which is understandability. If I look at a piece of code and I can quickly understand it, if I look at a line of code and the lines around it, can I see what's different between these lines of code? Can I see what's similar? I talk about this with, like, RSpec, you know, like, block of code, you know, a spec, a spec, a spec, a spec. I love having a lot of repetitive code that you can look at and go, "Oh, this part is all the same. That is the one piece that's changing," and, "Oh, look, that's the name of the spec."


Refactoring to understandability is hard to do if you refactor your code to platform, to hierarchy, if you basically say, "I'm going to write the database layer." And the reason we end up saying...this is where it gets really heretical on my part. If you have requirements coming in, somebody went out and talked to the customer, or to the CEO, and they said, "We want to do this." Then they went off and had a meeting with one of the tech leads, and they engineered up a solution to it. And then that gets handed down to a team lead, and it gets divided up into Jira tickets. 


And it finally gets to the developer, and the developer says, "Well, what about this?" And nobody knows, right? It's a waterfall, right? This waterfall design thing. And the developer says, "Well, what about this?" And the developer was the one who spotted that we're building the wrong thing, and we don't know it yet because we're downstream waterfall.


What is my defense as a developer when that happens? I'm going to step back and say, "Well, I'm going to write a generic database adapter that will solve however business wants to do it, and now I'm writing a platform." And so, years and years ago, I told people, "Don't write a framework. If you think you're writing a framework, you have had way too much caffeine, and you are probably solving the general case of a problem that you don't know the solution to your specific case yet. Go solve your specific case." 


And the specific case, that's your vertical line, that's your stream-aligned teams. I'm going to say the word pod, because that's a buzzword here at Acima right now. Cross-functional teams, you know, there should be somebody in your pod, in your working group, who can say, "Yes," to any problem that team has. "I need to fix this in the database." "Got it. I have the access to do this." "I need more network bandwidth." "Got it. I'm the DevOps guy in this pod." 


Make it so that there's nothing that comes up that everyone can say, "No," but nobody can say, "Yes." Make it so that people can say, "Yes." That pod is a team structure, and it is the exact opposite, in my opinion, of a platform team. It's almost like a vertical slice. Give me one person from each layer of the cake, and now I'm going to send them off. And you guys have passwords to everything you need. Go make some business happen. 


That was a long ramble down a kind of a weird thing, but that's what team structure to platform lived in my brain.


MIKE: And you didn't say that there shouldn't be platform teams.


DAVE: No. Yeah, there actually should be. Just every team in the company should not be a platform team. That would be one thing. There's four types. Please don't take this and say, "Well, pick the one you like, and now everybody's in that team." That would be a terrible decision.


MIKE: No, there's strong emphasis there that you should have most of your work organized around customer outcomes. And then you have dedicated people toward the systems that need to support that, you know, as support, right? As support for the main work that you're trying to get done.


WILL: I'll tell you, like, I've worked at...I worked someplace where they had implemented something very similar to that, and I like it in general, right? Because, like, right now, I've spent, like, literally my entire day, like, knocking heads with people trying to be like, "Hey, I need end-to-end ownership of this thing. We can't just pass it off and say, like, "Well, my part works, so I'm going to write a ticket for this team, you know [chuckles]. And I'm going to write a ticket for this team, and I'm going to make this other team validate it. And I don't know or care whether, like, the actual soup-to-nuts process gets done. I'm just going to do my end and bail." And I've been twisting arms and hurting feelings all day long.


But one thing that I did notice where...I worked someplace else where they did these domain teams, right? And they had a representative from each of the subgroups, right? So, you could solve this domain problem, soup to nuts, and everybody could do it. And one of the issues that we ran into, and just, you know, what I thought of, because I like the idea, but one of the issues that you have to deal with is, it's really hard for a lot of developers to succeed in that environment because you are an army of one.


If you're working on a platform team, you've got other people who know the platform, and you could reach out. And you can ping-pong around, you know, you could bounce ideas off them. Like, "Hey, have you seen this?" or that sort of, like, collective knowledge around a platform team. But, like, if you are a mobile app guy, right? And I've got a web front-end guy, and a DevOps guy, and a web back-end guy, and a mobile app guy, and we're all doing our thing. Well, if you don't have the answer to the problem flat out in your head, if you're an army of one, you're in a really tough spot.


And if you are a junior developer looking for mentorship and you just sort of get parachuted in with a bunch of senior devs, where it's just like, "Hey, buddy. Where's my backend? Hey, how you doing? This thing's not scaling very well. We're getting a lot of outages. What's going on?" And you're sort of like, "I don't know," you know. And so, that sort of development becomes really difficult because you are...I mean, like, I love the idea of a pod, right? 


I love the idea of bringing together the people you need to deliver a customer outcome, right? That I love. But you're never going to be out of the platform model because you're always going to have people. You're always going to have senior platform engineers that ought to be reviewing your code, right? I, as a pod member, I don't know, looks good to me. Ship it. It gave me back a 200. Let's ship this thing. Let's go. And, you know, the platform might have more refined [laughs] and subtle requirements for a good outcome than, like, I don't know, man, 200, let's roll [laughs].


MIKE: One thing interesting that Justin brought up before you were able to join, Will, is the idea of guilds that he's seen in a previous company he was at, where the people who had a specific focus, like all the database people, would get together in this guild and meet periodically, so they could swap expertise. They're the person you can reach out to, so you don't have that army of one problem so much.


JUSTIN: Yeah. And related to that, there was the guild channel, and I think this was actually more important than the periodic meetings, is, like, there was an active guild channel on Slack, or whatever communication channel you have. And people were chatting there every single day, multiple times a day, and they were helping each other out.


And it goes back to...there's kind of two types of leadership that you have in a company. You have your managerial leadership, and then you have the technical leadership. And the technical leadership exists in a guild where you have guild leaders who are ensuring that your guild is healthy and that there's communication and that they reach out to people who are struggling. And I would hope that a company that has that sort of structure, if they're trying to understand how things are actually getting solved, that they would look at both of those channels, and they would understand that the guild leadership is almost as important as the product leadership. 


WILL: I mean, in the end, somebody's got to review code, you know. Like, you got to have a code review, and so you have to have, like, I don't know. I hesitate to use a code review as a sort of, like, leadership, team building, development sort of exercise. Like, it's fine, and it's good, and it's necessary. But it's not really a substitution for, like, okay, I am going to mentor my junior developers via code review; that's a pretty...I don't know, not -- [inaudible 30:14]


JUSTIN: Yeah, I --


MIKE: It's a little late in the process. It's late in the process, right? If you're mentoring after the code's already written, then you've missed an opportunity.


DAVE: There's a soapbox that I've been railing at with our team, which is we've got some faults with our agile process. Our standup meetings run really, really long because people are just belaboring all of the status that they're currently in. "I worked on this, and I'm having this problem. What do you guys think about this?" 


And I'm like, "Tell me you're not pair programming without telling me you're not pair programming." Because if you were pair programming, everybody would know what you were doing, and all you would need to report in standup is your coordination. "I'm going to touch this module today, and I'm going to deploy it." And somebody else can go, "Oh, I'm touching that." That's standup. "Yesterday I did this. Today I'm doing this, and I have a blocker with this." And that's it. You don't need status. 


You can look at so many things...and, like, mentoring the new folk, if you're not pairing, then you're mentoring them in the least efficient way possible, which is code review. It's, you know, "Go spend days writing this; check in some code, and then we'll tell you what you did wrong, and you can cycle back." Versus, "Sit next to me, and let me show you how to peel a clean shaving off of this piece of wood," you know. I switched from code to woodworking, but you get what I mean.


MIKE: Yeah. Well, you say woodworking. You switched to talking about an apprenticeship-type structure for teaching.


DAVE: Yeah. Yeah.


JUSTIN: So, my first real job, the day I turned 16, I actually got hired by a woodworking shop. And, man, I was at the bottom of the totem pole. I was sanding every single day. I'd come home with, like, sawdust everywhere, and it really sucked. But I was working with people and learning, you know, hands-on with people, literally hands-on. And it was a good experience with that regard because you really got to know that other guy. And, like, you started to learn how to fit pieces together and what good wood looked like and how to stain. There was so much staining, oh man [laughs]. 


But I wish we could go back to...that kind of pair apprenticeship is applicable across all sorts of industries, especially the software development industry.


WILL: I believe...it is my, like, sincerely held belief that the software industry has been like is now, and always will be intrinsically...engineering in general, right? Engineering in general is that way. It's always been that way. You can study on your own. You can have formal coursework, like, all that stuff, right, to prepare you for your apprenticeship. But it's going to happen like that, no matter what. 


And I think all the attempts, I've seen many, to, like, make it be another way have all failed dismally. And sort of if you always...I mean, this is a core belief of mine, a heuristic, if you will, but like...what do you call it? What's the word? What do I want to say? Sorry, I completely derailed me. [crosstalk 33:37]


MIKE: Apprenticeship, blacksmithing --


WILL: But, like, accept it, right? Well, I mean, just accept it. Accept it, and make it work. Like, accept it, and make it go. I don't think there's another way around it. If you embrace it, you can do it efficiently. And if you do it the stupid way and you try to pretend it's some other thing, then you're stupid. You're doomed to failure. You're just going to repeat and repeat and repeat forever.


MIKE: My experience has been deeply aligned with that. I've seen lots of empirical evidence, in that I've seen a number of engineers, very successful engineers, come from non-traditional backgrounds that worked closely with senior engineers who were mentors, learned the ropes through that experience, you know, watching and learning together in partnership with others, and they got really good and went on to be extremely successful. 


I've worked with people with PhDs who their career never really took off. They've got all of that technical background, but it didn't go very far. And I've heard that lots of times. That apprenticeship aspect in the industry is absolutely true. That's deeply aligned with my personal experience.


I'm curious, so Vivian is here with an internship. And I'm curious, Vivian, if you don't mind, you know, how much are you learning from, like, shadowing, working with other people, you know, over the last...what's it been? Couple weeks now? Two, three weeks?


VIVIAN: Yeah, it's been about that long. Oh, sorry. 


MIKE: Yeah, no, go ahead. What's your thoughts about this idea of apprenticeship and what you learn there?


VIVIAN: I distinctly wish that apprenticeships were more common, more accepted, and a more natural way of moving through an industry. I think that, especially recently with the kind of addition of AI and the effects that it has had on kind of entry-level programmers' ability to be effective and actually contribute towards an organization, I think that the entire industry would benefit from apprenticeships being used.


But especially, I think that lower-level engineers could gain valuable experience that they wouldn't be able to learn in their careers until a decade in, unless they have that mentor to go to to ask questions, to watch do things and see them do something different in a way that they never would have thought to do because they don't have a decade of experience in this industry.


The amount of things that I've learned just from sitting in meetings and sitting there like a fly on the wall, watching things happen and seeing these discussions happen, and understanding, like, the thought process that these senior engineers have of why they're making the decisions that they're making, that has been invaluable to me, even beyond the amount of, like, value that it brings by having someone with a lot more experience that I can go to to ask a question while I'm in the middle of working on it. That close tie between someone with more experience and less experience, I don't see a way of ever replacing that, and it is incredibly invaluable.


MIKE: There you go. Thank you [laughs]. 


DAVE: I like her. We should keep her.


VIVIAN: See, that's what I'm saying. 


MIKE: [laughs]


JUSTIN: You know, we're hiring an intern. If you get tired of over there, you sound like an awesome person [laughter].


DAVE: Hey [laughter]. 


MIKE: Mine [laughter]. So, you know, we've been talking about organizational complexity, and we've gotten...We took a little bit of a detour here [inaudible 36:56] apprenticeship. I think that there's connections here though, right? We said that knowing who to talk to matters, and even just sitting next to somebody and watching them do their work may teach you more than a formal hierarchical structure, you know, a formal teaching program to teach you stuff. Because that line of communication is so critically important. It seems like it all connects here. It's just that, yeah, you want to get things done? Make sure somebody knows who to talk to. Make sure that that's easy. 


VIVIAN: I --


MIKE: Go ahead.


VIVIAN: This feels like an analogy to the human brain, and the way that it functions, and the ways that neurons on their own are more complex than most kind of virtual neurons that we create for a lot of machine learning applications. 


So, they are more independent than a lot of times we give them credit for. But at the same time, the quantity of neurons in a person's brain is not even close to a good measure of intelligence. The one thing that can be considered a good measure of intelligence when it comes to neurons is the amount and depth of those connections to the other neurons around them. 


DAVE: Interconnections. 


VIVIAN: The interconnectedness of the brain is what produces the intelligence itself. It's not the individual power of each neuron or the number of neurons that are operating. So, you may be operating an organization that's a brain of 10,000 people, but if those 10,000 people never talk to each other, it's 10,000 individual people. And there's no power behind it because they can't do the work of 10,000 people meshed together. 


DAVE: You have 1 person 10,000 times.


VIVIAN: Yeah, exactly. 


WILL: I mean, in the end, like, I spend so much more time figuring out what to do, and how to do it, and who to talk to, and how to horse trade, like, to get my stuff fixed and all that. I mean, the actual programming development, like, quote, unquote "engineering" that I do on a daily or even a yearly basis is ridiculously low. Maybe I shouldn't say that out loud. I should be [inaudible 39:00]


MIKE: It's why AI only boosts, like, 20% on your productivity, because that code writing is only 20% of the job.


JUSTIN: Yeah. So, we're doing spec-driven development, and it's literally writing specs. And, you know, we're following a template. We have architectural context and everything. And we fill out this spec, and it goes off and does the thing, come back the next morning and check to see if it worked. And the day is spent writing specs.


WILL: Interesting. I don't know. At this point, mostly I feel like an old jazz musician, I mean, in that, like, I just sort of sit down at the piano, and I'm like, "Just start humming, and I got you," you know what I mean? "Just count me in. It'll be fine [laughter]," which is how product, you know, where I'm at, sort of likes to develop their specifications and their features. Anyway, so it's just, like, it's been okay. Let's not pretend that this score is anything but a suggestion, and let's jam [chuckles].


MIKE: The most popular book of scores for jazz musicians is called The Real Book, which is a joke, because it's actually a fake book [chuckles]. It's for faking that you know what you're talking about [chuckles]. We have to fake our way through things a lot, and you get there by having practiced a lot [chuckles] on what you're doing, which you might have learned through an apprenticeship kind of program, sitting at the feet of elder musicians.


WILL: Man, I wish. They just...I've got a good poker face, with just handy stuff, and I'm like, "Yeah, okay. Sure, sure [laughter]. [inaudible 40:55] [laughter]." I don't know what to say, you know, fake it til you make it. 


MIKE: I don't think the world knows what percentage of software engineering revolves around Google queries and poking around to figure out [chuckles] what you're doing. 


WILL: I mean, just the ability to just sort of sit in a chair and wait until it works.


DAVE: And remember, if you're going to learn to code from Stack Overflow, the answers. Go off of the answers, not the questions [laughter].


WILL: If you're going to learn how to code off Stack Overflow, you got to remember...I mean, and this doesn't even matter anymore because I think we sacrificed Stack Overflow for --


MIKE: We did.


JUSTIN: Yeah, I don't think there's [crosstalk 41:44]...I don't know how many questions they have right now per day, but I am certain it is, like, several orders of magnitude less than, you know, 10 years ago.


MIKE: I saw some stats recently, and it's absolutely collapsed.


WILL: It's crazy. Well, it's always the second answer, or it used to always be the second answer [laughter]. The first answer was the guy who had a lot of free time. And then the second answer was the guy who came in and was like, "What did you write down? What are you doing [laughter]?" 


DAVE: Stack Overflow heavily incentivized being first, and there were people that, like, routinely would just camp. And so, they would see a question come, and they would put an answer on it, and it was literally just to be the first one in there. And yeah, it...the second answer [laughs] is the right one. Second mouse gets the cheese.


VIVIAN: Not to mention the effect of the most effective way to get the information you need on the internet is to first state it wrongly [laughter] because then the person who knows you're wrong comes in and corrects you because they cannot stand that you're wrong.


WILL: It's tough. Like, there's definitely a major cognitive distortion that, I think, we as a society are working through, in that, like, social media has empowered people with a lot of time on their hands to have an outsized impact on the narrative. And if you imagine your own life, what the kind of person who sits around and posts on Reddit all day would look like, and how reliable a narrator or life advisor that person might be, you might run into...you might have to sort of have some fairly serious questions about, like, where we're getting our information from and what that's doing to our thought process. This is my old man shakes fist at cloud moment [laughter].


MIKE: So, bringing it back to organizational complexity, we've talked a lot about the...[chuckles] yeah, about the...well, and it's...we went deep into this idea of, well, you were talking about expertise and where it comes from, how we learn. But we got down on that detour because of how critical it is to have somebody to learn from. 


And if you're in vertical teams, you might not have somebody else directly on your team who knows what they're doing. So, this was reinforcing the critical importance of those guilds, some sort of mechanism by which you can collaborate with people who know what they're talking about, and grow and learn together, that may be independent of the formal team structure. And that's something that I don't know that I had thought through. I'm almost certain that I hadn't thought through recently, at least about how important that is. And, I don't know, I've got some takeaways.


Well, any other thoughts about what we should do to, you know, organize simply so that we don't fall into failures because the organizational structure's too complex?


KYLE: One thing that's been on my mind as we've been talking about a lot of this is policies within the organizational structure and who's making decisions where. Because we have cases in the organization, say at a platform level, where you'll be told to use X, Y, Z tool. A small subset of people will have said, "This is the tool that we need to use," without talking to the rest of the org. It turns out this tool does not work for the rest of the org. But it's the tool that we have chosen, and that's what we're moving forward with. 


And how often that happens, especially as an org gets larger, like, that happens way more often than it really should, right? And we don't have these guilds, I guess, that maybe would solve this, if that would solve it. But I'm saying policy because they're not required to talk down. They're not required to communicate with the end user to determine what it is that they actually need. 


They get a spec or a requirement that says, we need X, Y, Z tool. And they go out, and, you know, the first vendor that takes them out golfing is the one that we end up with, you know?  And that feels like it's rarely the tool that would make us most efficient. And if we talk to everybody in the trenches, we might find out that another tool, and maybe even an open-source tool, or, you know, whatever happens to be in your field, is the more appropriate tool for the situation.


MIKE: Interestingly, our new CTO¬¬─I say new; he's been here a couple of months─he's been involved in some of the conversations recently around sourcing products like that. And his approach is generally to assign somebody, you know, to go talk to three vendors and bring in somebody from the team that is going to have to work with them. And I love that [chuckles]. I love that, because it gets that perspective. It enforces the comparison, right? 


And he also tends to have a pretty short, you know, "And get back to me in a couple of days," so that you get that quick feedback loop. You don't end up stewing on it for too long, and then you can, you know, regroup kind of the agile approach. Get feedback quickly, and then maybe there's going to be follow-up questions. "Well, okay, so this is what you found. You know, based on that information, do you need to get more feedback and go do another couple of loops?" But always has somebody who is closer to the end user, right? 


So, they were looking at some security tools, and he brought in somebody from engineering, so not from the security team, somebody who's going to actually have to work with it and have them talk to the vendor. Love that. Very helpful. And it goes along with that idea you're saying, that you should try to bridge those gaps, actually get the end user and the vendor closer together so they can see where those problems are or advantages.


VIVIAN: So, that makes me curious. I mean, I feel like that's a very, very good idea, not only because you get that end user close to the provider and the person, like, what the person's going to be interacting with, close to what they're interacting with, but it also helps to eliminate some of the bias that comes with, like, yeah, being taken out to golf to get shown what the best product is. 


But I'm curious, as an organization grows and the distance between the leadership that needs to be making these end decisions...because they will affect the whole company and the end users of this product...when there gets to be more and more and more kind of middle managers between these people, how do you connect the right person at the top with the right person at the bottom, or vice versa? How do you bridge that gap as an organization grows and the number of connections grows exponentially relative to the number of people?


KYLE: One thing that I would say is your leadership needs to be comfortable to talk to, comfortable to communicate with. Because I've gone through both, you know, leaders that I felt comfortable communicating with and those that didn't. I won't say who, but I've been under leadership where I really felt as though if I wasn't his direct report, he did not want to communicate with me, and he had no reason to. And I feel like that will kind of break down as you grow larger; that breaks down really fast. So, having a good leader.


And as Mike has brought up, the new CTO, he's very much, you know, I want to communicate with the trench people as much as he wants to communicate with his direct reports. So, I think that will allow us to expand and adopt some of these new ideas like Mike just proposed, or said that we're doing something.


MIKE: Yeah, yeah absolutely. 


WILL: I don't know. I mean, the whole...the concept, right, of, like, the management of managers, right? I mean, that's an enormous...I think it's an enormous task, and I, you know, it's more art than science. And, like, there's no...I don't know that there's a scalable way to continue doing that, I mean, you know what I mean? Like, how do you make that work? It's an art, and there's a reason that really capable senior leadership gets paid so much and is so hard to find, but everybody's got a manager.


MIKE: Yeah [laughs]. 


WILL: I don't know, above my pay grade, in all honesty. I have opinions about it, and I think, if you want to scale it, I don't know, like, it's pretty far afield from my, like, my direct experience. But, I think, if you want to scale it, I think disempowering managers is the biggest issue because, like, in all honesty, I think the biggest thing that...where things come unglued most often, in my view, is because "I said so," right? Which, if you're signing the check, then okay, that sounds like a pretty good reason to me. But the processes all break down.


But if you had one of these leaders where you didn't necessarily have to be in his org...I think I know who you're talking about. We don't need to get into specifics, but, like, this person was an unpleasant person to work with. People want to be good at their job. People want to have an impact on their job. People want to make money at their job. People want to be experts. They want to contribute. They want to have impact. 


And if you have a leadership that's good at driving those things and you, you know, say, "Hey, if you go out and you work on these things that are doing good for the company," you know what I mean? And that affects your direct compensation. That affects your, you know, ability to advance. That affects, you know, like, all these things, you know what I mean? And you say, like, "Well..."


But the managers, hey, you got to convince them to work with you, right? And it's not just, like, you were assigned. You're my chattel, you know? I own you, and you, and you, and you, and you, and if you want to work here, you're putting up with my crap, you know, I don't know. It's a [inaudible 52:10] I mean, just like the pod model, right? Everything, you know, it's a good idea, and it breaks down in a different way. 


But, I think, that sort of, like, where you see bad leadership, it's people you don't want to work with. And if you give people an out, if you give people an off-ramp to get out from under somebody who sucks, they're going to take it. And if I'm the CEO and I see, like, nobody wants to work with this VP, like, this VP completely sucks. He's bleeding team members everywhere. Are they a leader, or are they just another manager?


MIKE: Yeah. I'm going to go --


VIVIAN: The common thread that I'm kind of seeing between at least those two responses is, like, there needs to be a level of not only comfort, but trust, especially between, like, a worker and a manager, or a manager and an even higher manager, however that structure works. 


Because, I don't know, going back to that brain analogy, if you're sending signals to this other neuron and that other neuron is just doing nothing with it, or doing something with it and it's destroying your brain or destroying the system overall, or not communicating back, or ever getting to a point where you are able to see the results of the effort and time and work that you're putting in, you lose that trust, and then you stop sending those signals that are necessary for the brain to function. 


And correct me if I'm wrong, but this kind of, I don't know, every single connection that builds the organizational complexity or organizational efficiency and effectiveness without building complexity, requires that trust in that communication boundary.


MIKE: It's not just complexity. It's cohesion.


VIVIAN: Cohesion, mm-hmm.


MIKE: Yeah, cohesion. You know, we've talked a lot before on the podcast, in the past, about psychological safety, because research has shown it's the most important indicator of team success. Here we are landing again [laughs].


Well, we started with organizational complexity, make your people feel...make, not just feel, make your people safe. You know, make it a place that people can actually talk to you. And if you're not doing that, you're not going to succeed. Yep. 


You talked about how you do that as manager of managers. I had somebody tell me once, and you've likely heard something like this before, but it's really stuck with me. When you're considering a romantic partner, look at how they treat their pets. 


DAVE: I've heard this expressed as the waiter rule. See how your date treats the waiter, because you don't have to be nice to the waiter, right? You can treat the waiter any way you want, and same thing with pets, right? And pets are even more, because you have a duty of care.


MIKE: Yeah. And my wife, I say, when we went to her parents' house, she, like, got down on the floor and was playing with the dog, wrestling with the dog on the ground because they were such good friends. That says something, right [chuckles]? 


There is somebody who loves interacting with somebody that they could mistreat because they're in a position of power to do so, and instead, they're saying that they're just having fun together, right? That says something. And I think that, as a manager of managers, you have to make a similar sort of evaluation. Now, how do they treat their pets? Are they going to provide safety?


WILL: Fair enough. I, you know what I mean, I guess, like, you know, one thing, and I will push back...I think it was Matt, you know, where he's like, "I keep an open door policy, you know, and, like, and everybody can come and say anything they need to to me, like, because I'll listen to anything." And I pushed back on him, and I did it on the podcast, so I'll call him out, you know. 


But, like, the issue is that so many managers and managers of managers will mandate that thing. They'll say, like, "Hey, guys, open door policy, right? Come to me with anything. If there's bad news, I want the bad news, you know, like, you got to let me know so we can work it out. No judgments, you know what I mean? Open door, open book. Like, bring it to me because I can take it." And I'd be happy to give people the benefit of the doubt on that, that when they say it, they mean it. 


But the issue that you run into, very few people will tell you this, that's not yours to give. You can, I can be assigned to you as a manager. I can be assigned to you, and you're going to say, like, "This is what I need you to do. This is what I need you to not do. This is the criteria for, like, you know, your success. This is what I want you to do every day." But my feelings of safety and trust to you must be earned, and that is absolutely unequivocal, you know what I mean? But you could say that, and you could mean it, and it might even be true, although that can't just be assumed, you know? 


You can't just take some stranger, right, that I have no personal relationship with; I was assigned to him, or her, you know, whoever, right? I was assigned to them, and they say, "You can trust me with bad news." And if I take the wrong step, that could be, like, you know, I could lose my house, right? And they say, "You trust me." Nobody's going to tell you─very few people. 


You'd have to be pretty dumb with a pretty big mouth, like me [chuckles], to say, like, "Hey, man, time out." You got to earn that. That's not for you. That's for me. I could give it to you, or I can withhold it. And the smart money is "We'll see," you know? Like, that's the smart play, and I've been very successful. We'll see [laughs], you know? It's been a winner for me.


MIKE: And you can earn that trust by actually earning it. Like you say, somebody comes and gives you the bad news, and you don't kill the messenger. Somebody comes in and has a problem, and you help them fix it. You know, those are the...and you actively go out looking for problems to fix and actively go out looking for those bad messages because it's important for you to know them. And you actively don't kill the messenger when you learn them.


WILL: Yeah --


MIKE: Like, you can go and earn that trust by doing that. 


WILL: Yeah, and you ask people for feedback. You have to go out and, like, the first few times you ask anybody for feedback, it might not be completely, like, rainbows and kittens good news. Like, you're going to have to go out and find that, right? So, I mean, like, something's always going to blow up, and you're going to have a couple at-bats just for free because something's going to catch fire somewhere.


But if I never hear from you, if things aren't going bad and you'd be like, "Tell me anything," I'd be like, that's not a relationship. A relationship is when something goes bad, you know, then okay, then I can talk to you and, hopefully, you're all right. But, I mean, like...anyway, I mean, that's just how this is how things go. And that's why these sorts of things are an art, not a science.


VIVIAN: So, I have a bit of an advice question from all of the senior engineers here. How does someone relatively new to a company go about building that trust? I came into this company as an intern, and I can only imagine that most engineers want to do their job and get their work done and not micromanage an intern who doesn't know the ropes of an organization yet. 


But I've found that almost every single person I've interacted with has been nothing but kind, and patient, and accepting with me. But I really struggle to know how much that means that they trust me to do my work versus they are babying me because I'm brand new to an organization, and they don't want to hurt my feelings, or push me too hard, or not give me enough freedom. 


So, how do you go about building that trust when you're both trying to learn how to trust the people around you, to know that they are doing good work, that you can trust their advice, that you can listen to what they say, but also that when you do your work, you know that they will listen to what you have said? Even if they don't fully know why you've done it, they're willing to, at the very least, hear you out and trust you enough that you can do work.


MIKE: You know, I said a minute ago the manager earns trust by proactively going out and solving problems for you and not making a big deal when you get a message you don't like. If you go out and proactively solve somebody else's problems, they're going to like you [chuckles]. You know, like, "Oh, you went and fixed that bug, and I didn't even hear about it until it was fixed in production. Wow." 


I had somebody once tell me about, they gave the idea of change in the pocket. They'd heard it from their manager. Every time that one of those things gets fixed they didn't have to deal with, it was like a coin going into their pocket. And then when they broke something, they had to go tell their manager, "I broke something." They're like, "It's okay. You got a lot of change in the pocket." Like, "What?" "Oh yeah, well, all of these good things you've done have added up." And so, you know, it goes against that balance, and the balance is pretty high, so it's okay.


DAVE: I literally this week told someone...somebody did something that cost me some effort, and they were like, "I'm so sorry," and I'm like, "Dude, it's fine. You have a huge balance with me." Like, literally in those terms, like the emotional bank account kind of thing. It's like, yeah. 


WILL: I mean, honestly, like, more than anything, it's just consistently showing up and doing your best work. Like, they're going to give you work to do, and you do that work. And then, you know what I mean, and things are going to go wrong, because they will always. And when something goes wrong, you show up, and you give your full and forthright effort on fixing the thing. If it's your problem, figuring out what went wrong; if it's not your problem, finding help if you need it, right? Just taking responsibility. It's like, okay, this thing happened, okay, was it my fault? Then just show up. Just show up consistently. 


It is absolutely unmistakable when you have somebody who is going to do that consistently day in and day out. Pay attention, you know? Like, just do the work. I don't know why it's so...no, I do know why. I do know why. There's lots of good reasons for why it's difficult to find people who will do the work consistently. But, like, if you just show up and get things done, talk to everybody and get it done, you're going to do fine, like, honestly. I mean, that's it. 


You know, where I feel people fall off, where I've seen people fall off, is either lack of...well, the effort wanes because, like, it's just psychologically difficult to keep on, like, fighting this fight every day, day after day, week after week, month after month, year after year, decade after decade. Like, it's hard to remain psychologically committed to the work. 


And you have to be psychologically committed to the work. You can't be 50% in, you know? You could be an accountant and be like, "I'm not passionate about these taxes." I think you could probably successfully file somebody's returns even if you're listening to a podcast. But if you're in this thing, you have to be all the way in. And so, like, that's one thing.


And then the other thing is, like, when things do go bad, you get weird, you know? Like, you get weird. I'm dealing with...I'm right now fighting with some people who have gotten weird. And their things are not working, and we are having a lot of trouble coming to an agreement on how they're going to get fixed, and people are going to start losing a lot of money. 


Big people are starting to become aware of this thing, and because everything is digital, there's a paper trail of them being very weird for a very long time. And they are going to have a very big problem because, like me, they are consultants, and consultants don't have all that much grace. And so, accountability, accountability, and consistency. Work hard, be accountable, communicate. I don't know, I mean, like, I wish I had a more, like, I don't know, like, poetic answer, but really, that's really all you got to do.


VIVIAN: Honestly, it's kind of comforting to hear that there isn't some, like, secret sauce that everyone knows that I don't know. Just being consistent and showing up will pay dividends, not only in the trust that I can build, but also in the kind of connection and organization that I can help to be a part of and create.


KYLE: I'll just say one that's a pet peeve for me is, don't tell me you know something that you don't. If you don't know it, ask. I've run into situations where I've been working with an engineer that I was under the impression that they knew about a subject, only to find out that they don't. And that is a problem in the sense of, like, I can adjust how I'm approaching the situation if I know that you're not aware of something. Like, it's not a problem for me to teach you. It's a problem that I thought you knew this, and you're pretending like you do. Yeah, just a pet peeve here, but that's one of them.


VIVIAN: No, that makes a lot of sense, yeah [laughs].


MIKE: Well, there's kinds of dishonesty. Somebody saying, "Yeah, I know how to do this," it makes it impossible to actually get them up to speed. If they said, "I don't know this," great. Let's solve that problem. If you are dishonest about that, then it completely destroys the ability to progress.


KYLE: I would say to that, as a, you know, mid-level, senior level, you know, we...at least I would think that most people aren't going to assume what you do and do not know. So, it's kind of on you to say what you don't know. And there's no problem in asking because I don't think there's any senior that's going to look at an intern or a junior and be like, "No, that's a stupid question. Why are you asking that?" No, we want those questions. 


DAVE: And the seniors, too. I think I've shared this story on here, but I was in a meeting a year or two ago with Eddy Lopez. And we got to something...there was any questions, and I asked a question. And it was a boneheaded, stupid question. And, like, Eddy turned to me, big eyes, and he goes, "You are fearless about asking stupid questions." And then the person next to me said, "I'd actually like to know the answer, too." And I'm like, yeah. Yeah, I love a good, stupid question. I love a good, stupid question."


WILL: Yeah, I mean, embrace your stupidity. Like, I'm really honestly, like, I'm a beginner in this, like, sort of AI stuff. I'm actually getting fairly effective. But, like, if I had approached it from a position of, like, "Oh, I've been doing this for 30 years, I know how to do this stuff," like, I would be nowhere. So, I'm just like, "Okay, let's try some stuff," you know? 


I mean, you'll hear me, you know, hit up, you know, Dave. I have another buddy, Darin. And we're big, big AI guys. And I'm like, what about this? What about this? Can you do some of that? And how does this work, you know? Because I don't know. I don't know. I'm just brand new. I'm an old C programmer for crying out loud. That's what I know about. [inaudible 01:07:09] one of these function pointers? I bet not.


MIKE: [laughs]


DAVE: Oh, yeah. Love me some PFs.


WILL: But I will say that, like, you know what I mean, and, like, the secret silver bullet, you will never, ever, ever, ever, ever have a hard time getting an answer to your question from anybody in the world, ever. And they will happily answer whatever question you have if you just do this one secret thing, which is to say, make a concerted effort, you know, relative to who you're asking, right? Relative to who you're asking. 


But, I mean, like, if you're just like, "I've got a problem. I can't figure it out," spend 15 minutes thinking about it, trying some stuff out, documenting your approach and your specific question, you know? And anybody on your team, you could get an answer from the CEO, I swear to God.


Like, I don't know your CEO, but I bet you if it was a question that was relevant to him and you spent 15 minutes thinking about this thing and you emailed him, he would email you back. I bet you $1,000, you know? If you were sending to the right person and you put some effort into, like, figuring it out yourself and you're like, "This is what I did; this is my question; this is what I need from you," like, [snaps finger] you'd get what you were asking for, and everybody's like that. 


And where people run into issues is when they are...they just sort of, like, they just immediately give up and throw the white flag. And people will get frustrated with you then, you know? But if you did the effort, I swear to God, everybody, they will do backflips for you. You'd be stunned. 


MIKE: We talked about that first answer on Stack Overflow. Like, it's catnip to engineers to see a problem that somebody's gone halfway through and they couldn't figure out the solution for. Like, they can't help themselves. 


DAVE: It's like setting down an unsolved Rubik's cube. It draws attention.


MIKE: [laughs]


VIVIAN: That's very interesting. I'm kind of curious about how to find that balance. I have a strong tendency to dive really deep into trying to solve a problem to the point where it's all I can think about. And I'll look at the time, and it will have been five hours since I last talked to anyone or checked my messages or looked at the time. 


And I sometimes struggle to identify that time where I'm like, "Okay, I could spend the next five hours trying to solve this, but I know somebody that knows how to explain it to me so that I'll never need to spend five hours on this problem or a similar problem ever again." How...I don't know if this is too theoretical of a question, but how do you actually create that self-discipline to pull out?


WILL: Don't. 


MIKE: Yeah. I've got a very pragmatic answer to that. I say two to three hours. That's flexible.


WILL: I have an even more pragmatic one. Don't. Let it cook. Let it cook. Just cook. 


DAVE: That attitude --


WILL: If you find yourself at midnight, you know what I mean, like, working on a problem, and you're still engaged, and you're locked in, and you're focused, let it ride. Let it ride. Like, because, yeah, okay, especially where you are in your career, right, especially where you are in your career, like, just cook. Get in the weeds. Get weird with it, you know what I mean? Like, do any kind of crazy thing that you think of because, like, you are learning things you're going to take with you forever, so just keep it going. 


Where I wave the white flag maybe quicker, faster, but less often, is because, generally speaking, I have production quotas that I need to meet, and people are starting to crawl up my leg. And I cannot spend a week on a problem in a way that I might have happily done another time [laughs], you know? Prod is down. Did you know that prod is still down? Maybe let's fix that, you know? And so, I can't indulge those things. But I'd expect you as an intern to get weird with it.


DAVE: I will second that with a slight measure, which is, yeah, let yourself get obsessed, especially at this stage in your career and with this warning: That might cost you your job, but it will make your career. You can bank a career on that level of obsession. 


WILL: If you've got standups, and you've got people, and, like, you have people like, "Hey, Viv, how's it going? You still working on that thing? Can you show me what..." you know what I mean? Like, there's people in your standup, especially as an intern, they will redirect you. And you'll sort of start to get a feeling for, like, "Oh, I spent a little bit too much time on that," you know? But, like, there are people whose explicit job is to be like, "Hey, so let's walk through this. Let's pair through this thing," you know what I mean? They will redirect you. I mean, like -–


MIKE: Yeah, true.


WILL: Up until...I'm trying to think of a time where you can't get away with that anymore because, like, again, you know what I mean? Like, things, like, people get up my leg, you know, if I'm taking too long on something that ought to be resolved.


MIKE: Well, if you're actually engaged and learning stuff, that's productive work. The reason I said a couple hours is if you're stuck, that when you get stuck, and you don't know what else to do, and, you know, you're disengaged, and you don't ask because you don't want to ask anybody, that's where you get in a lot of trouble.


DAVE: Right. I had a really good manager when I was a junior who helped me with this because I was very much the obsessed type. He had come in in the morning at, you know, 8:00 in the morning, and I was at my desk, and he says, "You're in early." And I'm like, "I haven't been home yet," you know? I've been here since yesterday. And he liked that. You know, he's like, "You need to have some work-life balance, but it looks good on my productivity sheet." 


But he pulled me aside and said something really, really profound. And this goes to asking questions. He gave me two pieces of advice. One, carry a notebook and write down any answer you get because your coworkers will pay...and the reason for the notebook isn't for writing down. It's so that you never, ever ask the same question twice. Your coworkers will hear you ask the same question over and over and over again, and they will flip the bozo bit on you, and they'll withdraw. That respect that Will was talking about, they'll pull that back in. 


But the other thing is, you do have to value your time, and if you're obsessed and you're locked in, keep chasing that rabbit, man. That builds Vivian 2.0, man. 


VIVIAN: [chuckles]


DAVE: That's always going to be pushing you down the road. That's a superpower. Don't cure it. But if you are stuck and spinning your wheels and you don't know where to go, and you're just kind of beating your head against, you know, document pages that you can't find the answer to, value your time the same as a senior developer's. If you spending an hour on this can get you through it and will save a senior developer an hour helping you, don't waste their time. Just go spend the hour and get us the...but if you've been down this eight hours and you're still stuck, and a senior's hour of time can get you out of that eight hours, the value call for the company is go bother the senior developer. 


And this is psychological safety. Trust that the senior developer sees that ratio as well. We do. You know, we know which people are live ones and which people are help vampires. And if you're a live one and you've, you know, like, like Will said, you show up with, you know, a pile of broken pieces and half-built solutions that don't work, and it keeps falling down here, here, and here, that's when somebody can pull you aside and say, "Ah, let me show you this." 


Or, like we talked about at the top of the call, just watching somebody do this, you can have a senior just kind of look over and look at the pile of parts and go, "Yeah, it does that." And you realize, I shouldn't have been solving this problem in the first place. I've been trying to prove P equals NP, and okay, yeah, move on.


KYLE: Also, ask the question, "Get me out of my meeting," then I can spend time helping you and get out of a non-essential meeting [laughter].


DAVE: Yeah. Public calendars are a weapon. I love it [chuckles].


VIVIAN: I'll be honest, I have used that one once so far at this internship [chuckles].


DAVE: Nice. Nice. 


VIVIAN: Oh my gosh. 


KYLE: One thing I was thinking is double dip when you can, too. And what I mean by that is solve it yourself. Spend the time to solve it yourself, but don't call that the end. Go to your senior. Go to your, you know, person with the knowledge base and say, "Hey, I solved it this way. Should I have done anything different?" Have a discussion with them and see, like, what the better approach was, or, you know, the differences.


VIVIAN: I don't know how this will change as, like, my career progresses and I get into higher levels, but I've been really enjoying the code review process a lot more than I initially expected to. Because I love, like, getting someone who just has way more institutional knowledge and way more knowledge about programming in general to take a look at my code and say, "Oh, why are you doing it this way?" And I'll have to explain it. And in that explaining, the thought process occurs of, like, "Oh, this is why I'm doing it this way. Oh, and I could have done it better this other way." Or they'll look at the code that I'm writing and go, "Oh, why didn't you do it this way?" And, suddenly, that kind of reopens my brain just in the code review process to get something into prod.


WILL: Yeah, you'll get over that [laughter].


DAVE: Yep, yep. You'll get jaded. Yep.


WILL: Yep. I don't know. Sometimes you'll find yourself in situations where you're dealing with just how people want things to be, and it's sixes. And it's easier to just give them their way than it is...which is a substantial investment of non-productive activity on your part, just because somebody really likes, you know, all their widgets sorted in this particular way. It's easier to just give them their way and move on. That can be frustrating when you're operating under resource constraints yourself. 


MIKE: So, engage with the people who tell you why. There'll be people who say, "No, it's got to be this way," and there'll be people who say, "Well, if you did it this way, it would be easier because it would do this and this and this. Here's an idea for you. Here's some example code." That's a very different kind of answer.


VIVIAN: Yeah. Okay. Well, I feel like I've taken it way off of the organizational complexity task and into personal advice for Vivian podcast.


DAVE: This is what...no, this is absolutely going to be published, and there are going to be people that are going to tell us, "I am so glad we had this chat." Like, legitimately, these are...you have not been...unfortunately, Vivian, you have not figured out how to ask stupid questions. I'm going to have to ask you to work on that.


VIVIAN: Okay. I'll work on that.


DAVE: Yeah, yeah. 


MIKE: I think that's a good place to tie the bow on this one. I think we're going to have a podcast on organizational complexity and advice for interns [laughter].


DAVE: The thing is, if we did a podcast called Advice for Interns, it would be crickets, yeah.


MIKE: Thank you, everybody. And until next time on the Acima Development podcast.