People Driven Development

PDD: Episode 10 - Systemic Imposter Syndrome
===

Morgan VanDerLeest: [00:00:00] Hey everyone. Welcome back to the PDD podcast. Eddie and I both took some time off to do some summer traveling, and now we are back ready to continue the journey. So the annual Grace Hopper Celebration or GHC has just taken place in the second week of October. For those unfamiliar, GHC is the world's largest tech conference for women and non binary people. In today's episode, we decided to honor that occasion by addressing a very thoughtful question we actually encountered when we were just getting started with the podcast. We feel now would be the right time to discuss it. All right. Dear PDD. I'm a first time head of engineering for a Series A tech company. I was promoted to the role after three years here and five years at a different startup before that. I think I inherited a healthy organization overall: work-life balance is decent, people are nice and helpful to each other, the work is interesting, and I appreciate the benefits. The thing is the attrition is a little crazy and it makes it very difficult for the team to be effective. In the past three months alone, we lost three team [00:01:00] members who've been here for under a year. They were on different teams with different managers, but they all had something in common. In the exit interview, they all reported work stress is the main reason for leaving, but no one had any example of what we could do differently. A common theory I've heard when discussing this was imposter syndrome. People who've left in the past year were mostly more junior and maybe they were just stressed about working with experienced people. So my question is. Do you think that's what it is? Meaning we should do our best here to support them and otherwise just accept that frequent transitions are prevalent at this career stage?

Eddie Flaisler: I have to say I'm eternally impressed with managers who generally are interested in the experience of their team members and the impact it has on the organization. It's not obvious. This is a really good one. Could the intro? Let's do this.

Morgan VanDerLeest: I am Morgan.

Eddie Flaisler: And I am Eddie.

Morgan VanDerLeest: Eddie was my boss.

Eddie Flaisler: Yes.

Morgan VanDerLeest: And this is PDD: People Driven Development.

Morgan VanDerLeest: Okay. Before we dive in, assuming they diagnosed the problem correctly, and it is imposter syndrome, should [00:02:00] I call out the elephant in the room or should you?

Eddie Flaisler: You mean the part about us being two white men discussing a phenomenon considered most prevalent with women and people of color? Yeah, I think we should probably acknowledge that, but here's the thing, Morgan. I don't think we should do an episode on supporting individuals with imposter syndrome. I personally don't feel equipped or entitled to reflect on how it must feel for others or, you know, what kind of help would be most effective today.

Eddie Flaisler: I do experience imposter syndrome myself quite often, but the reality is that, how should I put it, we're part of a demographic that society mirrors back their self doubt to them the least. You see what I mean?

Morgan VanDerLeest: That makes sense. I can't deny that I feel the same way, but I would say it probably impacts me less for better or worse. So how do you think we can be helpful there?

Eddie Flaisler: So we can be helpful by challenging a fundamental assumption they made.

Morgan VanDerLeest: And what is that assumption?

Eddie Flaisler: The assumption is that If it is indeed imposter syndrome or any other performance impacting comorbidities like depression or anxiety, [00:03:00] then these are issues that start within the individual and in the vacuum of their own life situation. So as long as we're being nice and respectful and don't work anyone too hard, We've done our part, and the rest is just between them and their mental health provider.

Eddie Flaisler: As Donald J. Trump says, wrong!

Morgan VanDerLeest: That's a good point, Eddie. It's easy to assume that these are solely individual problems that we just want to avoid making worse. But we need to think about the organization's role in all of this. For example, there's a culture of overwork that's going to make it harder for people to feel like they're good enough, no matter how talented they are. So just to get everyone on the same page, I think we should start with the textbook definition of what imposter syndrome is, and then talk about what this actually looks like in a work setting. Let's see from the National Library of Medicine. Imposter syndrome, or in short IS, is described as self doubt of intellect, skills, or accomplishments common among high achieving individuals. These individuals cannot internalize their success and subsequently [00:04:00] experience pervasive feelings of self doubt, anxiety, depression, and or apprehension of being exposed as a fraud in their workplace, despite verifiable and objective evidence of their success. That was a mouthful.

Eddie Flaisler: It really was. You know, the whole story around imposter syndrome is pretty astonishing because it helps explain and specifically address so many of the issues we see in workplaces across all types of employees. However, even though it's been popularized in DEI circles, you don't hear a lot about it when discussing management in general.

Eddie Flaisler: It's like it's some edge case of employee management. And the thing is, we should all care about IS. Not because, you know, somehow the new age manager needs to also be a therapist, but because mental health challenges are part of the baseline package that people bring with them to work. You know, whether we acknowledge it or not in corporate America, we all have some default behaviors and patterns that are detrimental to our experience and to that of those around us. [00:05:00] It's called being human. Now, more often than not, these behaviors come as a reaction to our environment. So, design a better environment and you bdiscourage unhelpful behaviors.

Morgan VanDerLeest: Say more and do so more concretely.

Eddie Flaisler: Yeah, well, as the definition of IS that you brought from the National Library states, At its core, it's about self doubt. And the problem with people who doubt themselves too much isn't the actual self doubt, but what it makes them become. They typically end up as one of four archetypes or let's call it mindsets.

Eddie Flaisler: The first one is perfectionist. So this thing has to be done just right, or else I'm not enough, right? I also cannot trust anyone else because they might make me look bad with their subpar work.

Morgan VanDerLeest: I think that's definitely one that we've all had as managers or either been this person or have all had on the team and helping that person do better themselves and fit into the team is so important.

Eddie Flaisler: I can definitely align with we've all been that. Yeah. Perfectionism is a very common malady. I suffer from myself. The [00:06:00] second one is superheroes. So superheroism is about if I don't kill myself at work and feel like the future of the entire company is on my shoulders. What value am I even bringing?

Eddie Flaisler: Now, if you think about it, this also includes the tendency to work alone and to take on too much, because if I can't do it all by myself and I need help, I am less than. And of course, when you judge yourself for needing help, you also judge others.

Eddie Flaisler: One very sad story that I remember from my career was when I just inherited the new team and in my first one-on-one with one of the developers, they literally started crying on camera. And said, I wanted to let you know that I'm quitting.

Eddie Flaisler: And this is our first one on one and I asked what's going on. And they say, I can't do this anymore. I work day and night, all these incidents, the system are always down. I need to bring everything up. I need to debug. Nothing is ever working. I dream about the company. I dream about work. It consumes me.

Eddie Flaisler: And between [00:07:00] our conversation and the follow up I scheduled with them a few days later. I went and did some homework, and I found that, yes, they were logged in at crazy hours, practically 24 7, but also, there was no particular incident or issue or guidance or high priority bug that they were tasked with working on.

Eddie Flaisler: So, the self induced stress was just so incredible to watch. I unfortunately was not able to prevent them from resigning, and quite frankly, for their own mental health, I'm happy they did and got the break they deserved. But I think this is just a very extreme example of what happens when we let our inner narrative take over.

Morgan VanDerLeest: Work life balance is so hard for these folks to balance. I remember working with someone who very much saw themselves as a superhero for better or worse. And honestly, they were. There were so many times when they took the company upon their back. They showed up for, not just engineering and engineering issues, but [00:08:00] teams across the company. And then there came a time when everyone at the company was asked to step up more and they were like, yes, finally, other people are going to be doing this too. And I was like, hang on a second.

Morgan VanDerLeest: There are people that , can't do what you do. This person didn't have a family was really just responsible for themselves. Didn't have anyone else they were taking care of. To ask everyone to be a superhero when that is just not physically possible within your work and to have that expectation across others. It was really enlightening to them to hear it and then talk to some other engineers and realize like, Oh shoot, like I'd been thinking about this like, it was just my viewpoint. And really we want to enable a world where at some point this superhero can have a family and is not expected to be working for 12, 16 hours a day. And it's a really tough thing to work through and process, but a lot of times they can't even see it without taking a step back and realizing how they fit in and how things really can work within the company. It's a tough value. And also because we lean on them so much, it's tough.

Eddie Flaisler: 100%. And I think that this is something we covered in [00:09:00] previous episodes, and especially around developer productivity. I'm not going to deny that sometimes hard deadlines or you know, releases or bugs do mandate that people go above and beyond. But creating this culture where it's always 24 7, always on, for no real business reason, doesn't really help anyone.

Eddie Flaisler: Anyhow, to, to get us back to the archetypes, the third type is known as natural geniuses. As the Decision Lab Institute calls it. That type is about "I'm not going to ask any questions and won't empathize with any struggles. Because that means I'm not smart after all". And and I can tell you that this has always been an issue for me, even in my personal life.

Eddie Flaisler: I feel out of all four. The natural genius is the biggest one.

Morgan VanDerLeest: This is something that's very pervasive and it really hits on your sense of self worth in a big way. You know, we tell our kids like, Oh, you're wonderful. You're great. You're so good at this. Oh, you're so fantastic. And then you get to the point where you feel like you need to [00:10:00] be fantastic at everything and to know everything and be that, be that natural genius. When in reality, that's an unfair expectation of anyone, first of all, and you don't need to be that. That's not the point.

Morgan VanDerLeest: And we are better if we are integrating and interacting well with other people and self siloing yourself is never a good thing.

Eddie Flaisler: I think you totally hit the nail on the head with that. And it's kind of the, you know, it's kind of the core issue that people deal with in parenting, I feel like finding the balance. Well, one of the core issue. There are so many core issues. But finding the balance between raising a confident, happy, proud child who believes and knows they're doing well and that they're enough.

Eddie Flaisler: But not transforming all this list of achievements, of recognition into this baseline expectation that now the person needs to meet.

Eddie Flaisler: Speaking of expectations, the last archetype is experts And I don't have data on this, but it [00:11:00] feels to me like this is a very, very common archetype in the industry.

Eddie Flaisler: So experts are about, "I need to know this thing better than everyone else. It's my justification for being here." And this one is very problematic because it discourages knowledge sharing from several angles. On the one hand, one might worry about their status as an authority on the subject, so they would not be motivated to teach others the full picture.

Eddie Flaisler: On the other hand, even if they're not worried, they might still underestimate the complexity of what they know because they think they're, well, imposters. And if they think it's super straightforward, they might not give proper support to people who want to learn it from them. So, to bring it all together, we have four mindsets associated with IS.

Eddie Flaisler: Perfectionists, superheroes, natural geniuses, and experts. Now get this. Today's our 10th episode. And by now, we've spent hours and hours talking to a very long list of unhelpful and unhealthy behaviors observed at workplaces.

Eddie Flaisler: And you know [00:12:00] what, Morgan? I cannot think of a single behavior we talked about that doesn't have at least some roots in one of these four unhealthy mindsets. So many people problems start with these.

Morgan VanDerLeest: Absolutely. And to just be aware of these kinds of like fundamental root mindsets can really help us address and mitigate or prevent issues in the first place. Things like, being more forgiving of errors to help perfectionists or giving opportunities to experts to share their knowledge in a productive and helpful way that benefits everyone from that knowledge and doesn't keep them as the sole expert on the thing. Now, I'm normally the one who's rushing to get us to the actual advice part, but I think we have to spend some time here on the issue of boundaries. I think the whole concept of mental health at work is a very fine line that managers need to walk. On the one hand, we're both aligned on the business significance of a happy and healthy team. But I think you'll also agree that it's a very dicey territory, implying that a manager is somehow responsible for the mental health of their reports. Not only because it raises questions about the extent of corporate [00:13:00] accountability, but also because mental health is often much more difficult to objectively assess than other areas where there are measurable physical markers.

Eddie Flaisler: Yeah. So what I hear you saying is that you find it problematic to hold managers accountable to aspects of their team's experience, which not only can be impacted by factors outside work, but are also difficult to objectively assess. So they're prone to, I don't know, misreporting if an employee wants to retaliate against their manager.

Morgan VanDerLeest: That's exactly right.

Eddie Flaisler: Yeah. Well, first of all, we are a hundred percent aligned here. I personally would not want to be measured on the mental health of my reports. Nor would I like to be held accountable for every instance of problematic behavior anyone on my team demonstrates. That's not what I'm saying. What I am saying is that each unhealthy mindset we discussed comes with an existing set of preventative patterns we can use to design our organizations and structure our work.

Eddie Flaisler: By focusing on these, we as a leadership team can do what's, you know, [00:14:00] within our control to promote a healthier mindset among our team members. As an extreme example, I cannot prevent, heaven forbid, cancer in an employee. But I can make sure my office building does not contain asbestos or other cancer causing substances. Being involved in the resolution of a problem we have in the organization doesn't automatically imply fault or liability. It just means we're doing our job.

Morgan VanDerLeest: Yeah, I think that's very fair. We're not therapists, but we can certainly talk about how engineering organizations can create a more supportive environment for their teams. So It's time we get into solution mode. How do you want to tackle this? I'm thinking we start by mapping how the imposter syndrome mindsets show up in the behaviors we see in engineering teams. That'll hopefully make it a little more tangible for everyone.

Eddie Flaisler: That makes sense to me.

Morgan VanDerLeest: Okay. So perfectionism I'm thinking: challenges delegating or working in a team that are based in this foundational lack of trust that you talked about; keep adding features and delaying a release because you're scared to own the cutoff.

Eddie Flaisler: Isn't that a [00:15:00] story you heard from every single person you know who works in tech about why do we keep adding things? Why is the release keep getting pushed? I don't understand. It's not necessarily sensible. And I feel like it's such a big deal, like that, that ability to say, this is enough.

Eddie Flaisler: And if this is not enough, I will own that decision. I'm not saying there are not legitimate decisions to postpone a release. Obviously, we've encountered those so many times. I'm confident you met people, a lot of them, who have all these stories about, I don't know, they just keep adding features and like we're never done.

Morgan VanDerLeest: Yes, for sure. That's something that honestly is super top of mind for me. Most of the time now, I was like, what can we cut out of this? I know this is the epic that we have, cool, what can we cut? Because there's probably things that we can do later. Speaking of things you're not gonna need, YAGNI, you ain't gonna need it. I have to release this amazing thing that technically has all the bells and whistles, or else I'm doing a shitty job.

Eddie Flaisler: Absolutely.

Morgan VanDerLeest: You know, I think another one, [00:16:00] probably procrastination, because the bar for what needs to be done, it always seems so unachievable to begin with. I'll get to this task later. And then lower priority items are magically prioritized higher than those that actually matter.

Eddie Flaisler: I think the procrastination one is really, really good because. Again, I'm not sure we can attribute what I'm going to give as an example to that only, but that is definitely the case sometimes. I think as a manager, it's very, prevalent to encounter a situation where you give someone a task and then they say, I didn't do this because I did something else.

Eddie Flaisler: And then you start this whole complicated conversation because they did work and they worked hard and they did something else. It's not like they sat there did nothing, but they didn't do what you asked. Then you try to dig into why wasn't that thing done? And ever so often, you can't actually get a good response for why?

Eddie Flaisler: And I feel like, at least in some cases, it really is about, okay, I [00:17:00] just can't do this right now. I'm going to find something else to do. That will make me feel in control and I'm going to focus on that. So just a side note.

Morgan VanDerLeest: To extend your side note. I think that's why it's so important for Organizations to focus on the value or the objectives that you're aiming for versus the metrics of getting work done and there's number of tickets in a sprint. It's very similar thing. "Well, I hit my ticket numbers. So I did what I needed to do, right?" I'm like, no, we, we totally put this strategic project down and did this totally different thing. I would much rather it was a ticket, but it was the one that we needed versus 10 little things that didn't matter at all.

Eddie Flaisler: 100%. Cool. Let's do the next one. Superhero. So this one is really easy because we've actually discussed the superhero engineer anti pattern in previous episodes. You know, "look at me, I debug till 3am on a weekend for this customer. What would the company do without me?" But you know what's worse, Morgan? When it is the manager who wants to be the [00:18:00] superhero. So they impose unrealistic expectations on their team and don't say no to anything. It's not the only reason people don't say no when they should. But it's definitely up there.

Morgan VanDerLeest: You know, that's a good point, and it's something that we've kind of lightly touched on. It is even more difficult to help solve some of these issues or to help support the different mindsets when one of these mindsets is the manager on the team.

Eddie Flaisler: That is so true and is a key reason why I always say that probably the most prominent characteristic I look for in a manager is introspection.

Eddie Flaisler: Right? The ability to ask yourself. Because we're all irrational beings, but the ability to ask yourself, did I make this decision from the right place? I think it's really important because your decisions impact many others.

Morgan VanDerLeest: Speaking of self retrospection... Natural geniuses. I feel like this one is such a huge issue in software engineering in particular. What is it that you like to say that the worst day in the history of software engineering was when someone first attached the word "talent" to software engineering, [00:19:00] starting the conversation about "software engineering talent."

Eddie Flaisler: Yeah, because you don't hear about mechanical engineering talent or genetics talent, right? But somehow, at least pre-ChatGPT, if you knew how to code, you're all that. And you kind of brought it up earlier that being all that creates a lot of pressure.

Morgan VanDerLeest: It associates the job with this status of intellectual superiority that needs to be maintained. So suddenly it's awkward saying you don't understand the design or asking for help with this code.

Eddie Flaisler: Totally. Some of the biggest incidents in history in and outside tech happen because people were hesitant to ask.

Morgan VanDerLeest: True. All right. What about experts?

Eddie Flaisler: So maybe unsurprisingly, the biggest blast radius I've seen from people having the expert mindset wasn't when it was an individual contributor who found identity in being the one who knows everything, but when it was a manager. One of the biggest challenges of my career has been working with managers who have this subconscious need to be the expert.

Eddie Flaisler: It was very frustrating [00:20:00] working for them, and even more frustrating managing them. You know, these individuals often end up in management by building a team around a product whose MVP they themselves built, and now they're deeply attached to it. Or, another way to adopt this mindset is when in your early days as a manager, no one coached you or incentivized you to stop focusing on your own direct contribution to the critical path of the product and start focusing on your teammates.

Morgan VanDerLeest: You seem to be emphasizing the expert mindset more than the others. Is there a particular reason for that?

Eddie Flaisler: Yeah, so I definitely am. I think there are too main reasons why the expert mindset is so scary. Especially when it's a manager who has it. One reason is that these individuals become silos of knowledge. Others, including the reports, don't have the visibility they need to fully understand and be effective in working on the system, right?

Eddie Flaisler: So not only are these other people not properly utilized, but also the expert is so irreplaceable to the business, that they can get away [00:21:00] with many other unacceptable behaviors. The second reason is that this mindset is a huge blocker for innovation. Even when the person is generally motivated to make the product or service successful.

Eddie Flaisler: Because their knowledge of the current system is what gives them self worth, they're often opposed to making any major changes. And they get their way. Not only because the business leadership is so scared to lose them, but also because they speak so confidently about the current system that the confirmation bias in others does its thing, and now everyone thinks it's a good idea to leave things as are and work around them.

Eddie Flaisler: You know, the last thing I will say is that I keep talking about not othering people, but I also keep saying they, they, they when I describe this mindset. I want to clarify that it's been easier for me language wise to use they, but it's actually us. No one wants to suffer from imposter syndrome.

Eddie Flaisler: It's an issue we all struggle with trying to show up and we all want to do our best work. So it's just a work in progress for everyone.

Morgan VanDerLeest: You're absolutely right. It's important to remember that [00:22:00] imposter syndrome is something that we all struggle with from time to time. It's not something that other people experience. So I love that call out. We all have moments when we feel like we're not good enough or that we're going to be exposed important thing is to remember that these feelings are normal. We can overcome them and we can create an environment that helps people deal with them as well. We now have a good sense of what imposter syndrome and its associated mindsets look like in engineering. We said earlier in the conversation that we would focus on the systemic causes for IS as well. So let's talk about that. What was the organization's part in getting us to this problematic place?

Eddie Flaisler: I can think of a few things. One is we de prioritize entirely or almost entirely work intended to streamline the development lifecycle. What we also often do in parallel. Is reward those who are able to thrive in the mess by propagating it further under the guise of moving fast as opposed to the people who are invested in leaving the code in better shape than they found it.

Eddie Flaisler: This is exactly what we covered with Erin in the last [00:23:00] episode. If I have code that keeps crashing in production, and is not only of poor quality, but lacks the logging and observability to efficiently debug it, but the roadmap always magically includes just the next shiny feature that in practice requires five people working nights and weekends to keep it up, and memorizing random commands because nothing is automated, Then not only is it obviously poor use of resources, but also I have an environment that's ripe for imposter syndrome.

Eddie Flaisler: It rewards quote unquote expertise, right? The expertise is in these messy scripts that isn't of any value outside the actual product. It makes knowledge sharing impossible because how can you learn a system which has no way to peer into its inner workings? And if that's not enough to make the smartest person feel stupid, it's Then, you know, you can only imagine how it feels for an engineer who was told they came here to work with world class talent when they can't even get their code to build locally to test the correction of a spelling mistake.

Morgan VanDerLeest: Hits a little too close to home. [00:24:00] One thing that comes to mind too, is how we onboard new engineers. If we don't give them the information and support they need to be successful, we're just setting them up to feel like imposters. Need to make sure that new engineers have that kind of clear understanding of their role, responsibilities, how they fit in, what their onboarding plan is going to look like, and that they have the resources they need to do their job well and feel welcome and supported by their team. Often getting this right in the first place is one of the best things that we can do to help combat the way that people feel imposter syndrome within the company.

Eddie Flaisler: That's exactly right. I think the science definitely agrees that The first moment, the first days, weeks, months in someone's onboarding journey to the company are the ones that are going to eventually determine how long they stay with the company and what it is they're going to do there, how impactful they're going to be.

Morgan VanDerLeest: What else?

Eddie Flaisler: You know, another thing we tend to do is engage in communication patterns that are conducive to social cli We actually discussed this in the past. It can be making design decisions on Slack without a structured record that everyone can find, follow, understand.

Eddie Flaisler: It can also [00:25:00] be calling services by a name we find funny or cool, but isn't self explanatory. I believe it was your team who inherited the notorious Pizza Planet service at Lob, which, out of respect to Lob's proprietary information, I won't mention what it does, but I will say it's not related to pizzas or planets.

Eddie Flaisler: So when my teammates are talking about something that I think I should understand, and I don't, that's imposter syndrome right there. Again, you do not want to other people. There will be a direct cost in what they bring to the table.

Morgan VanDerLeest: Absolutely. And I harp on this a lot, but this is a great example of why you should aim to ask questions and over clarify everything that's said. Take the time to recap. Even things like calling out acronyms in the chat in case someone forgot what the meaning of them was in the moment. Building up common definitions of things. But even if it exists in some doc somewhere, pull that context in, in the middle of the conversation to help folks keep up with the conversation. Things like that.

Eddie Flaisler: Totally. A lot more engaging, a lot more [00:26:00] inclusive.

Morgan VanDerLeest: Yes. All right. What else?

Eddie Flaisler: You know, the product isn't the only thing that needs to be user friendly and customer centric. The code has to be that as well. I've actually worked for organizations that had strict guidelines around using constructs like templates in C++ or design patterns like proxy. They basically limited the use of any coding practices that are inherently challenging to follow.

Eddie Flaisler: And that paid off big time. You know, reuse is important, encapsulation is important. I'm not saying don't write succinct code that has potentially less work to maintain. On the contrary, but there are always trade offs with readability. Right? The entire culture around you're not smart enough to understand my brilliant code is all too common.

Eddie Flaisler: And I think at this point in the episode, we no longer need to explain how it contributes to IS. Not to mention, it's also bad for the business when the person quits, and then the next developer spends weeks fixing a bug that should have taken hour tops to figure out.

Morgan VanDerLeest: Never underestimate the value of human readable code, especially when you're under stressful circumstances [00:27:00] like an incident and trying to quickly grok a file to mitigate an issue. Writing efficient code does not mean writing code that's unreadable. All

Eddie Flaisler: Totally.

Morgan VanDerLeest: Alright, next.

Eddie Flaisler: Micro inequities. You know, coincidentally, Lizzie Matuso, who writes one of my favorite professional newsletters named Research Driven Engineering Leadership, wrote about this one in one of her latest editions. She focused, and rightly so, on women versus men, but for the purpose of this conversation, I say it doesn't matter who we're actually doing it to, just don't. So, Lizzie mentioned things like interrupting someone while they're talking, or withholding credit and acknowledgement, and sometimes even blatantly giving it to those undeserving of it due to social capital.

Eddie Flaisler: She also talked about someone being skipped over during the question that should have been directed at them. She mentioned things like being told you're bossy or aggressive for asserting yourself. And I'm not even talking about outright harassment, sexism, racism, casteism, and all the other isms. You know, the subconscious [00:28:00] remembers.

Eddie Flaisler: And we, as the offenders, end up reflecting back to the team member their deepest insecurities. And they in turn end up as someone whose work reflects the fact they don't want to be here because we mistreated them. I'll share a very personal story here. In one of my earlier jobs, I had a team lead, scrum master, who I respected technically very much, but was a terrible person otherwise.

Eddie Flaisler: And during stand up one morning, he asked the group a question. We're standing in a small circle, And as I started answering, he puts his palm about an inch from my face in front of everyone and says, "You shut up, I need an answer I can trust." I think I don't need to tell you that in the very little time I continued working there before giving my notice, I had zero initiative, not just because I didn't feel like he deserves my investment, But also because I didn't feel like I had any value to add.

Morgan VanDerLeest: Unfortunate that people who act like that are still responsible for teams and businesses. That reminds me of a manager I had [00:29:00] once who complained that the people on my team were asking dumb questions in Slack and that he could do the work faster than them. Think about the culture that mindset creates. How do you expect anyone to achieve their best if everything is judged based on the internal capability of a person at the top? And to top it off, I'll give you two guesses whether those comments targeted men or women and non binary people. You only need one guess.

Eddie Flaisler: I won't make that guess, but I guess everyone else can.

Morgan VanDerLeest: I don't remember if we covered the stack protocol here or not. That's an example of an approach that might be helpful to teams and minimizing these instances of disrespect, isn't it?

Eddie Flaisler: Yeah. So for those unfamiliar, the idea behind stack is creating a queue of raised hands to comment or ask questions. Some tools already exist that implement that others do not. But the idea is that people participate in a large scale or virtual conversation in true order and not just according to the personal, often not even conscious biases of the moderator, right?

Eddie Flaisler: So, you ask first, you're going to [00:30:00] answer first. Of course, it's just one micro thing in the list of things we mentioned, but it is an example of something you can do in terms of structure, process, systemically to make things better.

Morgan VanDerLeest: Love that because it's something just anybody who's listening to this can like instantly pick up and start using that. That's great. All right, back to the main thread. Anything else organizations can do here to make things better?

Eddie Flaisler: You know, when hiring us managers, I think we need to be vetted for saying no, saying no to stakeholders, accepting no from teammates, and controlling our own sense of scarcity. These tendencies are the reason we sometimes can't bring ourselves to own release cutoffs like we discussed. The reason we overwork our team well beyond what's reasonable, even tactically, to get effective results. Stuff like that. The best organizations I've worked with can exactly define what their idea of a high bar is. And it's always about consistent delivery of innovative and high quality solutions, not about volumes of half baked work that the team churns to not feel like you're [00:31:00] failing.

Morgan VanDerLeest: I love that idea of vetting for saying no, accepting no, and predicting scarcity. As IC lacking, those may hurt you and potentially those in direct contact with you. But as a manager, if you can't deal with saying and hearing no, you're going to hurt entire teams and that's going to bubble up to many more people. Something I've found helpful here is to keep refocusing on reality and our priorities. We cannot do everything all the time. What's more important? What's left? Is there a scope we can reduce or work that we can split into a future epic? Where's the value? Just because we said yes to this three months ago doesn't necessarily mean it's still a yes today. I think talking through this also makes me think of a good way to help with perfectionism. As a team, we can make our definition of done and hold each other accountable to what is and what isn't an overkill.

Eddie Flaisler: Absolutely. You know, just yesterday I was talking to a tech lead who mentioned they were frustrated by a team member. And the reason was the team member's code had a lot of smells, as they called it, and they didn't know how to [00:32:00] approach a conversation with the person. So, we ended up spending most of our time getting this lead to articulate what was it about the smells that they were worried about.

Eddie Flaisler: And we ended up with a sublist of asks where they could actually articulate the value in the change of practice. And another sublist, they just had to let go because, sure, it's not elegant. Pick your battles.

Morgan VanDerLeest: Definitely pick your battles and maybe a final one?

Eddie Flaisler: I think the topic of help is really important to cover because that's something people struggle with in personal lives as well. I know I do. There is this delicate balance in a work setting between asking enough questions to effectively move forward and asking too many questions which could have been answered independently. So that's where I'd flag on performance. I feel like people of all ages and levels of experience typically realize this is problematic.

Eddie Flaisler: So they very often don't ask enough, but when they do open the floodgates, it can be overwhelming. And I think more clarity about what's okay and what's not okay in asking [00:33:00] questions, set by personal example from the technical leaders as opposed to yet another write up no one is going to read, is ideal here.

Morgan VanDerLeest: Totally hear you on that. I actually found a certain pattern to be very helpful, which is pretty much the only thing I want my team members to agree on with me and amongst themselves, timing. Collect your questions and ask once or twice a day at agreed times, as opposed to overwhelming the person you're asking with constant context switching to answer. Not only does it cause less frustration from the environment, but also gives you an opportunity to research yourself while waiting. Assuming you're indeed motivated to unblock yourself.

Eddie Flaisler: Very powerful. If you agree on one thing, agree on timing.

Morgan VanDerLeest: Eddie, I think we've covered today some key areas where engineering organizations can reduce the risk of their teams experiencing imposter syndrome. As someone who deeply cares about DEI, I think I can tell you that there's already a lot of awareness around the do's and don'ts we discussed here in these circles. That said, I'm curious, do you think there's an aspect of the systemic causes of imposter syndrome or [00:34:00] any related issues like anxiety and depression that isn't getting enough attention anywhere, but should?

Eddie Flaisler: 100 percent and I feel like we should do a separate episode on just that. The aspect I'm talking about is is insufficient support for neurodivergent people in the workplace.

Morgan VanDerLeest: Can you say a little bit more about that?

Eddie Flaisler: Neurodivergence is not one thing. It's like, ten different things. Dyslexia, dyspraxia, dyscalculia, autism spectrum disorder, formerly known as Asperger's, Tourette's, dysgraphia, OCD, ADHD. I think the list is growing as we speak. The definition of each of those is out of scope for today, but I will share two interesting facts about this category of disorders.

Eddie Flaisler: The first one is, they are generally known as come one, come all. I mean, not all, but like, come one, come several. So your average neurodivergent, or in short, ND person, will have a combination of characteristics from different disorders in the category. So if someone has ADHD, it's not unreasonable to assume they [00:35:00] might have some autistic traits as well.

Eddie Flaisler: The second thing, and I know you're going to be in shock about this given how not socially awkward most engineers are, but neurodivergence is disproportionately overrepresented in tech. In the general population, I believe about 15 percent to 20 percent are assumed to be neurodivergent. So you can only imagine the numbers in engineering. And that's even before I get into the science of why in coming generations, I think what is now considered neurodivergent will be the neurotypical.

Eddie Flaisler: In any case, ND people suffer a lot from imposter syndrome and subsequently depression and anxiety. And what's interesting is that the research found it's not because they're inherently prone to that, but because the environment isn't inclusive of their needs. This is especially true in places like the U.S. Because in the U. S. regulation around ND people at work is still very early stage. For example, in the U. K. There's the 2010 quality act, and that act laid the foundations for things like [00:36:00] not randomly changing desk assignments for those who have an official diagnosis within the ND category. And asked to not be moved because the change bothers them.

Eddie Flaisler: In the U.S. I've personally heard these asks met with "don't be a baby."

Eddie Flaisler: If I were to leave the listeners with just one pointer about effectively managing the ever growing number of ND individuals, it is to always err on the side of more structure and invest in operational excellence. Not just because it's good for your offering, but also because it supports your team.

Eddie Flaisler: I have this ophthalmologist, Dr. Chen, and you know, there are plenty of good eye doctors in Oakland, and thankfully I don't have any particular problematic condition that requires some unique specialization, but I still prefer to drive over an hour in every direction when I need to see an eye doctor.

Eddie Flaisler: Why? Well, before she decided on a career change and went to med school, Dr. Chen was a preschool teacher for kids with special needs. And that background just screams for anything and everything she says or does. [00:37:00] Every step of the exam is explained.

Eddie Flaisler: She constantly checks in. She constantly makes sure you understand what's going on. Time with her literally feels to me like self care, because she offers the type of support many of us lack in our daily lives. Most people, myself included, are not this imaginary unicorn who's self driven, brilliant, and methodical, yet agile.

Eddie Flaisler: And quite frankly, I'm not even sure we as an industry fully know how to vet for those people. Chances are you'll end up with great people who still need support. And if you want to maximize what they produce, you need to put them first. You know, it's such a popular opinion on social media to say that if you have a great product, nothing else matters.

Eddie Flaisler: And I find that to be very limited perspective. If there's one thing I learned in my 22 years doing this, it's that "the how" does matter. Even if it doesn't matter to the business directly, it matters to the people who make the business. And they very much matter.

Morgan VanDerLeest: I know you didn't mean it this way, but I would like to push back on that last comment. [00:38:00] It does matter to the business directly. It just depends on whether the leaders of the business choose to act like it or not. More than anything, as a manager, you need to get to know your people. They don't need to tell you every detail of their lives, but do your best to be open with them, find out what stresses them, what strengthens them, especially in remote environments, you do need to go more out of your way to build that structure you talked about Eddie. Ask questions, be open to feedback. At the end of the day, no two people are the same. And you're a different manager

Morgan VanDerLeest: today than you were yesterday.

Eddie Flaisler: 100 percent.

Morgan VanDerLeest: Eddie, I really appreciate it. This was a conversation that means a lot to me that we're willing to talk about it. Not going to be perfect for everyone, but I hope it at least helps some folks in being able to better deal with some of the issues we see within the industry.

Morgan VanDerLeest: Appreciate it.

Eddie Flaisler: Thank you so much. I thought it was a great conversation

Morgan VanDerLeest: And to the listeners. If you enjoyed this, don't forget to share and subscribe on your podcast player of choice. We'd love to hear your feedback, anything resonated, or if we got anything totally and completely wrong, let us know, share your thoughts on today's conversation to people driven [00:39:00] development, all one word peopledrivendevelopment@gmail.com, or you can find us on X or Twitter @pddpod.

Morgan VanDerLeest: Bye everyone.

Eddie Flaisler: Cheers.

​