Anyone who has worked for a successful B2C knows how much better and more precise decision making gets, once it is empowered by data. However, two of the companies I worked for turned this into an art, and one of the two is, in my eyes, the unquestioned champion. In fact, we had such detailed knowledge of our numbers (despite the many cyclicalities) that we would occasionally find software bugs through our revenue figures: someone would notice a small drop in revenue and track conversion through the user journey to eventually find a broken page. And while that in itself is of massive value to a business, it is well understood and covered elsewhere. What I want to focus on in this article is the impact of data on company culture, and how to use the philosophy of following the data to empower your company culture.

Data as an agent of teamwork and collaboration

One of the biggest cultural challenges is to get people working together towards the same goal despite the fact that they disagree. They might disagree on what the situation on the ground is, what the best way to achieve the goal is, or quite often on what the goal itself should be. Agreement for anything non-obvious is hard to come by, no matter what kind of process you use. And such events are not unusual - they happen daily. A team doesn't really have the option to kick into an extraordinary decision making process to reach agreement, even if such a process existed. All of which adds up to one simple point: people will disagree (all the time) but the job needs to get done anyway. If unmanaged, this effect simply builds up large amounts of stress within the team, and is strongly detrimental to both the prospects of collaboration and teamwork, as well the the mental well-being of the people.

To make matters worse, the situation is often heavily mis-diagnosed. When person A cannot get person B to agree with them, they rarely see this as their fault. Most likely they will either attribute it to a flaw of character on person B, or complain that the roles and responsibilities are not clear, which is their way of saying that they should be allowed to make the decision, while ignoring person B's opinion. Ironically enough, while person A is doing this, person B is thinking exactly the same thing about person A (but also not seeing the reciprocity in their positions). More often that not, both people will probably end up escalating upwards, in the hope of getting the manager to decide in their favor, and browbeat the other person down. This is not hyperbole: I was once explicitly told by one of my team members that I should order a different team to do what he wanted them to do, or fire them otherwise. At any rate, no matter what the manager does, he or she will end up achieving nothing other than being blamed for the mess. If the manager sides with person A, person B will be seriously upset, complaining about the manager overstepping his authority, about himself not being empowered, and about bias or favoritism (and, occasionally, even sexism, or racism). If the manager sides with person B, person A will castigate him or her in exactly the same way. If the manager tells them to resolve it between themselves, both person A and person B will accuse him of everything as before, plus dereliction of his duties as a manager. In the end, even though this is really a matter that evolved solely between person A and person B, the manager is universally agreed upon to be at fault - meaning that the true cause of the problem is conveniently masked, and the root cause will never be addressed. No matter what else is done, next time person A and person B disagree, exactly the same process will take place, and exactly the same wrong conclusion will be reached, with the manager serving as a convenient scapegoat.

At the same time, this dysfunctional process is most of the time entirely unnecessary. While we as software engineers tend to be distinctly opinionated, we are above all engineers. My experience has been that once the facts are presented, engineers will generally agree to them. Or, put in a different way, in an engineering organization, the effect described before can only happen with opinions, not facts. And that is the first takeaway: one of the biggest levers in improving teamwork and collaboration, and removing some of the biggest sources of stress and employee dissatisfaction, is to replace opinions with facts. Every time you successfully do that, what was a brewing emotional hurricane of discontent and bad feelings dissipates into clarity. This is why I recommend you build a culture that values facts over opinion. As we used to say in that company I referred to at the beginning (the unquestioned champion of data): “Data trumps opinion every time!".

This devotion to data, however, is not automatic. Everyone in the company needs to understand what value it provides to the organization, and work to make it happen, starting at the top. In essence, the principle of Data trumps Opinion is a core value, and it should be treated as such. The company must not merely have it on a poster on the wall somewhere, or in the employee manual that new employees receive during on-boarding. It has to be something that is lived actively. The entire company must agree that they all choose to interact with each other based on that principle, even when the data goes against them. Effectively, they must all declare it to be the law of the land.

One of the main problems is that, while it is really a core value, it is not a politically palatable one. Companies like values that are about people, and sound empathetic: values like Respect, People First, Customer Centric etc. Data trumps opinion even sounds like the exact opposite: it puts inanimate data above the emotional attachment of a person to their opinion. In essence, though, this is simply a mistaken perception: The principle of Data trumps Opinion is all about people. Its goal is to ensure the fairness of human interaction. The best way to think about it, is through another exemplar (which I observed first hand in the previously aforementioned company multiple times). When all that is present is opinions, team dynamics rule the interaction between people. People with dominant personalities, or with power, will usually be able to push their opinion to the forefront. Similarly, people with influence (not the same as position or authority, mind you), will have a disproportionate impact on the outcome. One could argue that this is not fair, but that's how it works in the world of opinions. Make it a question of fact, however, and position, authority, power, or influence withdraw to the background. Instead, correctness, accuracy, and relevance become the measures by which an idea “wins”. An individual contributor can challenge the opinion of the company executive, and if the facts are in her favor, she wins (I saw this particular example multiple times in the company referred to above). An employee still in his probation period can challenge the tribal chief that has been with the company for 30 years, and if she has the right facts, she wins. You need no other principle to empower your workers; no holocracy, no flat hierarchies, no CEO-less organizations. There is no need to vilify or try to weaken the position of your management. All you need, is for everyone to accept this one principle, and the rest will work itself out. There is no principle of human ideas more fair than Data trumps opinion; it is the value that represents fairness of ideas in the workplace, and as a result one of the most human values there are. As Daniel Patrick Moynihan famously said:

Everyone is entitled to his own opinion, but not his own facts.

Empowering a culture of data

That being said, how does one create such a culture? To begin with, you need to eliminate a couple of detractors first. The first one is to eliminate any fuzziness in the definition of what data means in this context: data means hard data. If you allow any ambiguity, you will find that opinions creep back in the narrative, disguised as “data”. For example, you will hear arguments like “We know for a fact that our customers want X…", when in fact a single customer has asked for X, but people have never checked with the other 1000 customers if they also want it. The statement is an opinion, not a fact. However, one could simply survey the customers and find out exactly what percentage are interested in feature X. That figure would be hard data, independent of the the opinion of whoever gathered the information, or is trying to convince the team to implement feature X. It is worth the time to coach people on what is the difference between hard data, and opinions masquerading as data. Everyone on the team should point out examples of both when they see them, and there should be a culture of correcting opinions masquerading as data. It takes a while, but if the leadership leads by example and persists in doing so, others will learn to do the same and the effect will catch on.

The second detractor is a bit counterintuitive: In our quest to make sure that every opinion is heard, we try to elevate all opinions to equal status. Unfortunately, we often take this a step too far, and end up putting an opinion on the same level as data. The effect is very subtle: two people are discussing a topic and both put forward their opinions, A and B. To avoid team dynamics, managers, leaders, or other people in the team try to ensure that A and B are treated the same. So far so good. At some point, however, the person in favor of opinion A presents data that clearly supports her opinion, while the person holding opinion B cannot provide similar factual support for his. As a matter of habit, however, the other people that were arguing for equality, are still in the same mode and insist that A should be treated the same as B. That is not the case any longer, however. The situation is no longer one of two opinions competing in the absence of data, but rather data competing against an opinion. Data trumps Opinion every time! The fact that there was an opinion associated with A before the data was presented, does not make B equal to it: Opinion B is no longer competing against opinion A, but against Data A. The two positions are no longer equivalent and should not be treated equally!

With the detractors out of the way there's only really two things left to do. The first is quite simple: lead by example into this new mode of behavior. When two (or more) opinions are being discussed, point this out and ask if anyone has any data (we will revise this shortly, but that's good enough for now). Everyone presents whatever data they have, and the discussion continues on the basis of the data. Some of the data will be missing, but at least you now know what data you still need to get. If one of your points is contradicted by the data, concede gracefully and focus on any other points you may have. There's no point in continuing to argue in favor of an opinion contradicted by the data. In general, the data will not all support one opinion anyway. Also, coach other people, and make sure to point out both correct and incorrect behavior until everyone gets into the habit. Incidentally, you don't have to be a leader to lead by example. Even if you are an individual contributor, you can still be the example that everyone else imitates.

The final step is to make data more available in the discussions. We said earlier that after the opinions are put forth, one should ask what data we have. This is not exactly right though - one should ask what data we could get. This is the behavior that turns a normal, qualitative, opinion-driven organization into a data-driven champion. I'll explain by example: in the same company I already referred to so many times, there were a number of people that believed our release process was rickety and we should invest in improving it. Others believed that there wasn't enough impact to justify investing heavily in it when we had so much else going on. The entire discussion centered on how significant the impact of the release process was, but we did not have any hard data. However, it didn't mean that we couldn't get the data! Our releases happened every other week, which means that even in the face of cyclicality in the revenue, we could compare the revenue from the day of the week on the weeks we did releases, to the revenue of the same day of the week on the weeks when there was no release. I run the numbers and found out that we were, on average, $50,000 lower on the day we did releases. Note that it's not important whether this is a significant figure or not; the important thing is that we now could decide on the basis of the actual data, and a discussion that had lasted for almost a year before, and caused significant animosity between employees, was resolved in an hour and without and drama once the data was available.

Note that some times you may not be able to get the exact data you need, but you might be able to get proxies for the data, or bounds on the data. A proxy for the data is a different piece of data that could resolve the same discussion. To illustrate using an example from a discussion that I was part of recently: the point being discussed is what level of reliability was necessary for an exchange trading major investment assets. One person was of the opinion that the risk of an outage could never be reduced to zero, so we should determine what level of risk could be tolerated, and aim for that. A different person was arguing that no level of risk could be tolerated, since the impact would financially ruin the exchange. We asked if there was any data we could get, that would help us determine what the financial impact would be, but that was not realistic. What we could easily obtain, however, was a list of outages suffered by other exchanges, and see how the exchange weathered the event. As it turns out, the NASDAQ suffered a series of outages (notably, one due to a squirrel), and the NYSE suffered a 4 hour outage as recently as 2015. Both exchanges easily survived their incidents. While we still do not know what the financial impact would be if the exchange we were discussing were to suffer an outage, we have proxy data that supports the idea that an exchange can survive an outage. That was good enough for the purposes of our discussion. Similarly, one can sometimes obtain bounds on the data that serves to resolve the discussion. Once again, I'll illustrate with a real example: in one of the companies I worked at we decided to move our entire CI/CD infrastructure to AWS. As described in a different post, we would shut down most of the infrastructure when it was not being used to save on the costs. Sooner or later someone asked what this would cost us, but that was difficult to answer, since we did not have data on the usage of the system (the system not having been built yet). However, we could easily compute an upper bound to the cost, by assuming 100% utilization (i.e., the machines were never turned off). As it turns out, even at the upper bound of the cost the decision still made sense.

The key takeaway is that, even if you cannot get the exact data you want, it is surprisingly often the case that you can get enough data to resolve the discussion, so don't give up too easily on your quest for data. Also, as you get more and more in the habit of using such data to drive decisions, the value of data will become more and more obvious. This will shift the company culture to a mode where the default is to instrument your processes, infrastructure, and business as you build it to capture data, even if it is not clear yet what you might need that data for. This way, you will grow into a culture that is not only data-driven, but also data-prepared.