Transcript
Davis: Imagine that you're the leader responsible for destroying the One Ring of Power. For context, this scenario comes from Tolkien's fantasy novel, "The Lord of the Rings." The One Ring was forged by Sauron at Mount Doom in an attempt to rule over all of Middle-earth. Anyone who tries to wear the ring is corrupted by its power, even if they intended to destroy it. In order to eliminate the threat of Sauron, someone has to destroy the ring. You know that you aren't equipped with the right skills alone. You're vulnerable to the corruption of the ring. The people available for your team come from different backgrounds, and two of them really don't get along at all. Everyone has different levels of expertise and experience. One factor in your favor is that one team member is able to hold the ring without immediately being corrupted. You gather up your team, and you try to plan out what you can achieve to get to your goal.
Everyone shares different perspectives, the only place the ring can be destroyed is on Mount Doom. You realize, there are many paths to Mordor, because of the Ring's inherent properties, you must avoid many of them. You could get a ride from your friends, the giant eagles. The Nazgûl, who are servants to Sauron can also fly, and you would be at greater risk in the air than on the ground. The shortest path leads directly through Isengard, which is tricky, since many people want to possess this ring of power. You decide to take the longer but more sustainable route for all those involved. You have a map that isn't going to tell you what obstacles and the moment your team are going to face along the way. You need to think about how to help your team navigate the changing landscape and evolving relationships so that they can continually make progress along the way.
Background
I'm Jennifer Davis. My pronouns are she, her. I'm an engineering manager at Google within the DevRel organization, and a published author. My newest book just came out, "Modern System Administration." My current job, I want to help customers use Google Cloud products in a seamless way. My team works on all things serverless, orchestration, and DevOps. One of the many interesting things about engineering in DevRel is our zeroth customer approach. We want to help people understand how to build, test, deploy, and monitor modern web applications. We explore the concerns that everyday teams will have in building applications on Google Cloud. Then we build those sample applications that help explain the concepts to others, enough so that it's flexible, that people can adapt to their own organization's needs. We write code, test it, and manage all the CI/CD infrastructure to support others contributing to the samples as well. Some samples are small snippets of code and some are large conceptual apps.
DORA, DevOps Research and Assessment
For eight years, the DevOps Research and Assessment team have been doing research on development performance. There are four key metrics of software delivery performance: deployment frequency, lead time, change failure rate, and time to restore service. The last couple of years, they've also identified a fifth metric, which is the operational performance reliability. These metrics along with associated capabilities are predictive of business success, higher developer satisfaction, and lower burnout. We really don't want people to burn out. We know if we combine continuous delivery, loosely coupled architecture, version control, and continuous integration, we can foster software delivery performance that is greater than any of those individual activities themselves can contribute. How do we help people embrace these capabilities? My team has to embrace the capabilities as well so that we can support people embracing those capabilities. I need to support an environment that grows the capabilities, especially one that encourages autonomy, trust, sharing your different perspectives, and encourages learning through retrospectives.
Outline
I want to talk about the three areas that are crucial in my approach to support my teams to have high performance: functional leadership, boundary setting, and learning and adaptability. These helps build the crucial capabilities that inform highly performing teams. Again, autonomy, trust, voice, and blameless retrospectives. Those capabilities that we saw earlier that come out of the DORA research, those are the things that we want to focus on.
Functional Leadership
Let's start off with functional leadership. What is leadership? Often, it's defined by whether someone is following you. Managers can be leaders, but they're not always the leader. Sometimes leadership is handed to us, and sometimes we are compelled to lead, because something needs to be fixed. Some lead by example, and some lead by coaching in complex environments. Leadership is getting people together to figure out what the possibilities are, and then following through, fostering the understanding of the specific contexts that we're faced with to solicit what assumptions and experience people have about the situations that were experienced. We get to a shared context, and we foster collaboration. We also want to hold people accountable to be active in their participation. Mary Follett influenced many modern management practices. She said, leadership is not defined by the exercise of power, but by the capacity to increase the sense of power among those led. When we talk about leadership, we're talking about, it starts with individuals, and how we approach individuals. When I approach a new team, I respect the roles and responsibilities that each human currently has. I don't make assumptions about their capabilities or their interests based on that existing hierarchy.
Instead, my first step, whenever I'm approaching a new team, is to get to know the individuals on the team. I need to understand their motivations, their goals, their worries. Why they're here. What do they want to accomplish? What is on their mind? What's hindering them to make progress? Once I start building these relationships with the individuals and I see people in action, I can start identifying the different strengths and weaknesses that they have. Their different perspectives, their skills, their experiences, and any interests that support the team's goals. Next, I have to assess the state of trust of the team and begin to build that trust with each of them individually, one on one, and then together as a team. I start by sharing some of my values, my vulnerabilities, because when you start sharing your vulnerabilities is when you can start building that trust.
When I started managing my current team, I shared these three values: authenticity, kindness, and trust. What that means is that I will bring my true and genuine self to them, and that I encourage them to be able to do this as well. I'm not assuming that the minute I walk in the door, they're going to be able to show that true and genuine self. The reason why I encourage this is because I want to build better quality outcomes. When you consider different perspectives and styles, and bring that together, it's not going to happen unless everyone is being their true and authentic self. That, secondly, I value kindness in all my interactions. This means that I'm going to strive to be friendly, generous, and considerate. I expect others to try to do the same with each other. This includes being kind and telling people the feedback they need to hear when they need to hear it. Then, finally, that I'm going to strive to build relationships with me and with each other, because I don't take that trust for granted. Trust takes so much time to build and it takes just a moment to break. Trust is absolutely crucial in order to build highly performing teams.
When I think about functional leadership, I recognize that everyone can lead. That doesn't mean that everyone's leading all the time. It means fostering the capability of leadership in people. I'm helping the team to scale by helping them adapt to any challenges that come along the way. If we think about the One Ring adventure, if you take a functional leadership role, then your perspective is that any time challenges come, anyone can come up and be the person who leads, because at the core of it, energy is going to ebb and flow. People need to take breaks. I need to be able to take a break. I delegate leadership but I also clearly define roles and responsibilities. As the manager, I am part of the team's leads team that supports the entire team with escalations, team planning, and prioritization, and holding the line of standards and the expectations we have of the team. This diagram shows you the breakup of how we think about our roles and responsibilities on the team. We also have specific leadership areas around product areas, the product itself, and project leadership. Not everything happens all at once. When that area needs to exist based on the organization's priorities, then it does and we have people to be able to step into those leadership roles.
Boundary Setting
Let's talk about setting boundaries to support the individuals and the team. An educational psychologist, Bruce Tuckman, described the five stages of team development: forming, storming, norming, performing, and adjourning. In forming, you support the group of people in finding common ground in their skills, backgrounds, and interests. That's what I was talking about when I talked about sharing with people and then identifying them. You want to establish the set of goals, the timelines around those goals, and the ground rules of how you interact with each other. In storming, the group is learning how to work together. There may be conflicting personalities and perspectives. There may be different groups forming within the central group, and people having to take on different challenges. Multiple people may have strong opinions. At this point, it's so crucial not to tone down that conflict. Instead, you want to understand what those different opinions are, and foster an environment where people are supported and enabled to be able to speak up, even if they're not speaking up in the moment. It's ok for people to send emails and share their opinions and ideas in different forums. It's critical to find those different ways to enable everyone to have and share those different ideas and opinions. This may mean sharing documents early to get asynchronous feedback. It's also important to establish the appropriate boundaries for how the team will work together. Meaning, if there's particular language that's used, you want to make sure that the norm is that of like, this is how we talk. For me, I think about it from a kindness perspective. Of course, bring up your concerns, but always come at it from a curiosity rather than saying, no, that's a stupid idea.
In norming, the team has found that sense of unity. This is where we start seeing a team flow. When we think about flow, it's that getting into the flow of getting work done and people relying on each other. It's different from an individual flow, where someone can be in the moment and being able to find that place of working really effectively. Team flow is an even more powerful place. It's not like you get there and all of a sudden, it just happens automatically. You have to continue to foster the team cohesion, recognizing the value that everyone is bringing, and helping the individuals resolve conflicts, because conflict is going to continue to happen. Performing, the team is really getting to that high flow state. There's a large amount of safety and trust within the team, and individuals trust each other. You have to continually feed that team cohesion in positive ways. Finally, in the adjourning phase, you've met whatever the goal is, and some members may be starting to move on to new projects. This is one area where people sometimes forget to invest that time and effort, where they're saying goodbye to team members that are moving on, or whatever the case is, because this is where you really establish that and continue to establish that trust that people have.
The interactions between the team is vital for that team cohesion. There has to be room for individuals to have different perspectives, continually, and to share those different perspectives. You want people to be able to be different and not get into a group mind, because then you're going to be biased against all the other different perspectives, and you may not build as high quality of a solution. You want to preserve those differences, while also building trust and psychological safety for the team. It's absolutely crucial to identify the set of team boundaries and enforce them. It starts with communicating the boundaries and expectations, and repeat them over. This is an example of one of the ways I repeat and document boundaries. I literally copy and pasted from the agenda for our team meeting where it tells the goals of the team meeting. I set this expectation in the team meeting. We share information. We develop working expertise in a scoped area. We own collectively our team norms. It's not just Jennifer defining, this is what our team norms are. We talk about them, and we all share and embrace them. They can change over time. We align on our goals and we share feedback on the work people are doing because we want to share and talk about, make that work visible, and so that there's no single points of knowledge or failure within the organization. Do we accomplish that all the time? No. Of course, there's going to be single points of knowledge. It's a continual process to work on it.
We also introduce team rituals. Those are those small regular activities that are ingrained in our team culture, no matter how the team changes over time. Some examples of our current rituals include starting with a shared playlist, we have music that we share. This allows us to talk about different interests and see even different cultures. We also talk about our emotions. I started talking about authenticity, and bringing your real self. It's not all rainbows and sparkles all the time, even though, sometimes what I'm associated with is the sparkly DevOps. Being able to share when you're having challenges, and when you need help, is a really crucial part, because then we create a system of mutual support. Sometimes things aren't going great. By talking about these things, we can encourage and support each other. If someone isn't feeling great, this is an area where folks offer up support. We celebrate all the little things. We encourage a gratitude culture, because it teaches people how to give and receive feedback. Know that all those little things, even though that's just my job, people appreciate the effort you've made. Research shows that engaged employees are ready to go the extra mile to help other team members. This impacts the overall performance of the team. These proactive and prosocial behaviors spread and are shared within the team encouraging the behaviors with one another. It's this positivity spiral.
Play. Games, especially role-playing games, or putting Lego together, just talking, help people learn about the boundaries and appropriate ways of working together. Often, our work roles are really tied up in our identities. When we disagree with one another, that can add an emotional weight of any past traumas that individuals may have had about themselves in the workplace. Playing builds up that team connectedness and it gives people the chance to practice how they communicate within the context of the scenario that's separate from their identity. Some of the boundaries you can set and encourage them by encoding them. We're constantly evaluating, what things can we do to improve our work and minimize the toil? For example, we can put tools to support the norms. We can leverage GitHub Actions. GitHub Actions, this is a continuous integration and continuous delivery platform available right on GitHub. We create workflows that test and build every pull request to our repository. Then, this workflow is triggered when an event occurs. Events, like a pull request being opened or an issue being created. One of the actions we use is to auto label pull requests so that teams can better understand, when a PR comes in, what is the subject matter expert that should focus on it? We automatically label what the type of API is, and so the right person gets the right pull request. Then, if people want to learn something about something they don't have any expertise on now, they can go check it out, and learn about those particular areas. We also use GitHub Actions to lint incoming code, we have a style guide and expectations. Having that linting there, we can automatically test what it is the code coming in and whether it actually applies. This is an example of the black Python linter being run against our code. We also use Terraform linters.
When we're writing code, we're not just writing code to get something done. We're also writing code to help people understand what it is the concepts, and so we have to think about all the different concerns, that may not be something that every engineering team has to think about. Working code is not good enough. We need to write code people can understand, read, learn from, and then share with their coworkers or within their organization to help advocate for change. We have a publicly shared sample style guide that informs our values, our principles, and practices, and that informs across the org how we write our code. It's part of our onboarding process for when people are joining the team so they know how to write code as well.
We also have to think about boundaries across the organization. Interteam conflicts can aid in team cohesion and forming bonds, because you think of, this is us and them. The us and them can create this model within the org that can harm larger initiatives. Because a lot of times within DevRel, we are collaborating across boundaries to build up and develop and improve products. I don't want to have a lot of us then dynamics, I want to encourage cross team projects. These are larger, more complex projects that span different teams across the organization. With those kinds of initiatives, we can build even more value, but it's so challenging to get everyone aligned, because everybody reports to different people. Then you have the different feelings because, this is this manager on this other team, and how are they going to impact me as an IC? By embracing functional leadership, you enable individuals with the skills to lead regardless, to build these ad hoc teams, where it doesn't matter who the manager is, everyone's coming together to work together to accomplish a particular set of goals.
The problem is that different folks can have different team cultures within their team. It's not like I can define, this is the perfect team for all teams. The team culture emerges. Be aware when there's too much friction to overcome between members, especially when it comes to underrepresented folks. If the underrepresented folks in the industry are bearing all the cost to move the project forward, this is especially important as a manager to come in and enforce boundary setting. This may mean saying no in different ways than just saying no. What I mean by this is say, yes, and we'll do that far off in the future without a specific date. Not saying it exactly that way, to, no, this isn't possible at this time. Or, no, we're not going to be able to do this because these sets of experiences that people are having to have because of this particular environment.
Learning and Adaptability
This brings me to my final theme, learning and adaptability. The terrain is always changing, and I need my team to be able to adapt to whatever is happening around them without constantly churning on execution. This starts with setting time aside explicitly for people to learn about emerging technologies, as well as any technical leadership opportunities that they might want to pursue. How much training, really depends on the scope of the team and where people are at currently. I cannot stress how important it is to encourage learning and being aware of what's happening in the industry. I also encourage collaborative learning through friction logging. Friction logging is something we do at Google, that is exploratory testing. You take on this zeroth customer mantle to explore developing or building applications the way a customer would. We provide the feedback that we get through running through this friction log exercise directly to the product engineers, and then develop samples and use case scenarios to support demos to help people. Aja Hammerly, my peer in advocacy, has written this great blog post on friction logs. You can check that out. Sometimes taking that friction logging up a level not just as an individual, but as a team or a pair. When we do this team friction logging, we take that learning to a new level, because people are working together and then synthesizing what they've learned in the process. That really levels up the team learning about whatever this concept is, and also identifying where there may be mixed mental models about particular things.
We also use decision records in our large apps to help us build a coherent, shared understanding. Decision records show the path we took to users, but it also helps us onboard new contributors, and remind us of what we did and why. For example, when we were thinking about managing resources, we prioritize the need for IAM privileges, pull request checks, and nightly builds. We could have used GitHub Actions or other internal Google CI tooling, we decided on Cloud Build because it had the least overhead and security risk and IAM access to Google Cloud resources. We didn't need to export service account keys, and Cloud Build also had GitHub Integration, PR checks, and the capability to do nightly builds. Finally, it's just something external contributors can use, and that's important to us being an open source project. We also decided to use Canary rollouts rather than an all at once, or blue-green deployment. We crafted this pipeline with Cloud Build triggers, Pub/Sub, that use the Cloud Run traffic management feature. Then we auto deploy to staging but required a manual approval to promote to production. We can adjust the traffic in increments to staging and prod in the code. All of those decisions that we made, we documented in our repository, and that informs how we did and why. Then, people coming in to learn from this can see what decisions we made, and then apply that same context to what they're facing if it applies to them. Sometimes, we see a lot of these, this is the best practice. Why is it the best practice? Is it really the best practice for you in your context. Decision records really helped take things to that next level.
We also created a small show and tell just for the team. We have a larger demo time, and that's across the larger org. Show and tell, specifically named that way, it sounds more like, here's your show and tell for elementary school. That's exactly the feeling I want to get to because the idea is to not set up this large context that people have to get over in order to share, because sometimes it's hard to share what you're doing, especially if it's not finished, or it's only partially there. You're trying to figure something out, or you just want to connect with other people. This is a space for people on my team to share anything that they've learned or tried out. It's not some prescribed, here's exactly what you need to show and you need to show your work every week. Instead, what we get is people sharing, potentially photos from their recent vacation, so it encourages people to take time off. Or people showing some interesting tool that they learned about. This actually has helped develop the sense of sharing and learning across the team.
You also want to inoculate your team from stagnation for themselves and for your team. I encourage people to contribute to open source by getting involved in open source projects and working with other organizations across the industry. This gets your team exposed to other patterns of work, collaboration, and cooperation. It also helps you to experience some of the other learnings that are happening outside of your organization. It is so dangerous to get into this mindset of, it wasn't built here, so it doesn't matter. That makes you vulnerable to changes in the industry of patterns, and what are the things that people are caring about right now.
You need to think about all of this for yourself as well. It's so easy to stagnate and get caught up in the daily grind. Broaden your interactions with others and learn from attending conferences like QCon Plus, like other training. One of the most valuable opportunities that I've taken for myself this past year was attending Ruth Malan's Technical Leadership Masterclass. This opportunity was amazing for me because it gave me the opportunity to connect with other industry leaders, whether it was CTOs, CEOs, VPs, architects, senior developers, all within the context. We approached and talked about all these different problems, and how we were solving them in our particular organizations. This was so insightful because it gives you the broad depth and breadth across different places, and then helps you to see different ways of solving problems. Because a lot of times we're all solving the same problems, it's just maybe with a slightly different name. Another great opportunity is Lara Hogan's Management and Leadership Training with Wherewithal. I've also taken that. If you don't have a lot of time, they also come prerecorded. You don't get that same opportunity to connect with and talk to others, but it's still just an amazing resource.
Summary
I've shared with you three essential themes for helping your team navigate complex environments, and evolving relationships. Embrace functional leadership. Everyone can be a leader at different times, and may have a different style and different ways of leading. Start by building personal connections and understand where people are at, and what leader they can be. Build trust and delegate the leadership. Powering with your team enables everyone to feel ownership in the process and an autonomy to shape the team in a collaborative manner. It's not just my team, it's our team. Set and uphold boundaries. Establish team rituals that embed the boundaries within the organization and team itself. Use tools to support the boundaries that you have. Support cross team collaborative opportunities that can grow and foster relationships. Finally, plan and encourage learning and adaptability. Budget time for learning and support the collaborative learning opportunities possible, internal to the team, as well as externally through open source projects.
Questions and Answers
Reisz: What suggestions do you have to break down those walls, for people that maybe are a little more hesitant to share their authentic self?
Davis: There's no one prescribed way. First is, understand the context of why the person is feeling less open to different ideas, or willing to compromise. A key thing is about, it's not so much compromise that you want to get to, you want to get to consensus that everyone agrees. One challenge is making sure the systems in play are not impacting how people are choosing to respond. Because sometimes what is happening is there's a system, say for example, like incentivization, or how people are rewarded for their contributions. Maybe they think that the most important thing for them to do is execute lots of individual things, rather than coming to the right solution. I think really, there's a lot of paths to this. It's about a continuous coaching process. The key thing I start from is there's probably a system in play that is causing this, because people don't naturally just want to be close-minded. Especially in engineering, we want to do the right thing, we don't want to waste our time. I have run into situations where people are like, no, I'm the smartest person in the room and I'm doing the right way. That takes coaching. Sometimes you have to hold people accountable for the ways that you want them to interact. At times, they will decide that you're not incentivizing them to be the person they want to be. They leave the team because it's not the team they want to be on.
Reisz: I think when you hit on psychological safety, a lot of times it comes back to psychological safety. Really building that space for you to be authentic and be able to disagree, and it not to be like a poor experience or something that your heart starts pounding. It's the safety to be yourself and the safety to disagree. Sometimes I've found my teams, at least, that that tends to be harder. You found some similar?
Davis: It is. I think it takes a lot, especially in a team that's been having challenges, because they're going to have learned patterns. Those are the systems at play that are causing some of the friction. Part of it is just starting out and recognizing and being consistent about what you're expecting, how you're expecting it, and encouraging people to collaborate. That's generally where you run into the friction as well with people being close-minded. Once people start to see the value and they start having those experiences that are positive, it feeds into the positivity spiral, and they want more of that psychological safety within the team.
Reisz: I think you also talked about it's, modeling the behavior, being open to be vulnerable, making sure you set boundaries.
In the beginning, when you were talking about functional leadership, and you were talking about setting those expectations for teams, understanding who the team members are, how do you go about that? From a team that you don't know, that you're going to become involved with, how do you really get involved and get to know people, particularly in this hybrid world that we're in today? Because we're in-person and online. What strategies, both in-person and online, just to really get to know those folks?
Davis: The great thing for me is, I feel like I have a little bit of a head start, because I've been working in a remote capacity for the teams I've been on, for many years now. It's almost a decade at this point. To me, I feel like we should always have been doing work in a distributed model, especially coming from an Ops background and the challenge of being on-call for services, you can't expect people to immediately be able to do stuff. Because you have to be able to drive, or go to the restroom. You need to go do family type outings, go get some groceries, get food. You have to have a way to negotiate those microtransactions of mutual support where someone else can take on-call for you for that time where you need to not be available. From a distributed point of view, we need that. A challenge is for people in relationships, it's harder. There's something that we just don't capture when we're in-person versus here in a video screen. Even as I'm watching my talk in the recording, I'm like, I am so much more vibrant when I have a person. It's like, don't forget to have, at least at minimum, somebody to talk to, like I'm talking to you right now.
There are certain things that you can do to facilitate more cohesion for a remote team. I mentioned some of them, but I didn't put it in this context. We have a shared playlist of music, and sharing different things in chat channels, encouraging people to share, not just like, what is it you're working on? Like, what are you doing? Are you taking a walk for the day? We did a Walktober, where we didn't compete against each other, but we share how much we're walking. I also encourage, when people take time off, I'm like, "Great job taking time off. That's awesome." To encourage that pattern of behavior, so it builds more connectedness. People know, it's ok to say I need help. It's ok to say I'm having a challenge. It's ok to share your interest and who you are as a human being, because that's the missing piece. At the watercooler, in-person, you're sitting there taking a few minutes of a break and talking.
Reisz: For our program committee, we have six leaders across software, some from Google, that meet every week, to talk about who's going to be the track host, who are speakers, and recommend all these things that go for QCon. We do exactly that. It starts off with a check-in or work. It's just about building that connectedness as this virtual team is coming together for that next hour to be able to do some work. Then we end with a checkout. Really, you can feel the difference of that cohesion that you talk about in a team like that, and you don't do that, you just come in and check in and you go off to your next thing. That's absolutely a great callout to talk about.
I'm going to fast forward over to Tuckman's Stages of Group Development, because I've referenced that every single week in some aspect of what I do. You made a comment when you were talking about performing. You said, feed that team cohesion. I think you talked a little bit about it here with some of the interconnectedness. What are some ways particularly when you have this high performing team that you can keep it high performing? What are some ways that you do, that Google does to maintain high performing teams?
Davis: I think a crucial part of maintaining a high performing team is making sure people are taking enough time off away from work. You have to think about not working just as much. I'm always checking to make sure like, when is the last time? Burnout isn't just solved by taking time off. What you want to avoid in a high performing team is people burning out. You want to keep them. It's like a good motor running. Another part of it is checking in with the quality of the work, not the quality of the outcomes, but the quality that the person is experiencing. Are they still connected to the work? Is the work still important to them? What's motivating them to do these things? All those initial things of like getting to know people, you continue to get to know them. Because people evolve. It's not like you're the static person. I'm not who I was 10 years ago. It's like, I'm a new person.
Also, reward people. Rewards are very personal. People like different things. Money, of course, is always good, but also acknowledgement. Saying the thing out loud. We have some fantastic training about this at Google about making sure to recognize people, but not just that this was successful, but this was successful because this person, what is the specific thing that they did that was amazing? I also encourage a gratitude culture. When I first introduced this in my team, some people were a little bit like, why are people saying thank you for doing their job? What is the value there? Over time, it's just a little bit of easement of, it just adds a little bit of that positivity to the positivity spiral that you want for a high performing team. It's not just, you're just doing a thing. It was also that subtle, how you did it. How you did it makes a difference.
Reisz: There's a lot to unpack right there with your response there. Daniel Pink's autonomy, purpose, and mastery, being able to reiterate, a high performing team, make sure all those things are in play.
Really recognizing people in a way that's personal to them, is that just getting to know them, and then surfacing those things? Like you said, there's some great training at Google, what does that look like?
Davis: For me, it's really clear and specific, and it's timely. Say, a person accomplished something. One of the people on my team led a cross organizational effort recently. A very large undertaking that was across the org, not just within DevRel, but also within our libraries team. The goal was, bring our samples that were in these other libraries into this sample collection, make sure that they were all within the different languages. It was a big undertaking. It was like 170-plus repositories that touched. Assessing the samples, whether they were needing to be done. Then, coordinating this group of 40 people to execute on this. This is not just my team, but enabling him throughout this time, he is now enabled to do and lead in this way. In recognizing the impact, sending out emails. Making sure all the people know explicitly, because any one person in this effort would have seen one slice of his leadership. One part of it. One of the outcomes. The outcome isn't just, we moved all these samples over. We actually figured out there was a problem, researched it, identified it, brought it attention. Worked with all these teams to come to a collaborative, cohesive consensus of how we're going to approach this problem. Then, coordinate and execute on all of this with the various individuals. The recognition piece, crucial to make sure and inform all the people so they can also chime in and say, I really appreciated this as well. It also makes them aware of the larger effort and what the person actually did.
Reisz: Just hearing you talk about it, you can just feel the celebrating the wins in the way you describe it.
You talked about learning adaptability. There's a lot in there that I thought was great, too, the ADRs or decision records. Those are so important. It's like one of the first things we always seem to forget. How do you really get everyone to like, seems like we just made a decision that someone else may need to know if they're coming and looking at the repo. How do you make sure you hold each other accountable to make sure you're capturing these ADRs or decision records?
Davis: We do it at the start. It's an evolving practice. It's hard, because like, how do you know what thing to document. I think there's a lot of guidance informing. The way we thought about as some of the open source agencies and how they think about and document RFCs. It's so crucial, for us, at the core of what we are in DevRel, it's not just like we're solving a problem. We're solving a problem, and then showing people the way. We want to help people understand. How do you do that? You have to let go of this idea that every decision you made is the perfect right decision forever. That's where you start from, like, we know we're making this decision for now. If we document it, we'll know why we made this, and then how we can change it in the future, or what might be a trigger. It's been so helpful for us in just even not backtracking and repeating ourselves, which I've seen in so many different projects. Like, we did this thing, and then we did this thing. We came back to that thing but we forgot all this context.
Reisz: Do you keep them in Git as well, or in version control so you have the version that can be, this was the previous decision, you see the new version?
Davis: Yes. You can go check it out. It's a fantastic way, just a pattern if you want to copy it, of just like, here's how we decided this. Not all decision records are super wordy. Some are just like, we decided this thing just with the brief context that we had. Sometimes it doesn't matter. That was enough.
Reisz: Yes, I like it. Because again, you look at a code base. You see the decisions that were made, helps you come up to context. You weren't there for all those decisions so it helps you gain that context of why things are the way they are.
You talked a little bit about friction logs, could you double click a little bit? What is a friction log, and how did you leverage them?
Davis: Friction logs are amazing. It's basically exploratory testing, but with an explicit intention in mind, like you know you want to do this thing, but you don't really know how to do it. You take on this zeroth hat and say, "I'm a customer, I'm trying to do this. What do I do?" Usually, the first thing anybody's going to do, if they don't know about something, is Google it. We start out. There are tools that you can just record what your actions are, as well. It's really helpful to pair on this because writing and doing the thing can sometimes take a little bit of extra cognitive ability. What you're doing is you're documenting what you tried, writing it up, and then exploring, like how hard its friction log, because how hard was this thing to do? In your Google search, did you find the right thing that you wanted to do? Was it obvious? One of the ones we did last year was, how do you do a static site on serverless? What are your options? It uncovers a lot of the hidden debt that we don't think about. If you were planning a particular platform, you're focused on that platform, you might not be thinking about the broader picture. It helps people learn and explore things, and also uncover improvements that we can make.
Reisz: This goes back to when you were talking about making sure that you address learning and make sure learning's a part of the culture, and that you reserve time for it. Google's a big company, you've got a lot of resources, particularly in mid-size to smaller companies, how do you think about as a leader, making sure everyone has the space for learning?
Davis: For me, the very first thing is I budget from a team capacity perspective. Individuals, I take away a certain amount of time, and just like that's learning. I also put it in my OKRs. Those are the key results that we want to see from the team that we're doing learning, and we're doing exploring, and we're doing sharing. Also, part of just being the nature of DevRel, you always have to be learning. There's the industry trends, what is happening? One of the challenges I find is, how do we understand collectively what the team knows? That's a really big problem. I've been thinking about what tools, shared docs that we can have, because you don't really, always know what it is that you know as a team. There's no way to audit.
I am definitely not going to prescribe testing or checking, do people learn? You have to make space for it. You have to create opportunities. I've had some great discussions with John Allspaw, about, you don't know what anybody's learned. I created this presentation. I shared it with the world. I don't know what each and every one of you have learned from it. Different things are going to be takeaways from you. Same thing for my teams. I always need to be checking, rephrasing, and feedback, but also repeating things that I think are important. Checking to make sure what I've said is there. In terms of overall learning, I'm not checking for it. I'm making space for it.
See more presentations with transcripts
