Slack is Jackin' with My Zone

Technology Leadership Devs Output

This one is off-topic for me for this site, but it's something I've been thinking a lot about, in one form or another, for many years. With the COVID-19 lockdown helping companies finally get their heads out of their collective asses and allow people to work remotely, it only became more pronounced. That, coupled with the fact that my current role means I don't actually write any code anymore, this topic is a bit more relevant and close to my heart at the moment than, say, cache layers and graph databases.

First off, I make a hard distinction between "manager" and "leader", though I know few organizations seem to. The distinction, for me, is simple: you can get promoted to the role of manager, but leadership is a trait, and something you have to earn. People report to a manager, who performs the act of managing their work or their career or what-have-you, whereas people follow a leader, who inspires them to do a certain thing or think a certain way. Nobody talks about what a great manager Martin Luther King Jr was.

It gets fuzzy when organizations talk about managers as "people leaders". I think it's a nicer term than "person who doesn't do shit, but is somehow responsible for the people who do". Alas, I think that's my place on the corporate ladder now, too. I work hard at continuing to develop my leadership skills, too, because I think that the best managers are also great leaders, but you'd have to ask others how well I stack up there. Regardless, within my role, I have two main responsibilities and priorities: talent and enablement.

Years and years ago, when I worked at and became a Manager at Netflix, my boss told me: "now that you're a manager, your primary responsibility is talent acquisition. Your secondary responsibility is talent acquisition. After that, you can do your regular job" (thanks, Caitlin, you were right!). It's that mentality that has, for well more than a decade now, been the foundational reason that that company continues to boast incredible waves of talent, and in turn, the incredible results they've accomplished. I intentionally called out this priority as "talent", not as "talent acquisition", though, because acquiring talent is only part of the equation; retaining talent is the other. The two are intertwined: if you can acquire great talent, talented people tend to push one another, and accomplish amazing things together, so it becomes a bit of a self-fulfilling prophecy, but there is more to it than just finding a bunch of smart kids and throwing them into a room together and hoping they build cool shit. There are inevitably competing egos, competitions, personalities that don't always align, different career goals, differing opinions on what needs to be, when and why, amongst a myriad of other challenges that inevitably exist whenever a group of people congregate or work together. But this post isn't about any of that, either (I know, get to the point already!). Rather, I simply can't say "I have two main responsibilities and priorities: talent and enablement" and then not mention one of them.

What I actually want to focus on here is enabling talent to be as effective as they can be, and specifically, one interesting component of this, which is how a certain class of applications intended to make collaboration easier can be detrimental to fully realized effectiveness and output.

Everyone in tech knows who Joel Spolsky is, even if not by name. He's one of the original creators of Excel (back when it wasn't a confusing pile of unnecessary features that hide what everyone wants), and more importantly in this day and age, the founder of Stack Overflow. He's also written so many amazing blog posts over multiple decades, most of which are still incredibly relevant. One of them, which is now twenty years old, is entitled "12 Steps to Better Code", which includes one section (#8) around how to help developers get in "the zone" and stay there. [FINALLY] That is the topic of this post.

I talk about this a lot with my teams, and my teams are always technical. I mention that only to put some guard rails on what I'm talking about here. I won't pretend to speak to other professions, because I've not managed (or led) them before, but I do imagine that other creative positions are the same, so there's that.

All right, let's take a quick step back in time to see how it is we got to this one-size-fits-all work day, that, by the way, doesn't work. My entire professional life, like that of my parents, and in America dating back to 1937, when it became the Fair Labor Standards Act (29 U.S. Code Chapter 8), has been an eight hour work day, and usually something that starts around 9 AM and ends around 5 PM. Now, don't get me wrong, the eight hour work day is a phenomenal thing for people who were otherwise being exploited. The movement to get laws put into place were done to protect workers, and specifically factory workers during the industrial revolution, when employers were abusing their employees and forcing them to work 12/14/16 hour days building widgets. I can't even imagine what a shit life that must have been. I envision myself, back in 1880, standing on an assembly line on a factory floor, inspecting some component of a steam engine, next to some ten year old doing the same (times being as they were, child labor laws hadn't been enacted yet, either), and being subjected day after day to the conversation of "so...what's your fourth favorite dinosaur?".

So eight hour days become a thing, and why eight? Not sure it was the driver, but it's certainly curious, at least, that 24 is equally divisible by 8, so factories get 24 hour coverage in equal chunks. And, like other jobs where the work is incredibly repetitive (such as order entry), it makes sense on the surface. If you can sew 1000 eyeballs on teddy bears in an hour, we can reasonably expect a day's output to be 8000 eyeballs. Now, it's 2020 and I suspect most things that are that repetitive have been automated, but you get the point. For things that aren't as repetitive as eyeball-sewing, like the work that practically all other "skilled workers" do (horrible term, sorry about the inference, but I don't have a different one), there simply doesn't exist the hours-to-eyeballs ratio. It certainly doesn't translate to lines of code (LoC), nor should it (for many reasons, from focusing on minimizing LoC to the fact that experienced devs often accomplish the same task as juniors will with significantly less LoC). Engineers are creatives. They like building stuff. Probably, it's why they went into technology: to create cool stuff out of nothing. They always like problem solving, often getting more excited the hairier the problem is. And, of course, you can't make some bullshit linear equation between hours worked and problems solved.

But here's the thing: in order to solve these problems and build these solutions and do this amazing job that is software engineering, it really helps to be "in the zone". I talk sometimes to my Junior Devs about that, and frankly, most haven't experienced it yet, or if they have, it's fleeting. When a software engineer gets to that point in their career when they can work independently, "the zone" becomes a real thing, and as they get more experienced, they find it more often, and learn how to stay in it longer. The human mind is like RAM, and it can hold thousands of little details at the ready, and when that engineer has their noise cancelling Bose headphones on, and they're blocking out the world, they're making mental notes of little snippets to come back to, how to get around hurdles, nuances of deployments, sections they want to convert into classes later, adding a function here because it'll be reusable there, and thousands of other little details. The human mind is an incredible computer. And when an engineer finds themselves in this magical land called "the zone", time stands still. Music plays through the headphones as an unnoticed backdrop, and thoughts flow through your fingers as they dance on your keyboard and produce absolutely incredible output.

Until you hear the knock-knock-knock of a Slack message.

And this is really the point that Spolsky was making twenty years ago in his post. If you want to make your engineers really, really effective, give them offices, and put doors on those offices. From an architectural and design perspective, I love the modern day, industrial, open spaces that are currently the rage of technology companies. They're fun to go into and they look amazing. Too bad they stifle technology efficiency and the effectiveness of software engineers. Sure, the noise cancelling headphones are still a thing, but when you and I are both in the former rubber factory, super cool industrial startup space, sitting across the reclaimed boatwood table that serves as a first-come-first-serve community desk, headphones-on, and we're both in the zone, and I can't think of the function to get the index value when I loop through a list, so I pull the headphones off, staring at you (the tech signal for "I'm about to interrupt you"), and you take yours off and say "enumerate" like I've forgotten the name of my first born, what just happened? You saved me thirty seconds of Google time. I cost you twenty minutes, because I just took you out of the zone, and totally jacked with your mental RAM. Oops, sorry, but at least you saved me a few seconds.

Stick with me for a second here, and don't take this the wrong way, but if I had to put a finger on something valuable that came from COVID-19, it's that companies had to get with the program. Again, I'm speaking specifically for tech here, but really, it's not tech companies so much as it is tech positions, there was no reason before 2020 that folks in these jobs weren't able to work remotely, except that companies didn't give a shit about their employees enough to do their due diligence in setting it up, writing the policies (after all, if we didn't have formal policies, we'd all be stuck using common sense), and generally taking the small leap (and it was, or these archaic organizations that take months to order a new printer wouldn't have been able to enable it in days or weeks when not doing so would impact their bottom line), but let's be honest here, most of those companies are still clinging to 9 to 5 schedules, too.

Thus, COVID-19 forced us to give devs offices. With doors. They might not have been physical offices (I recognize most people don't just have an extra room sitting around idle, especially if both partners or an entire flat of people suddenly find themselves working from home), but at least you don't have me taking off my headphones to ask about enumerate. So we accidentally introduced the ability to increase output, and that is so incredibly powerful. But we were already, and became suddenly more reliant on messaging software applications/team collaboration software/chat tools/whatever you want to call them. Slack became viewed as EVEN MORE IMPORTANT (I suspect it was already the most used technology in every tech company), and that perception of reliance (not the software itself), killed the accidental gains.

NOTE: I'm using Slack herein as the de facto messaging and collaboration application, both because it's what we use and because it's the most common and fully featured one out there. Make no mistake, if we didn't have Slack, we'd be screwed. I love it. But it doesn't change the point I'm meanderingly trying to make here, and you could substitute any of their competitors or alternatives as a replacement and it doesn't change the point I'm trying to make.

Whereas you used to have to catch my gaze to know I needed you to mentally-google-that-for-me, or I had to *gasp* get off my lazy ass, walk over and tap you on the shoulder (and by that time, I might as well have command-tabbed over to my open Chrome session anyway and just searched myself), now I can just type it out in a twitter-sized message and ask anyone and everyone, and see who wants to race to help. And there are shared channels, where @here pings us all, and random memes that Larry in accounting thought we should all see, and Nikhil posting a picture of his aloe plant and Sarah just announcing that she's headed to In-n-Out Burger, followed by half the company discussing the "secret menu" there. And none of these little zone-killers are even the professional ones, where Jamie is asking about a pull request or Tyrone wondering if anyone noticed that the test environment database is down.

In a distributed workforce world, these team collaboration applications are a godsend. Not only do they give us a virtual office, where we can work together without having to be on a video call for every five second interaction, but they actually help to build team unity. It actually is important to know how proud Nikhil is of his aloe plant, and it's fun to chat about the secret In-n-Out menu and the like. So we need Slack to help stave off depression (these applications help with inclusion), they help build team unity (yeah, Larry, I'll admit, that last meme bordered on humor, at least), and they are absolutely indispensable when it comes to professional collaboration.

But my other responsibility (see, these ramblings occasionally come back to point) is enabling folks to be effective, which is to say, enabling them to sew as many proverbial eyeballs onto teddy bears as possible. And for creatives, that means helping people to get in the zone, and stay in the zone. COVID-19 helped with the former, by giving us all offices with doors, but our perceived reliance of the constant nature of our messaging collaboration software risks taking it all away, which is why we (my teams) are making a conscious effort to turn off Slack when we need to get in the zone. I don't have a good how yet. I think it's a bunch of little things; maybe one of those little emojis next to your name. Right now my devs will post a message to a shared channel saying they are going "off-line" to get in the zone. "Off-line", ironically, equates to "being online but just shutting down Slack", but you get it. The point is, you can't be in the zone and be interrupted constantly, and Slack is a constant interruption. And you don't get to pick the time when the zone calls you. You can't turn it at 9 AM. Sometimes it comes to you at 9 PM. Sometimes it doesn't come for days. You have to create and promote an environment where you can encourage the zone, and try to keep people in it for longer, and we do that, in large part, by promoting these little hints and practices that eliminate the interruptions that are zone killers.

sewing eyeballs

So, I don't ask my devs to start at 9, and I don't ask them to shut it down at 5. I ask them to have some middle-of-the-day overlap (10:15 is standup, we try not to schedule anything before then, and we consciously try and not have too many standing meetings at all), but that's the funny thing: I know folks won't be in the zone during those overlap hours. Those are collaboration times. Sure, work gets done during those times, of course. Really important work. Just not the types of work that require creatives to shut the world out. Not the type of work that requires being in the zone. We've got Juniors that need a bit more support. They can be assured to get it during these overlap times. More seasoned devs get vital collaboration time. When meetings do need to exist, they should happen during these overlap times. Almost the entire company, tech and beyond, is on during these times, so it's super important to get that face-time, collaborate, interact, talk about aloe plants, share stories and work with one another.

I encourage people first to remember life before work: your work would replace you in a week if you dropped dead. That's business. We want to create a healthy work place and fuel your professional passions, because optimizing for the professional passions that we hired you for equates to output, which equates to profits, and in exchange for that output we give you money to fulfill your personal passions.

In order for us to optimize that output, I have a responsibility to acquire talent (folks capable of creating output), then enabling them to find satisfaction in their work (which leads to retention), which is accomplished by throwing petrol on the fire that is their professional passion (helping them to get into the zone and stay in the zone). I insist on some middle-of-the-day overlap (aids in collaboration and unity), but I don't worry about 8 hours days or forced working hours, because, you know, it's not 1900 any more.

And as a creative, when the brain starts to go to that magical place, even when you're working remotely, have a physical door you can shut, and still put the noise cancelling headphones on, embrace the zone and the incredible output it creates, and set yourself up to stay there as long as you can, by turning off all the distractions you can, including Slack, and in turn, I promise not to come over to your house to ask you about enumerate.

Categories: Technology, Leadership Tags: #output, #team, #slack