What goes around comes back as an app

What goes around comes back as an app

Lessons from early Business Anthropologists

At the start of the 1920s, factory owners realized that improving the workplace might make disgruntled workers more gruntled, less unionized, and more productive. In trying to figure out what a ‘better’ workplace look like, factory owners’ research notes probably went something like this:

10 am: I’ve been watching my employees like a hawk since raising the overhead lights to sun-like levels. Productivity is through the roof.

11 am: Decided to go the other way with it. Turned the lights way down to speakeasy level. Productivity still through the roof. 

In 1924 when factory owners couldn’t figure out what was happening, they hired researchers to study the Hawthorne Works Factory to determine how the environment affects productivity. I imagine their notes read:

10 am: Sealed four workers in a mock production room. Have given them 7up and Charleston Chews, a 5 min break every hour, and a Buffalo Nickel for every extra Hawthorne Wipe Packet that comes off the production line over the hourly quota. Production is through the roof.

12 am: Took away the 7up and Charleston Chews.

3 pm: Haven’t given them a break in 5 hours.

4 pm: No more Buffalo Nickels.

5 pm: Production still through the roof. 

When looking back at the clumsy start to the field of Business Anthropology, we can now say: We know that when factory workers are watched by a supervisor, their production goes up. In other words: observation of a subject affects the outcome. By any other name, the Hawthorne effect.

As product managers, when looking to create a mobile application we must take this lesson and look for the moments when we divide users into different groups, altering the observable need for an app.

Intended Use V. Expected Use

My former workplace recently implemented a clock in/clock out the app for nonexempt employees. Along with the implementation of the app, the formula for exemption status also changed, skewing more towards supervisors and higher paid employees. This app was to be used simultaneously with separate time tracking apps and proved to be an extra burden on non-exempt employees. With no shared value the app set a dynamic between two sets of users. The supervisors were not using the app the way their employees were and therefore were not privy to the knowledge shared among non-exempt users to bypass the app in order to clock in remotely. This behavior, in turn, gives supervisors an inaccurate view of their employees.

When Shockoe develops an app, we study different user groups, anticipate different use cases, and instead of mandating specific app use, seek to capitalize on shared goals.  

Imposed Goals V. Shared Goals

Let me brag about my team for a minute. My coworkers at Shockoe are creating an app for a major trucking company. Unlike the aforementioned app, this app accounts for the unpredictability that comes naturally when humans are working and interacting with customers. Instead of using time tracking strictly for managerial oversight, this app utilizes it to streamline communication between supervisor and trucker, ultimately acting as a support system for both. A package goes missing?  A delay on the highway? The trucker can immediately report via the app, the supervisor can take immediate action to communicate with customers. The trucker’s goal of getting home and the manager’s goal of heading off problems at the pass can both be satisfied. With a shared goal, both users benefit from the use of the app.

Ultimately productivity applications should seek to create a more cohesive culture by acknowledging expected use cases among different sets of users. As we learned from the early days of business anthropology, altering group dynamics and creating two different groups of users can alter observable results. For us today that can mean an inconsistent corporate culture and poor app performance.