Virtual Panel - Culture, Code, and Platform: Building High-Performing Teams

Introduction

While 'culture' is often dismissed as a soft skill, high-performing organizations know it is the primary driver of productivity and stability. In this virtual panel, we’ll discuss how culture plays a key role in software development. It can make or break teams. A strong culture supports innovation and helps to get the best out of software professionals.

There are many things that can be done to establish and support a high-performing software development culture. In this virtual panel, we'll focus on performance improvement through platform engineering and fostering developer experience, to increase productivity, quality, developer well-being, and more. We'll also explore the role that tech leadership can play in culture change and performance improvement for software development organizations.

The panelists:

• Patrick Kua - CTO Coach and Trainer @Tech Lead Academy
• Abby Bangser - Founding Principal Engineer @Syntasso
• Sarah Wells - Consultant and Author @Sarah Wells Consulting Ltd

InfoQ: What role does culture play when it comes to high-performing software teams?

Patrick Kua: Before we talk about what role culture plays, I want to clarify what I mean by culture given it's a very overloaded term. For me, culture is the set of accepted norms about which behaviours an organisation encourages (or discourages). While words might define an organisation's culture, ultimately it's the processes and rewards, punishments and tolerated behaviours that define culture. 

Having said that, I've experienced that certain aspects can either help or hinder high-performing software teams. For example, company cultures that encourage teams to be as close to the customer can help teams perform. Amazon's customer obsession is a good example because teams can see the impact of their work. They're not just executing a task, but can come up with alternative ways to solve a customer problem if they're allowed better access to understanding customers.

Another important aspect of high-performing software teams is whether or not an organisation accepts mistakes. The DORA report/Accelerate book talked about generative culture, and one aspect is whether or not a company looks to blame someone so they get fired/replaced, or whether or not the company encourages people to learn from their mistakes. Accepting that mistakes can happen is an important part of high-performing software teams, but only if they can learn and improve their processes.

Abby Bangser: I subscribe to the idea that a high-performing team is one that can perform better than the sum of its individual parts. Just as Charity Majors says in high performing teams: "A truly great engineering organization is one where perfectly normal, workaday software engineers, with decent software engineering skills and an ordinary amount of expertise, can consistently move fast, ship code, respond to users, understand the systems they’ve built, and move the business forward a little bit more, day by day, week by week". Culture is what ingrains this shared belief and constantly improves the system to enable this flow of value.

A few years ago, I had the special opportunity to join a team from day zero. There is so much to manage when forming and norming from scratch, so as a team, we decided to tackle that head-on by mob programming for 2 weeks while building out a virtual development environment. This high-touch experience was extremely tiring, but also continues to shape how we all think about teams. We gained a shared understanding and investment not only in how we test our code, the value of shared environments, but also how we discuss and disagree on things and so much more. This became the socio-technical base on which our team built a high-trust environment where everyone stretched well beyond their previous experiences to deliver great outcomes.

Sarah Wells: The highest functioning teams I've worked on have been teams where there was a high degree of openness, an interest in learning and sharing, and an ability to respond quickly when things change. Above all, those teams worked independently and made their own decisions. 

That is only possible within organisations with a specific type of culture. The sociologist Ron Westrum calls it a generative culture, and it's about trust, a lack of blaming, and valuing of learning and experimentation. This was the type of culture we had at the Financial Times and part of the reasons we were able to successfully make some big changes in the way our engineering organisation worked.

InfoQ: How can platform engineering support engineers in their daily work?

Patrick Kua: Great platform engineering teams look at engineers as their customers. Similar to how engineers should have a deep customer focus and understand their jobs to be done and pain points, great platform engineering teams should engage with engineers to understand the friction they face and how they can help smooth it. 

One good indicator is where engineers are spending their time. If they're spending a significant amount of time on infrastructure, plumbing, or repetitive work, that's less time they can spend on customer-related topics and on adding value. Great platform engineering teams increase the % of time engineers can spend on truly value-added work.

Abby Bangser: Software demands many tools be used to turn engineering work into usable products. Everything from servers to run on through to other software that can test and observe the final product. There is always a gap between what a software engineer can buy off-the-shelf and what they need for their specific case in their specific organisation. Sometimes that gap is just some simple configuration; other times it is a large-scale investment.

Platform engineering supports software engineers by identifying where they can reduce the duplication of effort in lifting from the market offering to the specifically needed tool. Identifying these opportunities is product discovery, and then the impact on daily work is the measure of the product value. The goal, of course, being that the platform products create a high-value economy of scale within an organisation. Reducing the overall cost for solving a problem by providing a centralised service that can be shared across teams.

Sarah Wells: You don't want every engineering team to have to solve the same problems, particularly when those problems aren't critical to the business. That means having platform teams, who should apply software skills and product thinking to infrastructure and operational challenges.

The best platform teams work closely with engineering teams, focusing on removing things that slow teams down. They build just what's needed, and iterate, rather than going away for 6 months to build a complete "solution", because that lets them learn and correct course.

InfoQ: What leadership practices do you use to bring out the best in tech people?

Patrick Kua: This could be a whole article on its own. But to give this a short response: great leaders think about how they can multiply the effectiveness of individuals. Instead of managing people, leaders should focus on managing a system and improving it so that individuals can do their best work. 

Often, this is about setting a clear context for what is most important to the business/customers now (e.g., priorities). Other times, it's about learning how to delegate work effectively so that people can learn and grow by taking on more responsibility, but balanced out with the support to ensure they succeed, or when they make mistakes, those mistakes are not catastrophic and can be used to fuel learning and growth.

Sarah Wells: I've found engineering teams care about fairness and consistency, but things change all the time in an organisation, and there are almost always edge cases.

I try to focus first on clarity. What is the strategy, what are we planning to do, and why. Some people won't care; they just want to solve the problem in front of them. But others like to see the bigger picture, and very often, those people give me important feedback, changing my mind and helping me come up with a better approach.

What I also try to do is to communicate a lot. You have to repeat the message in different ways (slack, email, posters, meetings) until you are fed up with doing that, and some people still won't have registered it! But too many people in tech spend months preparing a strategy or building a tool and then send one email and consider it "done". That's just a waste of your efforts. Being a leader is also about sales and marketing!

InfoQ: How can giving proper attention to developer experience increase productivity and quality?

Patrick Kua: I just explained how paying proper attention to developer experience can increase engineering team productivity by allowing them to spend more time on customer-facing work. But platform engineering teams often have much more value and experience dealing with common infrastructure problems that, when done well, can solve this issue at scale for the organisation. For example, instead of each team developing its own way to deploy and monitor services, teams can benefit from a standard mechanism. When that mechanism improves, all teams benefit immediately.

Abby Bangser: Before saying why investment in DevEx can increase productivity and quality, we must revisit how Daniel Pink popularised that autonomy, mastery, and purpose are the keys to job satisfaction, not parties and perks. This also affects where and how we need to invest in DevEx today.

The impact of a great experience becomes so much more apparent when you are working for a mission you believe in. When I was on a team building tools to support job seekers, what I found so interesting was that no one complained about team off-sites or fun items around the office. The big thing everyone was frustrated by was the lack of access to user feedback and the slow deploys due to heavy approval processes. When these were improved through policy changes, the team noticeably improved not only their quality of work but also their energy for that work.

Creating an environment that encourages deep thinking, fast feedback loops, and low-friction experimentation enables engineers to focus on high-value work, learn more about the domain they are working in, and, in turn, produce better experiences for their users.

Sarah Wells: When you are building things for other developers, you are, as I learned from Kathy Korevec, "a chef cooking for other chefs". That means you need to pay attention to the experience of using your tools, because "Developers can spot inconsistencies, antipatterns, and hurdles a mile away". On the other hand, they can be great partners, provided you listen to their feedback. 

Good platform engineering tools are ones that solve real problems, felt by the majority of your engineers, and that guide those engineers to build things the right way, by incorporating your principles and guardrails. Consistency, higher quality, and a greater flow of business value are the rewards. 

InfoQ: Which benefits have you seen from platform engineering, developer experience, and tech leadership?

Patrick Kua: The right level of investment in each of these areas is really about helping teams achieve greater outcomes. For some teams, it might mean that teams can achieve more output. For other teams, it could mean they can focus on reliably delivering better quality outcomes.

Sarah Wells: If you have a platform engineering team that focuses on developer experience and sees their role as finding ways to enable other teams to deliver business value, you think you may be focussed on speeding up engineering teams. But you might also be reducing risk and costs, through standardisation, and by bringing your expertise to bear on a particular problem. 

Effective tech leadership is a separate consideration for me. You need it in both product engineering and platform engineering teams. 

Good leaders provide a clear sense of direction for a team, and if you do that right, you'll find the team can make decisions without you. When I was at the Financial Times, I was away during the week our annual OKRs were being planned (they moved the dates!). My team didn't take me up on the offer of answering any questions, they planned out all the OKRs. When I came back, I felt a mix of pride and alarm at whether they needed me anymore - but the OKRs addressed all our strategic goals.

Conclusions

Culture shapes high-performing software teams through the everyday behaviors that you encourage or tolerate, not the stated values. Foster a culture that emphasizes customer closeness, trust, and learning, where mistakes are treated as opportunities to improve.

Use platform engineering to boost team effectiveness by reducing friction in daily work. By standardizing and centralizing infrastructure and tools, platform teams can free engineers from repetitive tasks and help them focus on delivering customer value, especially when they work iteratively and closely with product teams.

Strengthen developer experience and leadership to enable fast feedback, experimentation, and consistency. To be an effective leader, you can provide clarity, communicate often, and improve systems so teams can deliver higher-quality outcomes with greater speed and confidence.