Author: Jennifer Davis

Transcript

Davis: I’m going to be focusing on the positive elements of this. I do not want to talk in depth about change. There has been a lot of change that has occurred over the last few years: whether it’s from COVID, whether it’s from industry changes that have led to things that cause fear and anxiety in the workplaces. There is also positive change, promotions, and all of those kinds of things, or reorgs that are negative, or can be sometimes negative, and you don’t really know what’s happening. I’m here to talk to you about thriving through change, being prepared for change. I’m Jennifer. I am an engineering manager at Google. I’m also an author. I’m a builder of communities. I value connection and making opportunities for people to connect, like we have here with all of our unconferences and our talks to inspire and inform.

Context

Just like any team, my team, we want to make more value faster. That’s not surprising. The key thing is, it’s not for one individual or one function to move faster. Within DevRel, we have to think about all the cars or whatever other thing that we’re building. We have to be part of that process. We have to think for our team, but also for the larger org, and be aware of everything that’s in progress of being built. We have to think about, so how do we maximize the value we bring? I’m in DevRel engineering. What does that mean? We build code. We write code. Our value is in code that our users find valuable. It’s not just writing code. That’s not helpful. Just like any other company, we’re not just writing code for the fun, unless we are. There’s a core value to that code that we’re writing.

We think about the things that we want to minimize, and that’s building the wrong things, spending a lot of effort writing code for products that are never going to ship. Or, having a lot of things in progress and never delivering them. Changing up our context all the time. Working on technical debt. How many people have big missions that work on technical debt? I don’t like those ones, because the existence of a software artifact means it inherently has technical debt, and unless it is valuable to my users, I don’t really care. Unless it’s security, then I have to fix it. I don’t know if you have this experience, but for our team, if we write code, people are going to copy it and paste it straight into their production, without maybe examining it or understanding the context. Because it’s Google code, of course, it’s perfect.

If it’s a security issue, I want to fix it. We also want to not repeat the same problems over and again, and not learn from those mistakes. We want to not have instances of samples where they don’t follow established practices, so it ends up causing more technical debt.

One of the things I really love about my job is that we get to hold the banner of the zeroth customer. What does that mean? We sit right there and think about, what are teams really building? How are they building? What’s the context that they’re building them in? It’s just so thrilling to be thinking about reliability, operability, sustainability, all of the abilities, and then bringing that into the world and giving it to people so that they can copy and paste it, and try it out and learn. One of the examples I’m sharing here is the Avocano solutions. Avocano is a dynamic website, like, how would you build a dynamic website using Google Cloud Services? We talk through all the different constraints that we have and what choices we were making. Is it the one way? No. There are multiple ways.

Actually, we provide different solutions on how you build a dynamic website. It’s a core solution that we think is important for people to understand. Just like solutions, and there’s more than one way to do it, everything I’m going to share, there is more than one way to team. I’ve tried to focus on some of the things that are important from my context and my team, focused on DevRel engineering. There are different components, and you may not find that my paths are your paths. I’m hoping that you can take some things from it.

I’m going to talk a little bit about change. Last year, after years of looking at our organization, we started a transformation. It’s just started. We recognized the ever-increasing challenge of what our org as DevRel was trying to do, and specifically DevRel engineering. How many different APIs, how many products launching? How can we actually deliver samples in a meaningful way? The previous org, you have dedicated product teams. This is a combination of product and engineering that would map over to a DevRel team. DevRel engineering teams had multiple products that they were responsible for. My product areas were serverless, DevOps, orchestration. Then from that, we have to figure out, what’s the highest priority? Every single one of those product teams are not talking to each other. We’re the interface. When you think about DevOps teams and all the things, that’s what we were. There were multiple DevRel engineering teams responsible for different sets of samples.

Collectively, we had virtual teams where we would share the burden of the platform management. How do we write samples in these four main languages? What do we test? What’s our infrastructure? This is a process and set of processes and tools that have evolved over 10 years. There’s a lot of cruft in it and a lot of friction. Ownership of samples all sat in the DevRel engineering team, a team that went from 100 people to 50 people, to 23 people, to 14 people. Last year, they announced a reorg, and my team became 11 people.

The mission is to build a lightweight platform that enables more stewardship of samples so that the product teams, external contributors, and all of DevRel, including tech writing, can own and drive sample contribution. Not to apply some standard SLO across all samples, because there’s different types of samples. There’s how-tos. There’s concepts. There’s API SDKs where people really need it to be perfect and it does exactly the right things, because there’s nothing like going and looking up something and it does/doesn’t work. We need a bigger set of samples, but we cannot manage it the way we have been managing it. That’s the change, or where we want to go.

As I was planning out this talk, I started with one context. As the reorg hit, I was like, I’ve got to change up how I talk about this because everything’s changing. Yet, my team has been prepared to navigate this change because of the things that I’m going to talk about. They were ready and empowered, and they have that autonomy. Other folks have talked about DORA. DORA is this research that’s been happening for over nine years now. Effectively, there’s a set of metrics and a set of capabilities. It’s a choose your adventure. What capabilities are you trying to drive up to increase the metrics that matter to your organization so that you can have a high-performing team? It’s a way to categorize and evaluate how well your team is performing. It’s not meant to say, we’re better than this team and that team. High-performing has a lot of feels to it, but the goal is to create context that help people deliver.

Embrace Functional Leadership

There are four areas I want to talk about, and the things that I have used and leveraged to make change be something that, yes, sometimes it sucks, but we have the power to enable teams to navigate change. We don’t get to control all the changes. As much as we like to have cabs and change boards limiting what happens in production, we don’t control all change. Let’s talk about functional leadership. I want to talk about leadership, actually, because really words are hard, and we use the same word to mean different things at different times. When I say leadership, you might not be thinking about it the same way, and that’s ok. What is leadership? Often, it’s defined by someone’s following you, so then you’re the leader. That’s not very valuable. Sometimes the manager is the leader, and sometimes they’re not. Some people lead by example, and some people lead by coaching, and both of these are completely valid approaches.

In complex environments, leadership is about enabling people to come together to figure out the problems and share all the context, figure out what’s ambiguous, what’s possible. We need lots of different perspectives to enable strong choices. Not right choices, but strong choices, because generally there is no right answer. There’s lots of wrong ones, but there’s not one right answer. We need to help people to understand. That’s what a leader is. Mary Parker Follett was an American management consultant who did a lot, she pioneered a lot in terms of organizational theory and organizational management. She has some really amazing writing out there. I highly encourage. It’s very under-read, but she’s quoted a lot. Her concepts on functional leadership are amazing to me. I felt like, am I inventing some new way of doing things at one point when I first became a manager?

Then I started reading her, and I’m like, no, we discovered this hundreds of years ago, or 100 years ago, and we’re just not talking about it. She said, “Leadership is not defined by the exercise of power, but by the capacity to increase the sense of power among those led”. What does that even mean? It means we need to focus on the individuals first, and we need to empower everyone to be a leader. Everyone can be a leader, but then who’s following? That’s not the point of leadership. Some people talk about situational leadership, and people stepping up into leadership as needed, and that’s part of it too. Every one of us can be a leader. I approach a new team. What do I do? The first thing is, I do nothing to change anything, because there’s already enough change happening. Figure out the roles and responsibilities that everyone already thinks they have. Understand, I’m not going to make assumptions, no matter what anyone says to me, any other manager, any other person, that person can’t do this, or that person can’t do that, because I believe in my heart, everyone can be a leader.

I find out, I’m building these relationships, what are the motivations, goals, and worries that every individual has? What is their context? What are they hoping and dreaming of? What do they want out of this? It doesn’t matter if they’re only here for the money, or if they’re altruistic and they want to improve the world.

All that matters is I understand what their context is, what their capabilities are. Maybe there’s some context that is impeding them that I can help with, and maybe it’s just something I need to be able to recognize, and not change the conversation to be something they can’t do right now. I keep building up this knowledge about them. I see them in action. I understand more, what do they bring to the workplace? What are they bringing to the team? What are the different strengths and weaknesses everybody has? Where can I have opportunities to empower them to grow, to be more? How do I see them in these different lights? I can watch over time as these things change, and I can help them connect them with the people and the opportunities that best suit them.

I need to build trust. A lot of people know, we’re going to talk about values. None of that matters. Why are we talking about values again? Everybody wants to talk about values. It’s important. Even if you’re talking to a team that hates talking about values, it’s important. It’s important to talk about what the company’s culture and those values are, but it’s important to talk about as individuals. As a manager, I am the first one to step to the plate to be vulnerable and share. The three core values I have inform how I want to be present in the world and present for my teams. Authenticity, I want to commit who I am, who I’m presenting to you, this is me. This is what I believe, and this is what I value. If I say I’m going to do something, I’m going to do it. I’m going to be kind. I am going to be generous and thoughtful. I am going to treat every interaction to the best of my ability with kindness. I expect and want that out of the people I work with and the teams that I work with.

Sometimes kindness is about giving people feedback that they don’t really know that they need it. It’s like crucial feedback. Kindness is not the same thing as niceness and not telling someone, “I know that you want to do this thing, but you know how you did it this way”, and having those conversations, because feedback is a gift. I value trust. When people talk to me, when I talk to them, I do not assume that I have your trust. I will give you trust, but I am not going to assume you’re giving it to me until you’re ready. I’m your manager, I’m not going to assume anything. When you’re ready, you can tell me, and it’s good. I value your trust. I’m going to work hard to not break that trust.

All of these things are going to build together. The conversations that you can have by talking about your values are tremendous, because everybody has different things that they hold true to themselves. Helping people be authentic to themselves means they bring their best selves and their best perspectives to build the best things.

Functional leadership is about delegation. I care that everyone can achieve this goal of being a leader if they want to. I want to foster that capability, so I’m going to identify ways that are going to make it possible. By doing this, I can respond to change. Energies ebb and flow. People need time off. I don’t want any single points of failure within my organization, where now we’re going to have a fire drill, because nobody knows this, or we’re going to go and call this person who’s on leave. No. I want everyone to be enabled and empowered. I want to be able to take time off. I don’t want to have to check my phone. I don’t want to have to check my email. I want to make that commitment to the people who report to me. I delegate leadership. I also clearly define the roles and responsibilities, because I want people to understand what decisions do they get to make, what kind of autonomy do they have. If they need help, I’m going to coach them.

Enable Healthy Conflict

A key challenge we have is in conflict. Healthy conflict is an important part of team cohesion and finding great outcomes. What is healthy conflict? It’s having an argument that fosters creativity and personal development and builds stronger bonds. If we don’t address unhealthy conflict, we can cause more pain to be borne by the people who already have so much stacked up against them. In an intrateam conflict, building healthy conflict. You can recognize when you have it, when you have open communication, people are giving constructive feedback in a timely manner, and folks are open to other people’s ideas. They’re not immediately dismissing them. It’s so crucial. I’m emphasizing this so much because I’ve dealt with these challenges, and it’s really hard to preserve trust and foster psychological safety if we don’t address when someone’s being contemptuous or when somebody is being disrespectful.

Now, interteam conflict, that may not be something you have to worry so much on. In your context, it might be something where it helps us provide team cohesion, because we can be like, “They’re over there, they’re whatever. It’s all their fault”. It helps build bonds internally, but within DevRel, it’s not effective. We cannot do that. We have to work with so many product teams, with so many other core functionalities, tech writing, engineering teams across the org, security, OSPO. We cannot be an us and them. When you’re trying to achieve larger, big-scale impacts, you are literally forcing your virtual team to not be effective because you have caused a problem by turning into an us versus them. I don’t recommend that.

The core piece of this, and I tell folks about this, is that you have to keep a lot of things in your mind that may not feel congruent, but at the core, you don’t have to like how someone leads. We might say, in short, I don’t like them. I don’t care. Let’s not be sloppy. Really, you don’t like their decisions or the way they’re approaching this. You have to respect them. As a leader, if you find that you have people on a team, and that doesn’t matter if it’s a small team, a larger team, and you have people that are showing contempt and not respecting each other, that is when you have to make corrections if they don’t solve themselves. Because you’re not going to have an effective team otherwise. Too often, we’re too afraid to say something because then aren’t you like, are you not respecting people’s opinions or decisions? No. It’s ok to disagree, but you have to commit. You have to move forward.

The first step is maybe I talk to them and say, I get it, but what can you agree on? What are the things that you can agree on? It’s ok if it’s just that you both showed up. You both care passionately because that’s what usually causes the biggest conflict is when someone is like, I care passionately about it, and it needs to be this way, and I am right, and you’re wrong, and your idea sucks. In some cultures, you have a culture where it’s ok to speak in that language, and it’s completely acceptable. You know your context. In some cultures, you have to call it out and address the concerns that are coming up from this. It’s ok. It’s ok for people to have different opinions. The way to navigate that is to have clear roles and responsibilities. I said it before, I’ll say it again, who is responsible? Yes, everyone can be a leader, but not everyone all the time. There is a clear, articulated set of roles and responsibilities that line up and set the context so people know when they need to disagree but commit.

One of the other ways I navigate this, and there might be another term for this. I just want to share this. It’s establishing a common work item vocabulary. What does this mean? We have OKRs. Then we have projects that map out to those OKRs, and have impacts and business decisions. If we’re all doing work our own way, yes, everyone gets to choose how we do the work, but how we document how we do the work needs to be consistent. That way, we can improve the way that we deliver results, because if we look at the tree of work that maps out to the OKRs and the epics or the projects, and we map this down, down to the tasks, I know at any point in time as an IC, I can go look at my tree of work and know what my work maps to. I know how my work is changing and impacting the org. I know, before I even start to do the work, what is the value of that work? Am I achieving something that matters? That’s a core part of being happy. There’s five metrics of happiness, and autonomy is one, but doing work that matters.

The org could say, we’re changing priorities, but you have the record of what you did and what you accomplished. Connect the day-to-day work to the strategic, larger-level projects. As a manager and a leader, this also does something cool for me, and that means I can look across what the team is doing and make sure that all the projects are level-appropriate, and the scope of work is appropriate. I can search our internal tools and say, what’s the tree of work? Who’s getting what opportunities? Am I being fair and equitable and empowering people to take ownership? Are people having leadership opportunities, because everything has a scope and a set objective. It also provides transparency and accountability so people can see what everybody is doing, because we’re all talking in the same language. You can see, that person hasn’t done da-da-da. They’re not doing this or that. Are they on a big project? Are they the only one working on something? You have that visibility. It decreases the opportunities for people to have conflict about things that really don’t matter. They matter, but there’s ways to navigate them.

Other questions that I think about in helping people understand where they fit in to the bigger picture are these seven questions. The opportunities to measure and the tools that you have to engage and create these visualizations will vary across the org. Every individual in your team and across your org needs to know what’s going on, what’s the state of our work? What needs attention right now? What’s urgent and important? Where is my place in this? Am I actually contributing to any objectives that matter? What is meaningful to me? How am I having that meaning at work? How do I know what good looks like? How do I know when I’m done? What’s the state of my team? How healthy is my team?

Establish Metrics that Matter

We’re talking about stuff that’s measurements. Let’s talk about metrics that matter. Back to DORA. Again, nine years of research, lots of context, lots of community, lots of people have input these things. It’s distilled down into these four key metrics of deployment frequency, and lead time, which is throughput, and stability, change failure rate, and time to restore service. Back to me, because this is about my team, that’s data. I can have that context in my mind, but I need to actually think about, what am I doing now? I got a new team. What am I supposed to measure? The first thing is, figure out what the problem is. I’m sharing some metrics. This is all open source. All of our samples are open source. There’s no secrets here. We have 12,963 samples. We have 7,288 distinct use cases. What does that mean? There’s an intent for a sample. What are you trying to show? That’s what those use cases are.

Our goal is to at least have the four core languages have the sample, and that’s Python, Node, Go, and Java. There are additional languages that we try to support. Not every engineer knows every language. There are 11,320 files. There are 118 repositories that this covers. That was just our first assessment. Then we discovered, but some samples are just in documentation. They’re not in GitHub. We’re not even looking at the full picture. What do I do with this? I started talking to the team, and you’ll see that these are similar. I literally copied and pasted this from my notes in the doc I share with the team. These are very similar to some of the DORA metrics, but this is the start. This is not the finish. Every team is going to have their own special context of how they apply metrics, and what they gather, and what they measure.

For us, thinking about system green, it’s, we tested, and it’s the whole system and set of samples, and what that state is. If we know that early, when we’re building and validating and testing, that’s less expensive than, at the end, and discovering that we’ve launched that, and now the customers are finding the problem. Because, ideally, customers don’t find your problems. Again, we’re DevRel, so we are the zeroth customer, so if we are finding the problem, that’s a symptom of a larger issue. Another measurement, time to ship. That sounds obvious. It’s like in GitHub, you shipped it. Actually, no. Again, code is only as valuable to us, not if we finish writing it, but if people are using it. It has to be in docs. The measurement is from the point of the PR, to the point that it’s merged into docs. It’s available for people to go ahead and click, copy it direct from documentation. Rollbacks are, someone submitted a sample, we validated it, it looks good.

Then we discover, no, this is terrible, we got to roll back. You wouldn’t think, how could that happen with samples? It happens more often than you think, because the context is lost with you having different people doing different things and modifying changes that you wouldn’t imagine could happen. Because if you think about the context of all the samples, we’re validating platforms, there’s a lot of little axes of constraints, whether it’s version of language, version of runtimes, different third-party packages, it gets messy. Then, release cadence, thinking about, how often are we adding to our samples catalog? All of these felt like, this is a starter point. These are metrics I can measure right now, and we can see how we’re doing. Then we can make incremental change and see how we’re adding value to the organization, while also making change and improving processes, reducing how hard it is to add samples.

I don’t get to just decide, here’s the samples, this is the samples, and here’s the metrics we’re going to measure. You have to get buy-in. You have to get your leadership to agree, yes, this is valuable. Sometimes your leadership will say, so here is the metric we’re going to measure you against. Result, 50% of technical debt. Then you say, here is actually what we’re going to measure, because I don’t care about technical debt. I do, for certain values of technical debt, but what’s the value of me updating a node version of a language, of a sample? How do I know my customers value that sample at all? How do I know that we even have the right set of samples? Those are all things I really care about. Except I’ll resolve all the security issues, I can do that.

Craft Supportive Environments

Let’s craft some supportive environments. First, take care of yourself first, because leadership is hard. We don’t talk enough about how hard it is to be an effective leader. When we’re doing it in an environment that encourages a generative culture, where we encourage people to talk and connect, and we don’t have hierarchies. We’re often dealing with a lot of emotional baggage that people are carrying, and their trauma, and it can be hard. It’s not a right or wrong situation often. We have to be ok with things being 80% good. Everyone is different and unique and special. What helps you, you need to know. I have gone through periods of really stressful work environments and had burnouts, and been too afraid to know how to speak about it or to deal with it. The things that people talk about, it’s like do this, do that. No. You have to find out what works for you.

For me, I know that I am having a problem if I’m forgetting to do a daily walk, because walking is where I process a lot. Walking is how I feel connected to my emotions, where my body is feeling. I also have gotten into fiber arts and crochet because it’s all math and creating three-dimensional objects, which is fantastic. The things that help you are going to change, depending on where you are at. Take care of you first.

Let’s talk about teams, because that’s too emotional and frou-frou, but no, it’s really important. Think about the boundaries that you’re setting. The first step is being explicit and repeating over and again. This is an example of one of the agenda descriptions of my team meeting. It tells people explicitly every time, the goal of this meeting is that we are building together shared information, open communication. We’re going to discuss things. It’s not just a status meeting. We have async standups for that. We’re not doing just status. We’re together establishing team norms. We’re going to align on a shared goal and a mission. We’re going to share feedback. We are intentionally going to share feedback. When someone shares what they’re working on, we’re going to talk about it. You’re going to have opportunities to help, and we’re going to connect together. We’re going to have team rituals. Every team should have a set of rituals. I just introduced these to my new team in the last few months. We start our meetings with music. It gives people an opportunity.

Since we’re a distributed team, we don’t have water cooler moments. We don’t have time to share little bits and pieces all the time. This gives us an opportunity for people to share, here’s a set of music I like. We kick off meetings with a team temperature check. That gives people an opportunity to express support if they need it. It’s not all rainbows and unicorns in DevRel. There are challenging times. People get to talk about how they’re feeling, and be heard, and that matters. We end the meeting with kudos. That gives everybody the opportunity to practice giving feedback and to receive feedback. Instead of waiting to just do it quarterly or once a year at the end of the year, it means that we are thinking about and expressing what was the impact of how you did something, and please do more of it like that, because I appreciated it. That’s just the job. We get to practice accepting the feedback. It’s hard sometimes.

Another ritual that we don’t talk about a lot, but that we do, is goodbyes. I don’t own my people. I am sad when they leave. The opportunity to give them appreciation, to reflect, to share this in a team setting, is the most amazing gift. We do not do this enough to say goodbye, and we wish you well. Because the industry is so small, we are going to connect with these people again and again. The opportunities are massive. Showing the people who are on the team that you valued these people who are leaving, sets the context and increases that value for themselves as well.

Also, play. Play is awesome. Games, especially role-playing games, give us the opportunity to practice where our work can very much be connected to our identity. I encourage people to not have that sense of identity tied to their work, because what you work, what you do, is different than who you are. I recognize that often, one of the key problems with conflict is that you are questioning my identity when you question my work, but we’re not actually. Role-playing helps us to build up team connectiveness. It’s ok to practice failure at communication. You can do bad things in your game and it’s ok. Everything is cool. Also, playing helps you do really awesome things with your work.

This is part of my team that is in Vegas right now at the Next Conference. This is one of the cool apps that we built. It’s a meta-inception of building a train and building an app. It’s an app that builds and connects and validates, is your app going to work based on the services that you select? The train will move or not. You can grab the code and play with it yourself if you want to take a look. Play can lead to creativity and fun and team cohesion in a way that you wouldn’t expect you can inspire people.

Minimize the human toil. Let’s maximize what the machines do. Don’t maximize what the machines do and give all the toil to the humans. That’s my explicit boundary about certain things. How we could think about ways to automate some stuff. Automate context. We use GitHub Actions. This is a great utility, a feature of GitHub, if you are on GitHub. There’s also GitLab Actions that you can leverage. We automate what PR is their context, so we can identify who would be the best person to actually take on this context. We also automate linting, because not everybody remembers to lint their code and then this gives them fast feedback, you’ve got a problem. They’re not waiting for a review to find out that there’s actually a problem before they can even get their code merged. We’re also looking at, how do we take our standards of samples and how we write samples? Because the goal of our samples is not just working code. We want to teach something. To be effective, we have to think about the concepts and how we’re applying them. We’re working towards, how could we potentially automate this process too, and check to make sure that samples follow our guidelines?

We want to encourage cross-team projects, because cross-team projects is another way to facilitate leadership opportunities and grow people. Also, when you get teams that are made up of different specialists, you end up achieving really amazing things. One of the key solutions that I shared, the Avocano solution, my team built all the code, and we wrote the Neyer’s tutorial. We influenced the writing for the script for the demo that was made for the video. We worked with all these different teams that alone, if we tried to do it, it wouldn’t have been as nice.

Now we have this nice, polished solution that can meet people where they’re at, depending where they are in their learning journey. That’s enabled and empowered by cross-team projects. Include training and educations intentionally in planning. I always slice off the top 20%, and I say, this is going to be some kind of training, education. I factor it in in different ways. One of those ways is friction logging. Friction logging is a way to evaluate and be the customer zero, and determine, is this a good experience? If I didn’t know anything, or if I had this context, what would I experience? We provide that feedback to the product teams. We share and talk through it together, so it’s not that in isolation, that I’m just seeing what I know. Now I have a shared context. Here’s what Cloud Build does. Here’s what Cloud Run does. I have that together with my team. We write down what decisions we made and why. Sometimes we work on really cool things, and we then get prioritized over somewhere else.

These decision records actually help us set down context, so we don’t have to keep working on something. We can come back to it. For example, Emblem is this multi-product app that shows how to do something, that now there’s a new feature in Cloud Run with Cloud Deploy that we could refactor. We have our decision records that would allow us to do this, and tell us why we chose what we did at the time.

Have a show and tell. This is also a learning experience. It does not need to be something that’s like, here’s my polished demo, and now I’m going to present to everybody. It does give people the opportunity to practice presenting, but, more importantly, it gives people the opportunity to practice sharing what they’re doing. What did I learn today? Your team may have policies around open-source contributions, so before you encourage your team to do open source, make sure you check your OSPO policies and make sure it’s ok. One of the things about working in open source, for example, the Kubernetes projects are amazing at this, is it sets context for how to work with other teams. It empowers people and provides opportunities to do leadership, where there’s dynamics and there’s feelings, there’s a lot of feelings and personalities involved, but it’s outside of your job. It’s a separate context. It helps and supports people. I encourage people to contribute to open source. All of the continuous learning, it matters to you as well.

Conferences like QCon give us the opportunity to connect with one another and talk about all these different problems we’re facing. I’ve had so many amazing conversations that I just want to write about because I’m so inspired. One thing I want to share that I have gotten so much immense value is Ruth Malan’s technical leadership trainings. These are not, here, let me tell you how to do your job. Instead, it is a conversation. “That sounds terrible. I already talked to enough people. Why would I want to do that?” It’s leaders across the industry and different industries at different levels, CEOs, CTOs. You get this opportunity to talk to people and connect with people that are doing different problems, but sometimes the same problems, and see things from a different perspective. Ruth provides context and a common language, but it’s not a, let me tell you how to do this. It’s a conversation. I also recommend Lara Hogan’s management and leadership training.

A lot of her things you can get, is like, a play on your own time. She provides lots of examples of how to have some hard conversations. I would like to encourage folks to fill out the DORA survey, because your experience and how you solve problems matters. By filling out the survey, you help us validate and continue to evolve, what are the ways that we increase software performance? How can we measure? How can we improve?

Recap

I’ve talked about quite a few things. Embracing functional leadership. Everyone can be empowered to be a leader. Enable healthy conflict, and watch for patterns of contempt or dismissiveness that can impact how your team performs. Establish metrics that matter to you and to your team and your org. Craft those supportive environments that are going to build and nurture and create sustainable paths where humans are doing valuable, impactful work that’s not burning them out.

See more presentations with transcripts

Transcript

Davis: I’m going to be talking about enabling developer productivity, an internal and intentional evolution of the platform. In case you were wondering or confused if my words were not clear enough in my description, this is not about Kubernetes, and it’s not about internal development platforms or internal developer platforms, but I want to talk about platforms. I’m Jennifer Davis. I’m an engineering manager at Google. I am also an author. I’m very passionate about building communities and enabling people in different ways.

Developer Productivity

The first part of this, I want to talk about developer productivity. What is it? It’s totally about lines of code, and the number of artifacts you make. It’s getting into that flow. It is? No, not at all. It’s hard to describe. Let’s think about it from a business outcome perspective. Ultimately, the business wants us to build more value, faster all the time. It’s not about an individual’s value. It’s about whatever your company is building, whether it’s a product or a service. If you’re building cars, it’s about building the whole car. If you focus on a single element of that car, the seats or the windows, you’re going to just create artificial bottlenecks that impact the whole team. You’ll be wasting your opportunities to improve. It’s not about the individual, it’s about the team and the whole.

If we look at the research coming out of the DevOps research folks from DORA, it’s been about nine years now that they’ve been doing this research, and there’s a new survey out right now that you can take and participate in. What they’ve done is identified a set of outcomes that are predicted by the team’s performance, the organization’s performance, and all of these are dictated by capabilities.

You can predict how performant a team is based on a number of things. When we think about it, it’s those components, those capabilities that define the developer experience. Those are things like, how hard is it to write code? How hard is it to maintain code? How quickly can you get feedback about your code that you’ve written? How much autonomy do you have in choosing things and selecting how you’re going to solve problems? Maybe you don’t get to say this is the problem, but you get to choose how you do those things. Those are the capabilities that can predict your performance. It’s about your developer experience.

There are hindrances to dev experience. A lot of times if you think about Conway’s Law and that organizations design the systems that will produce and deliver this, and it’s impacted by the communication structure, then those same challenges in anything that we use, we can see them. It’s one of my little hobbies, is to evaluate and look at what are the communication flaws I see and how different services are out there by what I can guess is going on within that company, based on their communication structures. In addition to just the dev experience, for me personally, or for you individually, it’s about thinking beyond ourselves. It’s something that some people have innate. It’s like, I see a problem.

I can imagine a world in which it’s better, it’s improved for more than one person, but for a whole set of folks. It’s ok if this is not something that’s innate for you, an individual’s experience does not define the DevEx of a product or a service. It’s more the set of experiences that people have. You might not care or need to care about DevEx. You might be the only one in a field. You might not have any competition. I promise you, if your service or product is valuable, someone else is going to look at your terrible experience and say, that’s an opportunity for me to do something better. You cannot care about DevEx, but ultimately you want to care about it at some point.

How do we combat this? It’s with this role called DevRel. DevRel is this interdisciplinary role that centers around people and relationships. Every company does DevRel a little different, but it has the same components of engineering and advocacy and product. It’s a way to combat releasing your org charts with your products and services. Everyone should embrace a little bit of DevRel. I spoke at QCon in London recently, and I was talking about DevRel, and I had totally made this assumption, everybody knows what DevRel is.

Some of the feedback I got, I realized I’m doing everyone a disturbance. I’m doing the exact thing that I talk about, which is making assumptions about what everybody knows. We’re all vulnerable to this, making assumptions, and assuming this is the way. Ultimately, DevRel is going to help you increase adoption, increase engagement, increase enablement, change perceptions about what your company does, but also change your perceptions about what your company does. It’s going to help you identify and drive change that better fits your product or services into the market.

I want to share some of my experience right now, what’s going on and what I do. I said I’m at Google. Really, you might think Google is this huge company. What do you have to worry about any of those? It’s not really a one, it’s more like there’s a lot of us all working at the same company. We’re enabled by different sets of tools and possibilities. My team within DevRel is an engineering team. We create samples. I get the meta of the meta in terms of DevEx. We build the platform that helps other contributors at our company and our partners to build samples. Those samples in themselves are a measure of the developer experience that our products and services have.

Once upon a time, we had a single product, App Engine, and so DevRel built samples for App Engine. Then, as Google Cloud grew, we had a split, a reorg to have focused capabilities per language, because we really care about the idiomatic language experience that every developer comes into an environment: what they’re looking for, what they’re trying to solve. If we show them a Java sample that actually follows some practices in Node, those are not going to sit well, people are going to have a bad experience. They’re going to feel friction. We reorged based on language. Then that was insufficient, we had so many products. Then we reorged based on product. A platform emerged of shared capabilities while building samples, but it’s all fractured, and things kept getting bolted on based on what people needed.

What that meant is, if a product was doing well, they would staff the DevRel team to build the samples, to build the documentation. You have an uneven set of samples in the catalog supporting customers, but customers aren’t coming around, going, I want A sample to do A thing. Sometimes that’s the case, but a lot of time it’s about a journey. I’m trying to build a website, what do I need? I’m trying to build a Pub/Sub like message delivery, how do I do this? When you have a team that’s on a volunteer basis, handling your platform management and contacting different stakeholders and managing their expectations, and then having a bunch of top-down driven initiatives as well, you’re not going to be able to accelerate as different parts of the org need different samples, you’re stuck. We were shipping our org chart.

We started thinking about, what is it that we’re actually trying to do? There’s like, step one, we want to increase value. What’s our value? It’s not just samples. It’s code that our users find valuable. Unless our users are able to be successful with these samples, their DevEx of using the platform, we’re not successful, we’re not doing something that’s meaningful. Ultimately, as humans, we want to build something that has meaning. We came up with a set of principles. What are the things that we want to minimize? What do we want to stop doing? What are we going to try to eliminate completely from the work that we’re doing that’s distracting us? We don’t want to build the wrong things. We want to minimize how much work we actually have in progress, so we can actually deliver samples to customers.

We want to stop context switching platform to staff, to our stakeholders, to actual individual samples, to friction logging. We don’t want to work on bugs. That feels weird. Why wouldn’t you fix bugs? How do you know that the samples that have bugs are actually the right set of samples? You’re cutting yourself short by focusing on something you don’t even know has value yet. Which comes to the final two really critical pieces, we weren’t learning from our mistakes. Everyone would run into a particular problem. They’d share that with the product teams, but it didn’t go across all of DevRel, and so everyone kept experiencing the same sets of challenges. Not following established practices. When it comes to samples, partly, samples are part of the individual products, but partly, samples are a product in themselves. That set of samples that you provide to people, that set of samples that support your documentation, if you have bad samples, you’re going to hinder people’s trust in your samples. You have to think about that as a whole, and you want to have a consistent voice in those samples.

The first step in thinking about your platform is identifying the value that you’re creating and those shared capabilities of the platform. What thing are you taking care of for other folks, so they don’t have to all be specialists in them? Where are we going? This is specific to my team. There is no single platform that works for everybody and everybody’s use case. It’s a journey that we all have to discover, which is part of why I’m so passionate about this subject. This is where we’re going. My hope is to enable and empower lots of contributors, including ourselves, and having a lightweight, flexible platform that enables the creation of much broader set of samples, hence the bigger purple cloud.

Platforms

I said platform, what is a platform? Kubernetes is a platform. Google Cloud is a platform. The platform is the combination of much more than just the tools and technology. It’s the tools, the technology. It’s the processes. It’s the workflows. It’s the collaboration, the communication. It’s learning and development. It’s the environment and culture that you create. Platform, of course, it includes the tools and technologies. We can think of this as, how are you solving your particular problem? If you start out trying to solve the technology challenges and just implement random tools, you’re not solving your underlying value.

You can’t just throw away what exists. If you go and architect something and just try to create the new thing, all of the things you have built in the past are not there, and people are going to get really frustrated and angry, and you’re not going to have adoption of your platform. You have to think about your constraints, what exists today. You also have to question your assumptions. I’m going to talk a little bit later about some of the assumptions we’ve made and how we’ve changed it.

Ultimately, platforms need to be lightweight and evolve. One of the constraints we have is we do all our sample development on GitHub. That might seem strange. Of course, that makes sense. You’re making it open and available to people. Internally, contributors want to use the tools they have available that they know. Why can’t we just use the Google tools? It comes with all these extra measurements. Why can’t we just do that? There are assumptions embedded in that, assumptions that we have as well. We had to question ourselves, are we using the right set of workflows? We determine, yes, we need to create these samples in the open, available for people to see, and be able to explore them and build trust.

We also need to build them here, in this external place, because that’s what our customers are doing. We are the zero of customer of understanding, how does this platform work? If we’re leveraging things internally to build stuff, we’re not seeing all the friction. We’re not experiencing the friction. We’re not getting that feedback back to the products. If it’s so bad, that is something that needs to be improved. It’s being aware of your constraints when it comes to your tools and technology, so that you know when and what to change and how to change it.

You also want to minimize human toil. It’s not making it so that I want to do the thing just because it’s hard. There’s a lot of things we can get machines to do. Some of the things that we use, for example, our GitHub Actions that allow us to label context of pull requests that come in, and basically set that information to who is the most apt and expert in that area to handle reviews on it. We also set up LinkedIn so that when something comes in, people get that fast feedback. Is there something that they need to correct before it actually makes it into the system, or before someone actually reviews it? We set and establish sets of guidelines. In addition to Google style guides for all the different languages we support, we set explicit tiered sets of responsibilities and expectations people have about our samples, and that’s to encourage people to follow and have that single voice.

Platforms include the processes and workflows. Wherever you start from, that’s where you start. You have to test what your assumptions are about those workflows. One of those I mentioned with using GitHub and working in the open. Within a team, you want to also establish some common work item vocabulary, basically set how you’re going to handle issues that come in, have a single intake, how you assess the cost of building things. That way people understand and can communicate, and you build that trust within the team. Trust is crucial for a high-performing team. If you have situations where people can question because work’s not out in the open, or there’s not transparency, or there’s not consistency, you can have distrust.

That person isn’t working on the important things that you say are important, they’re just doing their own thing. That didn’t take much time, where is the actual work and impact? By establishing a set of vocabulary about how we talk about work, it creates more confidence and understanding, as you can see over time. It’s not a, measure the performance of individuals, it’s sharing across a team how they’re performing, so people can build trust.

We also do something called friction logging, and it’s not just for products in development, but it’s also an activity that helps us to work and share information about stuff. Because in DevRel, one of the concerns is, is there like a half-life? Can you only be in DevRel for some amount of time? The truth is, I think everybody should be doing DevRel, but also being able to try things out and explore them as a zeroth customer. You get the opportunity to take on the empathy, look at the DevEx of your product or your service, explore a journey, and provide meaningful feedback to the people building that particular product or service.

It also helps when onboarding someone. We’d have a little exercise of doing a friction log as a team exercise to understand what is it that we’re making assumptions about that we shouldn’t actually assume. Maybe there’s missing knowledge that we haven’t documented. Maybe there’s practices that have evolved in the community and we’ve missed them, and this helps us instill and grow our culture. Which goes to the platform is the collaboration and communication. When you’re trying to solve something, it’s more than just you. It starts within the team. You definitely need open communication and an ability to provide feedback to each other. Because if everyone is just saying, yes, that’s great, you’re not getting that critical feedback to be better or to be able to understand different perspectives.

You need to establish that set of trust and ensure there’s not contempt happening in any way on the team, or stonewalling, not answering people’s questions. Key to this is not building an us and them across the org. Especially within DevRel, we have stakeholders across the whole organization. We can’t get into a mindset of, they just do this, and it causes us so much problems. Because the minute we get into that, we’re going to harm our ability to work with people. We have to come from a place of yes, and. There’s a component of thinking through, how do you do this, not just within your organization, but across the industry as well? The industry frames and changes things. It’s, people have choice.

People are going to take a selection of different possibilities and build things upon them. When you choose a service from here and choose a service from there, GitLab, Datadog, you don’t have the capability to say, I’m going to ignore everything else and not care. If you think about this interteam and across the industry, how we’re building our relationships and how we accomplish and solve problems, it’s really crucial to actually driving performance.

It’s about learning and development. One of the first things we did as we tackled our new team and started thinking as a holistic element of looking across the platform, not just for a specific set of products, we started thinking, we have to be able to scale. How are we going to scale? We just had a set of training where we trained everybody about, how do you update a sample? How do you submit a PR? How do you submit a change list for our documentation, so the change that you made actually shows up in the documentation? All of this is part of a normal cadence.

Instead of just saying, people can figure it out themselves, actually taking the opportunity and making time for people to uplevel. Making explicit documentation about what you chose to do and why, because ultimately, the decisions you make about anything, they have to be available for evaluation, or you’re going to keep evaluating the same options over and over as the platform changes, or the needs of the platform change. New technology and new tools come to be available.

One of the things we do with our samples that we create, as well as with the platform itself, is to document, why do we choose to do this thing? Why are we coding in the open? Why do we use GitHub? That’s a decision record. We want to take note of that. We encourage sharing, we call it show and tell. It doesn’t have any expectations. Sometimes people feel vulnerable about saying, it’s a demo, when it’s half-baked. It’s ok when it’s show and tell, you’re just showing and telling about something you learned, or something you accomplished, something you tested out.

I encourage people to contribute to open-source projects. That seems redundant, because we work in open source, but here’s the challenge, it becomes too insular and siloed. You don’t notice having to work with other people. When you go into open-source projects, you learn better how to evolve your platform, because you’re able to see the different practices across the industry and adjust your expectations of how things could or should work. It’s easy to get caught up in the today, and here’s the focus and here’s the energy.

When you’re contributing to an open-source project, it lets you step away and think about things in a slightly different way. Which goes to the platform is the environment and culture. What is it that you want out of your platform? What is the space that you want to create for people? Thinking about the team rituals and seeding them with things that you care about. Some of the ones I’ve seeded within my team is we start our meetings with music, it gives people a little time. Because we’re a distributed team, we want time for people to connect with each other, and maybe they’ve been busy doing something all week, that music just provides that little easing into that sharing, where we talk through, how are you doing? This is the team temperature check using zones of regulation.

It gives people, if they’re feeling safe, the space and time to talk about how they’re doing and feeling, showing that mutual care for each other. They don’t have to share if they don’t want to. We end the meeting with kudos, just a little bit of gratitude, sets everyone up for a happy rest of their day, maybe fuels them for the rest of the week. When people leave the team, we celebrate it. We don’t just say goodbye. We actually take time to celebrate on those things that we’ve built with them and done with them, and that builds up more trust into the actual building of the platform itself. We play. We create samples and demos that go beyond just, here’s this thing. We think about, how do we engage our active whimsy? That makes it so it’s approachable for other people. We built this train demo: it’s open source. The concept was this game of, can you build a set of components, a working architecture? The logic behind it we calculated, it was like this meta on meta situation where we’re using cloud to build a test on cloud and build education.

Intentionally Evolving the Platform

I’ve talked a little bit about the platform. I’ve talked a little bit about developer performance. Then, how do you evolve the platform? First is keeping in mind the people, because the people are core. A lot of the things I just talked about with parts of the platform are about people. You want to establish an active communication plan. You want to be telling people and informing people on a regular rhythm. You want to make sure you know who you’re talking to and why you’re talking to them. You want to create a RACI, and that’s basically setting up a plan of the clear roles and responsibilities so everyone knows. It’s like the contract. If you do these things, we’ll do those things. Once you’ve identified and documented them, you can embed them into your planning of your technology. Who has capabilities? What are those capabilities? What are the contracts that you’re making, and establish with samples.

For us, the person who owns or is accountable to their sample, if they don’t update their sample, and I can’t automatically update it, then it’s going to get marked as something that can be archived. We’ve agreed to that contract based on the RACI. It’s connecting the effort to the value so people understand, why am I working on this particular thing? Because it helps build value over here. It’s making sure to celebrate the wins.

You can identify the set of metrics that matter to you within your org, a starting place might be DORA or SPACE. When it comes to DORA, there’s a set of metrics that I mentioned earlier that have been shown to show software delivery performance. This is a starting place. For us, when I look at what our environment is, and these are updated metrics since the last time I gave a talk that included metrics, our samples, we have 13,798 samples that we need to monitor and update and maintain. There are another 6000 approximate samples that are not actually in our docs yet. We’re trying to reduce that count so that all of our samples are available in our documentation. We have 8352 distinct use cases, meaning there’s specific journeys that we’re explaining to our developers. How do we think about how we would measure performance or the experience?

Remember, our goal, ultimately, for our platform is a double set of requirements. Right now, we’re focusing on our contributor metrics. Ultimately, we want to empower developers who come to use Google Cloud. Right now, we’re trying to grow our catalog, so our problem is quantity and quality. Our metrics are evolved slightly from the DORA metrics. You can see the hints in them. We want to think about how costly is it to update a sample and to catch problems with it. What is the right amount of effort that we should spend on update our own samples? Areas that are easy to measure are things like time to ship. That’s from the point that you start to submit a PR to the point that it actually gets into documentation, that measurement. It’s shown that high-performing teams are able to do this in hours. It might not surprise you to hear that it takes days to weeks for some of our samples to ship as a baseline. That’s improved.

Rollbacks for us is when a sample goes out into the wild, and then we have to go and make changes to it. That means it’s not like, roll back your production, but something leaked through that actually caused problems, and did not help people. Then, how often we’re delivering samples. A hard one for us to measure is our system green. How much should we be spending on testing our samples? What is that quality? This is the first set of metrics we’ve established to define how productive our developers can be? How effective can they be? Based on these metrics, we can change and adjust what we’re doing.

The first thing we did was we friction logged the sample contribution experience. We’ve done this multiple times, and we’ve gained additional information each time. If you think about how large a company is, and you think about who possibly could help with something, with samples, we could have a large set of folks that could work on samples, except we’ve always thought about it from a, here’s the set of folks, the DPEs, the developer program engineers, they’re the ones working on this code. We want to make it self-service. We want anybody who is interested in contributing samples to be empowered to contribute samples. We need to take on that experience. Talk to the tech writers, talk to the advocates, talk to the sales engineers, talk to the support engineers, find out what is hard about doing this. We’ve uncovered a lot.

One of the challenges we identified is in our review capacity, thinking about how long it takes for code to get into production. Part of this, is there availability for someone to review the code? We realized over time we’d had this set of patterns. We had a whole mentoring program. It took months to get to reviews. We just did not have that ability anymore to have that long lead time. We are taking a risk. We want to trust people to do the right thing, but we want to hold them accountable and make sure we’re measuring and seeing the impact of people’s reviews. Then, we want to recognize the quality behaviors. We have little badges to showcase when people are quality reviewers.

We decided to eliminate flaky testing. Originally, we did some research, and we were like, 78% of our alerts are noise, but they are solving some issues, so maybe we’ll progressively fix this problem. We determined that actually we’re not going to get there anytime soon, and we should quell the noise, so we’ve eliminated our flaky testing. We’re trying out AI. I want to say that for us, core to samples is trust. We know that people copy and paste our sample code directly into their production environment. I’m not saying that’s what they should do, but we recognize it’s what they do. There are things that we have found that we’re exploring with small experiments to determine areas where we can improve the overall experience.

When people file issues across our 100 and something odd repos, what if we’re able to assess things more quickly and consistently based on training from our previous issues to get better results in responding to specific types of issues. We’ve also looked at metadata generation, so that 19,000 samples, 7000 approximately, that are not embedded in documentation. Part of that is because there’s no metadata associated, meaning their title and description, like the intent of the sample. Because the model is trained specifically on our samples, it can provide context and help us to initiate a set of descriptions that helps us get our samples in the autogenerated pages.

We’ve also found that it’s helpful in terms of giving feedback on PRs, so we have those set of extensive style guides. It takes a reviewer knowing and understanding, it takes a contributor knowing and understanding all of those components. If we train a model directly on our style guides, we’re able to get a specific set of feedback that’s helpful that says, here’s where you’re having this problem. It links to the specific style guide issue, and that provides a better experience.

Recap

I’ve talked a lot about different pieces of this, in terms of what is developer productivity and platforms, and my thoughts on them, and about intentionally evolving your platform to solve the value that you are trying to build for your company or your service or your platform. It’s really important, ultimately, when we think about what is the dev experience, and investing some amount of time in that dev experience to help each one of us solve problems that are better for us as an industry.

Questions and Answers

Participant 1: Imagine that I am an IC, an individual contributor in my company, and my company has small silos, each sub-project has their own APIs, their own SDK. When my customers use those sub-projects, each SDK would look different. Being an IC in one of those projects, how can I influence my peers to start to discuss about developer productivity of how to have a cohesive experience over all the platform?

Davis: It goes to the whole culture of the environment. When you’re in a space where your company, it’s very siloed, and that’s what happens, you have to have some kind of leadership change that supports and encourages it. Coming from the grounds up, if you are in this situation, you can reach out and create a technical leads program. That’s one of the things that someone started at Google, actually. It encourages and starts discussions across. When people find these common problems, people want to help. Another part of it is navigating how you’re discussing and sharing or advocating for the problem. When we talk to leaders, as an IC and you’re going to your technical lead, or you’re not considered an official technical lead, but you see a problem.

If you frame it as, there’s this problem, and I need to fix it. In this case, we’re shipping all these APIs, and they’re all different, and the user experience is not quality. It seems obvious, there’s a problem, we should fix this. Ultimately, it comes down to communicating in the language of whoever you’re talking to and knowing what’s important to them. In your case, it’s like really challenging, because you can inspire and get everyone on board, yes, but then do you have investment to make change. You speak to, depending on how people are motivated, all our competitors are doing this, look at that. That’s one way.

Another way is, “I did a friction log. Here’s the things that create a lot of friction”. Talk to support engineers. Get that support there. If you can reduce support costs, because those are very expensive, like by the time something is problematic in the environment and a customer’s reporting, that’s costly. Or if you can improve people’s productivity, that’s a set of things that can change leaders’ minds. You don’t talk about it from the problem. You talk about it from the outcome and how it will support things.

Participant 2: You have 15 awesome examples of things to work on, if you were to pick one to start with, which one would it be?

Davis: My first step for me was figuring out what the problem was. I’ve described a lot of problems, but I didn’t describe the big one. The big one is fragmentation, so that we’re spending a lot of effort spending. The very first thing is to figure out, is there areas you’re spending? Then navigate how you talk to people, your leadership, your peers, your reports, whatever the case is, and identify how you can help people change their minds. It’s not easy. Getting people to think about disabling flaky bot was hard. It takes time to get to a decision where people are comfortable because you’re making change. You don’t want to do wholesale big changes, so you have to identify, what is going on? What are the risks? What are people afraid of? What are people wanting? What are people valuing? Once you establish that, you can tackle whatever the next thing is, and be willing to fail.

Participant 3: I have a question related to one of the measurements that I look at when I try to measure the engagement and motivation of my developers and data scientists. I would like just to get your opinion on that. They are telling us that they would like to see the connection between their actual work and the mission and vision of the company. Sometimes for us as managers, leaders, it’s easy to see that kind of connection, but it’s hard actually to break it down in actual projects, and most importantly, to show them the linkage between their everyday work and the vision, mission of the company or the organization. What would be your advice for this kind of work as a manager and leader?

Davis: If you think about it, and I’m going to add a little more context, samples, one of the things we want is we want to trust. In open source, you really want people to trust you. Any time you talk about tracking and data collection, because you want to collect data to improve, not to do anything bad, but to improve, it causes problems. Then, how do you, as an IC at a company, identify what changes actually matter and what’s valuable? As a whole, our samples, people can go to GitHub, and they can go copy and paste, but how do I know it’s actually helpful?

One thing is, depending on the set of abilities of tracking you have within your teams, you can identify and see how many things are deployed. We have something called Jumpstart solutions, where we can see direct impact of if someone deploys a solution, how long it stays deployed, how it evolves. Are they sticky? Are we enabling people? Are they learning more? What does that impact? When people can see those real numbers of you’ve enabled or you’ve engaged, it’s great, but it’s tricky. You have to map things into a different framing.

Part of this is getting people to talk about what you’re working on, and then tying it explicitly into the larger orgs, and repeating over again the message, “This is to do this, and it’s driving these sets of changes”. Recognizing that if they’re not seeing that value return, if the feedback loop isn’t bringing back and changing their work. If you’re not doing retros or post-mortems or whatever you want to call it, and you’re not incorporating change, it just feels like they’re throwing stuff out into the void. It’s really important to incorporate practices that also enable the learning loop.

Participant 4: You are talking about developer productivity. We have several smart developers on the team who want to be productive, more productive than they are right now, but they all have different definitions of what productive means. What’s your recommendation on reconciling the definitions and how to do it in politically nice terms without offending them much?

Davis: When we think about productivity, that’s why part of it is productivity of a team as a whole versus productivity as individuals. Individuals can be productive in whatever way they want, how they measure, it’s great. For me, I will tell my boss, I need my cookies, because when I get my cookies, they’re not real cookies, it’s just like, good job, that’s my cookie. It’s not even qualitative, it’s just occasionally I need that. I have my own set of metrics for my performance, but it’s one of the things why it’s really crucial, what you measure is going to influence what you get. If you say I need lines of code, you’re going to get more lines of code.

If you say, I want clicks to a URL, I know how to write a nice little tool that will automate clicks to a URL, because I value about different things. To change what you’re saying a little bit, it’s ok for everyone to have different measures of productivity, but clearly articulating with a common set of work vocabulary, clearly articulating what the goal is. We’re building cars, your part is that cog. If you have too many cogs, this other piece needs focus, and this is creating a bottleneck. Encouraging people to have mutual care and reciprocal trust to engage and enable each other. It’s really important as a manager to note when someone is not performing and to manage that in a kind way, because ignoring performance issues harms the team.

See more presentations with transcripts