I usually work in software development, or “tech”. Specifically, I work in web services type of software development. This is an important highlight, because it is a different environment from, for example, designing software to specification to go on a space probe to another planet. Mistakes in web services type of software are not desirable, but they’re also not catastrophic.
This onboarding series is a summary of the things I found effective for me and (maybe?) the teams I participate in. The format is the way I usually present these things, which is, onboarding a new team member onto the team. It consists of three sections: Principles and Values, Team Processes, and How To Deliver Work.
Principles and Values
My friend and colleague Leora Pearson and I had the opportunity to create a team from scratch. This gave us the chance to sit down and think through our principles and values. It was a hugely valuable exercise to think from first principles as to why we were going to build a team and engage in the work. This is a lot of mental models, abstractions, framing, and techniques that help to align the team: complexity, Cynefin, how systems fail, black swans, metaphors, finite and infinite games, Wardley Mapping and doctrine, and Universal Scalability Law. I’ll share these Principles and Values in future posts.
As part of creating the team, we agreed on Team Processes. There are two processes that I find fundamental: the Advice Process, and the Conflict Resolution Process. I’ll share more on these in future posts as well.
How To Deliver Work
Lastly, having Principles and Values and Team Processes in place, I’ll share the ideas around how we organize to deliver work. These will include minimizing cycle time, setting commitment expectations, defining work items, defining failures, tracking ideas, system to human communication patterns, feedback loops, and learning documents.
- Principles and Values
More posts on Principles and Values, coming soon.
This post explores why the speed of software development can slow to a crawl inside large organizations. In particular, we will consider software services and their customers from the perspective of resource contention. It turns out that this framing highlights a major contributing factor that slows software development. We will conclude with what can be done about it.
Consider the problem of resource contention. Software services require resources to operate, and those resources are finite. When users use a software service, resource contention problem occurs as soon as there is more than one user. The key question to consider is, who is responsible for managing the resource contention problem? We have two possibilities. The service itself can manage the problem in a centralized way or the users can manage the problem in a decentralized way. This is the key insight to extract from this framing.
The service itself can manage the problem in a centralized way or the users can manage the problem in a decentralized way.
The resource contention problem can be managed by the service or by the users. In the case of the service, the management can be centralized within the service. In the case of the users, the management must be distributed.
There is a cost associated with managing the resource contention problem.
When the service bears the cost, it bears the entire cost of managing the problem. A typical solution to the resource contention problem is for the service to become multi-tenant. To every user, it seems as they are the sole tenant of the service and need not worry about managing resource contention.
When the users collectively bear the cost, the cost for any single user is mostly small, most of the time. A typical solution takes the form of an ad hoc, distributed, and probably incorrect, consensus protocol. This protocol is typically referred to as “careful” or “being a good citizen.” Every user knows that there are other users who at any point can do something that severely degrades their own use of the service, or worse, they’re unaware of it. Typically, users coordinate with each other in order to manage the shared service and not exhaust its resources.
Consider what happens when a user uses multiple services for which they have to manage resource contention with other users. Every new service requires adoption of a new, ad hoc, distributed, and incorrect, consensus protocol. While the cost of coordination may be low initially, the cost, per user, grows super-linearly with the number of services used, since all of the users of each new service, some of them unknown, must be coordinated with.
Alternatively, when each service manages the resource contention problem by offering multi-tenancy, every new service requires no coordination from the user. The cost, per user, increases linearly with the number of services used and is limited to learning how to use the service.
When each service manages the resource contention problem by offering multi-tenancy, every new service requires no coordination from the user.
Another relevant concept in the dynamic between services and users is the notion of internal and external users.
Users external to the business, tend to have other options, and therefore are less likely to put up with additional cost of coordination required for using the service. On the other hand, internal users typically have no such luxury, are cost insensitive, and must use the service designated for them. This tends to lead to a pathology where the service seems justified in not paying the additional cost of providing multi-tenancy, as the internal users have to use the service no matter the cost of coordination. But, what is often missed, is the super-linear cost the internal users must bear for their distributed management of resource contention. Fortunately, there are things we can do to avoid this situation.
Service seems justified in not paying the cost of providing multi-tenancy, as the internal users have to use the service no matter the cost of coordination.
We can demand that all services manage the resource contention problem by being multi-tenant. Alternatively, we can ensure that internal customers have a choice of using or creating another service that is multi-tenant, which may eventually lead to multi-tenant services as the cost of their adoption is lower.
Lastly, I want to highlight a pathological move not to make.
Forcing the use of a single service is the right move if and only if that service is multi-tenant.
There is great efficiency to be gained by removing duplication of effort. Forcing the use of a single service is the right move if and only if that service is multi-tenant. Otherwise, the organization is placed in a configuration where internal users must bear the cost of managing resource contention and cannot improve their situation by using a multi-tenant alternative.