Notifications
Article
The Ocean We Swim In
Updated 6 months ago
145
0
Improve team process and culture with a systems approach.

What is a Systems Approach?

I have seen companies get into a loop of reacting to issues, patching the symptom instead of fixing the underlying issue. Instead of looking at issues in isolation, a systems approach means to look at teams, design, development and so on as internally complex and overlapping systems. For example, adding a code review process may reduce bugs for development, but that may increase iteration time which negatively affects design, which could reduce team morale since everyone feels they are walking in molasses.
In other words, we look at issues as a multi-variate or design problems. It is hard to see exactly what is causing what, and unintended side effects are common. I have found encouraging an open atmosphere on teams leads to discussion, which can lead to a willingness to try new ideas which allows for creative solutions to iterated and accepted.

The Ocean We Swim In

The structure of a team is like the ocean a fish swims in, it is easy to be blind to it since we are so used to seeing it. It is the everyday process we live in, such as how work is assigned or how the areas we work in are split up. It’s proper setup and functioning is an integral part of a team’s success; it is the ocean that team members swim in.
Structural or cultural issues on a team can often be solved by modifying it's classification structure. This means the categories that team members use affect how work is perceived, which can affect behaviour and attitude. Often this indirect approach of modifying the environment is more effective than directly telling a team member to do something.
You may wonder, what is the point of this?

Create structure

When creating an app, it can be useful to articulate categories that are not used (so the team thinks about them) or further differentiate a category already in use.
We are developing an app to teach kids physics. We know there are six types of simple machines, with specific things we need to demonstrate for each. We need to find a way to design an app that teaches all of these concepts. First we split the app into one scene per simple machine, to allow each team member to own one or two scenes. Then we split development into three phases: design, build and polish. These are the underlying structural reasons why this approach was successful.
Simple Machines - Tinybop

Split a Large Category into Smaller Pieces

A large undifferientated category can often be split into more specific categories, with a goal in mind. For example, general app development could be split into a design phase and a build phase. This would avoid the common pitfall of creating too much of the app and assets before the design has gelled, which often results in work having to be thrown away.
Another category is code, which is sometimes split into Scripting and Core code. Scripting code is fast and dirty, and good for creatively iterating content. Core code is slow to write, but provides shared structure and can be reused between apps.
Another category is areas of responsibility, which can be split up into areas based on functionality or levels. This allows team members to own specific areas, which ties in with ‘Let them make the plan’. It also reduces risk, since the areas are compartmentalized a single failure will not damage the whole system, if a single area fails it can be easily removed and rewritten.

Merge Categories that are Unimportant

It can happen where team members make distinctions between categories that are not important, such as having a strong preference for using composition over inheritance. This produces unnecessary friction. These categories should be merged together under the umbrella of programming tools, which are used pragmatically when writing code.

Fall into a Different Category

It can be useful to change a process, which will cause the team member to fall into a different category. For example, if you let a team member make a plan, as opposed to telling them the plan, the category will change from ‘your plan’ to ‘my plan’. This will lead to a sense of ownership and responsibility, which will result in increased productivity, a sense of pride and meaning in their work, as well as a healthy competitiveness with other team members.

Conclusion

It would be great to hear your thoughts on this, thanks! :)

freedebreuil@gmail.com
Senior Developer - Programmer
1
Comments