Hooli vs Pied Piper, or the Responsibility in Making Decisions

The hilarious TV show Sillicon Valley is teaching us some valuable lessons about managing software development teams and making decisions

I have recently watched HBO’s Sillicon Valley season 2 and I have to say that I found it even better than the previous season. Although every situation is pretty much over reacted and they have the worst luck of all times, I find myself reflected in some parts of the show (I’m not telling you which ones!). Some gags are hilarious and if you haven’t had the chance to watch it, I really recommend you to do it - even if you are not a nerd-tech guy!

Besides being really entertaining, I have found something that made me think and I wanted to share here. From now on, I will tell something that happens in one of the episodes. I don’t consider it a spoiler, but just in case, I warn you. Continue reading after the image on your own responsibility.

Sillicon Valley

A rush decision

It’s precisely responsibility what I would like to talk about. But first, let me introduce the situation (or recap it, in case you watched the episodes):

At the end of episode 5 in season 2, we see Gavin Belson, CEO of Hooli, making an announcement: they will live-stream a fighting combat using Nucleus, their compression technology, in order to get to the market before Pied Piper’s technology.

The episode ends with an image of the Hooli engineers watching the announcement on TV and realizing that they have an important delay in the implementation of some core features in Nucleus, which may lead to a huge failure of the streaming, but none of them wants to tell Belson about this issue.

And, of course, it fails miserably. Who is responsible for such a big fiasco?

Listening to your engineers

It may seem obvious that Gavin Belson is responsible for making this decision. He tried to rush to get his product into the market before his competitors without making totally sure that everything was optimally implemented. In short, he was purely guided by a business decision.

Decisions in the software industry are guided by business analysis; in a constantly and rapidly changing environment, it has to be that way. If you get your technology to be first in the market, you may become a de facto standard and it doesn’t matter how good your competitors are if you are able to keep the market with you.

However, this type of decisions shouldn’t be made just on business criteria. If you are going to release a certain technology, you must ask your engineers for what is feasible to do.

Software projects usually have 4 variables: time, cost, quality and scope. To me (and I guess, to everyone of you), quality mustn’t be negotiable - it always has to be maximized. Time and cost may be imposed by business constraints. Therefore, we only have scope left. Let your engineers control the scope: they will tell you what is feasible for your deadlines and budgets. Making a decision combining business and technical information is more likely to be successful.

Informing to your managers

Besides Gavin Belson, I think that Hooli engineers are also responsible for Nucleus failure. Indeed, they knew the product was not going to work, and still they let their managers present it. That makes them equally responsible for the fiasco.

Some may argue that they didn’t inform about the state because they were under pressure and they feared to lose their jobs. Although I can understand that, not telling your boss that it is impossible to meet a deadline is an irresponsible behavior.

You are the expert on that field. You have been hired to do things, but also to speak up when something cannot be done. It is your responsibility to point those issues out. If your managers still ignore you, then shame on them; at least you did a good job. And even if you lose your job for pointing out a problem, do you really want to work for a company that doesn’t let you do your job professionally?

Dialogue & Discussion