Our most valuable technical asset is each other
I am a technologist. I love bespoke technical creations; I am excited about how Kubernetes will make it simpler to package and ship software, the implications of eBPF for systems and network analysis and could get into a long and healthy discourse about just how to represent human entities in existing data stores.
However, must as I love building these things, I have been struck recently by just how important it is to reflect on the humanity of the technical systems that we build. This lesson is nicely encapsulated in Conways Law:
“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
but the full gravity of this notion has but recently hit me.
A technical system that isn’t
I work in the domain of e-commerce. I have for some years now, and have come to a limited understanding of the domain. My job is to help build a commerce facade; a conceptual framework that users can navigate for the purpose of understanding, comparing and eventually purchasing the products of our clients.
For this to work, I need to be able to understand the users who are interacting with our systems, and how they see commerce. I further need to be able to represent and codify the abstraction that they expect, plotting out it’s interactions with other abstractions in a predictable way that the users expect, and that doesn’t fail in any spectacular ways. I must understand the entire workflow a user is expected to perform; when the users is “handed off” to systems I contribute to, how they can navigate this system in a way that causes them the least pain and how to hand them off to the next system.
Lastly, I do not work alone, but rather I work with a team of colleagues all of whom need to share this vision for us to collaboratively build a cohesive and logical system that makes sense.
That is an extremely hard thing to accomplish. By comparison, representing the system as code is a comparatively easy challenge with nice, fixed constraints.
How to build a shitty system
Practically speaking, The unifying vision that is a requirement for delivering the coordinated changes among multiple team members is not the default state. It is something that must be carefully balanced, and there are many ways that it can start to slip out of grasp.
Working in a vacuum
The simplest way to let the vision of a project disappear is simply not to define it. Instead, to kill a project effectiveness as quickly as possible we should instead simply define some tasks that must be completed without context explaining how and why, and blame the implementers for failing to live up to an expectation that we did not define.
This will rapidly degrade into a refusal to do anything but the most spec’d out tasks, and a a lack of ownership of the project by the team. Large parts of the project will rapidly degrade and the failure of these projects will cascade, making it difficult or impossible to ensure any stability of future development.
Feathering our own nest
It is possible, absent any re-enforcement of the project vision, for us to develop our own vision of how the project should be. We will decide ourselves what it should look like, how things should work and what the priorities should be.
The problem is when working in a team, we will each define our own priorities, and have our own view of what is important. We will continue to work on our own task at the expensive of other teams fracturing the project into components across lines that weren’t intended, and are badly suited for a higher level of coordination.
Personal grievance generating silos among teams
Despite a clear understanding of what the project is supposed to accomplish, without each member of the team finding a place for themselves within the vision and within the team the level of co-ordination required to set it about will be impossible.
Personal grievance can take many forms. It can be simply a feeling that one is not appreciated, or it can be someone failing to communicate effectively around an issue or perhaps a simple dislike on a completely non project related matter.
Regardless, personal grievance clouds our judgement, and creates a separation between team members that will lead invariably to siloing and blame shifting, fracturing the project.
Building good technical systems by building good social systems
While building a good social system is not the only thing that is required, it is a fundamental requirement of building a good technical system. All technical systems are still fundamentally human ones. Investing in the team is far more valuable than any technical investment, as it governs the implementation of any technical invest.
There are various ways that we can encourage building an effective team:
Vulnerability
“Vulnerability is the birthplace of innovation, creativity and change.”
― Brené Brown
For any team to be effective it must be able to self regulate; to collectively revisit the vision, address issues as they occur and provide a feedback mechanism for when external pressure have a destructive effect on team cohesion.
A prerequisite to being able to self regulate is the psychological safety required to honestly review and discuss issues that affect the team. It is critical that team members are able to be vulnerable; to come up with problems without solutions, or to suggest a potentially insane solution to a problem. The conversations that come out of these difficult topics in and of themselves improve team cohesion, as well as providing practical feedback to team leaders to modify the environment to improve team performance.
Finding a place
Companies are made up of teams, and teams made up of people. It is each individual person who is the lowest common denominator for all teams, and for a person to invest themselves and their passion into the success of a project they must first feel as though they belong in that team , and must see a way for themselves to grow and fulfil their own goals within the team. Absent this belonging an individual cannot take ownership of the project, and will not be able to understand or partake in the project vision.
Selflessness
In order to truly belong to a team one must first abdicate ones own self interest in favour of the team. It is only then, with the genuine desire to see the team succeed over ones own personal success that teams will become truly productive. Buying into the teams success as a mechanism for personal success means buying into the project vision, and using the project and the team as a means to further ones own success — in conjunction with the team.
Passion
Humans by nature take their cues from the other humans around him. For those who are in a leadership position or otherwise in a position of power within a team, they have a responsibility to show passion for the project, and find ways to illustrate the benefits and the possibilities that the project brings.
Passion is infections, and ignites in people the desire to find the best possible outcome for their project. It creates a value system based on outcomes that are positive for the project, and lets people become proud of their contributions, and understand they are a valued member of the team.
Principle
As mentioned, the status quo for a project is not to have a high performing team with a unified vision, but rather to fracture and break apart. It is only through establishing a set of rules that the team agree to be held accountable for that we can sustain the continual renewal of project ownership.
Principles are a mechanism to identify and regulate behaviours that are putting personal or subgroup success over the team. Absent principle, team members can inadvertently corrupt the vision for their own personal success.
In Summary
Building a high performance team is a complex topic. However, it is among the most valuable investments that a team coordinator or management can make, and will govern the success of the project going forward.
Our most valuable technical asset is human.
Thanks
- Antonius Koch for an early review
Related Material
- “Accelerate” — Nicole Forsgren, Phd (I haven’t read this yet)
- “Psychological safety in SRE teams” — John Looney
