バーチャルパネル - 文化、コード、プラットフォーム：高性能チームの構築

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

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

Feb 24, 2026 10 min read

Write for InfoQ

Listen to this article - 0:00 Audio ready to play Your browser does not support the audio element. 0:00 0:00 Normal1.25x1.5x Like Reading list

High-performing software teams thrive in a generative culture where trust, learning, customer closeness, and non-blaming responses to failures, enable autonomy and continuous improvement.

Platform engineering is more effective when it treats engineers as customers and removes repetitive, non-differentiating work so teams can focus on delivering business value.

Good tech leaders amplify performance by improving systems, providing clear context and priorities, and supporting growth through effective communication, delegation, and learning.

By improving developer experience with standardized platforms, fast feedback, and environments that foster autonomy and mastery, organizations boost motivation, reduce friction, and enable teams to deliver higher-quality outcomes more efficiently at scale.

When platform engineering, developer experience, and leadership are aligned, teams deliver faster, higher-quality outcomes with reduced risk and greater independence.

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.

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