"Founder Mode" at work when you're not a founder

Hello, hello, hello, and welcome back to another episode of Go Time. Today I am joined by some lovely co-hosts to discuss a - I don’t know, I’m going to withhold from applying any adjectives to this piece of work that we’re here to discuss, called Founder Mode, and how that applies to us as engineers, and us as product owners, and people who build software for a living, how does that apply to us when we ourselves are not the founders. That’s a slight bend to the topic there. But please, help me welcome Angelica Hill. How are you doing, Angelica?

I’m good, I’m good. I’m enjoying being inside. I’m not one for the heat… Somewhat of an English rose, in that if you apply too much heat, I will wither, so I’m enjoying being inside.

Nice, nice. Staying away from the heat. Yeah, it’s that time of the year on the East Coast. Awesome, awesome. Kris. Mr. Kris Brandow. How are you?

I’m doing good, also avoiding the heat. Last week it was like 60, and it was beautiful; now it’s hot again, and I don’t like this, and it needs to stop. It’s fall. It’s fall. We should have fall weather. Bring back the fall weather.

Look at us, defying stereotypes; engineers that don’t go outside? What a phenomenon…! [laughter]

What…?! Man… Alright, so let’s get into this, because I think – I’m going to assume that because of the sheer popularity of this essay by Mr. Paul Graham of YC Combinator fame, that most of us, and probably at least a few of us listening to this episode have heard of the whole Founder Mode. At least you’ve seen some memes on the interwebs about Founder Mode, and sort of the implications. But just to sort of make sure that we’re all on the same page here, a quick summary of what Founder Mode is, what the essay is about.

So I asked Chat GPT to provide me a summary, so I’m going to read the bullet points real quick. So Paul Graham’s Founder Mode discusses the difference between managing companies as a founder, versus a professional manager. Founders often receive bad advice on scaling, focusing on delegation, which can harm companies… A founder’s involvement in details and personal engagement are key to success, unlike traditional management’s hand-off approach.

Founder Mode leverages a deep connection to the company’s mission, breaking away from typical management models. This approach remains underexplored, but is essential to effective leadership, particularly in scaling startups.

So this is in effect about startup world, founders, and scale-ups, as they call them these days, and all these things.

However, I saw an opportunity to kind of apply sort of those of us who are not founders at a company, perhaps not currently… How do we take – so the spirit of the essay, I believe it is to sort of stay in touch, stay connected with the mission, with whatever it is that you’re building or working on or engineering every day, staying connected to it and not sort of losing touch, not delegating too much kind of thing. And that’s going to apply to us more so depending on where we are on that sort of engineering ladder. If you’re a staff engineer or above at a larger company, maybe you don’t touch code anymore… Or if you’re a junior engineer or a senior engineer still writing code, how does that spirit apply to you as a software engineer who doesn’t have the same incentives as a founder to deliver a product or a solution?

So that’s the scope. That’s the setting that we’re about to discuss here. So I want to get a sort of a gut reaction… Perhaps starting with you, Angelica. What did you kind of feel or react to when you came across Founder Mode?

[08:08] I mean, my initial reaction, if I’m honest, was twofold. One was this kind of just sounds like thoughtful micromanagement, where you are micromanaging, but you’re making sure no one feels micromanaged. But then the other side of me really felt excited at the idea of it being a positive, to be very in touch with the kind of day to day, on the ground operations, especially for those who are at higher levels… Because I think one of my core pain points sometimes, as I look at my engineering team’s team, is that when there is a disconnect between the kind of boots on the ground, engineers in the weeds, building the code, and the, let’s say, principal engineer who might be the tech lead or the overseeing architect… That’s just a recipe for disaster, where delegation is happening, but because there isn’t that almost one person who is keeping tabs on “Where is everything? How’s it going?”, and doesn’t have that in the weeds knowledge to be able to gut check, “Are we moving in the right direction, or are we completely going off in a tangent, letting people go off for months on end unsupervised?” I think a lot of it is just questions of balance.

Okay. Okay.

But I liked it.

Overall, you liked it. Okay, okay. You can see where Mr. Paul Graham was coming from.

Yes.

I do, in fact, have a take… This is, once again, VC Silicon Valley, stumbling via the the Socratic method on something that business people have known for decades. Basically, Founder Mode is like a really weird way of saying quality leadership. I think that the problem is the essay sets up a false dichotomy, and it does this really interesting sleight of hand where it’s like “Oh, the advice that you get when you’re a founder is that you should hire good people and give them autonomy.” And then they kind of say “Okay, well, that’s the advice you get, but then you hire all these people that are basically liars and swindlers, and all of that.” I think the problem with that is that those aren’t good people. Those aren’t people that are good at their – they’re not great. They’re bad. The fact that you cannot detect that they’re bad… Yes, that is a problem. That is a problem we need to solve. But the advice isn’t bad, just because you didn’t do it properly. Like, the advice of actually hiring good people and giving them autonomy is very well researched, very well founded, and extremely effective.

I think where the problem comes in is that we as an industry, and I would say to a degree the larger business world is very, very, very obsessed with not doing leadership as leadership needs to be done. I think when people hear the word leadership, they hear decision-maker. And that is very much not what leadership is, and that’s a very bad way of going about leadership.

So I think what he’s trying to get at in this essay is, we shouldn’t be doing this type of top-down management of things. We definitely shouldn’t be looking at different parts of the org below you as black boxes. I think he’s definitely right about that part. That’s a very poor way to manage any type of endeavor. I think where things go awry though is this assumption that leaders make decisions. I feel like I’ve probably said this on the podcast before, but a good way to think about leadership, as far as I frame it from studying and doing this stuff for decades at this point, is a leader is someone who enables decisions to be made. They don’t necessarily make decisions. And I think that’s where the autonomy part comes in.

[12:07] So you hire great people, and you say “You need to produce a decision about this thing”, and you can delegate that decision-making down further, but at the same time, that person at the top, or whoever you are, still needs to go and talk to people, and still needs the pulse on the entire organization.

I think if there’s a takeaway from this essay, it’s that leaders need to be connected into their orgs, and I definitely agree with that no matter what type of leader you are, you need to be going out and talking to people, and connecting with them. I think that the whole idea around skip levels that’s in this essay is that that’s correct. You shouldn’t just be talking to your executive leadership team. Or if you want to apply this to yourself as like an engineer, you shouldn’t just be talking to your own local team. You should be going out and saying “Oh, I have information, and someone over there hasn’t. I’m going to go talk to that person over there.” And I think that’s where this stuff can start to apply in.

But that is all just pretty basic level leadership stuff. I just don’t think we need to give it a special name. I don’t think we need to call it Founder Mode. I think what he describes as manager mode is really just poor management. And I know it’s really popular, and a lot of companies try and do it, and a lot of business schools push people to do it… But it’s just not a good way to run an organization.

So I think we should go look at the literature that already exists, that explains these concepts extremely well. That’s where I also disagree with him, when he said “There’s no documentation of this.” There’s lots of documentation of this. But in general, if you kind of strip away the name, and kind of the other annoyances, I think the idea is a good one for anybody… Because again, it’s base leadership. It’s base – being connected in with a group of people, and really localizing decisions where it makes sense for those decisions to be made.

I don’t quite know if that – I feel like part of Founder Mode is you’re still the decision maker, and I think that’s the part that needs to kind of not happen… But other than that, I think that the substance of it is okay-ish, given all those caveats I put out there.

Okay. I think it is contextual… Meaning, depending on the size of the startup you are, it’s going to require a different style of leadership, a different style of ownership. So I think rather than focusing on the leadership and the management, perhaps the better way of making this relatable to everybody, to all of our listeners, is perhaps to call it ownership. Because I think part of this – the key takeaway for me in reading this and trying to apply it to software engineering as a whole is basically – it’s just boiled down to that term, ownership.

So the style of ownership you have is going to very much be impacted by sort of where you are on the engineering ladder. If you are a junior engineer, who perhaps doesn’t own a lot… Again, all this depends on the size of the company, the culture, and everything else. And I think that’s perhaps sort of glossed over and sort of not really given a fair light in the article… But the article sort of talks about sort of having skip levels, and everything else… That already implies a certain size of a company. When you have to have skip levels, that means the company is a scale up, as we call it. It’s growing. There’s a lot of people, and you start to delegate things, and the delegators then start to delegate things, you start having hierarchy, and different people doing different things.

But in a much smaller setting, where – say it truly is a small startup, and say you have at most a dozen people, and you have generally a flat hierarchy, or rather there is no hierarchy, it’s just a flat structure, where there’s an expectation that different people are going to own different parts of a product, I think that’s a much more sort of relatable setting or context.

[16:02] So if we talk about ownership in that sense, that can apply to the code you’re writing. It can apply to the area of the product that you own. And that can apply to a product manager, and it can apply to a project manager; not the same things. But there’s different people owning different aspects of a product, and basically staying in touch with that.

So with that sort of framing, again, if you’re not a founder, say you just got hired a couple months ago and it’s a relatively small team, you’re excited, you’re passionate about the product, and you start writing code, and you’re not incentivized really by, perhaps monetarily, if you’re a junior engineer, you’re probably starting pretty low on the composition ladder, as it were… So you’re coming in just more interested about learning, about sort of getting experience, and all these things… How should you see and look at ownership?

I don’t know if I agree with the framing of ownership, because I think that implies something around, once again, making decisions about something. Whereas I think – at least in my mind, when I think about leadership, it’s something that anybody can do. So if you’re a junior engineer – and I guess this is where you can use this definition of own, where it’s like, you can own getting something done, even if you’re in a smaller part of the org. And I think that’s also where skip level is kind of a misnomer, because it doesn’t just mean up and down, but also side to side. So I think that is a concrete thing that is helpful, I think, to literally everybody, is don’t be afraid to go out and talk to other people that are outside of your direct sphere, and try and get things done if you need to get things done. Because I feel like part of the problem with lots of hierarchies is that you wind up with being like “Oh, well, something is blocking me”, and usually you have to throw something up a hierarchy, or go around something. A good form of leadership, or that idea of like Founder Mode would be to just go talk to the people on the other team, and see if you can like come to a resolution or figure out a path forward. Maybe that does need to include other people in the hierarchy. But I think that’s a very important first step on the journey to being more of that – okay, the word owner’s growing on me. More like an owner of things, or a founder of things, and really just a leader. You might not have the ability to make the ultimate decision at the end of the day; that might still need to get made by a VP, or by a director, or by a tech lead, or by somebody else…

But that doesn’t mean you can’t shepherd the conversation or clear the path for that happening. And I think that’s the type of leadership that is implied in this essay, and I think that does apply to – you know, you could have just started last week, and these are things that you can be doing.

Obviously, mind the politics of your org. Lots of orgs get very unhappy if people freely communicate for usually bad reasons. But if you’re in an org where it’s okay to just really communicate, which I think small startups usually are, just go talk to people. Don’t be afraid to go out and facilitate action and movement of things.

Break: [19:32]

So Angelica, you manage teams of engineers. Do you have the same expectation of ownership for juniors as you do with, say, people higher up the ladder, like the seniors and the principals? Do you have the same expectation of ownership?

I mean, there is an expectation that if I delegate a specific problem to them, that they take full ownership of that problem, and they do all they can, kind of as Kris alluded to, to like drive that problem forward, pulling in the right people as they need it. But I do think the spaces that I delegate ownership to various people do change. I would delegate ownership of perhaps a smaller, less complex problem to a more junior engineer. I would delegate a larger, more complex, to a more senior principal engineer.

So I think the expectation of ownership is agnostic of leveling. Like, there is an expectation you take ownership of your work, and you care about it, and you invest in it… And that’s kind of - reading between the lines I may have misinterpreted, but when I saw Founder Mode, that was what kind of excited me. I was like “Yes, a founder is deeply invested. They’re excited. They feel ownership in what they’re doing and they’re invested, so they want to see it through till the end.” So there is an expectation of ownership at every level, but the space and the level of ownership I think changes a lot.

So I kind of – I think it’s more shared ownership, as opposed to… And it’s changing ownership, i.e. like at the beginning of a project, I as the technical product manager, I own that space. I am defining it, I am accountable for taking ownership of like finding out what the problem is, finding out how we can best solve it in a business sense… I then delegate ownership of the problem to perhaps a tech lead to take ownership of how we technically solution. And that tech lead might choose to share ownership of that decision with bringing in a DIG analyst, a data analyst, bringing in a more junior engineer, bringing in a fellow, kind of – Kris, you’ve talked about this a little bit, like lateral leadership; bring in another engineer from a different team.

So I think it’s very fluid, but I do think the idea of feeling ownership of your work and seeing it through, and not just kind of throwing the buck over the fence is really important… I.e. when I give ownership to my tech lead, I am not relinquishing ownership entirely. Like, I’m not going “Oh, this is your problem now, it’s not mine.” I remain engaged. I share in that ownership, like the core driver almost, like the steward of that thing (perhaps that’s a better word) does change.

[25:30] But I do think there is an ultimate – to your point, Kris, I think there is ultimately a decision maker [unintelligible 00:25:36.29] might be deeply informed by – you’ve had a lot of people steward the problem, input, a lot of decisions, sub-decisions have been made… But if there is a concrete decision to be made around like “Okay, do we implement this in AWS or GCP?” and you can’t come to alignment… Perhaps it is the principal engineer who owns that decision. Or - okay, we want to build scheduling capabilities for push notifications, or integration of images into emails. Ultimately, I might be the decision-maker on that, or I might be like “Both of these things are amazing.” I have to go upwards and be like “Hey, I need a decision. I need you to tell me which of these two you want my team to work on, because I think they’re both similarly valuable.” But I’m taking ownership of like “I don’t want to make this decision. I’m not ready to make this decision. I’m going to own the fact that I need input from above, or from senior management.”

So there’s a scope – okay, so what I’m hearing is “Yes, ownership, but there’s a level.” There’s a scoping to the ownership. I’m not going to expect the junior engineer that I just hired two weeks ago to be making a decision to do multicloud or not. That’s not the ownership I want to give them. One, they might not have enough context… They might have the experience. I’ve met some incredible junior engineers in my time… They might have some context and experience for it, but that is not a decision I want them to own sort of politically, to use that term loosely, within the organization. Because I don’t want them getting flack, by some definition of wrong - the wrong decision is made and the wrong sort of service provider is used… There are certain things that I as sort of the first line of defense for them, and some sort of a hierarchy or sort of structure… I don’t want them getting heat for something that they shouldn’t. So the ownership I’m going to give them has to be scoped to their level of responsibility.

And therein lies the – there’s a subtle contradiction happening here. When I’m reading Founder Mode, and a lot of people are sort of chiming in online, saying “Oh yeah, it wasn’t my job to do X, Y, and Z, and I just did it anyway. #FounderMode.” So people are choosing – especially in a smaller startup environment, where many people wear many hats, it is lauded to be able to pick up something and do something that you weren’t “hired to do.”

In that environment, where seemingly scope and ownership seem to not – like, ownership carries more weight than scope does, right? So depending on where you are and what the culture of the organization is – like, I’m torn between not having decision-makers, to use terminology we’ve been using before… I’m torn between sort of giving too much or not having… I don’t want to use the term control, but not having any sort of guardrails, or guidance, or a sandbox for figuring out what to do. I can’t not have that, and just let somebody perhaps shoot themselves in the foot because they’re running, and moving fast, and breaking things, and broke the wrong thing and ended up harming the business in some way. So I think it has to go hand in hand. Scoping and responsibility and ownership have to go hand in hand.

And then being really clear when you give someone ownership, that they understand the scope, and then you actually let them. You say “Hey, this is your problem to solve. These are the –”

These are my expectations.

“These are the lines in which you can draw. Go crazy within these lines, do you…” But then also, once you say that, don’t then come in and start like getting in there, and [unintelligible 00:29:51.00] stuff out within the box. Set those really clear expectations, and then let them do them, and give them that ownership.

[30:00] So I think there’s a little bit of a fallacy – not fallacy; category error, maybe, happening here… Like, there is a difference between who owns something from a leadership perspective and who makes a decision. And I think for any decision, decisions always need to be made by the person who, I think, as you said, Johnny, has the most context, or is the most affected, or will do the work. So if you’re trying to make a decision between cloud providers, that decision needs to be made by your operations team, because those are the people that are going to be effectuating that decision, and so they need to own that decision. But they don’t need to lead the process of coming to that decision. So these are two separate things that are very, very important, especially as you move higher up in organizations.

I think a failure of the manager model is that it tries to do this idea that – I don’t really know where it comes from. I think this is how people think like the military works, or something… Where like the people at the top make the decisions and communicate them down. But once again, if you read books on leadership, like I do, what you learn is that –

The command and control style of leadership, yeah.

…it doesn’t work. And the thing that you should do is you want to push decisions down and have communication flow up. This is how modern militaries work. The people at the top aren’t making decisions about, what strategic things to do at like an action level. Those are the people on the ground that are doing it. Those are the squad leaders that are on the ground, actually going to do the work. The generals are just making sure the information is flowing, so that those people that have to make the decision have all the information that they need to make the decision properly. And I think that is the type of dichotomy that we need to have within our companies, and within any type of decision-making capacity.

So even if – say, because of org structure, you are someone that ultimately has the decision-making authority because of how things are structured now, a great way to do this, I guess, leadership thing would be to find out who’s actually going to be the most affected by this, who’s going to have to go implement this, and go talk to them, and then transfer that decision-making apparatus to them, and say “Ultimately, your decision is the one that matters here, because I don’t have the right context to make this decision.” And that happens at all levels of being in an org, from the tippy top all the way down.

And I think too with leadership one of the interesting things that is in a book called Good to Great, there’s this thing called Level 5 Leadership… And it’s one of the things that can make a company absolutely fantastic. It’s a good book, go read the book. But one of the things they’ve found is that these Level 5 leaders are spread throughout the entire organization. I think Level 5, you can kind of more or less translate that into Founder Mode, for the purpose of this podcast, sort of, kind of… They’re different concepts, but they kind of effectuate the same thing. But they’re all throughout an organization. And they’re not people that get – there’s no one going around, decreeing who a Level 5 leader is. It’s just people that have a very specific type of mindset, that enables them to do this work, enables them to pull people together and make things happen. And a major component of that, which I think is hidden in this Founder Mode idea, is that your ego and the needs of the organization become aligned. So your ego is no longer about you, it’s about making sure that the best thing for the organization happens. And that’s like a really key property of a Level 5 leader. And I think that that is something that, once again, anybody, at any part of the org can do, where you don’t have to be decreed by someone on high to go and be like “I’m going to figure out what’s the best thing we can do for the org. Not for me personally, but for the org as a whole”, whatever the org is for you, whether that’s just your department, or your team, or the whole company, and then start pushing forward initiatives for that in whatever way that you that you can, at the end of the day.

[34:13] So [unintelligible 00:34:14.15] I think that separating out this decision-making apparatus from that leadership apparatus is a key point in actually being able to be much more effective in leading things, and making things happen, which is kind of what this Founder Mode thing feels like, is also like actually being able to get things done at the end of the day, and make things happen. Because I think that’s what founders do when they’re running a company. It’s like “Yes, I want to accomplish things, not necessarily deal with the bureaucracy.”

How should this affect my approach to code, if at all?

I mean, it’s the same sort of thing… The way I like to think about it is who is going to be the most affected by this change in the code that I’m making? Am I the right person to be writing this code? Or do I need help from somebody else? Or if I need to write this, and I don’t understand it, and there’s no one else to write it, who can I go out to get information from to make sure I write this in the right way, instead of just trying to figure it out myself because I was vested as the person that was supposed to be writing this code?

Okay, so let me pause you. Let me give you an actual scenario… And I want both your take and Angelica’s take on this. So imagine you work at a fairly large organization. You are an engineer - junior, senior, it doesn’t matter. You are tasked with delivering a solution. That’s the job, deliver a solution. Nobody’s telling you what lines of code to write, where to go put your module or package, what services to deploy… Nobody’s telling you, as you said, the tactical steps toward achieving some desired goal, which fits into some strategy, from leadership. The tactical implementation is yours.

And you know that in order for you to deliver said solution, there needs to be involvement from at least two teams. Teams that don’t normally work with each other, but they are distinct teams. You’ve tried on multiple occasions to collaborate, to communicate. You own the solution. Your job is to deliver the solution, so you own it, by definition of what we’ve been talking about, but you just can’t seem to move the ball forward. Whatever you need to do, you are able to and ready to do, but you can’t seem to get all the ducks aligned. So in that setting - and we’ll start with you, Angelica. In that setting, what is the expectation for this engineer, who finds themselves, who they are willing and able, but they just can’t seem to deliver, through no fault of their own, seemingly? How do I own anything, and how do I go Founder Mode in this setting?

I mean, from my perspective I think because you own the solution and not the “How do we make it happen logistically across teams?”, like your ownership is the implementation of the solution you think is best, not the ownership of logistically “How do we get this done cross team collaboration?”, if I was that engineer, knowing my box and knowing this is outside my box of ownership - ideally that would have been set out clearly - I would then go to the person who does own that, which would be a project or a product manager, and I would own the fact that I need help, and I would be very, very clear and clearly articulating what I need, why I need it, when I need it, and who I need it from, to that person, and empower them to do their job and what they own, and own keeping them accountable, i.e. if I flag it to my product manager and two days go past and nothing’s being done, I should own the follow-up of being like “Hey, I brought this to you two days ago. I really need this. Flagging again. If you need me to do X, Y, Z, if I’m going to own this solution, what I need from you is X, Y, Z.”

[38:33] And I think taking ownership of driving that forward, even if you’re not the one actively doing the things to make it happen right then, is in my mind that kind of Founder Mode. Like, you’re not just throwing it over the fence, you’re taking accountability. You’re just asking for someone else to do something for you to help drive that forward.

Yeah, I think that’s how I would think about it. And then as soon as I get what I need – I’m still owning that solution, I just have what I need to keep driving that forward… As opposed to throwing your hands up and saying “I can’t do it.”

“I can’t do it.” Right.

Well, I think if there’s other teams that are not, for whatever reason, doing what they need to do to participate, then you become the contextually correct person to be making decisions. Like, if there’s some decision that needs to get made, and it requires one of these teams, and they’re not engaging, a) you probably have some deadlines, so you’re now the one that makes the decision, and that team that didn’t participate… I mean, I would say definitely document it, so if they come back later and say “Well, we weren’t involved”, it’s like “Well, I tried. Here are the emails. Here’s all the communication. You didn’t want to participate, so we had to make this decision.” But I would say that that is likely a sign of an organization that is a little toxic, and needs some help.

And I think that’s something that could be that you as the person who’s like responsible for this thing that kind of spreads across teams now should run that up whatever hierarchy you have to figure out why these problems are occurring. Like, you can own at least attempting to resolve some of these problems by - you know, maybe it is going to your skip level manager, or skip-skip level, and saying “We have these teams, we have this project, it’s super-important, but no one’s communicating. Can we figure out what’s happening and how we can start resolving it, so that people are coming together again, so that the right people can be making the decision, so that I don’t make a wrong decision?” So short-term, you’ve got to make the decision if you’re running against a deadline. But long-term, that’s a symptom of organizational problems that need resolving. And yeah, you don’t own the company, but that’s why we’re kind of talking about this Founder Mode idea, or the idea of your ego becomes aligned with what is best for the organization as a whole, what’s best for the company. And if teams aren’t communicating, that is not going to result in an effective organization, in a company that is as successful as it should be.

So that’s where you can run it up the ladder. And you might fail, you might get pushed back, and there is always politics… So someone might say “Well, we can’t do this, because that manager is just overwhelmed, or not too good at their job”, or whatever. But I think the Founder Mode or the leadership idea is that you at least try and fix it, and try and find a remedy, or try and start a remedy from happening. But in the immediate mode, you have to deliver something, so make the decision, and then move forward. And if people complain later, they complain later. And you say “Well, you had your chance, and you didn’t say anything”, and if your leadership comes back and says, “Oh, well, turn around, do it a different way”, then it’s probably time to find another job.

I kind of feel like the way that you’re explaining that, though, Kris, I think that is a more toxic work environment, to me.

In what way?

[42:01] Pushing forward, and breaking eggs, and having people be like “Why did you break these eggs? Why didn’t you include us? Why didn’t you–” That seems to sow disparity between teams that had you just had the conversation, talked about it more openly, flagged it in a way that didn’t feel quite so combative… That could have – yeah, I think you might spend more time in conversations, not doing work, but I do think that actually lends itself to a healthier work environment, if you’re able to stop and be like “Hey, I have this problem. The ideal solution involves these two other teams. They, benefit of the doubt, aren’t giving me the time of day; maybe they don’t mean to, maybe they’re just like on tight deadlines themselves… Let me own the fact that this is the problem, I’m going to identify it, I’m going to make sure those involved know what the problem is… Let’s collaborate together to solve it”, as opposed to “Oh, this is a problem, let me drive.”

The premise I had started with was that communication had already been attempted, and that you were not getting any response back. Obviously, the first step is to go talk to the teams. Like, you don’t just make a decision. The whole point of what I was saying is “Okay, you own this, you need these other two teams, or these other two teams have the context to make the decision… Okay, go talk to them.” Then if they’re not giving you the time of day, they’re not responding to emails, they’re not communicating with you, that’s when you need to a) protect yourself by making sure that your project doesn’t fail, or what you need to do doesn’t fail simply because someone else isn’t doing their job or isn’t holding up their end, and then try to resolve whatever the problem was with why they weren’t holding up their end. But obviously, the first step if you get a project that involves multiple people or multiple teams is to go talk to those teams. That’s absolutely required.

Or start opening PRs in their repos, and then adding #FounderMode at the bottom… [laughs] “Y’all can’t get to this. I’m gonna start doing it for you. I’m in Founder Mode, damn it.” Oh, man… Yeah, okay, so I think overall I think that there is consensus. The style may be a little different, but there is consensus on on what Founder Mode really should mean, even if you’re not a founder.

So there is something to be gained, even if you’re not technically incentivized monetary or otherwise by not being a founder yourself right there. There is value in taking ownership of things, there is value in sort of really, ultimately what it sounds like is learning how to be a better communicator to me, ultimately… Which somehow seems to always come down to that, “Learn to be a better communicator”, whether it be through your code, through cross-team collaboration, whether it’s managing up, as they say… It all ultimately could all just be better communication. And Founder Mode really to me is all about sort of that communication combined with sort of initiative. Taking initiative to do things.

Break: [45:15]

So I think with that, I think it’s a good time to transition into Unpopular Opinions, which - I think there might be a couple after this chat.

Jingle: [46:42]

Alright, who wants to who wants to land on me first?

I think Angelica should go first.

I mean, I haven’t –

You’re volunteering…? [laughs]

I haven’t got one.

That’s poor leadership of you, Kris.

Oh, no. Hey…!

Kris, why don’t you go Founder Mode and own this one? [laughter]

You’ve reached out to another team, they’re not responsive… Take ownership and drive forward.

I mean, I’ve got unpopular opinions for days. So let’s see… What should I start with…? Something I’ve been pondering a lot lately is that this industry needs more people with liberal arts degrees; it especially needs more English majors. Because I am very annoyed at this industry’s inability to use English words properly. Like, just – we’re bad. We’re bad at it. And I’ll give you an example of something I’ve been thinking about a lot lately, which is that the words concurrent, synchronous and parallel are all synonyms for each other. They mean slightly different things, but they are all equivalent, roughly. And yet, we use them to mean completely different things. Like, something that’s concurrent is not necessarily parallel. And synchronous isn’t even used when we’re talking about concurrency or parallelism. It’s talking about something else entirely… Even though synchronous and parallel basically mean the same thing. And to go on this rant a little bit more, parallel implies non-convergence also… So concurrency and parallelism are also – the way that we use them is just wrong.

But the other thing about this is that concurrent and synchronous are synonyms, and synchronous and asynchronous are antonyms. They mean the opposite thing. But people use concurrent and asynchronous to basically mean the same thing, which doesn’t make any sense. If you’re like “Oh, I’m going to go write this code in a concurrent way”, if someone has said asynchronous instead, you’d be like “Yeah, okay. That’s a word that would also fit there. Fine.” So now we have a situation where we have all these words, and the ones that we’re saying mean something similar and in the actual language mean opposite things… Which just doesn’t make a whole lot of sense. And that’s just really annoying me.

I think this is a case where we need to try better to look up the definitions of words, and actually use etymological references to understand what the meaning of words are, because we’re really bad at it, and it’s making us look really dumb, and it’s also making it very difficult for other people to learn how to be good software engineers, or understand software engineering at all. And I think we also wind up confusing ourselves often.

Okay. My unpopular opinion is English is hard. Ignore Kris. [laughs]

[50:07] It’s not that hard. I mean, you’re wrong. It’s not that – it’s not that hard. I mean, a thesaurus. That’s all you need.

That’s all you need. A thesaurus. Look at the word before you name something… Make sure it doesn’t mean the opposite of what you mean.

It takes too long. It takes too long. Evidently.

If you don’t have time – okay, here’s a spicier take. If you don’t have time to actually look up what words mean, then you should not be writing software.

Oh. Okay. Well –

That’s a spicy one.

Yes. We’ll let the people decide. We’ll let the people decide.

I mean, hey, at the end of the day, we’re all writers. So if you aren’t going to respect the writing profession, you can get out. That’s all –

Oh, you woke up this morning and chose not health. Not healthy.

Spice.

Spice. The spice must flow.

I love that.

You know what it is? When I try to explain… These concepts are not – it isn’t difficult to understand what is happening if you use words that make sense. But I think the problem is is that since we don’t use words that make sense, we wind up confusing ourselves about what is actually going on. And we wind up making words be meaningless.

Sam Newman has a talk about how asynchronous as a word is now completely meaningless, because in order to understand what someone means when they say that word, you have to shove so many other contextual words around it that you might as well not even say asynchronous. But it’s also – like, asynchrony is a good example. Because if you think about, let’s say, the event loop in JavaScript, where you say “Okay, well, that is asynchronous programming because you have a callback that gets returned to you, or you use async/await, which is just kind of a way of wrapping around callbacks.” You’re like “Okay, that’s asynchronous.” And I would ask “Why?” Why do we think that that is asynchrony, like not in time? What is the measure of time that we’re talking about? It’s concurrency; it’s concurrency with other things that you aren’t running. But as far as the logical time of your application, it’s still synchronous. If you do async/await, if you call await, your thread of execution logically stops, and then goes again. And it’s just still operating with time.

[52:32] So if you say asynchronous means like “without time” or “without a logical step with time”, what time are you even talking about? I think that people that named these things didn’t think about any of this at all, which is why the names are rather silly. But I think it does have rather large consequences on us as an industry, because we wind up designing things that just don’t really work that well, because someone came up with a word, and they named it that way, we didn’t really understand the concept that well, but everybody’s using it, so it’s popular.

I recently started trying to learn Swift, and I got to the part of the concurrency model of Swift, and I was like, you know, didn’t the dude write – Robert Nystrom, I think his name is… Didn’t he write what colors your function article? Like, so long – I guess he did write it after Swift was created, but it’s like, he wrote it so long ago. Why are we still having languages that have this problem of these colored functions and you can’t really call one from the other because of the weird models of asynchrony and synchrony?

Like, we as an industry shouldn’t be making these mistakes, because it makes it really hard to program, and it makes it really hard to get our programs correct. And popular opinion, “Go got it right with goroutines”, where everything is synchronous; you can just call go and it just works. I’m just filled with spice today. Lots of spice.

Yes, indeed. And before you go on another rant, Kris, I’m going to stop you right there.

Hey, we can do some Plus Plus bonus content…

No, no, no, no, no. We people have managing and delegation to go do, and ownership to go ahead…

Yeah… I literally have a meeting after this that is about delegating some tasks to my team, so…

We’ll just delegate running the meeting to somebody else, Angelica. That’s how this works.

I did. I delegated it, but I’m taking Founder Mode, and I will be in the meeting, listening to every word they say, and making sure that everything’s –

Boom.

You just send some random person “#FounderMode”, and it’s kind of like tag, and now they’re the one that has to do Founder Mode, and you can just stay here and talk about unpopular things.

I don’t want to go to the board next week and be like “Sorry, I just let the team do whatever. #FounderMode.”

But have you tried it? [laughs] Alright, alright, let’s not start another rant. Alright. Thank you, listener, for being on this episode with us, and I hope you had fun along with us. With that, we’ll see you on the next one.

Bye…!