Driving development team success

Simon Maple at Snyk explains that for developers understanding and solving problems, and meeting high-level goals has greater strategic value than churning out hundreds of lines of code

 

The success of businesses today is as rooted in the success of development teams as it is in the performance of any other business unit. As Microsoft’s Satya Nadella said back in 2015, nowadays “All companies are software companies.”

 

Thus, understanding and implementing best practice for ensuring that teams flourish and operate highly effectively becomes a business imperative. 

 

The key factor

A key finding in the pioneering research work from DORA (DevOps Research and Assessment) was that the top performing development teams at the most successful companies have a key factor in common. This wasn’t the number of PhDs, staffing levels, perks or remuneration. What they found was that the most successful development teams have considerable independence and freedom in how they work.

 

This autonomy isn’t absolute. We’re not talking about developers turning up whenever they please, or each individual following a different path, working on whatever they like, whenever they feel like it. 

 

Rather, successful teams are able to approach challenges and problems in their own ways and self-organize to produce the best outcomes. Developers do not need to be micromanaged and will not flourish when other people are looking over their shoulders. Independence and high levels of trust objectively leads to better results, the research shows.

 

In this context, it becomes management’s job to establish the goals, principles and guard rails that allow developers to understand what they need to achieve, what their priorities ought to be and the limits to what they should be doing.

 

It’s hard for organizations to arrive at the perfect balance between direction and autonomy, and there needs to be a willingness to change: There’s a cycle at play between centralization and decentralization. Between ivory tower decision-making and pushing that decision-making down to teams.

 

Establishing, communicating and assessing progress against these goals and principles is difficult. But there are certainly some best practices that may add value to organizations.

 

Know your limits

To cover the guard rails first, helping developers understand the boundaries of their freedom is important. These are very clever and creative people, and their skill set means that very often, they can envisage how an application might be better, or deliver more functionality for its users.

 

Frequently, these ideas are exactly what the company wants. But changes need to be assessed against product principles and longer term impacts. 

 

Developer experiments and changes might be described as being ‘one-way’ or ‘two-way’ doors. Some changes can be tried, assessed and easily rolled back if they have undesirable consequences. These are the kinds of experiments developers should be actively encouraged to pursue.

 

Other changes, ‘one-way doors’, are much more difficult to revise - especially if you offer new features or functionality to users, for example. Killing such features can be very unpopular, and pursuing such changes needs to be carefully assessed.

 

Stick to your principles

This is what makes goals and principles very valuable. Slack, for example, has had a ‘master plan’ comprising four key tenets that have remained unchanged since 2014. The first of these is ‘don’t make me think’. If a feature or a function isn’t obvious or self-explanatory, or makes users feel stupid because they can’t quickly work out how to use it, then it doesn’t belong in the software.

 

Master product principles thus become a very simple and clear yardstick for assessing any proposed change.

 

Product strategy and principles need to be continually and consistently articulated because they need to constantly guide independent decision-making. There’s no such thing as overly repeating these principles publicly. You might think you’ve already repeated the strategy ten times, but it turns out you haven’t said it enough or it hasn’t been said correctly. It will almost always be possible to find people who say they don’t understand the company’s strategy. 

 

And many technology companies are growing very swiftly: if the strategy is only articulated once a year, then half the company might not have ever heard it before a few months are over. Indoctrination in the strategy and product principles needs to be built into the onboarding process.

 

It’s also important to ensure that active listening techniques are employed. People take surprisingly little from listening passively to a presentation. But if they are charged with explaining the material in their own words, then they are actively processing and thus retaining the information.

 

The language of these principles needs to be plain, unambiguous and easily committed to memory. ‘Don’t make me think’ is one example. Because it’s so simple, it’s also memorable.

 

At Amazon, when it was led by Jeff Bezos, there was an intense focus on ‘time to glass’. They didn’t say ‘reducing latency’ - which would have put the focus on technology. Rather, ‘time to glass’ focuses on the end goal, an improved user experience.

 

It’s also important to build these goals and principles into team and individual OKRs (Objectives and Key Results). This reinforces the power of those principles, that they’re not just nice to have, or something extra, but genuinely the priority for management. If OKRs default to less strategic measures, like the number of tickets closed or code commits, then it undermines the strategy and reduces the ability of developers to behave autonomously. 

 

Autonomy should also extend to tooling choices. Typically, developers will adopt the tools that allow them to be more productive, make it easier to work and allow for reliable automation.

 

These are all desirable things for the company at large, and may mean different individuals use different tools to some extent. So long as this doesn’t block other team members from effective collaboration, supporting individual preferences will be a boost to productivity and work happiness.

 

Security and freedom

Extending these ideas to security practice has some small complications. Good security is, in some ways, invisible. The code has been checked for potential areas of weakness; components have been carefully scanned for vulnerabilities, cloud and container configuration follows best practice - and nothing happens.

 

Application security is in the unfortunate position of often only being noticed when something goes wrong. 

 

In this case, it becomes important to recognise the hard work that goes into making sure the application is secure. That the timing and thoroughness of checks and eliminating issues are fully recognised: that the absence of flaws is as important as the addition of features.

 

This is different to a lot of work in that it adds nothing visibly new, and the positive benefits of secure code are difficult to assess. It’s best to shine a light on best practices here: acknowledge the work done and assess its value to the business in terms of the losses that would accrue were security to be compromised.

 

This is already common practice in understanding the ROI of cyber-security, and ought to be extended to the recognition and prioritization of the work incurred.

 

Code development has sometimes been treated as akin to an act of physical production. People have been assessed on the volume of code they produce, as though making an application were similar to assembling components on a production line. 

 

Nowadays, we recognise that creativity and imagination are key aspects of the craft; and that understanding and solving problems, and meeting high-level goals has greater strategic value than churning out hundreds of lines of code.

 

The role of management is thus in helping developers to do their best, most creative and imaginative work, aligned to the broadest goals for the application. Defining and communicating strategic objectives, expectations, limitations and principles becomes the most important task for management.

 

---

 

Simon Maple is Field CTO at Snyk

 

Main image courtesy of iStockPhoto.com