Webinar: The Best-Kept Secrets of High-Performance Development Teams

Ever wondered what separates high-performance development organizations from shops that struggle to maintain productivity?

Last week, Pivotal’s Richard Seroter hosted a wide-ranging and interactive discussion with Forrester Vice President and Principle Analyst Jeffrey Hammond about the information they’ve learned from high-performing teams. They discuss how developers can best use their time, context switching, office culture, how to get the most from agile, and much more.

Webinar: The Best Kept Secrets of High-Performing Teams from Pivotal Tracker on YouTube.

Here’s the transcript of the webinar:

Richard Seroter: Hi there. My name’s Richard Seroter. I’m Senior Director of product at Pivotal, and today I am joined by Jeffrey Hammond of Forrester, and we are gonna have, I think, a fun chat about unlocking some of the potential of your dev team, and what high-performance teams do differently. And then draw some of the contrast from our years of experience. Jeffrey, you want to quickly introduce yourself?

Jeffrey Hammond: Hey, thanks a lot Richard. I appreciate you having me on today. It was fun when we’re chatting ‘cause I think together we’ve got almost 50 years of experience when it comes to writing code, building products, building development tools.

Across that time, you have good experiences and bad experiences, so I think we’ve got a great opportunity today to kind of talk about what we’ve seen that works as well as some of the research that’s been done into high-performance culture, and some of the nonobvious things that can really make development teams more productive.

And just some of the philosophy about how you should think about managing teams and supporting them with tools and processes and organizations that make them most effective.

Richard Seroter: Absolutely, and for all of you, I’ll have a couple of polls during this. And one of the reasons we were excited, actually, to drag Forrester on this call is they’ve done some great research in this space. I think you’ll see some pretty novel information.

So Pivotal, for 30 seconds, the mission is to transform how the world builds software. That means helping teams figure out methods, technology to make that happen. So Pivotal Cloud Foundry is a great platform for building, deploying, running apps on any cloud. But as we’re gonna talk about today, it’s not just the technology.

While technology can trigger the right cultural changes, there are a lot of organizational and psychological aspects to high-performing teams that doesn’t just mean throw them the latest tools and they will magically ship more software, better, of higher quality.

As we think about what a high-performance team is—and Jeffrey I’ll be interested if you completely disagree with my take—but in my experience a high-performing dev team quickly delivers production-ready relevant software. It puts the user at the center.

Production ready is defined really in Susan Fowler Rigetti’s new book, Production-Ready Microservices. And she called this a criteria. If you’re production ready in software, you have stable, reliable, scalable, fault-tolerant performance, monitored, documented, and well-prepared-for-catastrophe software.

I don’t know Jefferey. Do you have anything you would quickly add to that?

Jeffrey Hammond: Yeah Richard. I agree with that. You know, for me, a lot of it comes down to value. High-performance teams are able to deliver value to the customer more quickly than other teams, so it gets into that production-ready concept.

Because if you think about software and value, it doesn’t matter how many lines of code you write, it doesn’t matter how many test cases you write, if that code production, and it doesn’t accurately capture the intellectual property that makes your business unique and delights your customers, then it really doesn’t have a lot of value; 10,000 lines of code that haven’t been pushed to production are really just work in process.

I would agree with that. The other thing I would say is I’ve worked with teams, and I have been privileged enough to be on a couple of what I would really consider incredibly high-performance software teams, and you know it when you’re there.

There’s a team cohesion and an ability to work together that, at least for me, in my career, has been almost intoxicating. And if you’re in a situation where you’re not one of those high-performance teams, it can really be frustrating and hard to accept a situation that is not high-performance because of organization challenges or cultural challenges inside the business or even not having the right tools or platforms to make the teams effective.

Richard Seroter: Yeah. Hopefully our goal today is to help you, if you feel like you’re in an underperforming team or managing one, whether those things that you can do at the end of this, I feel like you’re ready to go.

With that, wanted to kind of kick into some of Jeffrey, your points, I think introduce this and potentially throw a poll in there, but want to give you the reigns.

Jeffrey Hammond: Yeah. Thank you. We’ll go ‘head and push the poll up here. While we’re doing that, I want to give a little bit of background into some of the research that we’ve done in this space.

I’ve been working with our data team on our yearly developers survey for a number of years. And as I thought about the kinds of questions that I wanted to ask developers, some of those were very much informed by the experience I’ve had over the last 25 years.

I spend about 10 of those years at Rational Software, and our mission at that point in time was to turn software development into an engineering process, and to some extent, into an industrialized process.

As I reflect now from being out of that sort of mission for almost 10 years here, Forrester, in some ways, I question exactly what we were trying to do because, as a result, I often talk to clients and they tell me about their efforts to create software factories, and there’s something about that concept of a software factory that just really troubles me now.

In trying to understand the value or challenge of a software factory, we wanted to drill in and understand the way that developers work, the way that they engage at the companies that they’re at.

And even something as basic as what they do throughout the day. If you go and you talk to somebody who’s in the business side of an organization and you ask them, well, what do developers do? They kind of quickly come back with the obvious answer, which is, well, developers write code.

As far as they’re concerned, developers spend all day writing code. I’m not sure that that’s exactly the case, so for the last few years, we’ve been asking developers questions as part of our research in terms of how much time do you spend during the day writing code and how does that compare to the other activities that you’re involved in?

We’ve been collecting this data over a few years, and we’ve seen that actually developers don’t spend as much time writing code as you might expect, that there’s a variety of other things that they do. Some of them, I think, good and healthy, and some of them may be a little bit not so good, and things that get in their way of becoming high-performance teams.

Let’s look at some of that information, and some of the feedback that we get.

We asked the developers across a wide variety of different tasks and we find that the good news is that about 58% of developers spend at least an hour a day writing code, doing what we think they do.

The interesting thing is, when you dig into it, only about 28%, so a bit more than one out of four developers, spend three or more hours a day writing code. And only about 10% of developers spend four hours or more a day writing code.

If you think about that, only one in 10 developers spends at least half their day, assuming you have an eight-hour day, maybe some people work more, some people work a little bit less, writing code.

It’s not just about writing code in terms of how developers work. If we look at some of the other tasks that they are involved in, we find that about 48% will spend at least an hour a day building their software or integrating their code with somebody else’s code or somebody’s third-party package.

We find that about 46% spend at least an hour a day debugging or dealing with production support issues. Essentially, I would qualify this as dealing with the technical debt of the systems that they create; 45% spend at least an hour a day designing new functionality, which I think is great.

You could argue that you want as much time designing new functionality as possible. You could argue that maybe that’s an architect’s job or a designer’s job, but it’s developers that are doing this.

And at least 33% spend and hour a day unit testing. I think that’s good and bad. I think that’s great that developers are doing testing, and I think developers should be doing more testing because that’s part of their job in terms of ensuring quality and production-ready services. You know, I would love to know a little bit more as to whether or not that unit testing involved manual unit testing, which I don’t think is particularly valuable. Or creating automated unit tests, which then can be run very, very quickly.

All these are kind of basic nuts and bolts type of activities, but they’re also not the sum total of what developers tell us that they spend time doing.

Richard, I think you had a comment or two about this when you saw this data.

Richard Seroter: Yeah, I think one thing that jumped out from my own experience is how much production support issues can cause so much variability. It can obviously be zero one day or eight hours the next day. As teams start to shift to these pod-based or DevOps, whatever we like to call these sort of smaller units, trying to solve how do we deal with production support without completely injecting variability into our plan is a really big important part of that strategy, otherwise you’ll constantly distract your team and never keep on focus there, at least from my experience.

Jeffrey Hammond: Yeah, especially if you get issues that come in and they become hot-patch type things, or student body shift left, or if the backlog is kind of constantly being re-groomed as part of the morning standup. It can really kill a team’s functionality and flow. I’ve certainly seen that in the past.

But there are some other things that developers tell us that they spend time doing. I think a lot of what you see on this slide is really good. I’ve left the writing new or changing existing code up there just for reference.

But we find that about 35% of developers will tell us that they spend at least an hour or more a day in meetings. I don’t think that’s necessarily bad. At minimum, you should be spending 15 minutes in the standup, but when it starts getting to two to three hours a day of meetings, about one in 10 developers spend at least three to four hours a day in meetings, you have to wonder, is that really the best use of their time?

I will tell you, when I look at organizations that I would call agile from a process perspective, they say they are doing agile, but you really start to drill into what tactics they’re using and how they’ve started to scale their agile techniques, you sometimes find these organizations that are very dogmatic in the way they adopt agile.

And in some ways, they’re just exchanging one process for another, and when there’s a lot of meetings to kind of build consensus or discuss what you’re gonna do, you sometimes see that as a real flow-killing activity. We also see that about one out of four developers spends at least an hour getting feedback from users, which I think is probably a pretty good thing.

I think the more developers can understand how things are actually being used, the better. And about one out of three developers will work with external customers for at least an hour a day or with business sponsors for an hour a day.

Richard Seroter: Mm-hmm. Those are good numbers. I think the meetings is always tricky, as you point out. I used to tell my product owners on my team that part of your success metric is if your devs are spending 90% of their time coding or not in meetings with you. That’s successful.

Sometimes, as a team manager, you have to protect that time preciously because meetings are often counter-productive, at least in large groups.

Jeffrey Hammond: Yeah, I think so. And one of the things I see, I’d be curious in terms of what you’ve seen here, but in organizations where there is a strong product management type function or product ownership function, if that product manager takes responsibility for a lot of that meeting-type stuff and shielding-type action, it can really help a team spend less time in meetings and increase their flow right.

It’s one of the reasons that I often recommend that sort of two-in-the-box model, kind of the Scrum-based, Scrum master product owner or the product manager with program manager as that shield to a high-performance team.

Richard Seroter: Yeah, no, I agree.

I’ve been heartened to see more companies embracing the product manager role, and sometimes that’s an evolution of a business analyst or things like that, but someone who understands the customer need is able to flow that down and help prioritize and help do some blocking and tackling, and shielding developers, sometimes, from the noise that’s not necessary for building the app.

Jeffrey Hammond: Yeah, I’m seeing that increasingly in digital organizations at some of the largest brands that we work with as Forrester clients.

While it’s been a very common practice in the ISV end of the space for years, it hasn’t been very common in IT shops at large organizations. And I think that it is changing, and it’s the digital organization that is driving that change in a lot of case, and I think it’s incredibly healthy.

Richard Seroter: I agree.

Jeffrey Hammond: There’s one last set of tasks that we see developers doing, and I would say that these are the things that tend to be the most worrisome to me.

We find that about 38% of developers, so almost four in 10, spend at least an hour a day dealing with e-mail.

And hopefully, it’s at the start of the day or at the end of the day, and not throughout the day because every time you’re gonna drop out of your tools to go look at your e-mail queue, and deal with those e-mail queues, you essentially take yourself out of the zone, out of flow, and you have to reinsert yourself back into flow as a developer, and that can be extremely time consuming.

But it’s the other two that really bother me. It’s three out of 10 developers, 30% spend at least an hour a day deploying code. That seems like it’s way too much from my perspective. Done right and with the right tools and the right automation, deployment should almost be an afterthought.

It should be something like, you know, I’ll go over to what you guys do at Cloud Foundry, Richard. It should be as simple as saying, “CF push, master,” and being able to deploy.

And that 29% that spend at least an hour a day configuring infrastructure, in some ways, I look at that and say, “Man, that is so 20th century, you know, when we used to have our own development machines under our desks.” We had these specially built infrastructures and with modern day containerized infrastructure, public cloud infrastructure, even VM based infrastructure, that idea that you would spend that much time configuring the infrastructure as opposed to writing code seems almost like a downside of DevOps or maybe even DevOps gone wrong.

What do you think about that?

Richard Seroter: Yeah that configuring infrastructure one jumped out at me as a red flag. I mean, you’re arguably saying up to 50% of folks spend an hour a day doing that.

If you also look at our poll results, if you haven’t had a chance to fill it in, I’d love people to add their votes to this. But excessive process, getting software to production is the runaway winner here at 58% so far.

I think that echoes what you just talked about is that some of that biggest de-motivators for shipping software is shipping software. It’s deploying code. It’s being able to get your infrastructure scaled and acquired, and to some extent, the companies that are most successful have automated their path to production, which means those things become almost zero activities because that’s part of an automated pipeline.

Jeffrey Hammond: Yeah, it’s interesting Richard. Last week, I watched a webinar that Home Depot put up on YouTube, and one of their folks was talking about their path to deployment, and their “no release.”

They talked about the first time they went and said, “Hey, we want to do a release, and how long is it gonna take?” And the answer they got back was about four hours. They were like, “Well, why?”

You know, it’s a very simple change, and they had to go in and the person that presented talked about going into all the rules and all the processes that were involved in doing that relatively simple push to production.

And I thought it was just a wonderful example of what I call the “no release,” and an organization that puts all these rules and processes in place to make it hard to deploy.

I once had a client that I worked with in the government. I asked what their “no release” was, and the response was 18 months. It didn’t matter whether you changed one line of code or 10,000 lines of code, it would have taken them 18 months to get a new system into production.

So when you think about high performance and delivering value, that’s almost as far away from high performance as you can get because of the span of that “no release.” How can you deliver value when it takes you 18 months to get changes out into production? It just blew my mind.

Fortunately, most folks are not at that layer of lack of flow, but all too many folks are not even at that four-hour window that the Home Depot guys were before they started attacking the waste in their “no release” process.

Richard Seroter: Yeah, we’ll talk about in a moment, I think, some of that waste in process. To your point there, to some extent, software has no value until it hits production. It doesn’t matter if your stage is finished. If you’re even fantastic coders, and that code is just sitting as work in progress waiting for the next step in the pipeline, you’re not done really.

You’re not done ‘til someone’s able to get value from that software. Sometimes, I think getting visibility to that whole pipeline really changes people’s mindset.

Jeffrey Hammond: Come on, Richard. I thought developers were done when they check the code in, right?

Richard Seroter: Somebody else will test it.

Jeffrey Hammond: That’s been the classic measure, right? Certainly not something I would put as part of a high-performance team for sure.

Now, let’s pivot a little bit. We’ve talked a little bit about what the developers do with their time on a day-to-day and hour-by-hour basis. I want to poke at this 58% response on the poll that excessive processes are for getting software into production.

Process, by and large, is the responsibility of a management in development, and in development operations.

And I want to ask, OK, well then what is the role of the manager when it comes to managing a development team and managing a high-performance development team?

Why don’t we go ahead and push the second poll that we have because I think when you think about designing a high-performance culture, it’s very much…the way that you go is very much dependent on your philosophy about what development looks like, and how it works, and the role of process with people and tools.

And this is where I see a lot of organizations go off the rails because they don’t necessarily have the right context for what management does or what the role of process is, and how they blend that with the talent and the tools that their development teams use.

Richard Seroter: I’ve read some good books around management. Frankly, as I’ve gotten older, I have more appreciation for management versus leadership, and sometimes it’s easy to talk poorly about management because everyone’s inspired by leaders, but managers have to translate sometimes complex directives, and turn that into something actionable, and they have to layer that often helps people what are the right things to do.

There’s a lot of value and unique skill in management that is different than straight-up leadership. I think sometimes we conflate those two incorrectly.

Jeffrey Hammond: Yeah. They also have to deal with the realities of what we see in the development space right now.

I’ve been looking at the demand for developers in the United States, if you believe the Bureau of Labor Statistics in terms of the number of positions that are gonna be created over the next 10 years, and then you look at the graduation rates from computer science programs at various universities in the US, it’s pretty clear that there’s barely enough supply to keep up with the demand, even if you expect developers to be perfectly distributed across the US and all the areas where companies need them.

But even so, I find that increasingly organizations are competing to try to get what they would call the best developers, so the developers with the right skills. It’s one of the things, I think, that’s driving the inflation out here in San Francisco, and managers have to deal with the reality of talent sourcing, acquisition of that talent, and then retention of that talent.

In a situation where processes keep developers from getting the work that they want to get done, done, it can be an extremely challenging environment to create those sorts of high-performance teams that organizations are looking to create.

Richard Seroter: Right.

Jeffrey Hammond: I’m gonna go ahead and move forward while we look at this additional poll. One of the biggest challenges that I find, and I chatted a little bit about this earlier when I talked about organizations that are agile by process is that it’s really too easy to swap out one set of process guidelines and rules and deliverables for another.

If I think about the last 25 years that I’ve been in the software development space, we’ve seen a gradual evolution of process thinking. We saw initial, kind of mythical man-month type work that built on the concept of productivity that we saw out of manufacturing things built on the works of Deming, and Humphrey, and Crosby, and Juran.

And then for a while, the thing that every firm aspired to was to be CMMI level three or even maybe above eventually, and we had all these CMMI certifications.

When I was at Rational, we did very good business selling RUP to lots and lots of organizations. RUP was something around the order of maybe 10,000 pages in a 100 or two deliverables, different types of deliverables.

And then that got replaced by various agile techniques and principles, and we’re now seeing a lot of firms that are trying to figure out how they effectively scale the various agile process that they’ve decided to use, whether it’s Scrum or whether it’s XP or some other discipline or minimum viable product or lean thinking.

Throughout all this, I still see so many organizations where they use the process to infuse dogma into the organization, and I think what I have seen with high-performance teams is they move beyond agile by process.

They start by embracing agile by practice, and what I mean by that is they start getting away from saying we are gonna practice Scrum, and we’re gonna do everything that the Scrum thing tells us to do.

We’re gonna do everything that XP tells us to do, and they start to say we’re gonna use the tactics that work for us. They might do standups, but then they might also embrace extreme programming, and they see value out of that.

They might mix in some of the thinking from lean startup around minimum viable products, but they take specific tactics, and then they benchmark the success and the increase in productivity that comes from those tactics. And they gradually get better and better because of the practices that some of the processes prescribe, but not necessarily by slavishly following the process itself.

And then kind of the final level that I see from organizations where we see high performance tends to expose itself are what I would call agile in spirit.

And they really start to look at this issue of value delivery, and they start to restructure the organization. They start to focus on measuring the end value that is created, so instead of developers checking in code, they look at things like the ratio of defects found in production to the ratio of defects found in pre-production.

They look at the amount of user engagement that the new systems are driving. They look at minimizing that “no release” time frame so that they could rapidly deliver value or recover when they deliver something that maybe doesn’t work as well.

Setting yourself to commit to that sort of high-process culture is moving from that agile by process thinking to the agile by practice, and then agile in spirit type of approach.

And Richard, I know that the Pivotal Labs guys have certainly dealt with many customers that have gone through that sort of process to improve their overall productivity. I’m sure you could talk about that for a while, but let’s take a few minutes and get your reflections on that.

Richard Seroter: Yeah, I mean just a moment I think you describe well, too, the difference between what’s often called big A agile versus little A agile. Like be agile, whether it’s the little a, which means, as you said, sometimes taking in the best pieces without worrying about the ceremony, and just having a standup doesn’t make you big A agile. Doesn’t make you somehow magically ship better.

Understanding your organization, but also recognizing sometimes it can be dangerous to say we need to fit X process to our culture because your culture may be broken. So then, you’re actually degrading the process, so there always has to be some self-reflection and some good self-awareness about do we think we have a healthy delivery-oriented culture, and if so, then let’s fit something to do that.

If we don’t, then maybe we do need to shake things up, and Pivotal Labs does help companies learn things like test-driven development and pairing and doing real short releases. Those things help.

But, you know, it’s funny you’ve probably seen this, too. I’ve worked in places that aren’t even at the list of things you listed here. They’re almost doing Frederick Taylor-esque scientific management with software saying this is a factory. This is a prescriptive way and you can write X amount of code in X hours, and this is a repeatable task that I could outsource instead of respecting what you’re gonna talk about in a few moments. I think there’s a more creative aspect to software delivery that doesn’t just go to screwing toothpaste tube tops on, and it’s not that repeatable of a process.

Jeffrey Hammond: Absolutely. Takeaway then, process is important, but process is not everything. We find that high-performance teams are able to balance their investments in process with their investments in culture and organization, and then in their investments in talent.

And it’s doing all of them successfully that create, at least, the climate that enables high-performance development teams.

Let’s talk about that sort of factory, software factory-driven approach. If you are at that point, there are some things that you can do. I search for metaphors for development teams, and we’ll talk about some of those in a second.

But if you look at traditional, kind of total quality management or Toyota-type model approaches and how they would apply to development, that gets you to the idea of waste.

In manufacturing, the Toyota method talks about three specific types of things that you have to look at: Muda, which would be waste, Muri, which is overburden, and Mura, which is unevenness.

And we do see all three of those things in software development. They’re very, very common. This is an example of the types of waste that you see in manufacturing, but if you look at the types of waste that you tend to see in software development, tell me you’ve never been at a shop that has suffered from some of these: analysis paralysis, too many surplus artifacts.

When you’re creating artifacts, and you’re asking, “Well, who oversees these artifacts? And what are they used for and do we keep them and evolve them over time?”

What’s the point in creating things if they’re not gonna be used throughout the life cycle of the application.

Broken builds is one of my favorites because, you know, creates waste faster than you could imagine. Rigid architecture, late discovery of defects, high “no release” ratios, like we already talked about.

In terms of overburden, one of the things that we see a result of all those things that developers have to do and the need to context switch is that a lot of developers work a lot more than 40 hours a week.

I was struck yesterday. I was watching my Twitter feed, and I saw this article come through that talked about how a CIO out in the Valley here has replaced most of his meals with a protein supplement called Soylent.

And I’m thinking here, man, if that isn’t an example of overburden that you don’t have enough time to eat? How many development shops do we see where, because of we’re measuring line of code or we’re dealing with all of this waste, the developers feel like they’re on a death march.

I remember early in my career sleeping under my desk at one point on a delivery for a customer and just thinking about the overburden involved in that, or context switching.

To me, that’s one of the things that leads to a lot of unevenness, going back to that debugging or production support issues. Whenever you have to be taken out of a coding session to go deal with a hot defect that’s come in, or have to switch from feature delivery to defect delivery, the context switching there is extreme.

There’s a Twitter quote I had in my feed yesterday that I thought was right on point. Whenever you tell a developer to switch up the task that they’re doing, think of it as if you’re asking them to go drive two hours to a remote location, do something, and then drive two hours back.

Because the pain of getting yourself out of the variables, and the code, and the features and the functions that you’re trying to deliver as a developer, and having to go to that meeting, and then come back in is something that I find that teams constantly underestimate the waste that is caused by a constant stream of context switching.

You pull people out of the zone, and I can’t tell you the number of instances that I’ve seen developing teams suffer from that sort of rapid context switching that leads almost to flailing on the team.

Richard Seroter: Right. Yeah, no, some great points there. You’ve called out a handful of things there.

You have to ask yourself what’s the impact of the waste? I mean, in some cases, you might go through bits of this. Waste can’t always be zero because you are experimenting. You are learning, and things like that happen, but I think as you start to look at this list, which is a great one, especially as you map it back to development.

You have to figure out what type of waste is ever acceptable, and then what is the impact of the business when you overproduce? What is the impact on the business when you’re waiting too long? Are you missing business opportunities? Are you struggling with low-quality code that ruins your customer experience because you have so many defects? I mean there’s all these things that actually really have a material impact on your business, every single one of these.

It’s interesting, as you start to think in a waste to mindset, and a lean mindset, I think it puts light bulbs on.

Jeffrey Hammond: Yeah. I’ll give you a specific example there. In 2005, we did an analysis when I was at Rational and we discovered that we had about 42 people that had release engineer-type titles.

And I think from a salary perspective, we were spending about $6 million a year to build our products, and that seemed like really high to us, and we looked at, “Well, why is this the case?” And what we found was because the build for the roll-up products that we sold were constantly broken that all these different teams were going out in creating their own private build streams.

And then those private build streams, where all their integration happened, and where all the new features happened, and then they didn’t have to care about the master build being broken all the time, and as a result, the testing folks couldn’t get fresh builds to test all the time, so they were sitting on their hands.

And then when we went to integrate all those private builds, you would have just blow ups in functionality because they were all working with different versions of the code, and it was a nightmare. And instead of saying basically, we are going to evolve the culture such that, if the build is broken, everybody needs to feel that pain to isolating that pain, optimizing around the individual team, and in the process, costing the company a lot of money.

Needless to say, when we discovered that, we went forward and fixed it. But it’s an example of where these little things can spiral out of control if you’re not aware of them.

Richard Seroter: Absolutely.

Jeffrey Hammond: So that kind of leads to the fundamental way that you need to think about high-performance culture. It gets back to my concern about the term software factory. Because if you think about it from a developer’s perspective, how many developers do you think would really like working in a factory and essentially screwing bolts on nuts or doing the same thing all day long, and essentially turning their brain off and letting their hands do the work?

And yet, when we think of software as our factory type concept, or essentially defining it as an algorithmic process, and that’s not what I’ve seen. And this is one of the places, I think, we fell down a little bit when I was at Rational because we tried to over-rotate on the idea of software as an algorithmic, and I think some of the processes that are out there do the same thing. Let’s turn it into an algorithmic pursuit.

In fact, I would argue that software development is actually a heuristic process, that it is one that is defined by creativity. Whether or not you look at software development as algorithmic or heuristic very much defines as a manager how you create your culture, the tools that you pick, and the processes that you invest in to either support heuristic workers or to support algorithmic workers.

And to me, that’s one of the things that I think so many organizations get wrong. They look at software as too much of an algorithmic process.

Richard Seroter: Yeah. I’ve even heard people start to use the term “designing software” instead of developing software. ‘Cause even to that respect, you’re not even just…I mean it’s the design. It’s a creative aspect. Part of the balance teams you see when you work with Pivotal and Pivotal Labs is a product designer is a first party…a prime part of that team.

That’s super important to be thinking of user-centric design at all times, and developers are thinking about the user experience.

As you mention, that’s not the sort of algorithmic, rote, turn-your-brain-off activity. That’s extreme creatively, and this sort of iterative constant prioritization is a design aspect. I think that’s exciting, and it’s a big realization.

Jeffrey Hammond: I would say that, one of the concerns that I sometimes have about so many firms being focused on DevOps, and almost everybody is at this point in time, is that it becomes very easy to start to tilt that focus toward algorithmic as opposed to heuristic concepts.

To me, the best analogy that I can think of is the Broadway show. If you think about how a modern Broadway show is developed, like Spiderman, or any of the Disney shows, there is a mix of algorithmic staff and heuristic staff.

People aren’t gonna go and see Hamilton if you don’t have really good actors that are on stage. You have stand-ins that can go on. You’ve got specialized swings for dance numbers and that sort of thing, but you still have that stage crew making sure that the cues get hit or adapting the cues if the actors ad lib.

And you’ve got the orchestra that’s ready to go, and you’ve got all the lighting calls that are ready to hit. And to me, when you think about DevOps from an algorithmic perspective, it’s that stage crew that is supporting the heuristics and giving them the time to spend more time doing the things that they like.

If you think that software development is heuristic, the types of things as a manager that you have to invest in setting the stage for high performance are people, and people over tools, and Type I developers.

I’ll explain that concept of the Type I intrinsically motivated developer a little bit in a second. Measurement of the end results instead of the steps in the process. Rewarding or looking for folks that are capable of demonstrating cross-skill mastery, the double threat or triple threat if you will.

Focusing on processes that enable flow as opposed to rewarding specialization. Automation where it aids that creativity: the DevOps automation, the test automation, the test automation, the investment in containers to be able to allow developers to spend more time writing and designing the functions that they want to build.

Feedback becomes a very important part of the process if you are trying to build a heuristic team. And enabling failure, and investing in responsiveness so you can correct the errors that sometimes occur when you are moving faster.

I would say that in today’s software world, high-performance teams are teams that invest in supporting these sorts of heuristic types of capabilities.

Richard Seroter: I see your point. And I think, for especially this audience, as we think about modern app dev, it’s sometimes figuring out where that level is, and that there are things that should be just operationally available.

If a team’s deploying quote unquote “serverless functions,” or they’re deploying just app code, there’s some group that does want to take a very automation-centered approach to the platform underneath it that, you know what, managing VM is commodity.

Managing orchestration layers is commodity. I want to have my heuristic team focusing on the creative thing, and not back to your original point, building VMs and configuring patch cycles.

So there is that piece of it that’s extremely mechanical that needs people that can build automation, who understand that I have to hand deliver a data platform, ready to hand deliver an app platform that can handle containers and apps and functions and things like that so that heuristic team doesn’t have to deal with it.

But that function is still very very important, so I think as these companies evolve, you’re gonna see more of these platform ops teams to handle some of the algorithmic emphasis. Building great platforms, and any heuristic creative teams that are deploying to those fabrics without dealing with everything down to the metal.

Jeffrey Hammond: Absolutely. Now I think if you look at the research into development productivity, there’s support for the idea of heuristic orientation. If you look at the numerous productivity studies that have been done over the last 20 or 30 years, we do see variances in developer productivity in the real world.

I’m not gonna claim that, you know, I know we talk about the myth of the 10X developer, and I don’t think that they’re just people that are naturally born as 10X developers, but the way that I would interpret this is that there are situations where the developers are set free to maximize their creativity, maximize their flow.

They are put in environments where they can succeed, and as a result, they respond.

I have certainly seen the results of more productive developers in the real world, in my career. I think about the two most productive developers I ever worked with, and what they were able to accomplish versus an entire team of developers that was sent to rebuild the product that they built in the early 2000s.

That’s nagged at me for years, so it’s like well, you know, was it just that these developers were that much better than everybody else? And as I think about it, I think, where I’ve come down at is, no, they were definitely good, and they knew their craft, but they were surrounded with a culture that enabled them and that got out of their way as opposed to a culture that questioned every move that they were gonna make, or prescribed what they could do, or limited the experiments that they could run.

So I think that the 5X or 6X or 8X developer is out there in almost every developer that’s there, and very much their ability to reach their potential is constrained by the management and culture that is put around them.

The takeaway that I would have here is, if you see a wide variation in productivity, it tends to be characteristic of heuristic work as opposed to algorithmic work.

And Daniel Pink, when he wrote the book, Drive: The Surprising Truth About What Motivates Us, observed that. That you tend to see a 2X variation in algorithmic work where you see a much higher variation in creative work.

How do you set a culture that enables this?

I think the Netflix guys really crack the code on this. One of my favorite quotes come from Adrian Cockcroft. He gets this comment about the Netflix culture from a Fortune 1,000 CTO.

Netflix has a superstar development team and we don’t, and his response captures it so well. Netflix hired those developers from you and got out of their way. They put in place a solution for them to succeed, and I think this is why it’s so important to invest in that talent and culture aspect.

I know, again, it’s something that you’ve seen, Rich, with a lot of your clients in Pivotal. When you get out of their way, when you give them the ability to engage, when you give them the ability to succeed and create a supporting culture around them, you will see developers that you thought maybe were 1X or maybe 2X at best, that come alive.

They become 4 and 5 and 6X developers because of their ability to succeed and their ability to engage and make correct decisions.

Richard Seroter: No. That’s right. And you’re gonna cover this shortly, but I think most developers are doing it because they love the work. And many of them, of course, are doing it ‘cause it’s a good job, but a lot of us who write code…it’s a blast, but at some point, you get demotivated by the constant process.

Look, I want to be able to use cloud accounts to ship applications. I want to be able to use the latest frameworks. I want to use the best tools. Tech people cost a lot more than computers do now. That’s obviously flipped over from 40 years ago.

It’s about investing in these people and getting rid of roadblocks. We always see that. People who maybe had been average performers become superstars because, finally, you’ve unleashed them.

Jeffrey Hammond: Absolutely, absolutely.

Now why is that the case? There’s a piece of research that I did a couple years ago, and I think it’s still just as current today as it was back then. And it really looked at the idea of intrinsic motivation in terms of it being part of software development.

It made the case that we really see two types of developer behavior. I’m not gonna say there’s two types of developers because an individual developer can either be Type X or Type I depending on the company that they’re at, the culture that they’re in, and what they are asked to do.

A Type X development pro? They do development because it’s what they get paid very well to do. They work 9 to 5. They don’t necessarily invest in self-improvement, so they learned how to write Java, and they’ve got no interest in learning Go or JavaScript or mobile application development, or any of the new technologies that are coming out because they check out at the end of the day.

And they’re more interested in other things. The Type I developer, they are a developer. They don’t do development, they are a developer, and that’s a key difference.

They get involved in side projects, they learn on their own time, they are constantly operating in what we would call “a culture of mastery.” And they do development because they enjoy it. I think of a peer of mine at Forrester, a guy by name Mike Facemire, and the first question I asked him when we were looking to hire him was, “When was the last time you wrote code?”

And his answer was, “This morning is the right answer as far as I’m concerned.” Mike spent his vacation when he was in Santorini with his wife learning to Haskell.

That’s just one of the best examples of an intrinsically motivated developer. It’s the same reason a musician might pick up a different instrument and try to figure out how to play it. Or have to write even if they aren’t necessarily working on their next album. They’re on the road from concert to concert.

Now we see this division. High-performance teams tend to have high populations of Type I developers. Less productive teams tend to have lots of populations of Type X developers.

One of the favorite things I talk about is what’s your parking lot metric? What’s the amount of cars that are in the parking lot at 9 am and that are in the lot at 4 am?

Now in the modern world as we have more and more folks that are coming into downtown development shops, it’s probably more the desk metric that are there and early and late as opposed to checking out as soon as they can.

In a lot of organizations that have problems with development, have problems with innovation, they don’t have those high percentages of Type I development behavior.

Now, I want to be very clear that what we find in our research, when we do ask about intrinsic motivation, is that actually about seven out of 10…actually, it’s higher, four out of five developers show intrinsic behavior on their own.

Four out of five, in fact, have five projects. Projects that they’ve worked on, that they don’t get paid for that they’re doing on their own time for a variety of reasons ‘cause they want to automate their home or they want to learn that next best programming technology, or they’re building tools to make themselves more productive, or their friends more productive, or they’re contributing to open source software.

We find in fact that that amount of time that they spend on side projects is even higher in the Millennial generation. I’ve been writing a little bit about social development.

My takeaway from this is those intrinsically motivated developers are out there. They’re not hard to find. We beat that intrinsic motivation out of them in the organizations that we form because we make it hard for them to get involved. We make it hard for them to do the right thing, and we don’t trust them or hold them accountable for their actions with that high trust environment.

To me, this is almost the most counter-intuitive thing about the way that we manage software development teams. That we are disengaging our developers and we don’t even realize it.

Richard Seroter: Mm-hmm. Yeah, I’ve seen in real life plenty of innovation come from side work. It’s one of these things, if you look at your own organization today, how easy is it for your team to open source software that they’ve come up with?

How easy is it for them to go speak at a conference about what they’re doing at your place? So side projects have this way of bringing innovation they’ve done back into your organization ‘cause people are learning new languages, they’re learning new clouds.

It’s a recruiting tool. There’s all these benefits of empowering your team to be doing things at the office, and if they’d like to, outside the office. I guess how are you helping, to your social development point as well, how are you making development more of a choice of thing, not just a job, by making it easy to open source, consume it, or do it yourself, and be out there in the community, if you’re not fostering that you’re really starting to snuff the life out of your team.

Jeffrey Hammond: Absolutely, so what can you do if you are managing a team? The first thing that you need to do is you need to focus on creating a high-performance culture. And if you look at the research, if you’ve never read Drive, I suggest you go out and pick up a copy and read it ‘cause it applies really well to software development.

We find that high-performance teams, engaged teams, that are intrinsically motivated, are teams where there is a high level of autonomy. That folks are told what they need to accomplish, but not told how to accomplish it. There’s a culture of mastery. Folks are expected to keep their skills sharp. They’re given the time to learn on their own time.

They’re given the opportunity to bring in new open source projects that might solve the problem or propose new solutions that are gonna make it work. And then they’re also in an environment of shared purpose. They believe in the work they are doing, and there is a connection to the customer in terms of the value that they are creating.

Focus on doing all three of these things, an environment of autonomy, mastery, and a sense of shared purpose.

Richard Seroter: For managers, purpose is one of your most important responsibilities. The best teams I’ve worked on understood what they were doing and why. Who the customer was. How the customer was using your technology. As a manager, context is key ‘cause often the people who are building the software don’t always have it.

And if you’re a manager listening, my gosh, purpose, all of these, are super important, but purpose is one of those underrated ones that you can do tomorrow that doesn’t involve a culture change. Instead, it involves a new way of thinking, of not, “Hey, they only need to know what they need to know, they’ll crank out some code” to “Let’s try to put these things into purpose, put these into context, so you understand why their work matters.”

Jeffrey Hammond: Yeah absolutely, absolutely.

In terms of that piece of autonomy, I think one of the most important things, and this is something that the Netflix folks talk about all the time is providing context instead of control. So what does that mean?

Essentially providing the metrics that matter. What do the customers need? In Netflix’s case, it’s how many hours of online video are they watching on a month-to-month basis and how do we make that go up? Provide the assumptions that you’ve made, the objectives that you want to hit, clearly defined roles, knowledge of the stakes, and then transparency around how the decisions are made.

For those that focus on algorithmic management of software, you tend to see more top-down decision making. You tend to see lots of committees. You see stage gate-type processes. You see that the planning and the process and the rules are more valued than the results of what come out, and a real focus on the deliverables.

If you find that those are the things that matter in your shop, it’s a really good clue that you’re not in a world where autonomy is a highly valued commodity, and it’s gonna be really hard to drive a high-performance development culture as a result.

Now, there’s some other things that you can do. One of the things that we’ve seen in our research is organic processes that lead to this sort of agile-in-spirit mentality can be extremely useful.

We’ve got some examples here from the research to keep standups on track, the JIRA team has an iTunes playlist that they do as a queue for the standup. So everybody knows when it’s time to go do the standup because the music starts blaring. I like the Netflix vacation policy as an example.

There is no policy. Basically, you know, we trust you to do the right thing, and manage your time appropriately. A lot of companies have headphone policies. My favorite is the unwritten policy of both headphones are on, it’s leave me alone, I’m in the zone. I’m writing code and I don’t want to be disturbed. If I have one off, then you can disturb me. If I have both off, then I’m ready to collaborate or be social.

Context switching. The Atlassian guys had a role that they called “The Disturbed,” so every week, one of the team members takes on the role of The Disturbed and they have a little like Edvard Munch Scream-type doll, and everyone knows that that’s the person that you can bother if you have a question, and the other members of the team get left alone, and that role of The Disturbed rotates so that at least only one person’s flow is being sacrificed to meet the needs of the larger organization.

There are lots of these sorts of things that you can do to build up flow and to increase high performance.

Richard, I know there’s some things that you folks have seen at Pivotal as well.

Richard Seroter: Yeah, quickly. We see a lot of teams doing as many lunch and learns as they can so you don’t end up with a lot of lone geniuses who have some of the technology in their head. Instead, you figure out ways to share knowledge, share best practices, and having the teams organization these.

These aren’t organized top down. The team should be wanting to learn from each other. Sometimes process is in culture like the AllState team. When they incubated their new group over there, they all got matching t-shirts and decided that casual was the way they were gonna work. And even up to the executive staff. Even just these ways that the team starts to redefine their culture and say this is how we’re going to work, that’s empowering, and letting the team have some choice over that is huge.

Jeffrey Hammond: And it’s interesting because when you go to a measurement and recovery culture, you can kind of see whether or not that stuff works, and if it doesn’t work, well then maybe you have to do something else.

But you’re not afraid to try something and fail knowing that you can recover quickly, and I think that just becomes incredibly powerful not only for the software that is built, but for the team dynamics as well.

Richard Seroter: That’s right.

Jeffrey Hammond: I think it’s really also important, when you’re creating a high-performance culture to really carefully consider your measurements because you get what you measure and not always in the way that you expect.

This is one of my favorite cartoons from Dilbert. It’s gotta be almost 20 years old now. But you know, if we’re gonna measure the number of defects that we fix, then don’t be surprised if you see folks over-rotating on identifying as many defects as they can fix. Even ones that might not be reproduced in production.

It gets back to the if you’re measuring lines of code that are getting checked in, well, don’t be surprised if you get a line of code that gets checked in, and your builds are broken. I think in general measurements that reflect user value are the ones that you want to emphasize when it comes to high-performance teams. I mentioned that ratio of defects found in production to defects found before production, that’s a measure that ultimate software uses and goals that developers on to try to emphasize the importance of creating production-ready code. Another measure that I’ve seen which is used, it’s like that I mentioned in the Netflix thing: the number of hours of online video that customers are watching. It tends to focus the developers to think about what they are doing and the potential value that it creates.

Richard Seroter: Mm-hmm. I mean we’ve seen a lot of Pivotal customers, when they try to measure value over time, especially a platform, so they look at delivery speeds, cycle time, how many deploys per day, what kind of lead time from getting an idea to production, or stability. What is your service availability? I want to measure that. That’s a material thing, or scalability. How many requests per second can my API handle?

Or security? What is my percentage of unpatched environments. Things that are tangible, things that are driving the behavior I’m after like delivering faster and better, higher quality, all of these things matter together.

I don’t want to ship faster and then introduce more instability. There has to be some cross section there. But there’s to dev measuring to stack overflow ship some results today from their survey of 65,000 developers, and one question was what do developers think you should measure them on?

Like asking developers themselves. Customer satisfaction was number one, followed by on-time or in-budget, and then peer review, and at the bottom were things like hours worked, and lines of code.

So ask yourself, you know, these are what developers themselves want to be measured on if you’re measuring them by the opposite, you’re probably not motivating your team.

Jeffrey Hammond: Yeah, this is what blows my mind, Richard. You know, it’s pretty apparent that the devs get it. You know, that they want to create software that matters.

In a big way, that software, it’s the way that the customer engages that results and how much the software matters. When I think about the things that I’m proud of in the last 25 years is that software that I can see and I can touch, and it’s shrink-wrapped, and I talked to the customers who were able to use it and do really cool things with it.

That is just so affirming, and it’s another reason that developers should really be looked at as creatives because they want to build things that matter. And it’s a great opportunity to create shared purpose around that customer engagement.

There’s one more thing that I do want to talk about which is that you can do to support your high-performance teams, and that’s to create a physical space that supports their work. We see organizations doing lots of interesting things right now. They’re moving from the suburban campuses into rural campuses. They are into urban campuses downtown, near public transportation. They’re creating open spaces. These spaces have recovery zones. They create authentic working environments. They have very open central spaces. And they allow the teams to personalize and own those spaces to take autonomy over how they use them successfully.

I think that’s a critical part of creating your high-performance culture. Richard, I know it’s something that you guys take very seriously at Pivotal as well.

Richard Seroter: Yeah, we believe the workspace does a lot to motivate teams. And not everybody can drop their office park tomorrow and move to some downtown loft, which makes tons of sense. But I think it does make sense to look at…do cubicle farms actually facilitate communication? Should we have team rooms? If we have a lot of related product teams that work together. Do we want an open space because there’s a lot group who does work on a collective effort, but also understanding your team dynamics.

‘Cause for some, these sort of open spaces are extremely disruptive and unproductive, so not just following what the web start-up does, but looking at how your team works together and tries to organize yourself physically by that.

It’s gonna help you produce much better throughput than necessarily carving everyone off into individual offices.

Jeffrey Hammond: Yeah, this is where that kind of process thing kicks in because it’s like, well, if we do it for one team, we’ll do it for all the teams ‘cause it must be great, and that doesn’t always work. And it’s one of the reasons I’ll often recommend that you really try to do a classic flow analysis when you’re looking to enable your team to understand the things that will result in an increased flow.

This has been fun. I mean we could talk about this kind of stuff for hours, obviously, but the thing I would lead you with on your own quest for high performance is that processing tools need to support your people and your culture. Get away from that one-size-fits-all mentality because it just doesn’t work when you’re trying to enable creative developers.

That flow analysis I think is critical to driving your own increase and performance. Think about these Type I developers and rebuild your organization with them at the core of it. Make sure that you give them the autonomy that they need, like Netflix has done, but you demand mastery and accountability as a result.

And that you work to establish shared purpose as a manager of those teams. And then make sure that your metrics are based on business needs. If you can do nothing other than those things, you’re going to be able to see an increase in your flow and an increase in your productivity, and you’ll be well on your way to a better high-performance culture.

Richard Seroter: Low-performing teams that I’ve been on, or observed, kind of have stagnant skill sets, some lone geniuses, long time horizons to deliver something, lack of focus, limited passion, and they ship unreliable systems.

And so the high-performing teams I’ve worked on, they’re really accountable to each other within the team. They ship independently. They know their business impacts. They use the right software abstraction. They don’t just build platforms for the sake of it. They actively grow their skillset and they actually believe in continuous learning. That is not an unachievable objective. Those teams are all over the place. And it doesn’t even require you fire your whole team and hire a new one.

You have a lot of talent in your organization. Sometimes it’s about arranging them the right way and often bringing in the right technologies that cause seismic shifts.