Boyan Angelov’s journey as a technical and business leader has taken him across several domains (e-commerce, healthcare, HRTech, LegalTech). The latter part of his career has been spent as a data strategist in different managerial roles, but he takes advantage of his technical background in science and engineering to consult clients on all topics in data. He has overseen the development and deployment of end-to-end ML and data-intensive systems and products by leading teams of data scientists, engineers, and analysts. He has designed and delivered data strategies for organizations of all sizes and various industries. Boyan is also the author of O’Reilly’s Python and R for the Modern Data Scientist and Elements of Data Strategy.
In our last post, we discussed how systems thinking can help us tackle legacy systems and similar technical problems. Today, we’ll explore how systems thinking can help us improve engineering team culture.
When teams struggle to work together productively, it can be challenging to pinpoint the cause. Factors might include:
Technical and operational processes
Management practices
Communication
Personal circumstances
To make impactful changes to the system (team culture), we need to understand how these factors interact.
As with a legacy system, it can be tempting to make quick assessments and jump into action right away. However, issues with team culture are usually deeper than you think. If you rush to change a few internal processes, you’ll likely fail to address the full complexity of the problem.
To get started, we’ll apply a systems thinking framework in 3 steps.
I find it helpful to create a mental model of the team. Just as we captured a software system’s different components, we can visually represent our team members and how they interact.
Our first impression of the team can inform observations. However, we can gather more accurate data by asking directly: talk with your engineers about how the team works together.
This is where it’s important to build trust with your team. If you are transparent about your goals and methods, people are more likely to be candid about potential issues.
Once you have a mental model (visualized in a tool like Miro), you can make more informed hypotheses about changes that might impact team culture.
At this stage, you must make one change at a time. Otherwise, you won’t be able to tell which variables significantly affected the bottom line.
Let’s say your team is slow to complete workflows. Through your observations and mental modeling, you learn that team documentation is outdated and difficult to navigate. As a result, you might do the following:
Gather baseline data about how long it takes your team to complete certain workflows.
Update documentation for these workflows.
Monitor the system over time. Are there measurable changes in team productivity? If not, you can shift your focus to other potential variables.
My approaches to solving technical and people-focused problems are very similar. That said, you can quickly observe the impact of changes to technical systems. It takes much longer to see changes in people and culture.
Even if you’ve made the “right” changes, you likely won’t see the positive effects for weeks or months. It’s easy to become frustrated and assume your efforts have failed. However, this mentality can lead you to abandon experiments prematurely.
Managing complexity is one of the most important skills an EM can cultivate because it impacts every area of your team’s work. Whether navigating challenges with architecture, team dynamics, or business strategy, you need to balance sound judgment with swift decision-making.
The systems thinking framework we’ve discussed today can help you tackle complex problems more effectively. However, I think the biggest lesson here is one of humility.
When dealing with complexity in software and people, it’s important to set your ego aside, listen, and make careful decisions. You won’t transform systems overnight. But taking small steps in the right direction is success—and will help your team move faster in the long run.
Free Resources