Blog

TL;DR
(short version)
You must control the narrative.

There. That's pretty much it. I'm done. No need to read any further.

(long version)
But yes, if you do choose to read a bit more here, you must control the narrative, usually because if you don't, someone else will.

I would love to say that you must manage the narrative or influence the narrative or help to steer the narrative or something softer and more mollycoddle than, CONTROL THE DAMN NARRATIVE. But here's a story that should help you appreciate the imperative of it. Control the narrative means, don't be a chump, step up, get angry, keep your head straight, and protect your client, protect yourself. Here goes...

We were creating an SSO integration as part of a large website build for a multinational tech company. With API integration work like this, especially work where there are many security measures in place for good reason, each step in the process is more like a trip and fall. This is normally fine, a native part of software development, especially with API work, especially with high security. But in the cases when many large teams are trying to work together to get a thing done, the process can be tedious. If you add a critical and short deadline to the mix, it's even more onerous.

So we were building up this SSO thing, SSO by the way stands for Single Sign-on. It's like what you do on a website when you use your Facebook account to logon to a site you have never been on before. (Shameless plug here). In order for an SSO integration to work when done for a large enterprise client, you have to integrate the system with code and servers belonging to several different departments inside the organization. Each of these departments has their own agenda and their own narrative. You quickly lose control of the story.

So we are on this tight deadline to launch this website. The SSO piece was a critical component. Each step along the way our code was failing because we were getting incomplete information from someone, or we were coding incorrectly and didn't know it, or a server was blocking an IP address or a certificate was not correctly installed. We lost control of the narrative and allowed these other departments to hold us responsible for the failure and the deadline stress.

"Well I think Mitchell's team just needs to update the way they are making their server call. When I try my script it works fine. I'm not sure what their problem is."

We found ourselves in a position where we could not prove that we were doing everything we could to get our work done. Everyone was pointing the finger in a direction away from themselves and pressing us to exhaust every avenue before they would do their job and make sure their system was in fact working or even plugged in to a power outlet.

But fairly early on we accidentally did a really smart thing. We suggested that one of their internal teams write a Codeigniter library to demonstrate how the SSO integration should work. They somehow agreed. I think they regretted it later because we were able to use it over and over again to demonstrate problems in their own systems at each step in the integration.

So we had this accidentally very helpful tool. We could point them to a url on a server that would prove positively that some component of their system was working in one circumstance and failing in another. Once we learned to do this, we began to regain control of the narrative.

It took a couple of times of proving that we were right, but once we had enough of these under our belt, the narrative began to shift from, "Solspace is just a bunch of dimwits and we'll never make this deadline" to "Solspace is just a bunch of dimwits, but don't screw with them because they occasionally get stuff right and also we might possibly make this deadline."

Why is controlling the narrative so important? Well we want to succeed right? I mean, we want to get hired to do good work, we want to do the work, we want it to launch and we want it to launch on time. In order for this to happen, we have to work together. And as soon as you introduce any form of 'together' you get into the space of competing versions of the facts.

Controlling the narrative means maintaining your hand and your influence on what the reality of a situation actually is. In the realm of software development and systems integration, there are too many people involved, too many different moving parts, too many bits floating around, for any fact to actually be conclusively known. With so much space in between things, there is room for interpretation. Someone is going to do the interpreting. This is inevitable. You need to throw yourself at this fact and take ownership of your part of the narration. Principally because of the above, you want to succeed. You want to launch. You want to complete your task. For this to happen, you have to protect yours and your client's ability to work and work well.

So when I heard something like, "Mitchell's team needs to fix their code.", I took great pains to participate in the narrative around what 'fix' might mean. I found it extremely powerful to be very obvious and very transparent about when my team was at fault. I found that being so loud about it somehow drew extra attention and emphasis on the times when we were not wrong. When we were in a meeting and someone was asking who's at fault for a certain problem, my being silent, after having so loudly taken responsibility for my faults previously, ended up drawing attention to those who did need to step up and take responsibility.

When I say control the narrative, I don't mean bend the truth. Some do, but I don't. When I try to control the narrative, I try to pull a group of people back into accord with the facts. And I only stick my neck out when I can demonstrate the facts. This little Codeigniter trick I mentioned above was my major turning point in this particular lesson. I suddenly had a tool that could demonstrate the facts for me. And with it I was able to exert my own influence over the narrative.

So we're one hour away from launch. We have found a way to test our production SSO credentials against production servers without them all actually being live. As soon as we did, the system failed and it failed opaquely. It was not at all clear where the fault was. Thanks to my new commitment to controlling the narrative, I started pulling the pieces apart until I could prove that a security certificate provided by the super duper extra deluxe expensive hosting company was in fact corrupted. (It was very much in the interest of this extremely expensive hosting provider to never admit error, never be wrong, and also never actually do any work.) But I was able to prove that they had fubarred the thing. I took ownership of the narrative, thankfully at the zero hour just before launch, and they quietly reissued the cert. We launched and avoided a meltdown. I recommend it to all my friends.