The Ocean We Swim In
Updated 9 days ago
Architecture of creating an app.

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 the team swims in.
Structural or environmental issues on a team can often be solved by improving the classification structure. In which categories things are put into changes how they are perceived, which will result in a change in behaviour. Often the indirect approach of modifying the classification structure is more effective than directly telling a team member to do something.
You may wonder, in what ways could I modify a classification structure?

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 prototyping phase and a building 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.
Senior Programmer - Programmer