Ruby developer. CTO. Swimmer. Always trying to write more
As a young corporal in the Air Training Corps, one of the most valuable lessons I learnt was:
You can delegate responsibilty but you cannot delegate accountability
What does that mean? It means that when you delegate a task to a subordinate, you give them the responsiblity and the authority to get it done. When they succeed, they also get the praise because, after all, they did the work. Some of that praise will reflect well on you, but it still belongs to them.
But. If things go wrong, you are still accountable. You must still take the blame when the shit hits the fan. You cannot deflect the blame onto the other party because the task was originally given to you. Privately, of course, you can address the subordinate’s failure but publicly you take the flak.
Well, that’s all fine in the military but how does it work in the real world?
It means that when your hosting supplier has an outage, you have an outage. You can’t tweet “AWS is down. Soz!” and expect your customers to absolve you of all blame. After all, you gave the task to Amazon but did you really give them the ability to do the job? Did you, for example, ensure that your application uses multiple availability zones across multiple data centres? Probably not.
It means that when your ticket supplier is having problems with the volume of visitors you’re sending them, you own that problem. Perhaps you should release the tickets in batches, or find a different service, or delay the launch, or just shut the fuck up and say it’ll be fixed soon. What you absolutely should not do is name and blame the supplier in an email to all your thousands of potential customers.
This isn’t the first time WebSummit has publicly blamed suppliers for their problems but I don’t want to pick on them specifically. It’s a common problem across the tech industry.