Platform Teams: Adopt These 7 Developer Productivity Drivers
Are you looking to make your developers unproductive and unhappy? Who isn’t, right?
The fact is, happier developers are more productive. The New Stack sat down with LinkedIn’s Max Kanat-Alexander to discuss the common anti-patterns that continue to negatively influence developer productivity and joy. We offer seven developer productivity drivers your platform engineering team absolutely needs to consider.
Life-Long Observation of Developer Productivity
Kanat-Alexander is a principal software engineer at LinkedIn and author of developer productivity books “Code Simplicity” and “Understanding Software: The Fundamentals of Software,” The latter reflects on his own experience and observations around software design principles and developer productivity improvements in organizations. He’s also worked as the chief architect of the popular open source bug-tracking project Bugzilla, as well as a consultant, working with a lot of software development processes. Prior to joining LinkedIn, he was the tech lead of Code Health at Google, helping to shape engineer practices around code review and testing.
He takes the perspective that “It’s not just you, an individual, sitting alone writing code, so what are the things that you might need to know as you go into a larger sphere?” He’s the tech lead for the Knowledge Systems team, which builds metrics and feedback systems to understand how they can improve developer productivity and happiness across LinkedIn.
And as we’ve learned through our study of platform engineering, knowledge proliferation, documentation and discovery is half the battle toward increasing developer productivity.
What Kanat-Alexander has uncovered is that, despite platform teams truly caring about getting it right, “There are definitely things that are frequently done wrong and could be done better.”
Now we will reflect on what most often goes wrong and teach you how to foster developer joy.
Developer Productivity Driver #1: Listen to Your Developers.
As the discipline of platform engineering becomes commonplace, one of the main challenges isn’t technical — it’s getting your internal developer customers to trust in and adopt your platform and leveraging the golden pathways it creates.
“A situation that many developer productivity engineering teams find themselves in is that they feel like they’re doing their best and they’re delivering work, and everybody’s unhappy with them,” Kanat-Alexander said, which in turn makes executive teams reluctant to fund developer productivity teams in these tighter times. One of the problems is that a platform engineer is a developer, “and you know what all developers need and want. You know exactly how all people work, because they all work the same way. They all work just like you. And as a result, as long as you fix your own pain points, everybody else will be happy.”
He is, of course, fluent in sarcasm and recognizes that not all software development teams are the same, even within the same company. A successful platform engineering and developer productivity strategy relies on continuous developer feedback and treating your platform as a product.
Start with a developer survey. In a smaller org, he says, do one-to-one interviews. LinkedIn, Google and Spotify each perform extensive quarterly developer surveys.
“Doing a good survey is really hard,” Kanat-Alexander admitted, but “any survey is better than no survey, even if you just sent out one thing that was like ‘Hey, rate your development experience.’ And then here’s a free text box ‘Complain to me about whatever is the most top-of-mind thing that you think is blocking your productivity the most’.”
Any surveying action will help you develop a closer relationship with your internal developer customers.
Developer Productivity Driver #2: Know Your Different Developer Personas.
Your organization likely has several different developer groupings waiting to be listened to, from Java backend developers and Python developers, to frontend web, iOS and Android developers to site reliability engineers. If you focus on only making one of these groups of developers happier, you will likely make the others unhappier.
“The reality is, different types of developers have different workflows, and, until you actually learn to understand the needs of those developers as separate needs and serve them separately, you can still generate a lot of animosity, and fail to do a great job of serving your developers,” Kanat-Alexander said.
“The thing that needs to happen is that priorities and requirements need to be looked at, based on types of workflows. And not just [the] number of developers affected.” He explained that the mobile team is often much smaller than the server team. At first, it may make sense to focus on increasing the productivity of the highest number of developers, but the whole point of platform engineering is to deliver value to end users faster — the mobile team is most likely to impact that.
“The business impact of improving the lives of those mobile developers can actually be higher than the business impact of improving the development experience with the backend or web developers,” Kanat-Alexander said. Although that depends on the pain points and blockages of your individual org right now. For example, if the mobile app developers cannot ship out API changes in the backend, then backend developer productivity is what’s blocking the mobile devs.
The platform team has to prioritize between the different types of developers dependent on the breadth of your tools. And if a certain team has a unique workflow, he says, it can totally make sense to follow the DevOps way of that app team owning the parts of its toolchain that are unique to the team.
Developer Productivity Driver #3: Consider Your Platform Team Setup.
Conway’s Law — where systems mirror communication structure — reigns supreme in your platform engineering strategy, too.
If your platform team — and the engineering department it serves — is large enough, you could separate that team by roles that serve different personas or at least have platform evangelists who advocate on behalf of each group. On the other hand, Kanat-Alexander said, you may benefit from having a very united platform team that has very deep experience and expertise.
This is one of the causes of, according to Puppet’s 2023 State of DevOps Report, the average company having three to six platforms — one size rarely fits all.
Splitting off your platform team’s focus, he said, “could be good because you’re creating a focused product that helps those individuals,” focused on their purpose and offering a potentially exceptional developer experience.
But “it could be bad if you are failing to leverage commonalities, and thus people are doing a lot of duplicate work. Or if you’re creating a fractured workflow, when you have multiple platforms what happens is they don’t mesh together,” leaving developers to request almost identical permissions from different teams, slowing things down by adding a human in the loop, or unnecessary hurdles to data streams, or leaving them to try “to figure out how to get their CI [continuous integration tool] to interoperate with this other deployment system over here because now they own two different artifacts and they need to coordinate them somehow.”
Developer Productivity Driver #4: Don’t Make Them Ask for It.
“Another great way to make developers unproductive and unhappy is, every time they want to do everything, make sure they have to ask another human being for permission before they do it,” Kanat-Alexander said. That person may take a couple of days to respond. To make matters worse (slower), you may add forms and different teams having to talk to each other. A one-day task can turn into two months.
Developer frustration was one of the causes of 2022’s quiet quitting trend, which found workers putting in the bare minimum. Indeed improved developer experience can prevent burnout which was a main trigger of the Great Resignation. In addition, studies found that organizations with a longer change time to lead, saw an uptick in resignations.
Chronic issues are repetitive and/or long-lasting issues. These problems tend to be very difficult to solve, explained Lesley Cordero at DevOpsDays London. “This is why they become chronic in the first place, but these are important to solve because chronic issues are actually indicators of bigger issues in the organization.”
Unnecessary hurdles and permissions foster a culture of what Cordero calls acquired hopelessness. “These situations make people lose trust in your team’s ability to stay true to your values.” Senselessly adding friction to the developer experience further harms motivation and increases turnover.
But, most manual processes are a reaction to risk, Kanat-Alexander said. Though not all human processes are bad. He gave the example of a code review as a gauge of the simplicity, understandability, and future maintainability of the code.
“On the other hand, a process that’s like: Am I allowed to call this particularly dangerous API? should not require a human being because a computer should be able to answer that question for you, through static analysis,” he said. “Or, at the very least, static analysis should be able to say no to almost all of the cases, and then have a detailed explanation and an understanding of what the specific time is that you would need to request an exception,” as dictated by an established and codified exemption policy. There still might be a need for a human stopgap, but that should be the anomaly.
Anything that extends delivery timelines can destroy motivation and the desire to innovate and experiment.
Developer Productivity Driver #5: Don’t Neglect the Innovators.
Now, this author has previously argued to keep the platform team away from the innovation sandbox, and that the platform should serve the 99% developers so as to not stifle or restrict the 1% of innovators. But, it turns out, that not having the golden paths may actually stall the speed to innovation.
“When you have a platform, you need to think about both the person who is a dedicated, committed, long-term owner of a thing and the person who just wants to dabble around for today or tomorrow,” Kanat-Alexander said. “Often, platform teams forget about that second use case. And they think that it’s fine if somebody has to spend a month learning how to do this particular task because once they do it, it will probably be their job for the next three years. And that’s not so great.”
Imagine, he said, a senior tech lead who only has a few hours a day to write code, but then has to tackle permission hurdles and wait times, every single time they want to get things done.
And it’s very hard to predict when someone will want to try something new. He calls this the innovation versus committed development problem. If it takes weeks to set up a repository and get machines in production, these human-made hurdles that are there to stave off risk, actually stagnate innovation.
Instead, make it easy to do trivial things, like setting up machines within a special secure zone, with default access and no personally identifiable user information. A platform team, Kanat-Alexander argues, should set up automated mechanisms and default templates within their frameworks so app teams can just get infrastructure — because most of the time that isn’t what they are trying to innovate.
Developer Productivity Driver #6: Sometimes, Just Say No.
You can’t handle every use case, but, eventually, you can handle about 80% of them, Kanat-Alexander said. “You want them to have an experience where most of the technical decisions have been made for them — all the decisions that don’t have to do with the business logic that they’re trying to implement.”
You’ve got to be able to say no.
“Those paved road owners have to be able to say no to developers. If they can’t say no, then they become a sprawling one-size-fits-all…monstrosity that serves every need, but none of them well.”
But, by layering the platform in what he calls “platform primitives” — where some can access the internal developer environment, CI system or build system — you can point the team requesting that edge use case to the platform components, so they can build it themselves.
This could be like Airflow or Terraform, languages which he says you wouldn’t typically want to expose the average development team to, so you’ll keep them tucked behind a user interface. But, when the UI can’t handle that edge case, you can give that team access to write their own.
The wrong solution, Kanat-Alexander said, is to always say yes to edge cases, but, sometimes, “If these niche use cases are genuinely important enough for the business, the business [should be] willing to invest in specialized people on that team or in that area to engage in this very niche but important infrastructure work.”
Warning: If you don’t help out these edge cases at all, your engineers will go off and engineer their own solution, which contributes to ops sprawl that takes them off the golden path.
Developer Productivity Driver #7: Don’t Half-Ass Your Platform.
Platform engineering teams typically get an abundance of requests. It can be tempting to place bandaids or just get proof of concept out there. But a platform-as-product-mindset means you finish what you start and work to deliver a polished product your users actually want to use.
Platform success relies on continuous improvement based on user feedback. We already mentioned the need to survey your developer customers ahead to prioritize your platform backlog. Those surveys must continue to check that you’re satisfying their needs. Factor both platform metrics and inevitable follow-up requests into your platform strategy.
Never forget that one of the aims of platform engineering is to enable self-service. This means your definition of Done relies on it being documented, in hopefully a highly searchable and self-service way. Done also means monitoring and alerting throughout, with post-mortems when incidents inevitably occur.
To achieve all this, on top of building new platform features, you need to be able to speak to business stakeholders too. “It’s quite a skill to be able to express upwardly to management why doing great engineering work is important,” Kanat-Alexander said. You may have to negotiate not only building the shiny new stuff, but protecting your time completing the older stuff. “Finished is — to a greater or lesser degree — no human being will have to pay attention to this thing anymore,” which is impossible to accomplish completely, as teams, demands, tooling, and environments are in constant flux. However, in a practical sense, you can achieve it for most projects; where you can get the required human attention down to a low level, by taking the time to polish off the rough edges of the platform or tool.
A platform takes ongoing dedication to quality — your colleague-customers deserve it. And they won’t use it if you don’t work to offer a complete developer experience.
A platform team can get in the habit of saying, “‘I guess it’s okay for us to not finish this thing because it’s just one thing and how important could it be?’” But, Kanat-Alexander continued that “Software is a giant, durable object that is usually contributed to by a large collaboration of people. And if there’s no oversight of how many of those things are being left unfinished, then eventually you can get yourself into quite a pickle.”
