Transcript
Beth Anderson: At 8:53 p.m. on August the 5th, 1997, Korean Air Flight 801 departed from Seoul Gimpo International Airport, carrying three flight crew, two pilots, and one flight engineer. There were 14 flight attendants, 237 passengers on board. The flight was bound for Antonio B. Won Pat International Airport in Guam, the U.S. Island territory in the Western Pacific Ocean. The flight was under the command of 42-year-old Captain Park Yong-chul, previously a pilot in the Republic of Korea Air Force. He had close to 9,000 hours of flight time. He had recently received a flight safety award for successfully landing a 747 that had suffered an engine failure at low altitude.
The first officer was 40-year-old Song Kyung-ho, who had more than 4,000 hours flying experience, along with flight engineer, 57-year-old Nam Suk-hoon, a veteran pilot with more than 13,000 flight hours. It was raining heavily in Guam as Flight 801 made its final approach. Visibility was considerably reduced, and the crew attempted an instrument landing. The airport had a Glideslope instrument landing system known as an ILS, which is a precision radio navigation system that provides short-range guidance to aircraft to allow them to approach a runway at night or in bad weather. This was out of service. However, Captain Park mistakenly believed it was in service when he picked up a signal from another unrelated electronic device on the ground. At 1:21 a.m., cockpit voice recording captured the first officer saying, “Captain, Guam condition is no good”. Approximately 30 seconds later, the captain replies, “Uh, it rains a lot”.
The first officer questioned, “Don’t you think it rains more in this area here?” The captain didn’t respond directly to this. At 1:39 a.m., air traffic control called up, “Korean Air 801 cleared for ILS runway six left approach. Glideslope unusable”. No acknowledgement of the Glideslope being out of service was received from Flight 801. Cockpit voice recording then captured the flight engineer asking, “Is the Glideslope working?” One second later, the captain responded, “Yes, yes, it’s working”. At 1:42 and 19 seconds, as the aircraft descended, the first officer is heard saying, “Let’s make a missed approach”.
At about one second later, the flight engineer stated, “Not in sight”. The first officer echoed, “Not in sight, missed approach”. At 1:42 and 24 seconds, the ground proximity warning sensor can be heard making altitude call-outs of 100, 50, 40, 30, 20. A few seconds later, Flight 801 impacted hilly terrain at Nimitz Hill in Guam. Of the 254 people on board, 229 died as a result of this crash. The National Transportation Board determined that the probable cause of the collision was the captain’s failure to adequately brief and execute a non-precision approach, and the first officer and flight engineer’s failure to effectively monitor and cross-check the captain’s execution of this approach.
However, all of the information the captain needed was captured on the flight recorder. When we consider the nuances of the culture in the cockpit, we can see that the first officer and flight engineer were warning the captain. Maybe arising from a respect of authority or a fear of upsetting their superior, the co-pilots found themselves in a situation in which the pilot started a visual landing without an alternative emergency signal. Was this culture centering heavily around hierarchy, authority, and power distance to blame for this crash? Although the conditions arriving at Guam were challenging, if the captain had listened and taken heed of the warnings of his officer and engineer, the crash could have been avoided. Of course, we as software professionals aren’t often in this life-or-death situation, but using this as an extreme example of how power distance and hierarchy can hinder effective communication. We can apply the learnings to our own organizations and become aware of where effective communication is hindered by the culture.
Background
My name is Beth Anderson. I currently work as a principal software engineer in the BBC on the media services site reliability engineering team. We transcode and move and make available the BBC’s on-demand audio and video. We currently have, on the last check, 2.5 petabytes of content in our main on-demand origin. We’re the department that does the encoding and handling of on-demand content, and also live content, which we call simulcast in the organization. Prior to this, I’ve worked on a number of companies, such as small digital agencies, gaming companies writing embedded codes for arcade machines. I’ve worked on voice recognition systems, and also large companies like BT and EDS. During my time at the BBC, I’ve worked on a number of different teams, including the API backend for sounds and the data lab team, which is the artificial intelligence and machine learning specialist team at the BBC. I’m also a co-organizer of the London Gophers Go programming language meetups in my spare time. I’ve had the privilege of spending the last almost 30 years of my career writing software, including the 16 years at the BBC.
Over that time, I’ve had the opportunity to experience development teams as a junior software engineer, as a team lead, as a development manager, and now as a principal software engineer with the site reliability engineering team. Our team sits within a department called media services at the BBC, and we’re focused on enabling and empowering our product teams to build reliable products and services to achieve our goal of broadcast level reliability. We build components and systems that support our SRE principles, such as observability and release engineering. We provide consulting for other software teams. We provide out-of-hours support covering media services and our own systems. It is a tough job, especially with the out-of-hours on-call, but it’s hugely rewarding, and the team is incredible. They’re really the best people.
Over that time, I’ve learned that every single person I’ve met in my career has taught me something. By keeping an open mind to their ideas and their input, my own career has been immeasurably improved. During these 16 years, I’ve been able to apply these principles of software engineering, and I should say I’m not a psychologist, although I did study computer science and artificial intelligence back in the day at university. As part of that, I did two years of undergraduate psychology. My interest in this subject doesn’t come from a specialty. It comes from my desire to ensure that everybody feels safe and valued in their engineering teams.
Outline
During this talk, we’re going to look at power distance. We’re going to look at psychological safety. We’re going to look at what I’m calling asymmetric psychological safety. We’re going to look at how to curate psychological safety. We’re going to look at some active listening, look at some learning approaches. Also, some practical organizational changes that you can make tomorrow, maybe.
Power Distance
First, let’s talk about power distance. The concept of power distance was introduced in the 1970s by Geert Hofstede, a Dutch psychologist. He developed this through a survey in the ’60s and ’70s with IBM. The study asked questions of how frequently in the employee’s estimation were they afraid to express disagreement with their managers? Hofstede designed this power distance index to measure the extent to which power differs within the society, organization, and institutions, and how power is accepted by less powerful members. It’s helpful, I think, to look at some examples of what low and high power distance looks like. A low power distance could look like student-centered education, in which it’s focused on the learning outcomes of the students. Maybe parents treating their children as equals.
That subordinates have an expectation to be consulted before decisions are made. Subordinates is a term from that original study, it’s not an ideal term. Pluralist governments representing all people are based on majority vote, and they’re changed peacefully and democratically, maybe a point for current events. Religions stress the equality of believers. Also, that corruption is rare, and when scandals happen, they end political careers. These are all examples of low power distance, but of course it’s not a complete list, it’s just some ideas to get some estimation.
A great example, I think, of a low power distance relationship or environment is the environment that’s created by Leslie Knope and her team on the TV series Parks and Rec. Leslie actively encourages her team to share their own ideas, feedback, and criticisms, even if they disagree with her. She values their input and sees them as collaborators rather than her subordinates. The work environment she creates is very casual and friendly, and characters like Tom Haverford and April Ludgate and her boss Ron Swanson are comfortable making jokes, challenging ideas, and having personal conversations with Leslie, despite that she’s the deputy director. Leslie often seeks consensus, and she seeks collaboration when she’s making decisions. She trusts her team members to take the initiative and supports their own personal growth. While Leslie is technically the team lead, she often acts as a peer and a friend, and her leadership style is nurturing and supportive, and it’s rarely authoritarian.
As a comparison, let’s look at some examples of high power distance. Education in this example would be centered around teachers, maybe even focusing on dogma, propaganda that the teacher just simply wants to pass on by rote learning. Parents teach their children unquestioning obedience above all else. Subordinates simply expect to be told what to do and don’t have any agency with their work. Autocratic governments with absolute power are only changed by revolution.
Another example would be religions with a hierarchy of priests, potentially filtering information and establishing a power structure. In high power distance environments, corruption is frequent and scandals are covered up. Given this situation, we might unpack some of these and ask why a high power distance might be problematic. There are certainly situations in which getting instructions on how to perform our tasks is a good thing, although we have to think about the motivation behind this type of dynamic, and more importantly, the effect that it has on creativity. A classic example, I think, of high power distance is the dynamic between Miranda Priestly and her employees in the movie,
The Devil Wears Prada. Miranda Priestly, as the editor-in-chief, has absolute authority over her employees with a clear unquestionable separation between her role and theirs. Communication is almost exclusively top-down. Miranda gives orders, often with minimal explanation, and expects them to be carried out immediately and perfectly. She’s intentionally distant and unapproachable, and that creates a strong sense of fear and intimidation among her employees. Everyone in the office is expected to show unquestioning respect and obedience to Miranda, and she enforces this with her demeanor and sharp criticism. This high power distance relationship serves as a central conflict in the movie, and conflict is not a good thing.
What can this mean for organizations like our own? The Power Distance Orientation and Employee Help Seeking paper by Zhou et al., asserts that employees and junior staff in high power distance environments are less likely to seek help from their supervisors. It’s also suggested that in some cultures, junior staff asking for help equates to incompetence or lack of ability. This type of culture reinforces to employees to think that it’s preferable to deal with difficulties by themselves rather than talking to senior colleagues. A culture which dissuades junior staff in this way to come forward to ask for guidance not only misses an opportunity for senior staff to provide that help, but misses an opportunity for the senior person to reflect on the challenges the junior colleague may be facing.
It affords a chance for us to think about how things could be done differently or things could be improved. When people are not actively encouraged to challenge authority or think independently, innovation and creativity suffers because they avoid suggesting improvements or speaking up about problems. Not only would junior colleagues not be getting the support they need, but in a high power distance environment, also they’re potentially feeling this lack of agency. Senior colleagues’ decision-making is also affected because they’re not getting detailed information. Open communication is a benefit for everybody. While hierarchy and authority is present in all organizations, pretty much, high power distance cultures institutionalize inequality, discourage questioning, and inhibit individual agency. This type of dynamic can undermine innovation, equity, and accountability, traits that are essential for thriving organizations.
Psychological Safety
Related to this as well is psychological safety, and I’d like to touch on this. The term psychological safety comes and was coined by the psychologist and the psychotherapist, Carl Rogers, in the 1950s, in the context of creating conditions necessary to nurture creativity in an individual. In this, Carl Rogers outlined three processes. One of them is to accept the individual as of unconditional worth, to provide a climate in which external evaluation is absent, and understanding empathically. Of course, in our teams, we often do have to evaluate our own work using code reviews, PRs, and the like. Being mindful of the worth of our colleagues and understanding the differing experience and viewpoints is really important. Amy C. Edmondson and Mark Mortensen in “What Psychological Safety Looks Like in a Hybrid Workspace”, define psychological safety as the belief that one can speak up without risk of punishment or humiliation.
In software teams, this could relate to engineers believing they can speak out, they have agency in their work, and learn without being shamed by other team members. However, we often find in development teams that not everybody in the team has the same perception of psychological safety. Senior engineers or people with a great deal of domain knowledge may feel completely comfortable speaking out or questioning approaches. However, more junior engineers or less experienced engineers might not feel like they can speak up or that their input isn’t valued. In this instance, the team doesn’t necessarily establish a psychological safety. Instead, we could describe this as asymmetric psychological safety. Ask yourself, as a little experiment, if you’ve ever worked on a team that was dominated by one or two particularly outspoken people. Also, then try and think of a time that you worked as a team that was truly uplifting, where everybody contributed to the best ideas and each member of the team seemed interested in what the others had to say.
As senior engineers, we need to make sure that we’re conscious that even though we feel comfortable, that others feel comfortable too. A team in which only senior engineers and domain experts are comfortable speaking out does not have a high level of psychological safety, even if us senior engineers feel comfortable. Timothy Clark, in his book, “The 4 Stages of Psychological Safety”, described four stages of psychological safety. The first stage is inclusion safety, where members feel safe to belong to a team. They feel comfortable. They feel included, and that they are wanted and appreciated.
The second is learner safety, where members are able to learn by asking questions. Team members here can experiment. They can make mistakes, and they can ask for help. The next is contributor safety, where members feel safe to contribute their own ideas without fear of embarrassment or ridicule. This could be more of a challenge as you can feel more vulnerable contributing your own ideas, especially to a new team. This would be a really great example for a senior engineer to support and listen to those ideas with an open mind. Challenger safety, the fourth stage, is when team members can question others’ ideas, including those in authority, or suggest significant changes to ideas, plans, or way of working.
Given these stages, what are some practical ways that we can use to navigate through them? First, let’s touch on inclusion safety. As seniors, we need to make sure that we are making it clear that all voices are welcomed and they’re valued. We need to model vulnerability by admitting to our own mistakes and asking for input from everybody. We should use inclusive language in our documentation, code comments, and team discussions.
A simple trick that I was taught a while ago was to say, yes, and, in response to an idea, rather than, yes, but, which I didn’t realize that was a pattern that I had. I really liked an idea and I would use the word, but, and it always came across, as I learned, that I was picking fault with the idea, which I wasn’t. I now use, yes, and. This takes practice and we don’t always get it wrong, but feedback from our colleagues is really essential for us to unpack how we work and how we approach our work, and it really helps. We also need to be aware of different cultural norms, communication styles, or neurodiverse preferences. It’s good to ask people, rather than just saying nothing and getting it wrong. It’s important, also, to credit individuals for their contributions, not stealing ideas, forgetting who suggested things, or by overshadowing people. We also mustn’t ignore exclusionary behavior, either, such as interrupting people, dismissing ideas, and gatekeeping. Ideas that you are given may not be something that can be implemented. It may not be practical or may not be workable, but that can be explained.
Getting ideas is the most important thing, not shutting people down. We also need to call out microaggressions tactfully and firmly. These are subtle, often unintentional verbal behavior or environmental slights that communicate hostile or derogatory message to an individual. These could ensure that people don’t use terms such as noobs to describe juniors, inclusive of people being oversensitive, using derogatory terms, or taking over instead of allowing people to work things out in more of their own time. We should all feel comfortable calling out these microaggressions and explaining how things affect us, but again, with compassion. We should also empower bystanders to speak up if they notice somebody being left out. This is something that we should all be aware of. We should check in with people, giving them a chance to speak without pressure or time limits. Ensure that our meetings and huddles aren’t filled with voices. Allow some space and allow time for people to join in their own speed. This isn’t an exhaustive list either, but it’s some ideas of how we can start approaching analyzing our own cultures of inclusion.
A great example, I think, of inclusion safety is depicted in the TV series, Ted Lasso. Ted actively works to create an environment where everybody, regardless of their background, talent level, or personality, feels welcomed and valued as part of the team. Ted’s leadership style emphasizes that players can be themselves without fear of rejection or exclusion, and he constantly demonstrates empathy and compassion, especially towards players who may feel marginalized or misunderstood. Ted encourages open and nonjudgmental dialogue, allowing players to express their concerns, vulnerabilities, or ideas without fear of ridicule or dismissal.
Let’s have a look at learner safety. We should try and create a space to learn outside of our regular work. This might be the form of 10% time or individual development time. We should show that learning is for everybody, and that you, as senior engineers, constantly learn too. To this end, we should share what we’ve learned with each other, with the rest of the team, including seniors doing this as well at our regular all-hands or any meetings that we have in our teams. Seniors should be happy to say, “I don’t know, let’s figure this out”. We should celebrate curiosity, praise people for asking insightful questions or admitting confusion. Encourage everybody to ask why and reply with good faith. Understanding that asking why is a desire to learn and it’s not a comment about your abilities. We should also pair new developers with mentors or buddies. Also, we can allow the junior to choose who they may buddy with, maybe depending on skill sets and project work, of course. Hopefully, your teams do embody this kind of learning culture.
I think a good example of this culture is the relationship from Dead Poets Society between Robin Williams’ character, John Keating, and his students. Mr. Keating creates a classroom environment where curiosity is not only encouraged, but it’s celebrated. He urges his students to question traditional norms and think for themselves, promoting a culture of learning over rote memorization. Students in this environment feel safe experimenting with self-expression without fear of judgment or ridicule. Mr. Keating normalizes mistakes and making mistakes as part of this process. He acts as a mentor rather than an authority figure, offering feedback that encourages growth and independent thinking. He has a warm and approachable demeanor, and he builds rapport with his students, allowing them to feel comfortable enough to share personal thoughts and creative ideas.
Let’s look on towards what makes a good environment to encourage contributions. We should take suggestions seriously and act visibly on them. Even though you know something might not be visible, you might have tried it in the past, actually spending some time working through the idea and giving it the time it deserves. Don’t just dismiss something because in the past it may not have worked for you. Because even if the idea isn’t applied in its current form, it may well lead to some other interesting ideas that haven’t been considered before. We should focus on code and not the coder. Using language such as, “This method might be more efficient”, rather than, “No, you’ve done it wrong”. Encourage show and tells or lightning talks where team members teach others something new or something interesting to them. Treat bugs and failures as learning opportunities, not occasions to blame somebody.
In SRE, we have a mantra that humans are never the cause of failures. Instead, we should provide protection so that humans aren’t in a position to inadvertently break something. In retrospectives and meetings, we should focus on what we’ve learned from an incident rather than who caused it. In planning or brainstorming, ask, what is something unconventional we could try? These are all examples of how to create conditions in which our colleagues could feel empowered to contribute. Maybe an example of this contributor safety is from the TV series, The West Wing, particularly in the relationship with President Bartlet and his senior staff.
The president actively encourages his staff to voice their own opinions, even when their opinions contradict or don’t agree with his own. Staff meetings are often intense, but Bartlet establishes a culture where ideas are debated, not people proposing them. Individuals are encouraged to present bold or innovative ideas without fear of retaliation. Bartlet respects the knowledge and the skills that his staff have, and he allows them to take ownership of their areas of expertise and delegates critical tasks to his staff, allowing them to contribute meaningfully to the administration’s goals. He trusts their judgment and abilities and reinforces their sense of value and safety.
Finally, let’s look at challenger safety. We should make space in meetings for questions like, what risk might we be overlooking with this? Or, is there a better way? Can you see a better way of doing this? Leaders should openly say, “I’ve changed my mind”, or, “You were right, I hadn’t thought of that”. Treat being challenged as a sign of team strength and confidence, not insubordination. Avoid knee-jerk defensiveness. Pause, thank the person, and explore the point fully. Also use active listening, which we’ll talk about in a moment. We should also remember that not everybody wants to speak in public, so also consider using individual meetings, one-to-ones, email, Slack.
If somebody hasn’t spoken up in a meeting, maybe chat in person or via Slack, depending on that person’s preferred style, and check in to see if they’ve got any questions or ideas. Maybe this process might help that person feel more comfortable to speak up in meetings too. “We’ve always done it this way”, is a red flag. History isn’t always a great predictor of the future, so we shouldn’t have both of our eyes on the past, maybe just one of them. To celebrate experiments, even if they fail, they’re signs of a growth-oriented team. Again, this isn’t an exhaustive list, but I hope it gives you an idea of where we can improve our culture to challenge the status quo.
A great example, I think, of this challenger safety is the relationship between Captain Raymond Holt and Detective Rosa Diaz in the TV series, Brooklyn Nine-Nine. Captain Holt actively encourages Rosa to challenge his ideas if she believes there’s a better way. Rosa’s known for her straightforwardness, you could say, and feels comfortable pushing back on Holt’s strategies or decisions where necessary. Holt makes it clear that he values challenging ideas. He creates an environment where Rosa feels safe to speak her mind, and even if that is contrary to his own perspective. Holt respects Rosa’s judgment and her expertise, and it makes her feel safe to push back where necessary. It’s particularly evident when they work together on high-stakes cases and value each other’s input during this stressful disagreement.
In a case study, The New York Times article, “What Google Learned From Its Quest to Build the Perfect Team”, this revealed exactly what we’re talking about here. Because back in 2012, Google embarked on an initiative, which was codenamed Project Aristotle, to study hundreds of their teams and figure out why some were low-performing and others were really high-performing. The name was a tribute to Aristotle’s quote, the whole is greater than the sum of their parts.
In this study, they discovered that teams excel when members feel safe to be able to take risks, to share ideas, and be themselves without fear of judgment or punishment. Effective teams, we discovered, are not just about assembling the most experienced people. Behavioral norms, such as how team members interact and empathize with each other, are much more important. Some critical behaviors of these teams, illustrated in the study, show that when everyone takes turns speaking for roughly the same amount of time, that is cognizant with a high-performing team. Also, that there is a high social sensitivity.
The members are skilled at reading emotions and understanding how other people feel. As a result, Project Aristotle encouraged balanced participation and actively listening to all members. It recommended fostering empathy and emotional awareness, being aware of emotional outcomes within teams. Also recognized the importance of emotional interactions and interpersonal trust. That creating psychological safety can be difficult and messy. With openness and good intent, it’s essential for team success.
Applying some of these ideas, how can we curate safety in our own teams? While culture can be defined as the ideas, the customs, and social behavior of a group of people, we can also be conscious of the power distance affecting the individual’s ability to affect culture. The power dynamic is such that seniors can have a much greater influence on the culture than juniors. We should always be conscious of that. We’ve been talking a little bit about some definitions and some examples about how we, as seniors, want to create or can create a place of psychological safety. I think a really good example of this, again, comes from Brooklyn Nine-Nine. In one storyline, Sergeant Terry Jeffords experiences racial profiling by a fellow police officer while he was off duty.
The reason why this storyline, I think, is relevant here, because Terry speaks to his superior, Captain Holt, about reporting this experience as an official complaint. Captain Holt tells him, the most powerful action you can take is to rise through the ranks so you can make large-scale changes, and just to ignore this incident, to put it behind you. However, Terry decides to go ahead and report this incident anyway, without the captain’s support, because while it might hinder his career, and he was aware of that, he wanted to call out this exact behavior, because it was meaningful to him. Eventually, Captain Holt saw that he had the ability to help here, and he agreed, saying, “I put all my energy towards rising to a rank where I could make a difference. I’m there now. I realize that if I don’t back you up on this, I’ll be betraying the very thing that I worked so hard for”.
The point I want to make with this is that sometimes we think we should affect large-scale change across an organization, in a more broad and general sense. We have good intentions, and we focus on the headlines, such as our organizations being a good place to work, or feeling comfortable to bring our authentic selves to work. Although the key to this, I believe, is in the details. It’s dealing with the instances in which, in the greater scheme of things, they may seem smaller, and we maybe think we should pick our battles. These are things that genuinely affect people and inform the culture of our organizations. You might also think that I had to fight for what I’ve got. That’s a normal part of the process, even. All that means is that you’re making other people face exactly the same barriers that you faced. Now you’re in a position of seniority. You can make some real changes based on your own experiences. Given this, we could think about our own styles of leadership.
Maybe thinking about the character traits of the film Top Gun is a good example of an antipattern here. Maverick here had a number of problematic traits. While that makes a good film, a good story, they’re hard to deal with when you’re actually working with somebody like this. Taking unnecessary risks during flight exercises, Maverick valued thrill and personal success over safety. His natural talent made him overly sure of his abilities, and that led him to ignore protocol and advice. Compare this to the reality of the qualified weapons instructors, known as QIs in the RAF. They’re the equivalent of the United States Top Gun program. These highly trained and skilled leaders don’t work on bravado, even though they are brave. They’re honest, and they admit their mistakes, and they own them. They listen, and they look after their team.
Active Listening
We’ve been talking a lot about culture, and now we’re going to move slightly more into behaviors while leading our team. One skill set that I mentioned earlier on was demonstrating active listening. Active listening essentially can be summed up as the intentional practice of listening to understand, not just to respond. It involves observing both verbal and nonverbal cues, and providing thoughtful and relevant feedback.
Essentially, the most important thing is to hear before speaking and ask open questions to make it clear that you’re listening. Some techniques could be to include paraphrasing, to repeat what you’ve heard in your own words to confirm understanding. To reflect emotion, recognizing and acknowledging the speaker’s emotions. To ask open questions, encouraging deeper discussion and clarity. Also, to overcome barriers, that you should minimize distractions, some environmental noise distractions, for example. Also being patient and open. Also, establish that you’re not too busy for these discussions with others. We all have a lot on our plates, but making it clear that you’re always available for a conversation, maybe at a later date, is really important. To actively engage in and value the conversations that you have.
Learning
Another approach is continual learning. When writing this talk, I ran some ideas past my colleague, Valeria. She’s been with the team for a few months now. She’s the newest member of the team. This is her with the rest of the team at our Christmas dinner. I wanted to understand a little bit more about her experience joining the organization and the team. We do have a new starters guide, which we’ll talk about. I wanted to ask her if the subject of this talk itself was a good idea. She had some really great knowledge to share with me. She talked to me about one of Aristotle’s best-known works, Nicomachean Ethics. For Aristotle, teachers aren’t simply there to transfer the knowledge, but to create a supportive and nurturing learning environment. This environment should empower the learners to take ownership of their education. Teachers also need to get to know their learners so instruction can be tailored to their needs, talents, and preferences. Valeria summed up this as, people do well in affirming environments and smart people have been writing about that.
If Aristotle has been writing about it for that amount of time, then it’s obviously a good idea. My colleague Valeria also talked to me about The Farther Reaches of Human Nature by Maslow. In which he says that self-actualizing individuals flourish in spaces that encourage exploration, creativity, and the pursuit of meaning. Maslow describes this environment as one that minimizes artificial constraints and allows individuals to be fully themselves without fear of judgment or suppression. This environment fosters openness. It enables growth and it supports their drive towards realizing their full potential. Essentially not being Cameron Diaz in Bad Teacher, who was cynical, sarcastic, manipulative, unethical and often driven by self-interest and manipulated others to achieve her goals. Maybe more like Robin Williams in Dead Poets Society, who was supportive, lifted up people’s voices, encouraged unconventional approaches, and showed empathy rather than just delivering answers. He pushed his students to question norms, to challenge authority and form their own opinions.
Practical Organizational Changes
We’ve broadly discussed culture, but what are some practical organizational changes that can be made, maybe even tomorrow? I would recommend considering carefully psychological safety and power distance in your organization. That’s quite a lot to work through potentially. Some quick changes could be to implement reverse mentoring for senior staff, where junior engineers mentor senior colleagues, providing fresh perspectives, technological expertise or insights into modern trends and diverse cultural practices. By creating an onboarding plan for junior engineers, focusing on where knowledge and support can be found and establishing how the junior can be supported through the learning process. By asking juniors to review your PRs too, which we’ll look at. By documenting decisions in architectural decision records. By codifying approaches in best practices and keeping these fresh with input from the juniors. This is a chance to introduce new ideas and keep your components up to date as well as sharing this information.
There are a few things I think that could be added to almost any organization without much upheaval and can be blended with your current approaches. Let’s delve a little bit into reverse mentoring. An example of reverse mentoring could come from Brooklyn Nine-Nine again, in the relationship between Detective Jake Peralta and Captain Raymond Holt. While Holt is Jake’s superior and he’s a seasoned by the book captain, you could say, Jake is much younger and more unorthodox, and often helps Holt adapt to modern ideas and approaches, especially in the areas of social interactions, humor, pop culture, and emotional intelligence. Jake also encourages Holt to loosen up and express himself more authentically, which Holt slowly learns to appreciate.
Meanwhile, Holt provides Jake with invaluable guidance and mentorship in discipline, professionalism, and leadership. Their relationship is mutually beneficial and built on respect, even if they have wildly different approaches to life and to work. The fact that Holt is a very experienced and established professional is open to learning from Jake’s fresh, sometimes chaotic, but innovative perspectives, really highlights the value of reverse mentoring. It shows how older generations can benefit from the skills and from the viewpoints of younger generations, especially in rapidly evolving environments. Reverse mentoring, though, does need genuine support from seniors, both in time and explicit acknowledgement that it is important to them.
The goals and objectives of the relationship should also be established. A mentor or mentee should be matched based on skills and objectives. There should be guidance provided on how to give and receive feedback, to handle disagreements and how to build trust. Mentoring is best coming from personal experience rather than abstract ideas. A structure, a cadence, and a duration should be established as well to outline really what the outcome should be. Again, mentoring is another subject which is really complex, but this maybe could be a good starting point.
During my time at the BBC as well, I got the opportunity to be involved in our mentor up scheme, and that paired me with a senior member of staff. Over a number of months we met so that I could share my own experience. Hopefully it was valuable for her. I found it a really amazing experience. Also, within BBC News, we also have their Next Generation panel, which was launched in 2016. It was with the aim of bridging the divide between junior and more senior members of staff, while ensuring that we are investing in and listening to our more junior and younger colleagues. This isn’t mentoring. This is more what’s called a shadow board. It’s another approach that can be taken.
One of the benefits of having this approach is that junior members together are able to support each other in challenging culture and assumptions. Naja Nielsen, the Director of Digital, Channels, and Weather, and Next Generation panel sponsor, said that we, the BBC, are going to benefit enormously from the Next Gen panel, helping us understand what the now is. Could you benefit from something like this at your organization?
As I mentioned earlier on, an onboarding plan is also really important. Nobody should be a member of your team and not understand what they’re doing or where to go for support. It’s important to establish where new starters can find information for themselves and assign a buddy to support them, to establish what’s expected of them in their first few months. I would say, maybe I’m on my own here, but it’s not as important to measure their performance in the first few months, but instead your ability to effectively support them in their new team and make sure that they can flourish. You should also routinely ask juniors to review your feature pull requests. This might not make sense in an organization which uses PRs as a way to control and limit what’s being implemented, but I would say there’s more value in PRs as a way of sharing knowledge, and also giving good examples of how features are implemented.
Many of us would have been in a situation where junior engineers, we were asked to implement some code, and the only feedback that we got was right at the end telling us that we’d done it wrong and to do it again. It’s such a demoralizing experience. Instead, we should ensure that junior engineers have all of the details beforehand so they can implement the features in an informed way. I think a great way of doing this is to share the knowledge of the types of features that are being merged into your code base via PRs.
Our language is important here too, as well, when reviewing PRs. A bad approach would be to say, why did you use threads here when there’s obviously no benefit to be gained from concurrency? A good approach could be to say that the concurrency model here is adding complexity without any actual benefit that I can see. Because there’s no performance benefit, it may be best for the code to be single-threaded. Would you like to discuss this further? Obviously, just an example.
This brings us to decision records. Decision records, we use very heavily in the organization. They are valuable tools for software teams as they provide a structured, accessible way to document the rationale behind key technical and architectural decisions. They make for revising our past decisions more efficient and grounded in historical context. They act as a collaborator between teams and a reference point in code reviews, in architectural conversations, and during planning. Related are best current practices, which we, again, use as much as we can. It’s a very important thing for us. It provides a set of proven standardized methodologies and guidelines for particular approaches. The design is to enhance efficiency, consistency, and quality across projects. They establish a clear, effective practice based on collective experience and industry standard. Teams can reduce ambiguity and avoid common pitfalls by enabling developers to use BCPs and then focus on solving their own business or more complex problems, rather than reinventing the wheel over and again. They also facilitate onboarding of team members to the teams by providing a reliable framework and a process to understand workflows.
Summary
We looked at power distance. We looked at psychological safety. We looked at asymmetric psychological safety. We looked at some ways of curating psychological safety in your organizations. We looked at active listening. We looked at learning. Also touched on some practical organizational changes. We looked at some attributes of low power distance. We looked at some attributes of high power distance environments. We established the concept of psychological safety. We talked about the 4 stages of psychological safety. Also, we covered some approaches to active listening. Then we finished with some practical organizational changes, which you can make in short order.
Takeaways
Some quick takeaways I’d like to leave you with. Remember that seniority isn’t power, it’s responsibility. To be willing to pivot and change your mind when new information is presented to you. To give feedback in both directions, sharing between juniors and seniors. To consider reverse mentoring for senior staff. To use active listening. To assume best intentions when people ask a question or question an approach. One quote by Mahatma Gandhi has always stuck with me in my life, that is that my aim is not to be consistent with my previous statements, but to be consistent with the truth as it may present itself. It’s important for us to be confident with the decisions that we make. We should also spend some time to see if our understanding of ground truth has changed over time, and be willing to change our position if our understanding of the subject changes. This is something that junior engineers can help us all with. Or, in the words of Captain James T. Kirk, young minds, fresh ideas, be tolerant.
See more presentations with transcripts
