Problems or solutions

There comes a time during the evolution of a platform team where you have to scale organizationally. Usually the motivation is to share load across geographies and allow the current maintainers lead a life outside of work ¹. We agree to apply a variant of follow the sun↗ model with globally distributed teams.

Here’s the challenge: you have toiled hard to build this platform. You’re super proud of those 100 lines of code that saves ~2ms at the runtime. This is the best platform with a perfect design. Now, the new across-the-ocean team doesn’t get it at all ².

Wise people suggest that you’ve to trust and empower people. I’m sure you will find a way to fix that. This post will talk about a core human attitude that can be a superpower in your journey.

Us and them

The frustration of they don’t get it manifests in our behavior unconsciously. It limits our interaction and causes severe damage. The first step is awareness, here are three of these behaviors (and yes, I’m guilty too).

1. Going micro by questioning every damn thing.
2. Unbundling layers of knowledge like peeling an onion.
3. Raising the bar super high.

I used to think one way of ramping up a team is to hold their hand. I would get involved, nicely of course, and explicitly tell people what to do. This blocked all the diverse perspectives the product could have gained from. Or, I’d try to ask 20 questions on every PR or design document. The level of questions rarely mattered. This created too much chattiness in the system. It triggered defensiveness in people and that’s not how you get the best in someone.

Another flawed behavior is gradual unrolling of knowledge. Take a design proposal, in the Iteration 3, some past knowledge will be quoted and will become a blocker. Buddy, it is past knowledge, what the heck were you doing in the first two iterations? And how much more of such layers you’re going to peel? Will this design ever close?

Third, and probably the most interesting behavior is the bar we set. I don’t have good test automation coverage (legacy code, I know 🙈). My shipping checklist has an item asking a vendor team to run a test pass across 2 days. But suddenly I am going to ask for the listing all unit tests in the design proposal from the new team (instead of the equivalence classes or a strategy). What the fish 🤣

It took a while to realize that this sucks. And all of the above can masquerade as doing the right thing™, whatever that means for you. Please don’t fall into this trap.

There’s a better way to do this.

Thinking together

I realized that I have been thinking in terms of problems and challenges ³. In some cases, my questions or asks might not even be obvious to the peers because they lack the years of context I might have.

Just stating the problem is not enough.

I must transfer the context and help them see things with historical context. Help everyone build a mental model. I have to make everyone around me succeed.

The opposite of this is the solution attitude. I explicitly state that we’re in this together - instead of me sitting on a high pedestal and only calling problems out. We review together, we state the problems - I put forward a few, and you bring some more on the table. We discuss and close on a solution. Some problems may be simply scoped out, nothing is perfect any ways.

I must give everyone a chance to solve the problem. But I will not intimidate them by throwing problems across the line, and indirectly stating that it’s your problem.

Two approaches

Improvisational comedy has a rule of thumb called Yes, and …. Basically, you must agree with the core premise of the other improviser (“yes”) and then improve upon that with your line of thinking (“and …”). If you reject the basic idea of your collaborator, it throws them off, and harms the flow. See https://en.wikipedia.org/wiki/Yes,_and…↗.

The complement of this is No, but … providing a mechanism to constructively brainstorm.

If I have to summarize everything we’ve been talking so far: do NOT just say No when you’re collaborating with someone, do NOT throw the problem to the other side. Always include a but … to share a point of view, show your skin in the game by including a solution too.

It is even better if there is a continuum between each other point of views. Always try if you can respond with Yes, and … to maintain the flow.

On excellence

As I get older, I am more and more convinced all of us have a single goal. We want to build the best thing out there. And that is NOT possible without each of us bringing our best to the table. This is excellence.

At times our behaviors may be limiting. It is always worth a reflection to correct the course before it’s too late. People are your strength, not those ~100 lines of code you’re super proud of.

Thanks for reading!