Transcript
Hemphill: This is great. I'm pretty jazzed to see so many people show up, both because I actually think that this track is interesting to watch and it has grown over the years, and I think the ways in which we think about software, there is a bunch of things we can do around the craft of software and writing code. A lot of what we do has to be with the interactions we have with others, with the business organizations, what we're creating in this world. I think the fact that we're paying attention to that stuff is really awesome, so thank you all for showing up.
The talk today is sort of a two-piece. It's a bit about behavioral psychology, and then, we're going to focus that behavioral psychology around how in economics, we see that play out, and then, we'll orient it back to software development. We're going to go on a little bit of a tangent, and then, I'll bring you back to something that is relevant to you in your world.
A bit about myself, why you should care to listen to what I have to say. My name is Courtney Hemphill. I have been developing since '99, so I've been around the industry for a while. I wrote code, and then obviously, got into management and leading teams. For the last 14 years, I've been a consultant. I get to go in and out of these different companies which, for me, is quite fascinating. The way that we do consulting at Carbon Five is very integral to team and team dynamics. We oftentimes are actually building the teams. Oftentimes, we work with start-ups to actually create them from scratch. We'll come in early, build the software itself, help hire the teams.
It's interesting that I've worked with tiny companies that are just getting started, I've worked with growth companies, like Stitch Fix and Coinbase. Then, I've worked with these giant companies like Citibank. Within each of those companies, you would imagine that the cultures and the contexts and the incentive structures that are set up would be dramatically different. There is, in fact, a lot of commonality that you see, particularly around software development. That's what I wanted to talk about today, and some of the learnings I've had along the way, and some of the bad behaviors that I've also witnessed.
Focusing Illusion
First, let's talk a bit about what the heck a focusing illusion is. There is a great book that was written by a fellow named Daniel Kahneman, and it's called "Thinking Fast and Slow." In it, he describes a whole bunch of biases and heuristics that we come up with as individuals, to really just manage the complexity of our world.
Many of these behaviors, we've just evolved to have them. A lot of them are really just for us to be able to make decisions quickly and on the fly. The focusing illusion, specifically, is this interesting thing that happens, where if you get someone to focus on a particular thing, their perceptions of everything around it are really primed. Marketers love to use this, so you have all been the subject of focusing illusions, oftentimes from marketing. Some of the ways that you can think about it are, in fact, a study that Daniel Kahneman did, where he went out and went to a bunch of different colleges, found a bunch of college students. He asked them two questions, but he asked them in different orders. The question was, "How happy are you? Scale of 1 to 10, how's your general satisfaction in life?" When he asked that question first, 66% of the people were, "I'm pretty happy. I like my life, things are pretty great." Then, he would ask them, "How many dates did you go on last week?" College students were, "I don't know. 12, 10," and they're, "I'm kind of lonely, actually." "Zero," is probably going to be my answer.
Then, he flipped, and he asked first, "How many dates did you go on?" People literally are writing this down, and they're contemplating this or writing this down. "How sad is my life? How many dates have I had?" Then, he asks them, "How happy are you?" Same colleges, same demographic, same statistical significance, 12%. This is an example of focusing illusion, and it goes across a variety of variables. It's interesting in that we have a perception, also, of what happiness is, without being in that context. When you actually ask people, "How happy do you think if you made more money," oftentimes, people are like, "Way happier, for sure. I'm going to be much happier if I make more money."
When you actually interview the people that do make more money, what you find out is, it's not as gross a difference as you might expect. It's really, when you start to look at these things that we perceive to have a lot of value, when you actually are in that experience, you don't have the same amount of value. The reason that this is pertinent is, it's part of our systems-one and systems-two thinking. Systems-one thinking is part of what the focusing illusion does. There's a whole slew of biases that come up in our exchange with the world every day and the way in which we make decisions. He goes into a lot of them in this book, but the big number here to look at is that 95%.
So much of the decisions that we make every single day, 95% of them, in fact, are these gut, instinctual decisions. That leaves five percent for us to do that scoping-out, rational decision making that would allow us to get that bigger context. This is something to look at, in that we're not going to be able to change human psychology. We evolved this way, it's going to take a lot of years before we change this. We have to bake this into how we think about working with our teams, and how we can structure the types of context for our teams, to allow them to make the right decisions.
Part of this means we need to really set up those environments and prime our teams with the right dynamics and the right context, so that they can make the right decisions, given the fact that we know, 95% of the time, they're going to be banking this on gut instinct. The things I'm talking about are really the experiences of the team, so what have they experienced over the time that they've been working together, cultural norms of the team and agreements, beliefs, biases, and then, basic, just human intuition.
When you learn of the culture and context of your team, and when you start to figure out ways that you can make it more oriented to the type of actual productivity that you want, the better options that you have, in having a high-performing team.
The one thing that I'm going to rail on in this talk is, we are creative individuals. Software teams are creative thinkers, and we also work with cross-functional teams. So when we focus in on these metrics that are these discrete, detailed metrics, and we only think about those things, or if the company puts in place incentive structures that sort of forces us into thinking about just that one thing, we typically are not going to get the outcome that we want. The other thing is that outcomes in software are extraordinarily hard to measure. Usually, it takes a certain amount of time for us to see the impact of our work in this world. It's very difficult for us to see an immediate feedback loop of exactly the outcomes of our work, and so, we have a tendency to focus on these really discrete metrics.
The Bad
Historically, though, there was an option for us to be able to measure outcomes within the profession of engineering. I'm specifically here talking about mechanical engineering. There was this fellow, Frederick Taylor. Taylor himself was an engineer. He started at a factory, and over the time that he was at this factory, he did a good job, and he actually worked his way up in management. Taylor was obsessed with measurement. He was obsessed with this thing that came to be known as scientific management. There was a lot of great things that he actually put into place with these factories. These were things like tests that you could do, things like wage incentives, Gantt charts came out of his came out of his collaboration with Henry Gantt. A lot of statistical methods, quality control, great work, a lot of it that influenced the Ford lean system and the lean manufacturing, and also, agile. There was a lot of bad that came out of it, as well. Taylor, to be honest, was a bit of an asshole. He believed in eugenics. He was, "Some people are just created better than others," and he firmly believed this.
He put into place in some of these factories, this really false dichotomy between the craft and the workers and the management. He really felt that management was the only part of the business that could really make decisions. It led to this idea of workers just being cogs in a wheel, and it also led to various strikes. There's this great story. This is a photo of the Watertown Arsenal. This was during the war, and there were these beautiful, gorgeous - "gorgeous" is probably a bad word for a gun, but anyhow - the workers were creating these significant, necessary pieces of military hardware, and it was critical.
They brought Taylor in because they were, "We need to be more efficient." Taylor sent someone in, unannounced, basically with a stopwatch, to stand next to these workers and time them. The workers were sitting there like, "Who are you? What are you doing?" They basically just walked out. They were, "Look, we know what we're doing. We're very good at what we do. Why are you timing us?" This strike lasted six months, so this was a really big impact on the bottom line. It got all the way to President Woodrow Wilson, and he was pulled in front of the House committee and basically interviewed as to why this was happening. There was this famous interchange where Taylor was making some dumb comment about how men were just similar to horses or singing birds. President Woodrow Wilson was furious, and he responded, "We're not dealing with horses nor singing birds. We're dealing with men who are part of society and for whose benefit society is organized."
As you can see, you have to be careful when measuring things, we are working with individuals who really matter in this world. I think there's a different way to think about incentives, sometimes, that can be really beneficial. This is a photo of the CEO of Walgreen's - or he was the CEO for a period of time. He was interesting, because he realized a way in which to approach incentivizing the people that were doing the franchises for these Walgreen's stores.
Typically, most drug stores of the day, what they incentivized for was, basically, the profitability per store. These franchisees would go out and they'd say, "Ok, where's the cheapest store? That's the biggest I ever had, I'll get the cheap stores," but these were typically in areas where there just weren't that many people. Walgreen's was, "I'm going to look at profit per customer visit." He annihilated the competition by doing this, because Walgreen's, just then, put themselves anywhere that there were tons of customers, i.e., cities, and they really just annihilated the competition. That's where it goes well when you put in good incentives, from sort of the top down. It can go really badly.
I'm not sure if people remember Wells Fargo and "The Great Initiative." This was an internal goal set by the executive team, of at least eight financial products per customer. A financial product is a bank account, so you can see what happened. There were 190,000 accounts that were created that had fraudulent fees associated to them that people didn't even know about. There were workers that were actually hounding their families at Christmas to create accounts for Wells Fargo. It was because their management team would come to them four times a day, like clockwork, to ask them how many accounts they had opened. This is really bad incentive structure right here.
An interesting thing to note is this is, again, very discrete metric trying to be captured. There's other ways where you can give your entire company a mission to get behind, and you can give them the agency to do it, particularly if they can get behind the mission. This is Indra Nooyi. She is the CEO of PepsiCo - or she was, she just stepped down. She basically put into place a really outstanding mission that the stakeholders and the board thought she was crazy to do. The mission was around making healthier foods - and this is PepsiCo - and helping the planet. Two things that for the core business, seemed totally sideways. Yet, revenue went from $35 billion to $63 billion, share price nearly doubled.
There was this really wonderful story of a Frito Lay's plan, where the workers were given such autonomy that they actually figured out a way to take a local landfill that ran out of space, with all the trash that they were sending there. They took their refuse and they learned how to recycle it into creates outerwear, and other useful goods for the community that was surrounding them. This was in Arkansas. Here's an example of, not a specific metric, but a mission that's given to an organization, and people really rallying behind it.
Overemphasis on Highly Visible Behaviors
The point of all this, and what does it matter to software teams, is that when we overemphasize on these very visual behaviors that are very easy to measure, you get things like this doodle cartoon where people are, "Sweet. You're going to incentivize us via paying us to create a lot of bugs, or to fix a lot of bugs?" People are not going to check as hard for bugs when they check in their code. They'll probably get a lot more money if they just write a lot of bugs into the code. Things that are highly visible are not always the things that you want to focus on, even if the measurement of them is still something that you can make physical.
The point of all this is, try not to get myopic and focus in on some mandate that came down on high, trying to figure out, "What is the metric we can use to capture that," and then, developers scrambling to figure out, "How do we even figure out how to measure that metric?" The best way of reaching a goal, oftentimes, is to actually scope out and incentivize ownership by giving people the type of culture and the type of context that they can use to make the right decisions. Sort of a corollary to this, or a metaphor, is, people that rent a house are less incentivized to do upkeep on that house and make it a great house than people that own a house.
Ownership
Part of this is, how do we get to ownership? Some of the core concepts around market economies, which are highly complex, involve a lot of people that need to do work to create value that is going to be valuable to someone else in that market economy. The things that put in place great dynamics and market economy, or at least some of them, are things like ownership. You can freely exchange your work product, your service. You don't need to get permission from anyone else to do so. You also can operate in a certain degree of safety, meaning you know there's not bad actors in the system that are going to make the thing that you are providing value irrelevant.
Then, also, you have free access to information, meaning you know the value of the thing that you are delivering. I wanted to dive a little bit into some of these, the first of which is ownership. I think there's various ways in which you can slice ownership. One is assets, so straight-up assets. In our world, that is, more or less, code. The other way is thinking about self-interest. It sounds like self-serving, but to be honest, we all are going to be operating in our own self-interest. What are the ways that we can recognize that that's the default, and how we see that in a collective ownership structure? Then, finally, freedom of decision. How do we allow for that without introducing too much risk?
Diving into the first one. I get in a lot of conversations with teams about his, particularly when people are like, "Why can't I understand the type of code that's happening over there," and, "Why don't I get full access of a full-step development stack?" This comes directly from Martin Faller. He has a really good take on it, where he really sees this is "best," "ok," "not awesome." Collective is what most of us, I think, operate in, where most people can go and do a code base. Given the fact that you're on a team, you can contribute code, you can do pair reviews. There's a nice collective ownership of that code, and it's really something that's in the Agile XP handbook, this idea of collective ownership.
Collective ownership works fantastic, particularly if you're on a team where there's generally a same skill level. There's generally a shared trust, and people's discipline in the work is pretty well-considered. The code base isn't a good place. It's not totally a mess. Then, also, unit tests are in place. Those are core components of what make up an environment in which collective code ownership really can thrive. Without those things, you oftentimes can get into a situation where people are writing code that actually isn't meeting the bar, and you've got a lot of other individuals that are doing a lot of work to raise that particular individual's code up to another level.
If you start to see that happen too much, you can see defects crop up in the code. There are certain situations where even Martin Faller is, "weak code ownership," meaning that there are certain individuals that are overseeing the code, and they're allowing others to be involved in the code in different ways, maybe fixing bugs, maybe pairing more. That weak code ownership still has a place, depending on where your team is at.
There is a study that speaks to this. It was done by Microsoft, it's basically too many cooks in the kitchen. When you have too many people that are operating on a code base, and there is collective code ownership, but that structure that I was describing isn't really in place, you do see an outsized incurrence of bugs. Those are the things that you can monitor for, to understand, "Where should we be in this code ownership sphere?"
Another thing, which is the second topic, is the self-interest. How do you motivate individuals to take interest in code that is not theirs, it's not owned by them? There is this wonderful - I don't even know if it's a book, but it was an article that was written called "Homesteading the Noosphere." This was written back, roughly, in the late 1990s or mid-1990s by Eric Raymond. It's a super entertaining read, so I highly recommend going and reading it. There was this idea thrown out in it of the benevolent dictator for life. This is really someone in open-source development that is the curator. They take a project, and they really oversee that project and the persistence and maintenance of it over time. He pulls from this idea of a Lockean proviso - it's almost like homesteading - where as long as you're owning a thing in a way where it doesn't impact others negatively - with Locke, it was more around this idea of things that were utilitarian. If you were going to own a piece of land, you couldn't also own all the water that would be impacting acres of land around you. In this scenario, one of the ways that he sees the self-interest being attributed, is this idea of a reputation return. Your return, in this case, is not economic, but people are giving credit for the work that they're doing in these repos. This is particularly important in collective ownership, where people recognize that the work that they're doing is valued, because they're giving kudos, the reputation is held, and it persists over time.
Then, the last part of ownership that I wanted to talk about is this freedom of decision. Definitely, the bigger risk it is to do organization, the harder it is to feel that you can give autonomy and agency to team members. I think it's important to recognize what type of project you are working on.
I totally get that there are arguments for where there needs to be a lot of control, because the risk to the organization is incredibly high. In those scenarios, I think you can have less agency, if there's a collective understanding by the organization that you're basically choosing waterfall. There needs to be a ton of upfront work to declare what work needs to be done and defining it. It is really waterfall development, and the developers are just doing that work. There's going to be less true sense of ownership in that situation, but as long as people understand the why behind it, it can work.
That top right-hand corner is really where you want to be, if it's a risky project. The trick with this is that you had better have you're a-game on for communication. If there needs to be a ton of control and a ton of agency for people to be quickly making the decisions, the communication channels have to be real-time, people have to be on board, people have to really prioritize the team and its needs above everything else. Then, obviously, you don't want to be on the bottom left, but giving agency to software teams oftentimes means just giving them direct access to the outcomes that they need. If it's a lower-risk thing, and you believe that you can give a generalized outcome statement and a problem to a developer and say, "Go to it," that's also a really productive place.
Then, finally, this is something that at Carbon Five, we tend to hire for a ton. We've ended up doing interviewing processes all around this, but figuring out how you can hire product-minded developers. When I say that, I don't mean it has to be a B2C product. You can have a product-minded developer, or you can have a product mindset as a developer, even if you're building tools for internal teams, or you're doing infrastructure work. In that case, you just have to think of your consumer as being the other teams at the company. Your consumer, in that situation, is other developers of the company, and their satisfaction is the thing that really is what should matter to you.
Be sure that developers are really getting access to whoever that end customer is. When we were working with Stitch Fix, it was awesome because we really didn't need a product manager on the team that was working in the warehouse, because the developers would go into the warehouse all the time and talk to the people that were working in the warehouse. I've seen great success when you have developers sit in on customer success calls, or customer service calls. Then, in terms of the internal customers, really having API teams or tooling teams interview and get empathy for the other developers that they're writing code for, or writing infrastructure for.
We also ended up finding that sometimes you think that you are giving that full picture of what the product outcomes or what the problem is to development teams. We ended up developing this sort of assessment tool. It's like, how do you assess the collective product intelligence of a team, so that they know the value and they all agree on it? What we found is that oftentimes we'll do this, it's almost a super-retro, but people fill out a bunch of statements around core responsibility, shared trust, all of the things that I've been talking about. When you find that there are deltas between the team, you know you have a problem, and you can focus in on that thing and try to solve for it.
If you have more questions about this, I was part of the people that built it, so I'd be happy to talk about it more.
Safety
Jumping into the next part of what really can help market economies thrive, is this idea of safety. This is, how do you ensure for a protected, level playing field? You really can't get anything productive done, if people feel that they are either under threat themselves, or if they feel that the game is rigged. You have to make sure that you go back and you're looking at how to ensure that safety is part of the system. There's a lot of talk about psychological safety, which I'm a total advocate for. I think the other thing is that whether you like it or not, people are operating on a set of first principles. I mean, it's either their own, or it is a collective set of first principles.
When you think about how first principles are created, typically, it's through experience. There's this great quote that was done by, actually, Justice Holmes. This was way back in the day, but it was a famous quote. He said, "Where the life of the law has not been logic, it has been experience." There's a lot of different interpretations, because it's law. That's what they do, they just interpret all the time. What he was saying is, never lose touch with the needs of the ordinary people. What that means is that oftentimes, your first principles have to adapt to your situation. This is actually pulled from Lon Fuller, who was a fellow who wrote "The Morality of Law" in 1964.
He felt that there were eight minimal conditions that needed to be in place, in order for great first principles to survive, and these are the eight. I would encourage, and I think this is a great practice for teams, particularly if they're going to be working together for a while, to go through, to figure out what are their first principles, and then, make sure that they meet these eight conditions.
I'd say the other thing that we have to our advantage as software developers is, there's a ton of stuff that we have in place, to ensure that we can reduce the risk, and/or sometimes, make it reversible. We can take really risky decisions, and we have all sorts of safeguards to ensure that if we mess up, we can do our best to scramble and reverse that risk that we took. These are things like testing and code standards, PR reviews. If you write something into the code that you're not 100% sure about, but you've got a really strict PR review policy, then you can know that someone else is going to be covering your back. Also, I love this idea of canary deployees, AV testing, letting things go out in the real world incrementally, with the knowledge that you can roll back a deployment. This is also a call-out to, if you don't have these tools in place, you are reducing the safety and the ability of your team to make great decisions, and to do so in a way that they can feel safe around. These tools take effort to put into place, and time, but allocating that will ensure that the productivity is increased over time. It's a great investment to make, and it's a great investment to keep up with.
Information
Finally, I wanted to talk about information. Communication is critical for any team to be productive. I think one of the things that I see really break down the productivity of teams is when there's just lack of communication. What we've found is that we've oriented now to this microservices world, where services are everywhere, and we have smaller teams. Honestly, that is probably the best thing for productivity, but the overhead of communication is definitely increased.
It's important for us to recognize that strategies for communication and how we can optimize communication. If we're going to focus on anything, this is probably the thing to focus on. Great communication between your teams is one thing. I would also say, amazing communication with stakeholders is something that we, as software teams, could probably work even harder on. When I say "stakeholders," I mean customers, but also management, ensuring that there is a nice, easy communication pathway, both up and down.
There's a fun way to think about communication strategy. These are just some of the ways that we communicate today. There are others, obviously, different companies, but these are some of them. I like the way that this has been framed around cold and hot. We're a consulting company, so we jump into brand-new companies, brand-new industries, totally new domain language, totally new team members. What we know is that we have to optimize for really hot communication from the get-go. You have to gain trust, understanding that collective language. That only happens with face-to-face communication. We overemphasize face-to-face communication from the get-go, to ensure that we have established that type of rapport with the team.
Then, over time, you can start to flex down into the other types of communication, understanding that there's a trade-off. You are gaining an efficiency, face-to-face is very expensive, but you are losing in some of the optimized abilities to have that free communication, and really, just understand how other people think and work. I don't know if anyone here has ever had a Slack message that came from someone you haven't met yet, and you're, "That was weird. That person's nasty." Then, you have a coffee with them, or you have a meeting with them two weeks later, and you're like, "I totally get it. That's just how they communicate." You want to do that first, so that all Slack communications that come after that are well understood, and you can understand the way in which people communicate with one another.
Coming up with a strategy and just recognizing, if people haven't met yet, make them meet. We work with a company that's completely distributed. It's this company called Protocol Labs, and the intent is for the team to always be distributed. They get their whole team and our whole team together routinely, usually once every two to three months, for a huge powwow at a - they'll take over a hotel, and everyone's working together for that week. That makes all the work that's yet to come way more productive.
The other thing that's interesting is, there was a study within that same agile principles and practices book, about the effectiveness of communication. There are two really fun things that came out of this. First, answers here are rated on a range from "very ineffective," that's -5, to "very effective," so that would be on the positive end of the spectrum. The one that I love here is "overview documentation." I don't know if people can see the numbers there, but for everyone, "overview documentation," thumbs up, good stuff. Check out "detailed documentation." No one reads it. We get asked this all the time "Are you going to be putting together a detailed documentation," and you're, "For what?" No one reads it. "Overview documentation" wins.
Other thing that's super interesting here, and this is why I was bringing up the stakeholder thing, online chat is fantastic for development. Fantastic if you need to ask your designer something, when you need to ask the PM something. When you need to communicate with stakeholders or people that are really busy in the organization, or customers it's really bad to get on chat to do that. This is really fun. I loved seeing these numbers, because they validated some of the hypotheses that I had going in.
Finally, I wanted to chat a little bit about visibility. I've been harping a lot on "You shouldn't measure," "You shouldn't focus in on these metrics." I kind of lied. You do need to capture metrics. If you are not having some amount of tracking of what's going on, observability, monitoring, and even better, visualizing that in the space that you're in, you are not giving your team that heartbeat check of health. Thinking about metrics more is this, how healthy are we, how our team's doing, how is the product doing, are we up, are we down? These are good things to know, and making them as visible as possible really helps people to motivate. People aren't going to look at these monitors every day. They're not going to check these metrics every time, but when you want them, you want them right now. Ensuring that you've got the muscle memory and the skills already in place to pull the metrics, and figuring out what are the metrics that matter, and then, making them visible so people can get to them really fast are super important.
When I was talking more about don't chat with your stakeholders, the other thing is, it's really hard for software developers to want to put a PowerPoint presentation together. Although I will say, this was really fun. I enjoyed putting this together. Doing that, stakeholders love photos. If you are not getting your message across, if you're, "We should have launched. Here are all the reasons, and here are all the detailed analysis that I've done," and you're saying the thing, and you're giving them the Google Documents and nothing's happening, try to figure out a way to make this narrative a little more real: if it's pictures, if it's PowerPoints, whatever it is. Clear, concise communication with the people that you're trying to convince is really a great skill to develop.
The other thing is, there is a half-life to communication in all of our organizations. Has anyone here ever been frustrated where you're, "I said that thing. Why is nobody hearing that thing?" It's funny, because in the military, there's this statement that they teach generals straightaway. It's, "Tell them what you told them, and tell them again." It's just hard sometimes to hear something clearly when there's a ton of other things being said all the time. If you think you stated something and you've delivered the message, do it again, and then, do it again.
Then, finally, Julia Evans has this fantastic blog post where she talks about how to tell people what you're working on, and why it matters. I think this something that we typically don't do. We go into work, we do our work, we're with our team, and then, we go home. Through lunch talks and just externalizing the work that you're doing, others actually both understand the work that you're doing, recognize why you're doing it, and gain a little bit of empathy about maybe why it's going slow, or how you were super-productive, and you discovered something. Telling people what you're working on is not an ego boost. You're not trying to be proud, although you should be. It is really bringing people into your work and allowing more communication to get distributed around the organization.
I already talked about dashboards and metrics. Then, the final thing is, there is a sense, I think, that we all get of just a little bit too much collaboration and communication. I know that there's a lot of stress that's felt in these open-floor plans now, and just feeling like you're constantly on tap to respond to people on Slack. That is a thing to consider. Figuring out small units that you can do well and communicate well, and then, really just exposing either great APIs or contracts or ways in which to communicate with people, where the overhead is low on you, but the exposure to the rest of the organization is high.
There was another fellow that worked with Taylor. You can tell I don't have a wonderful opinion of Taylor. This guy, a fellow by the name of Harrington Emerson, he was a pair, at least of the time, with Taylor. He came from a totally different viewpoint from Taylor, where he basically was, "The people that are doing the work are the ones that are going to be able to figure out how to be most productive themselves." He has this wonderful quote where he conceived of an organic organization where efficiency was a natural occurrence, not an imposed set of targets and procedures.
Anyhow, I'll leave you with that. I think it's important to believe that your teams can actually find a way to productivity, if you give them the right focus and the right mission.
Questions and Answers
Participant 1: On the topic of incentives and incentivizing the wrong behavior, do you have any strategies you've found work well for explaining to management and people above ICs that incentives are not aligned to their goals, and that they're using, as you said, things that are easy to measure?
Hemphill: I don't have one specific silver bullet that you can take back to your organization, sorry. What I would say is, there really has to be a cultural shift in organizations. What I have seen in my experience with dozens and dozens of companies is that you typically will find particular organizations where they find success in really analyzing and having metrics in other areas of their organization, for example, with sales teams, where they figure, "We can just apply this in other areas of the organization." It's really trying to educate them in the difference between a factory and a craft studio.
Development and product, it's really in the world of a craft studio, rather than a factory that's just got outputs that you can measure really easily. It's almost like you have to orient them more to this idea of thinking of this as a different type of operating organization than something like their sales organization, and that incentives are typically not going to work as well as hand us problems and tell us the outcome that you want, and we can provide you the outcome that you're looking for.
Participant 2: We've found that when we have communication on consulting projects - we're working with an outside customer - that having developers communicate with stakeholders is really problematic. It doesn't work well. What we've found is that the developers will tend to pander to the customers' needs that way. What have you done, or what suggestions do you have in that area, in making that communication more concise, and actually getting through some of the needs?
Hemphill: Partly, what I was talking about when I said we hire for product-minded developers is, when you think about product management, great product managers will never overpromise. What they'll actually do is, they will under-promise and they will over-deliver. That's something that's a core concept that we really educate our developers around. You will only be successful if you can show success iteratively and discretely over time. Being able to hold to that core value system and communicate that to stakeholders is stitched in to how we operate.
I would say, in general, I love the idea of educating everyone in our organization, but specifically software developers, around what does it mean to be business-minded? How do you have empathy for the business, so that when you do go and talk to them, you can recognize that by overpromising them something, you're actually not going to get the outcome that they want. Also, a lot of the time when people want the thing, if you ask them a little bit about, really, what they want, you can find a smaller way to achieve the outcome than doing a ton of work. It's a little bit of an education, and I think we've done stuff where, generally, it's stitched into our process.
Also, we've had developers go to management courses. There's this wonderful one run by a guy, Michael Dehring, called "General Management." It's a four-day course, and it's fantastic. They teach "Communication" by Barbara Minto, and all these core concepts. That's a great skill to have as a developer, so I think that might help in your situation.
Participant 3: Can you talk about the relationship between voice of employee, so collecting feedback from employees, it could be engineers, or it could be just broader organization, and tenure? I've worked in previous contexts where we had a lot of things that you described, but we still saw a regular rate of churn within the organization. Managing churn alongside making sure that those things are present is very difficult. How do you make sure that those are aligned? How do you set up your organization so that you can consistently provide all the things that you talked about, and at a broader level, make sure that people stick around?
Hemphill: Did you feel that the attrition was due to the fact that some of these things were in place? I guess, maybe what I'm hearing is partly the first problem to handle is the attrition problem. Part of the reason people leave is really, honestly, bad incentives and bad management. That is typically why people leave organizations. One thing to think about is how do you make sure that the management allows for people to feel like they're valued to the organization? Partly, it is through some of this stuff.
I'd say the other thing is, I think a lot of this has to do with great mentorship. These types of practices only get put into place when people respect them, and they honor them. Also, they pair with others to mentor them into that philosophy and teach them why it matters. That has to happen. None of this will happen if just a bunch of the ICs are doing it. The whole organization has to buy into it. That's, honestly, a lot of the difficulty that I see in organizations. They're, "We want productivity," but they're not willing to realize that the friction is within the dynamics that they've set up. Starting to help them understand, "We are not working quickly because of the friction points that are here and here. Help us to work more efficiently in these ways."
Then, also being a little bit considerate around the things that they're going to be seeing as risky changes they can make culturally, versus the ones that they can make more easily. Oftentimes, communication is the thing that you can focus in on first, because it's low-risk.
Participant 4: In your opinion, what's the order of incentivizing an employee to keep them happy and less attrition, in terms of monetary mission of the organization, versus ownership? What would be the order? What's the presentation?
Hemphill: Like, what's the priority?
Participant 4: Yes, and in terms of presentation. You shared some numbers that were very interesting.
Hemphill: Ownership becomes a loaded term, a little bit. If you use it loosely, people will draw their circles around things, and that's really problematic. In fact, oftentimes, what'll happen is, the people that have either the most tenure in an organization, or the most power in an organization will start to do that. That's really bad, because that basically pushes other people out. I would over-index on the idea of what the mission is for the organization, and particularly, for the development team.
We have a mission to ensure that we are gaining the trust of the rest of the organization around the work that we do, and we are going to get there by delivering value incrementally and quickly. That is a way in which you could have a mission that allows people to understand that they have work to do, and how they know they're being successful. I will say, people tend to get behind missions more than they get behind decrees. If you're saying, "We're going to work in this exact way, and this is what ownership means to us," it's a very structured thing for people to have to consider. When you orient people around a shared mission, obviously, it'd be awesome if you could co-create that mission with them. Then, everyone's bought in, and they're willing to work in that way.
Participant 5: Is there a way in which we can foster ownership when we are working with external partners? For example, the developers are coming from several companies, and you're creating a team, but you don't have, really, a mission for everyone, because everybody has their own mission in their own companies.
Hemphill: Obviously, we're involved in this a lot. I think the thing is to recognize, at the boundaries, where is the value given and received? Meaning, every single one of those individuals that is part of this context that you're setting up, they're producing something that clearly is of value to some other entity within the system. They need to see those other entities in the system as their customers, and they need to treat them as such. Ownership doesn't have to include all things, but ownership has to respect the boundaries, and it has to understand the value that they're creating, and what the market appetite is for it, and to understand and appreciate that market.
For example, if you have an external team that's coming in, and they're doing a specific thing and they have their mission, understanding what is the value that you are gaining from them, and having a conversation around expectations and what will be highly valuable that you'll appreciate, versus them being like, "We're just going to give you that." There has to be a free-flow of exchange and understanding of that value. That's how people can maintain ownership around their sphere and their mission, while still allowing to operate with others in, effectively, like a market economy.
Participant 6: For developer productivity, I think there are two concepts. One is looking at individuals' productivity and team productivity. What is it that you have measured to show team productivity? I have been trying to do this for the past six months, and besides seeing how fast they produce value, haven't come up with anything.
Hemphill: The thesis of this is that the reason you haven't come up with anything is because it's immensely hard. Most of the time, people try to figure out what it is by lines of code. Output of developers is something that, A, it's going to take time to measure. The best way to think about how you measure productivity is looking at different areas of the organization and how they measure things. For example, marketing return on investment. You don't time the amount of hours that the marketing team is in their seats, at their desks. That's just dumb. You do understand how these big initiatives, oftentimes, are crazy, like $8 million to do a thing. They're, "We have indicators that we believe it had some sort of value in these ways," Honestly, marketing is really hard to figure out how you can measure the productivity, or really, the results for marketing. I think you have to think about it in the same way. What you are looking for are, "How do we understand that the work that a team is doing has measurable business value, not measurable productivity measures?" I think it's important to have metrics analyzing just the activity of a team, and monitoring the software itself and observing it.
It's a falsehood to go chasing after productivity, because you're missing what, ultimately, is going to be more important for the business. You could make the developers crazy productive, but if they're doing the wrong thing for the business, it's not good for anybody. This is getting the rest of the organization and the people you're working with on board with the idea of "We're going to meet you in the middle by explaining to you how we are providing value, and how the outputs of the developer team are meeting these business metrics that you've put into place."
It's a little bit of work on their side to say "Here's the problem we have and the outcome that we'd like to see," so that you can meet them at that place and say, "Ok, we'll meet you there," and the way in which you're going to give us the full problem. Then, we are going to incrementally show you value along the way.
Participant 6: Follow-up on that. We've tried that also, but there are some products that are inherently cash cows that are $100-million businesses, and there are products that are just coming up and are $1-million or $2-million businesses. Somehow, comparing these two also does not really work well.
Hemphill: I don't know if I have a great answer. I guess the one thing I would say is that if you look at some of the greatest products, like Google Earth, these were never monitored. There was never productivity associated with those products, and they became multimillion-dollar successes. Obviously, it's appropriate to measure the success of a team, but I think there has to be a certain acknowledgement of it's more important to measure the business value created. There has to be a creative exercise done by you and your team, as to say, "How can we show early value?"
Instead of chasing after the productivity metrics, can you prove to the business that you have garnered a certain amount of money in a discrete piece of work that you have done that is measurable? To me, if I was the CEO of that company, that's more what I would be interested in, not so much you telling me, "The development team wrote this many lines of code," or, "fixed this many bugs," or whatever. I think it's interesting when you dive into SLOs and SOEs for systems that have to be a certain amount of reliability and resiliency, even those can get really complicated when you recognize how complex it is. I don't, again, have a perfect answer for you. I would really try to orient to something that, at the end of the day, has a market value that has a dollar sign behind it.
Participant 7: I have a very complicated thought that I want to express. There was a slide you had up about how few people read complicated documentation, or detailed documentation. First of all, I was in the Air Force for nine years, we had a saying, "R.T.F.M," very important. Secondly, some of the greatest developers that I've ever met were people that wrote and read very detailed documentation. Frankly, the percentage of really great developers that I've met matched the number that you had up there, of people that read detailed documentation. Maybe you'll express some further thoughts on that. Just because something is popular doesn't mean it's right.
Hemphill: Totally agree. I think it's easy to make statements that feel like you are generalizing the world into one nice, spiffy little tweet. I don't have an intent to do that. What I would say is that for much of the software development that I have seen, detailed documentation has a tendency to age quickly, because the systems change quickly. The more details that you stick in the documentation, the more out-of-date that documentation gets, and the more effort it is to keep it up-to-date. Having said that, I think clearly there are really important detailed documentation that needs to be put into place into systems that are very important for support of critical functions of human beings, such as healthcare systems, or military systems.
It isn't to say that in all cases, what I'm showing up here will carry. There's obviously going to be differences. I would say what we have experienced is that software development changes a lot. Software itself changes a lot, and documentation oftentimes does not keep pace. Tests do, though. Really great tests will always track the development.
Participant 8: Because you said these metrics are hard, when the team is making a decision for something like bad programming, it gets really hard to justify it, because the pushback is, will all still be larger, if people just work on it on their own. How do you handle that?
Hemphill: I think what we've recognized is that there is very dogmatic pair programming, where it's just expected that everyone does it. I think that is a totally fine approach in certain situations, particularly where the skill level's a little different, or there's new team members, where they need to come up to speed. I'd say pair programming is fantastic for so many reasons, but there's a time and a place and a product life cycle or a project life cycle, where you can pragmatically pair, where you're about to approach a really complex thing, and you want to pair on it.
I wouldn't advocate for doing pair programming as a directive that has to be followed all the time, because I actually do think that if it's done 100% of the time to the disinterest of just getting things done, oftentimes, you'll see that it's not the most productive way. I do think it is critically important to do it, and I think that you've got to be careful you don't lose the faith of the company and the idea that pair programming has a lot of value.
See more presentations with transcripts
