One of the most interesting side effects of the so-called API economy is that the forced interaction between systems has unexpectedly led to forced interaction between people. After being a part of that industry for almost 12 years, frequently against my will, I’ve noticed many common patterns in those forced interactions. And there’s one I find particularly concerning and harmful.
Some time ago I joined a company as the tech lead of a team responsible for integrating many different APIs from many different teams into one single tool. Most of those teams were located in remote offices, all around the world. Shortly after joining, I noticed that the developers used to talk in pretty bad terms about the other teams they used to work with.
They were always complaining about other services’ stability, specifications, response time… Every failure or (apparent) issue on the other side was followed by a curse and an angry email to the service’s owners. And at the same time, the recipients of those emails used to answer in a pretty defensive way, blaming our implementation, our usage… even our business logic. All those comments were immediately tagged by my team as excuses and therefore, dismissed without even considering them.
That immediately triggered some inner traumas. In one of the first companies I worked for, our new, superb service-oriented architecture quickly became a blame-oriented architecture. The teams used to blame each other when things went wrong (and they used to go wrong very frequently). The service my team was responsible for sucked so badly that it eventually became a common (and therefore, easy) target for other’s problems. Sometimes they were right, but usually they were just wrong, so we naturally became more defensive, and started resisting and dismissing reports. We also became more aggressive when finding errors in other components. I still remember how toxic and frustrating it was.
But we eventually reached our limit, and we realized that something had to change. It just didn’t feel right. So we radically switched our approach, and we started accepting all the error reports without any complaints or comments and investigated them thoroughly.
Sure, we spent more time, but switching our policy from “prove us that our service is not working” to “let me prove you that my service is working”, and being more systematic before reporting issues to other teams had a very positive impact in the long term. We were able to better understand how people were using our components, but also the weaker points of our solutions and of course, lots of real, legitimate bugs. And the other teams started to appreciate our honesty, humbleness, and hard working attitude. They became less defensive, and they were actually more prone to admit their own errors now. We were better every day, and so was our software.
That experience had a deep impact on me. I remember how I felt before and after. I’m still thankful to my manager on that project. It was a life lesson, humbling and enriching. It stopped the blame party and had a great impact on the company.
So now I was apparently sitting on the other side, and seeing my new team complaining bitterly about all other teams made me go back to that old project. Still, I had joined recently, so I decided to take a deeper, more critical look behind the scenes before taking sides, and then to form my own opinion.
Unsurprisingly, among all their reports I found quite a small number of actual issues and a huge number of false positives. Some of them were due to bugs in our own code, others were due to our lack of understanding of the specs, others were just caused by unrealistic expectations from our side.
Most worryingly, even when my guys were right, nobody was taking them seriously. They were the assholes nobody wanted to listen to.
Now you might be thinking: “maybe your team was right and the others sucked so badly that they created the situation by being incompetent, and your team naturally adopted the role of demanding improvements”.
Maybe.
I didn’t care.
I wanted my team to be honest. I wanted my team to behave with others the way I wanted others to behave with me. I wanted this team to be like my first team. I wanted my team to be professional. I wanted my team to be listened to if something really happened. I wanted my team to be an example.
So I did the same thing. I asked my guys to let me know before reporting any issue or creating any tickets to the other teams. Every time they wanted to do it, I sat with them, took a closer look, and helped them discover what I kind of suspected: that most of the issues actually were our fault. We fixed our stuff, we made some changes in order to make our services more resilient to other components’ failures, and when we needed to report bugs, we just tried to be as nice as possible with the other teams.
After only one month, we were all able to see the difference: we felt in control, happier about our colleagues, and listened when something actually went wrong.
This is what I learned, my philosophy, my method, and my personal manifesto:
When I talk, I want others to listen
The method to achieve that is simple: I don’t talk too much, but when I do, I say something interesting, so the others will listen.
That way you don’t bother anybody unless you’re completely sure about what you’re going to say and you’ve done your homework first.
Blaming others is toxic for them and delusional for me
I don’t like to see my people blaming others, even if they’re right. Of course, it’s easier to keep a team together when you have an imaginary enemy that is the cause of all your problems, but a culture of blaming and complaining is toxic and harmful.
Even if you don’t mind working in a company flooded by fear and mistrust, it will end up contaminating your team with a false sense of superiority and overconfidence.
And more importantly, blaming others will prevent your team from taking actual ownership for their work. It’s more comfortable for us to think that we can’t succeed because someone else is doing something wrong, instead of focusing on what we can actually do.
Is an API crashing? Good. Is my service failing because of that? I’m sure there’s a bunch of things I can do in order to mitigate the effects on my side. “But this should work”. Yes, but it’s not working now, so maybe I should face the cruel reality and think of a way to fix it, instead of complaining. Apparently, my assumptions about that system were wrong, so I’ve got work to do. And if the other guys are in my own company, I should help them too.
We are ourselves and our circumstances
We have no idea what the other teams’ problems, constraints or resources are. Maybe they’ve got a horrible legacy project they hate, but they are just trying to keep it alive because it’s very profitable. Many years ago, the team with the shittiest project in the company was actually paying for the party, while our new, fancy project was just burning money non-stop. Those old guys working desperately around the clock to keep that horrible legacy alive paid our paychecks for months.
So please, be sincerely respectful of other people’s work and appreciate their dedication. You don’t know their circumstances.
The preoccupation with what should be is estimable only when the respect for what is has been exhausted
— José Ortega y Gasset.
I’m not better
Lastly, nobody wants to feel that their work is being over criticized, dismissed or permanently questioned, especially without a good reason. I’m sure you know that very well.
“But hey, their work really sucks. I don’t do that kind of crap.”
I don’t believe you. Your work is likely the same shit as the other 99% of work out there, including mine. You are not better. Stop thinking and pretending to be so.
Laws of human behavior say that people will always try to preserve their honor, so they are not likely to accept that they are just wrong and you are right. And in the same way, the more ego you’ve invested in your angry email, the more painful it is going to be for you to admit that you were wrong, if and when it happens.
I’m not better either. So I’ll do my best to be respectful and humble.
Do your homework. And when something goes wrong, review it carefully, take one more look at the specifications, make sure that you are doing everything right. Double and triple check. And then, only then, ask. Write a polite, respectful, humble, message. Provide as much information as you can, challenge your assumptions, ask what you’re doing wrong. I can assure you they won’t become defensive but thankful.
I want people to listen. I don’t want blame to get in the way of my ownership. I have no idea about other people’s circumstances.
And I’m not better.
