The Value Of Screwing Around At Work
Why getting away with stuff is good for the soul, and good for the stock.
Everyone is probably familiar with Google’s 20% Project, where the company encourages employees to spend up to 20% of their time working on projects of their own choice, provided it could conceivably benefit the company in some way. This was a big deal when Google rolled it out in the early 2000’s, but although still going on, it has since largely faded from public discussion.
Detractors point out that only 10% of employees take advantage of the program, and say it amounts to nothing more than advertising for Google and not really a ‘perk’. Maybe so. I will give Google the benefit of the doubt (if not credit) on this one though because I like the idea of letting employees have some freedom to be creative.
But let’s be clear here, this is not what I am exploring in this article. I am talking about screwing around.
As in: doing stuff your employer doesn’t know about, does not sanction, and doing it on company time, instead of what you are supposed to be doing.
Sound inadvisable? Unethical? Maybe even illegal? Well, in many situations it definitely could be. But I am about to argue that a certain amount of screwing around is not only beneficial to you and your mental health, but to your company’s bottom line.
Breaking Into The Time Vault
Back in 1993, I was working as an engineer for Digital Equipment Corporation in their Maynard, Massachusetts headquarters. This was a 19th-century woolen mill that originally made blankets for the civil war, but had since the 1950’s been the home of Digital, which at this point in time was the #2 computer company in the world.
The Mill was a labyrinthian complex of over a dozen buildings, interconnected by a crazy system of tunnels and catwalks and haphazardly enclosing over one million square feet of office space. In short, a great place to screw around, when we were not otherwise busy designing the companies new Alpha workstation computers. Our small team of perhaps six people had been moved into an oddly-shaped, temporary office space that had been shoehorned between two elevated walkways spanning other buildings.
The area had not been used in some time, but was very spacious for the small group we had there. Just before moving in, one of my coworkers did the math on how many cubes we would need, and finding one extra, decided (without asking any permission) to remove a wall from the row, and then re-distribute the other walls to make everyone’s cube bigger. We ended up with these enormous, 10x20 foot cubicles that allowed each of us to have a little seating area. I put in a little round table and chairs in mine and called it my “breakfast nook”.
When our boss showed up in the new area after his vacation, he was puzzled why we were one cube short on the row. When we fessed up, he was kind of mad, but mostly because he was worried about how our group’s giant luxury cubicles would look to other engineers in other areas with smaller cubes. He let it slide though, and for that short time there, I was in the largest work office I ever had or will have — even my home office now is smaller.
In this area there was a curious, tin-plated metal door. Very old and painted over, seemingly going to nowhere. When we peered out the window next to the door, we could see that there was actually this little round turret of a building, protruding like a wart off of the main structure. Note: I searched high and low for an exterior photo of this, and the 1918 shot above I believe actually shows this turret, in the (faintly) circled red.
The door was locked. But curiosity wins out over locks more often than you would think, and in this case the door jamb and door were separated by a gap large enough to get a paper clip into, releasing the latch. We opened the heavy door, there were literal cobwebs to clear away before we could find a switch, and to our surprise, the single bare bulb it was connected to came to life.
Inside was an abandoned workshop of sorts, untouched for decades. Dusty blueprints for the vast complex lay on tables, interspersed with a small assortment of tools. The most notable objects in this room however were time clocks — dozens of them, stacked up in forgotten piles on tables and the floor. They had apparently been used back in the days when the Mill was a manufacturing site, machines for tracking the punching in and out of factory workers to regulate and track their hours and pay.
We didn’t take anything and left the room as we found it (although I was tempted to keep a page of Mill blueprints as a souvenir.) But I continued to think about all these time clocks, sitting there in what we would now refer to as “The Time Vault”. These machines were symbolic of a shift from the manufacturing age to the information age, timekeepers from a bygone time of timekeeping.
Engineering and business offices replaced manufacturing space as Digital grew through the 1950’s and 1960’s, and at some point, the punch clocks from those spaces ended up in this room, which perhaps should have been called a crypt instead of a vault, given they would never be brought to life again.
Are You Worth Your Salt?
It got me thinking (possibly while drinking coffee in my breakfast nook) about what luxuries I was enjoying compared to the previous employees of the building, and how no one now was really tracking my time at all. The idea that you could base someone’s pay on the work done as opposed to the hours spent doing it was of course not really all that new - salary as a concept having been around since before Roman times.
The word Salary is thought to be derived from the Latin “Salarium”, or salt - and in some theories anyway, this linked it to the payment of Roman soldiers. (Why you would want to be paid in salt is not clear to me - but a few bowls of popcorn without any might convince me otherwise)
This also relates to the expression “worth your salt”, meaning what you do is actually worth what you are paid. This is an old expression and hints at the idea that maybe employees can be measured by their output, rather than the exact measure of how long they work.
The information age had only made the work/time relationship even more decoupled, rendering clocks a useless instrument of measurement. Employee productivity now can’t always be measured or predicted by hours worked — there can be people who hang around the office at all hours but are useless, and also people who work erratic hours, clown around at times instead of working, but who were highly productive and star players nonetheless.
In the process of creating these new types of jobs, it feels like we crossed some Rubicon (another Roman reference, as it turns out) to a place where spending a certain amount of time at work not working is actually valuable, because it keeps the productive people happier. And the tech world definitely noticed the phenomenon.
This is where the game rooms and sleep pods and 20% time came rolling in, and while I guess it is a good acknowledgment from tech employers that time is not always money, these perks always felt a bit forced and controlling to me. Goofing off (in my opinion anyway) is something that needs to be organic, spontaneous, employee-driven, and by definition, not regulated.
Og and the Blueberry Bush
I know what you might be thinking. Here’s this guy who is obviously privileged enough to work in an environment where his time is not tracked, unlike most of the regular working world. And as if that isn’t enough, he’s advocating for the right to fool around instead of work!
I get that there are many jobs that simply cannot allow people to randomly mess about instead of working. There are jobs with safety aspects that prohibit it - airline pilots, crossing guards. Also, in many, many jobs, there is a more direct correlation between hours spent actually working and output. Factory line workers, delivery people, painters. These are examples of jobs where productivity tends to be more linear with time spent “on the clock”, and it is very easy to see why not spending paid time at the job would be frowned upon.
It is hard though for people managing things to really come to terms with jobs where productivity is non-linear. I imagine a scenario where there is this caveman named Og, who is sent out one day to collect blueberries for the clan. Og didn’t get a good night's sleep - I don’t know why, maybe howling wolves or something - but he does his best even if tired, and after a full day of picking, comes back with a modest but acceptable share of berries for his clan.
The next day, Og is sent out to hunt. He’s still tired and not in the mood for hunting, so he jumps in the river, swims around, then proceeds to fall asleep in the sun on the river bank. When he awakes he is refreshed but it is dusk, and he has not accomplished anything. But as he gets up to leave, he spots a deer bounding from the river, and with the full might of his rested body, hurls his spear at it, killing it instantly. He arrives back in camp with a bounty, and all are happy with him.
So which Og was the better employee? Is it Day One Og, who put in a full day’s work even though he was tired, and came home with a modest dinner? Or Day Two Og, who in spite of slacking off, managed to come home with a feast? From the perspective of another clan member, they may likely favor Day Two Og, under the ends-justify-the-means principle (and also, the BBQ for dinner principle).
In reality, Og was able to bring home dinner on both days, first when working in a linear-productivity job, and then again in a non-linear one on day two. Many of you I suspect though would say that Day Two Og was mostly the beneficiary of luck, because it is not every day a deer will be right in front of you after you wake up from your during-work nap.
If it is just the one day of hunting we were talking about, I would tend to agree with you. But work is not a single-day event, and the trouble with the evaluation of Og, for either job, is that it is too short to be meaningful. What if Day One Og had fallen asleep while foraging for blueberries? He might come home empty-handed, and be fired from his blueberry job, beaten with a stick, or whatever cavemen do to discipline employees.
But say Og was part of a more enlightened clan, who overlooked his shortcoming that day, and had him keep at it? Maybe Og would catch up on his sleep, and be a lot more motivated and productive the rest of the week. Maybe he would be happier, and he might do better at it. Maybe he would take his friends picking, and make a game out of it, have fun and come back with a haul, every day.
There will always be differences between jobs regarding what amount of “screwing around” can be tolerated. Some jobs are more linear in terms of the time/output relationship, and some less. But I feel that even in a very linear job scenario like blueberry picker or factory worker, there is room for relaxation of the rules that dictate “time is money”.
It seems we constantly see companies missing this basic concept, that the short-term gains of measuring and controlling an employee’s time down to the hour or minute are more than offset by the longer-term losses incurred due to employee turnover, burnout, and lower overall morale and productivity. It is a trend that spans both the hourly-wage and salaried-employee worlds that even the supposedly egalitarian tech industry has fallen victim to. The recent shift to working from home has not really changed things much, either.
We’ve seen a rise in tattleware concerns, and also stories about anxious companies trying to usher their reluctant workers back to the office. The claim is always that innovation and productivity are increased when work is done in the office. Maybe that is true, and to be honest even the quality of screwing around is better when you have someone to do it with in person. But the likely biggest motivator for companies to get people back in from their homes is to regain control over employee time and productivity that is perceived to have been lost.
The Banana Calculus
Perhaps my Og story seems a bit too contrived, and you are not really buying the analogies there. I will make a parting attempt to further my argument then by returning to my Workstation engineering days at Digital’s Mill in Maynard, Massachusetts. It was certainly the case that breaking into areas of the building we were not authorized to be in and upsizing our offices were not the sum total of our “at-work-but-not-working” behaviors back then.
Because we were also writing a game, called ‘mpr’, which stands for ‘Multi-Player Rogue’. This was an X Window implementation of the classic rogue-like game, our version of which included a ridiculously detailed set of features, including flowing rivers, taverns with NPCs driven by state machines, and wands that could cause out-of-control forest fires. And I won’t sugar-coat it: A lot of work hours went into this one.
There was no particular plan to productize or sell this game, or even to share it beyond the three people who worked secretly on it all through the development of Digital’s first Alpha chip product, the DEC 3000 AXP Workstation. It was a labor of love, written for the sheer joy of creating it. And as such we would spend inordinate amounts of time on minor details, the most famous of which became known as “The Banana Calculus”.
This was a lot of complex math that had to be figured out in order to make speech bubbles that the characters on-screen had for dialog look good. In a typical comic book, the “tail” part of the bubble was curved, like a banana. But to have this created programmatically, it involved calculating two intersecting arcs of different radii, that are constrained to meet at a point where the character was.
We could have just used two straight lines and formed a triangle for the tail of the speech bubble. But no, that was not good enough for us, and the whiteboard discussions about the math of it all competed for space alongside various (actually work-related) hardware schematic drawings and plans. We got the math to work at some point though, and the speech bubbles looked gorgeous.
When I reflect back on this time, I don’t think I ever goofed off so much at work as then. Our boss was very hands-off, and DEC as a general culture was very liberal in its management style and allowed employees a wide latitude to do things how and when they wanted. (not 100% crediting DEC for being enlightened here, it was a lot to do with management not even being a focus at the company)
I would also say though of this time that I was never as dedicated to the success of something as this product, and probably never learned so much in such a short period of time as then.
My real job on the project was strictly a hardware engineering one, and my software skills prior to this consisted mostly of just BASIC programming. It was this secret game project that got me to learn about Unix, C, and GNU tools, and emacs, and a bunch of other useful things I would come to rely on greatly in the years to come.
The net benefit of the screwing around here was not limited to my personal development though. As it turned out, the newfound software skills I learned would come in handy immediately, because we ran into unexpected problems getting our printed circuit board assembly information into DEC’s manufacturing process.
The Alpha workstation group had been formed only a year prior, and had decided to use a new design flow featuring Unix-based, third-party tools, where previously things were always designed with internal VMS-based tools. This was pretty much considered internally to be Heresy, and did not mesh at all with the existing manufacturing software, and so we needed some data translators to be written to get things through from the Unix world to the VMS world.
By the book, this would have normally been a job for a centralized VMS CAD group that was responsible for the creation of many of the internal tools at DEC, but they did not understand much about Unix, and were very conservative and bureaucratic with schedules and estimates for creating new software for internal customers. The net result was, it was going to create a big delay for us. I realized at some point that the files that were missing from our flow were fairly simple, and in a pretty short span of time, wrote a couple of simple C command-line programs to produce the needed data formats.
Being a hardware engineer, this was definitely not in my job description. But the same freedoms that let me goof off and write games also allowed me to contribute a missing piece of code to our manufacturing process, the absence of which could have led to big schedule impacts for the product.
There is of course an element of luck that this problem even came my way, and was easy enough to solve with my fledgling C skills. But every once in a while, a deer really does show up down by the river, right in front of you.
In total, I think DEC also got all the missing hours back that I was not working anyway, because I ended up putting a ridiculous amount of overtime in on one of the follow-up Alpha workstation projects I have written about before. I like to think that they just spent capital they had earned from the past, in the form of allowing engineers to do things their own way.
In summary then, I am not sure it is right to universally endorse screwing around at work. But there are bananas out there that need to be calculated, and blueberry bushes that need sleeping under. Sometimes, doing those kinds of things is just what you need, to be the best employee you can be!
Explore Further
Next Time: What happened when I found a 40-year old program I wrote as a teen stuck in an old magazine, and tried to resurrect it. Of TRS-80 and Tardigrades coming up in the first installment of: The Dead Code Diaries
Sorry to interrupt your not-working at work, but have you considered subscribing to the Mad Ned Memo? You’ll receive weekly posts from the nerdy world of computer engineering and technology -- past, present, and future. (check the link for a sample of past articles). The Mad Ned Memo is cost-free and ad-free, and you can unsubscribe at any time!
The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.