Dependencies, technology, and who's the client?
There are a few patterns in the behavior of teams from small to large scale software organizations. Although culture may play some role in that behavior, it doesn't change the fact that some of them are known to yield better results.
The culture may become a barrier to implement some of these behaviors. In a company with a micro-management culture, for example, managers can force programmers to write short-term code they'll have to rewrite in a few weeks. Likewise, managers can force designers to test a sub-optimal experience against the happy path but not against unknown and potentially disastrous paths with side-effects.
However, culture doesn't change the purpose of software, which is to create value for a customer. Also, culture doesn't change the path every team is doomed to follow if they don't understand where they're going. This post is going to talk about 3 ways to improve a software company to achieve a more efficient value creation.
1. Reduce Direct Dependencies Between Teams
If half of the teams didn't exist, would the company still be able to deliver value to the customer? If the most crucial team, or team member, is hit by a bus, would that eventuality yield the whole company or the whole team to a halt?
High performing companies enable teams to own all the pieces of the stack up to the customer. Each team owns a business context that enhances the value of the company. One team can't be a single piece of the puzzle; they have to be the puzzle.
Here's an example:
Imagine a social network where the user tries to change their status. The service that receives the command saves the user's intention, adds the "update" job to a queue, and returns a message to the user saying the change is "in progress." Another service, also owned by the same team, processes the queue.
Imagine the server responsible for processing the queue is offline due to an outage. The team responsible for user status update can't revert the outage quickly enough. In that case, other team members can look at the queue and update the database manually using a SQL script.
The team responsible for the user status update can also have a support department. The support department is embedded within that same team so that they can answer support calls from users complaining about the time it's taking to change their status. Having a support department embedded in the same team closer to the programmers can reduce the communication distance and prevent the divide between the programmers and the customer.
Manual updates to the database using a SQL script does not scale to the size of Facebook, for example. However, having the ability to make manual changes, if necessary, is a piece of evidence the "status update" service does not have direct dependencies to the "profile picture" service. Therefore, different teams can own each of those services and operate independently.
The ability to run manual updates is an efficient Litmus Test to check if your teams are independent or not. It also allows outage recovery without the system bombarding the user with all kinds of errors.
If a job processing service is down, there's one team responsible for that service that can run the jobs manually, if necessary.
2. See Technology As An Enhancement Of Reality
If the software in your company didn't exist, would customers still be able to get the value they want, albeit inconveniently?
Before the existence of real-time communication apps, people used to talk to each other face to face. You can still do that today. Nobody is stopping you from trying to visit your friend right now.
However, there's a significant cost to keep in touch with your friends without technology if they live far away — car fuel, time, airline tickets, bus tickets. The advent of social networks and real-time communication apps haven't changed the underlying reality of how people communicate. They have simply enhanced the existing reality through the use of technology.
Technology is not essential to create value. However, it is essential to maximize value creation. Technology should enhance your business, not make it dependent on technology. Teams should be capable of creating value without technology, at the obvious cost of efficiency.
Technology is not essential to create value. However, it is essential to maximize value creation.
3. Understand Who Your Client Is
It's vital for every individual working in a company to understand who gets value from their work: the client. If you don't know your client, then your work has no purpose; you can't get feedback from the ones who use the code you write to make sure your code is heading in the right direction.
A client can also have many faces.
If you work in a small payments company, the clients are the other businesses that pay for the payment solution. If you work in a big company, the clients may be other teams that consume the API of a service you maintain.
Clients are always there, even if they don't pay for your work directly.
If you write code for an Open Source library, even if nobody pays for your work, the clients are the developers who use that library, not the project maintainers. If your work in a company's employee intranet system, the clients are the other employees, not the standard company customers.
Your client may also be a manager. It depends on the kind of work you're undertaking.
If you're building observability for the product so that the Product Manager can make better decisions, then the client is the Product Manager. If a Team Lead asks you to run a sprint simulation using the current team's tracked velocity, then your client is the Team Lead.
Knowing your client is all about maximizing feedback efficiency. It makes no sense to get feedback from someone who is not the final user of your work.
Understanding the client is paramount. Without them, your work serves no purpose.
In summary
Reduce direct dependencies between teams. Otherwise, you run the risk of facing an outage that can render your whole organization offline.
See technology as an enhancement of reality. Otherwise, when that outage happens, there's no human intervention fallback.
Understand who your client is. Without understanding your client, you won't receive adequate feedback from the ones that are impacted by the code you write. Use the feedback of your client to build the right thing first instead of only focusing on building the thing right.
Don't get scared. The lack of these practices won't destroy your company or prevent it from becoming profitable. You may still be able to create a decent organization with a "reasonable" income. However, if you care about who your client is, your work dependencies, and how technology enhances your business, you'll most likely exceed whatever is "reasonable."
It's all about which standard you're aiming for.
It's all about if you want to produce something great or simply "good enough."
Thanks for reading. If you have some feedback, reach out to me on Twitter, Facebook, or Github.
Thanks to Avi Kessner and Matt Smith for their insightful inputs to this post.
Wanna chat in person? You can find me in the Sydney Software Crafters meetup.
Top comments (0)