In a large organisation, it’s very easy to feel like a small cog in a big machine.
But the truth is, the only thing keeping you in your corner is you. Engineers who really succeed in these large organisations know how and when to venture out from their little corner.
Go and find the most successful, smartest Engineers in your organisation. I guarantee you not a single one of them stays in their lane, in their corner, or in their service in a larger system.
These Engineers know that in order to understand their own component(s) better, they need to know the system that they belong to. You need to find ways to work on the other services/components. You need to understand the process that your service is used within, and how it relates. You need to know how and why you are relied on. You need to get your hands dirty to really get to grips with it.
We need to carefully think about when and why we cross these boundaries though. We don’t want to step on any toes, and we don’t want to waste time. But if we find ourselves in a situation where we are waiting for another team to do something, and we are blocked. We should prioritise unblocking ourselves.
Don’t be afraid to jump into another service you don’t own. It’s all just code at the end of the day. You can and should be able to understand it.
Customer & Use-Case centric thinking
It is easy for us to get stuck in ways of thinking that are not very useful to the customer. They want to do something, they don’t care that that happens to be broken down over 20 different micro-services.
The more time we spend arguing about which service is responsible for what and why the other team did something wrong. Is less time that is spent actually solving the customer problem.
Don’t get me wrong, we must learn from these. Find better ways to collaborate and to organise problems across our micro-services to stop these problems from happening again. But in the midsts of an incident, the worst thing you can do is to stay in your lane.
Stepping on toes
When we cross these boundaries, it should be in times of need, and under the guidance of the owning team. If you jump in and force through a change that doesn’t make sense in their context, just to solve your problem. You will destroy trust. We want to use these opportunities to build trust, and break down knowledge silos. Coming in hot and heavy and leaving a mess in your wake will only make the silos stronger.
We shouldn’t go in and rewrite things without context because we think we know better. It should largely be about learning, and growing our understanding of the wider context, and knowing how and where to insert our deep knowledge of our piece.
Respect the ownership of the code, but don’t let it stop you from getting shit done. You may be on different teams, but you’re actually part of the same team.