The Systems within a Software Team

A brief insight into what is affecting your team’s results

I’ve been discussing how to apply Systems Thinking in engineering leadership and how understanding the systems and processes involving your team is the best way to get good results, both for the team and the people within it.

However, that is relatively abstract. In practice, what does it mean to think about the systems in a team? Where should you look, and what can you do about it?

I will address this by talking about systems in a software team. While teams vary, a few standard processes exist across most of them. Even if the examples described here don’t apply to your team, the thinking behind identifying and understanding them. Looking at some practical examples will make it easier to see.

Why should you care?

Because whether we understand them or not, systems always affect how we work, and software engineering is no exception.

Understanding and iterating on systems and processes is the easiest way to improve your team’s results, both from a productivity and an engineer’s satisfaction point of view. If 90% of a team’s performance is within the system, that’s where you can get the best result from your attention.

The 10000 feet point of view

From a high-level point of view, three main areas must work well for a team to succeed in the long run: Product, Engineering, and People.

From a product point of view, a team needs to produce something worthwhile. That is the primary purpose of its existence. From a technical standpoint, the team also needs to deliver work with enough quality to fit the product’s purpose. And from a people perspective, engineers working in a team need to be fulfilled with their roles.

If you are an engineering manager (EM), all these areas affect and are affected by how engineers in your team work together. Your role as an EM is then to understand them and act to create the best working environment possible.

Product — Creating something people want

It’s easy (and sometimes convenient) to look at product management as an area that EMs should not be interested in influencing. However, while Product Managers own the decision of what is getting developed, multiple processes within product management will significantly impact how engineers work.

How does work go from idea to production? The product discovery and planning cycle will define the work engineers will execute. For example, a system that doesn’t include an engineering perspective in its planning stages might result in unnecessarily complex work for engineering during execution.

How are requirements and tasks defined? One of the bits of advice I give to EMs is that the format of tasks is one of the most important things to pay attention to. Requirements are the input to 100% of work that engineers do, and ineffective requirements can lead to scope creep, lack of work clarity, lack of collaboration, and many other issues affecting engineering teams.

How is success defined? From a product perspective, how is a project evaluated to be considered successful in your environment? That will ultimately determine where the engineering team might feel pressure. For example, if strict deadlines are a part of your routine, it will significantly affect your way of working compared to companies that worry less about time and more about quality.

Engineering — Delivering software

We can find many processes affecting your team results and your engineers’ experience within your team when we look at how a team does engineering work. Here are some common examples.

How are iterations managed? How your team plans and manages sprints and iterations will define how engineers work daily.

How does a task go from creation to delivery? Who needs to work on it, and how do these people collaborate? How is work tested for quality? What is the definition of done? These questions and others are part of understanding how your team works. And that is key to its results.

How are your projects and work organized? Does your team run projects or evergreen initiatives? Who plans for them, and how are they led? As discussed in the past, project leadership will impact the experience of everyone working within it.

People — Making engineers fulfilled

Lastly, the processes around the people in your team are essential to how the team works. That will define the team’s member experience and how your team delivers work for the company.

What are the feedback loops for engineers? How do engineers get feedback on their work? That applies to technical feedback (PR reviews, design docs) and general feedback (is it given often or not?). It is impossible to understand performance unless you understand the feedback loops.

How does an engineer learn on the job? How your team and company collaborate and provide learning opportunities will affect individual growth and team performance. While this has always been important, it is even more essential in today’s remote work setting.

How does career growth work in your company? What are engineers evaluated on and promoted for? How is the career ladder defined? Tell me how you measure me, and I’ll tell you how I behave. Everyone is working towards growth, and understanding how they achieve it in practice will help you know how your team’s engineers behave.

It’s all a big overlap, but still very useful

As you can see, most of these processes overlap with each other. How your company rewards an engineer will influence how they work in the team. How the team works together will affect how much they learn and are rewarded.

This complexity is typical in any actual situation. Thinking in systems doesn’t mean dissecting a complex environment down to basic rules. But instead, it means understanding the main feedback loops in an environment and how they affect each other.

And that is very useful. Whenever you have an area of improvement, the best path forward is to understand how that works from the subject’s perspective. For example, to analyze how people grow within the company, look at the process to obtain learning/growth opportunities from the engineer’s perspective. To improve how a team works, it is essential to understand how a task moves from requirements to done from that task’s perspective: who has to contribute to it? Where does it get blocked?

As an EM and team leader, you should routinely observe and understand the main processes within your teams. That will highlight the opportunities you have for improvement. And when improvement is needed, analyzing the process you are focusing on and its adjacent systems will highlight the best levers you can pull. It will also show a way to measure the results and codify your changes.

If you have found this content interesting, this post is part of a series on Leading Software Teams with Systems Thinking. More broadly, I write about leading effective software engineering teams. Follow me if you are interested in the area.