I deal heavily with workplace sensor technology. This is the tech where a sensor is placed under a desk or in a room that can tell you if space is occupied or not. Basically, it reports a 1 if it detects new occupancy and a 0 if that occupant leaves. Pretty straightforward.
From a primary data standpoint, we can use this data to understand the utilization of the office. Were we 70%, 80%, 90% occupied on average? What was our occupancy late morning? Mid-afternoon? What days of the week do we see our peaks occurring? It’s pretty cool to see some of these trends.
From a secondary data standpoint, it can report the average occupancy of the office across the day accounting for the time a given desk sat empty. If you measure an office between 7a and 7p, you may never get higher than 50% occupancy because the tails of your measurement period are extremely low occupancy. If you measure between 10a and 3p, the lunch period takes on outsized significance. If you measure between 9a and 4p, the trend changes to something else. Picking the right measurement period is tricky. Even more tricky is understanding what’s good or bad with a particular measure.
I’ve recently seen a number of requests to measure conference room utilization by counting the number of people in a room at any given time. Naturally, a 10 person conference room occupied by only 2 people is under-utilized. Unless those two people are the head of sales and a big client he’s working with. Then it’s perfectly utilized. But what about a 6 person room only occupied by 2 people? Is that under-utilized? Even if it is, is it 33% below utilization target or 67%? Identifying how to define good and bad performance is extremely difficult.
Primary data is binary – good or bad – difficult to argue with. Secondary data is open to interpretation. Focus on the primary data first. Evolve to include secondary data over time as you learn what it means to your business.
Good data is often very boring. It contains the basics and comes in as expected (right format, schedule, completeness). There are lots of things we can do with good data in order to move the ball forward.
Interesting data is never boring. It contains interesting attributes and never-before-seen elements. Usually it comes in as a one-off dataset. There are many interesting things that can be done with interesting data but sometimes it is hard to tell if those interesting things are valuable.
Recently, I’ve been involved with a few technology companies looking at their new capabilities in development. There are some truly fascinating things being developed. My first question every time is, does this new feature drive user adoption of the system? Stated another way, does this new feature give users a reason to either contribute data more freely/voluntarily or come back regularly? If no, then you are developing a second tier feature. If yes, it’s a core feature that is making your system better.
Most interesting data comes from second tier features. It’s the data that may or may not be correlated to the main data. It may or may not be indicative of performance. But my goodness can it show some interesting things…..those things just may not mean anything.
One of the things about data-driven innovation is that it relies on what came before it. The longer the legacy of a particular innovation path stretches, the more built-in history that is inherited to future generations. As legacy is baked in, it becomes harder and harder to deviate from the paths previously laid out.
When your future paths become fixed, innovation turns into evolution. It’s the iPhone problem. At this point, all new versions of the iPhone are evolutions of what came before and not truly something different. Innovation continues to occur but there are more and more features and things that cannot be changed. It’s unlikely that the iPhone line will ever truly deviate from the path laid out over the past 10 years.
It is true that there are no truly original ideas in this world. Any new innovation will have some history but that history is different than direct legacy.
You can restart the process by taking a product with a legacy and stripping it back to day 1. Often this means splitting the product into two paths – one with legacy and one with an entirely new team, direction, and goals. This isn’t as easy as it sounds as many features have a built-in legacy that can pop up unexpectedly. But the attempt can often yield surprising results.
One thing that I’ve seen over and over in my career is that few people actually realize the ways their workplace is used across the business. It’s not uncommon for a real estate group to have a complete misconception of the day-to-day reality of a site they are about to run a project in. This isn’t to say they are operating without asking first but it’s just as common that managers at the site don’t realize it either.
Most of our perceptions about how an office is used come from anecdotal information. We experience a shortage of conference rooms on the occasions that we go looking for them or we think things are too loud because we do a lot of heads down work. It also comes from hearing about things that are going on – but the things people usually share are bad events. Most anecdotes around the office are the negatives.
The day-to-day reality of most offices is that everything runs smoothly. There’s usually enough desks for everyone. Most people can get a conference room when they need it. Most people make use of the work areas to be productive. The biggest risk in a workplace change is breaking the culture.
How does one actually learn how the workplace really works? The basic blocking and tackling that occurs in any other group: asking people. Surveys on how offices are used go a long way and systems to track usage data around desks/conference rooms/equipment. Blocking and tackling is most of the job in most areas and it’s just as true in real estate.
The biggest difference between real estate and other areas is that a workplace design isn’t going to change much from when it is implemented. That design is going to be in place for anywhere from 5 to 10 to 20 years depending on wear-and-tear. Planning too much around today can actually be a bad thing because the primary requirement of an office space is to be useful for years to come.
Quartz just published a phenomenal article titled Data shouldn’t drive all of your decisions. Go read it first because I can’t find a single thing I disagree with in it. It hits all of my favorite topics on innovation and decision making.
Go ahead, I’ll still be here after you finish reading it.
Done? Good! Because there’s some summary to unpack:
- When solving new problems, yesterday’s data isn’t going to give you the answers.
- Data is best used in story form, not in charts and tables.
- Just because most of the data says one thing, that doesn’t mean your conclusion won’t be something else entirely.
- Sometimes experience isn’t everything and can lead you down the wrong path.
I come across a lot of people who proudly proclaim that they are not “data people.” They avoid spreadsheets, they hate columns of numbers, and they claim to get confused easily amidst it all. I’m here to help them all understand – data is your friend and everyone is a data person.
Let’s start with a simple clarification about what “data” is. Data is simply information. It doesn’t have to be a million line spreadsheet, it can be the text of an email. Data is any recorded and referencable piece of information. That’s it. If you go through your email for the number of times you were asked a question, you are doing data analysis.
The common misunderstanding with data is that you need to know everything about Excel to be able to be a data person. Here there is a misunderstanding of the difference between raw data and formatted data. Anyone can work with formatted data but raw data is a different animal.
Raw data is that information which comes in that hasn’t been cleaned, checked, validated, or organized. This process of turning raw data into formatted data is not something that anyone should do. You have to understand the original intent of the data, understand relational data standards, and generally be comfortable inside of data tools. This is a specialized activity.
After the data is formatted, it’s now anyone’s to work with. At this point, working with data largely comes down to asking questions and using the data to answer those questions.
The basic skill set of many jobs can be boiled down to “knowing what questions to ask and getting the right answers.” Those answers may come from experience, reading tea leaves, interviewing other experts, or (most commonly) analyzing the data. If you know what questions to ask, you are 75% of the way to being good at working with data.
“Set it and forget it” is a popular saying on many late night infomercials. Take some new cooker, throw your food into it, push a few buttons and then a few hours later you have amazing gourmet meals with no effort. At least that’s the theory.
In the business world, many people have begun treating their algorithms the same way. They create these elaborate rules for metrics, benchmarking and scoring that will assess a thousand variables to come up with the perfect rank. The best will even apply the probability curves around the score that is generated. Today they may even give results that make sense.
Time is fickle. As time passes, conditions change. The rules that governed a process no longer apply because people begin moving back to cities or technologies change the way that work is done or home officing continues to pick up or local policies change the way that financials are calculated. Something always changes.
But this change is often not handled well in algorithms. Often, the team that builds them puts a pin in them and then moves on to the new shiny toy letting the old one run with no supervision. What this really means is that there is no one around to catch it when it stops returning valid answers. To a layperson it may seem like good numbers – everything worked, the data is all there, the results are consistent with what was previously calculated – yet now the answers are no longer statistically valid for some reason.
Shelf-life is a mandatory concept within the perishable food space. It should also be a concept within the data science space. Data can go stale over time much like algorithms can no longer be applicable.