The tent in the office

A few weeks ago, I was in Richmond, VA chatting with my Uber driver on the drive back to the airport. She asked where I was from, and upon hearing SF she brought up the latest news from our city that had apparently made it across the country—the ban on plastic straws. 

Every ban has two sides, and the interesting thing about this ban is who is speaking up against it most compellingly. Here it's not a big company that makes plastic straws, it's people with disabilities who need straws in order to consume liquids. This use case was not in my awareness before I saw it in the news, and it likely wasn't for most people who supported the ban. My surprise reminded me of how people react when I talk about my appreciation for the tent in the office.


If you walk into the Instabase office, one of the first things you'll notice is the tent pitched in a walled-off corner. When one of my friends came to interview, he had already heard about it from a VC. The tent blends into the fabric of the office when you see it every day. I have lost my beginner’s eyes, so I observe the reactions of visitors. Some are repulsed; others see it as a sign of a committed team. Yes, it's occasionally used for crashing, and that is the most obvious meaning and utility of the tent. That’s not why I use it or love that we have it. 


On a Wednesday morning a few months ago, I was scheduled to give an onsite interview. I realized shortly after I woke up I was probably not going to make it. My period had started, which meant in a few hours I was likely to have bad cramps. I pinged the two other people who were available to cover, and luckily one of them was awake and free.

Based on talking to friends, I'm guessing my pain is on the higher end of the spectrum. Painkillers tend to reduce but not get the pain down to a level where I can be productive, and based on experience my cramps continue until I either take a nap or fake it by lying down extremely still for one to two hours. The good thing is there’s a straightforward solution. I just need a spot to lie down. In the age of open offices, though, this can be surprisingly tough.

At the start of my career, I spent four years at big companies where my periods led me to discover how much of a privacy desert an open office is. At my first job (at a company I overwhelmingly feel grateful to), there were nap rooms, not to mention nursing mothers’ rooms, but they were perpetually occupied—demand exceeded supply. When I lived close by in Menlo Park, I would cab or Uber home. Later I moved to SF, and that ride became a more painful and expensive proposition, so I stuck to the office. I would walk a few buildings over from where I worked so people wouldn’t recognize me, and lie on a couch in a small living area between two clusters of desks. It was exposed, next to a busy walkway. I was a bit embarrassed, but it was the best option I found.

I became curious how other women were dealing and posted in an internal women's group to ask. I saw a range of responses, from sympathy from people who experience less discomfort, to stories from other women who sought spaces to rest. One woman said she had trouble finding places to lie down during her pregnancy, so she would go to the parking lot and lie down in the trunk of her SUV.

As much as it's judged and possibly ridiculed, the tent at the office is the most available space I've encountered in my working life when I need to lie down. It's private, yet not entirely secluded, so I can hear what's going on in the rest of the room and even respond. From an engineering/product standpoint—how well it solves the problem, cost, mobility, ease of deployment—a tent is a great solution for our tiny but fast-growing startup.

The tent solves one of the two uncomfortable parts of my experience with period pain—the space to rest. The other part is talking about it when it throws randomness into my schedule. It has always been a weird topic to bring up to my managers, especially as only one of the ten I’ve had has been a woman. But I recognize it’s primarily weird because it’s not usual; I bet there was a time when being a nursing mother was weird to talk about, but nowadays mothers' rooms seem a normal fixture of offices. 


The main reason I wanted to write this post is, well, the plastic straw business reminded me about it. The tent is my plastic straw. In the bigger picture, this is one issue that highlights to me what it means to have and support diversity in the workplace. I have nothing to add to the broad strokes in the dialogue about diversity, but I can help fill in the details of what that concretely means in the office. It's in the mundane details and crevasses of everyday working life that we all can shed more light. 

The Oncall Conundrum, and thoughts on the heroic last-minute push

I have never met a software engineer who liked being oncall. It makes sense: we're used to flexible hours and working conditions—we don't show up for a shift, aren't usually tied to a location—and the most glorified and interesting parts of the job typically happen in deep flow, while building things. Being oncall violates all these terms. You are on the hook for a fixed period, you can't go off into the woods and your plans may be interrupted at any time, and when shit happens, you're stressed and maybe sleep-deprived and you're not building—you're debugging and doing damage control. Your actions feel like short-term hacks, and you know you're going to have to actually clean things up later. Add on top of this: when an incident happens at night, often you are alone, you feel bad for waking other people up, and you may end up hunting around in systems you don't really understand, seeking out outdated half-done documentation. It's a special loneliness.

Some of the worst oncall situations I've been in occurred on the ads team at Pinterest. I described it to some people as feeling like being thrown in a meat grinder—I knew I'd get chewed up by the machines. Of course, the one most memorable experience was caused by my own work, which left a painful but deeply-ingrained lesson. (Long story short: I had to work around a flaw in my new metrics workflows by staying up all night, refreshing pages and clicking buttons every 20-30 minutes. That or else advertisers wouldn't get their metrics, which sounds relatively benign, but is your whole point of view when you are working on ads data.) But when the fires are due to systems you didn't build, especially large ones that will take a long time to fix, that can cause a lot of frustration and loss of morale. 

Perhaps this is why, when Li Fan first joined Pinterest as its head of engineering and the company held an eng all-hands, I remember only one question from the Q&A. Someone stood up and said: I think being oncall is one of the most under-appreciated tasks. You may stay up all night keeping the site up, yet this stuff gets little visibility and recognition. What are you going to do about this? 

I'm going to guess fundamentally not much has changed, and not because of her or Pinterest. It has taken me the past five years of experience to realize this. It's because the issue is tricky: you want to praise the motivation and raw effort that goes into great firefighting, but you also want to recognize firefighting as a failure case: "Thanks for doing this work, but this work should ideally not exist." You don't want to create perverse incentives by explicitly rewarding firefighting, otherwise people will be incentivized to set fires or ignore preventative measures. On the other hand, the human effort and individual sacrifice involved in firefighting is inordinate compared to other parts of the job. Unlike literal firefighters, software engineers who are oncall do not consider firefighting their primary responsibility. It's usually the activity that takes away from the parts of the job that they are hired and recognized for. Thus the conundrum.

The best thing to do, of course, is to decrease the amount of firefighting needed. One thing I've never seen tracked at any company I've worked at is the number of hours spent firefighting. At least, as an oncall, I have never reported it or been asked. Measuring has to be the first step. Then surfacing it, e.g. in managers' team health reports.

But no matter what, something will always happen. One thing that could improve how oncalls feel is to give explicit time off for people who do end up fighting fires at odd hours: i.e. something like, "if you fought a fire last night, don't come in the next day." This seems obvious, but I have never heard this policy articulated at any company I've worked at. I think it should be time off immediately after the event, so the intent is clear: to help people recover (and so people wouldn't be motivated by getting extra flex vacation days). One concern is then: but what if I have commitments the next day and have to come in anyway? One way to mitigate this is to plan ahead of time: don't have people who have time-sensitive commitments be oncall close to their deadlines. (I find that when I think about people things, often I end up with some version of "talk about it" and "do better planning.") 

There are bound to be places where the constraints are too hard and the above approaches can't work, like if there are deadlines and fires all the time. If that's you... you may work at a startup.

I now work at a startup where the flavor of oncall issues are currently less fire-this-moment, more customer-support oriented (though this is not to say there are no drop-everything fires). They also typically happen during business hours (which does not mean just US or SF business hours). The point being that oncall has actually not really been top-of-mind. At this SaaS company it does feel like part of the job.

I was thinking about the oncall mentality recently because of a pattern I've seen across my whole career, though it's more pronounced in smaller companies: the heroic last-minute push to finish and ship a product. When you're participating in one of these, it's like a longer version of an oncall shift—you are often hammered for several days or longer. In January, there was one week where I worked sixteen hours a day for seven days straight. We stopped working shortly before our demo at 10pm on a Sunday (business hours in another time zone). At the end of one of these, you want to feel good about having put in the hard work. The tough thing is to step back and say, but really, ideally this should not have happened. And on a tiny team, you know it happened in part because of you.

It's actually easier to reflect on the meta-failure if you were part of the team in the sprint—you have more contextual information and the platform to self-criticize. As an observer, it's uncomfortable to say something because it might be perceived as taking away from the hard work that other people put in. Unlike oncall, where even the participants may easily admit that the work is better off being entirely mitigated, the participants in a product sprint are building something that should be meaningful and that they should want to feel good about. Invariably a discussion about the "how" of a product execution is tied up with people's feelings about their contributions. 

This is the lens through which I can understand the value of an explicit product manager, or even a project manager, at a small company that might perceive their biggest challenge as having enough hands on deck to build—there is someone whose craft is this meta, which makes it easier to talk about and critique this meta. A software engineer invites a discussion of code style, because it's part of their craft. A product or project manager invites us to talk about the craft of execution. 

[Daily] Saturday 2018.05.26 - Brain dump: a few things I learned this week, mostly about people

I learned a few things this week from two events and a new acquaintance. This is a brain dump of things that stuck.


== Work -> Coworkers -> Health ==
On Tuesday night I went to an event where Jeffrey Pfeffer, a Stanford Business professor, talked about his new book on the cost of modern management practices. His opening line: “According to the Mayo Clinic, the person you report to at work has a bigger impact on your health than your family doctor.” It's obvious when you think about how often we see doctors, but it's an unusual way to frame the people we work with: are they helping extend your life? That's a question to turn inwards to ask myself: am I helping extend the lives of my coworkers (or killing them faster)? It's also a responsibility I had never explicitly thought about.

One objection to measuring "well-being" at a company is that it's hard to measure. However, Jeffrey said a single self-reported 1-5 of “do I feel healthy” has been found to correlate to mortality. I.e. people roughly know whether they are healthy or not.

== You get what you screen for == 

Wednesday night, I attended a panel about mentorship that featured a mentor/mentee chain: Ken Coleman, Ben Horowitz, and Michel Feaster. The second half of the panel focused on diversity and inclusion (often shortened to d&i). People management lessons are best conveyed in stories, and Ben told two stories that stuck.

The first story was about a person named Chris they'd hired for a role that required being really good at making people like you. They had interviewed and passed on a number of people who were investment bankers (Ben joked that was probably not the ideal profession to be looking in) before considering alternative profiles. Chris used to work as a waiter at the Cheesecake Factory, where they rank waiters by their tip percentages. Chris had ranked #1 chain-wide in percentage tips, so he was a champion in a field where to be good, you have to be liked. Ben's points: 1) when hiring, are you defining what skills you actually need for the job? (notably Ben didn't stress the title of the job, rather the skills needed), and 2) are you then seeking out people with those skills in all possible places, including non-obvious ones?

Ben prefaced the second story with, "People at the firm don't like it when I tell this story, but I'll tell it anyway." He once asked a team that was all women, "What is it about your interview process that you can't hire any men?" The team responded that they screen for helpfulness. Ben could have taken this response in a number of ways—are no men helpful? this team must be crazy—but his observation was, hey, it's unusual to screen for helpfulness, and that is clearly making a material difference.

I remember this one statement by Ken: if you are discussing a candidate and can't identify their weaknesses, stop. You are probably missing something because everyone has weaknesses, and if you know about them upfront, you can manage around them.


== Words and connotations; Culture from office furniture ==

Yesterday, I met up with Jules W, whom I ran into at the a16z event. He's a product manager at Slack working on growth. During our conversation, he told two stories that gave me, "oh shit, I'd never thought of that" moments.

The first story is about words. At Slack, they did a few months of user research and found the most effective phrase to describe Slack to most new users was "collaboration hub." For the longest time, Stewart, the CEO, had opposed using the word "collaboration" because it's a fluffy, overused-to-the-point-of-meaningless word in Silicon Valley. But the Valley is not the rest of the country, where "collaboration" can be viewed quite positively, and the Valley already knows and uses Slack. Their research also found that people were confused by the word "tool," because people outside of tech don't really use "tool" to describe software and tend to think of physical objects. A "hub" captured the feeling of "tool" while illustrating the purpose. For me, that's something to chew on regarding the words we use to describe Instabase. Mind you, we have many other critical things to think about, but I had at least personally been operating with the mindset that an "operating system" sounds cool!

The second story was actually a statement. "Slack will never have a ping pong table." Why? He said, a ping pong table is fun for people who have looser schedules—which tend to be younger folks who don't have families. They can afford to take longer breaks, play matches, and make up for it by working late. People with more commitments outside of work can be conflicted, possibly feeling left out because they can't afford the breaks in the middle of the day. In general, Slack wants to foster a culture of "come to work, work hard and stay focused, then go home," because that culture tends to work for a wider range of people. And building that culture requires thinking about even the office furniture. I have thought about open offices and noise and distraction, but not about this particular second-order effect of fun things.

Environment and Compatibility

There's a certain kind of thinking that can only be done in coffeeshops in the morning. Or maybe there's a kind of thinking that's just hard to do in the office, where the environment envelops me in a sense of duty. This morning, I picked up coffee to-go and came into the office early, falling back to what I've been doing my whole short career. There's still no one here, but the first hour and half became responding to emails and ticking off boxes, the type of things I can do in the minutes before bed. This small experience shows to me the impact of environment—even four walls with connotations, no people around, can do this. I've now put on Dave Brubeck and Coffitivity, which helps.

This reminds me of a related topic, that over the years I've come to believe a similar thing about jobs as relationships. W.r.t relationships, I have lost most of the inhibition to make the first move, because rejection does not hurt much anymore. (It will always hurt some.) This is ironically an outcome of being in several relationships (and other not-quite-relationships) that didn't work out, which made me realize that modern-day compatibility is incredibly hard and rare to find, and failure is not explicitly the fault of either of the two parties. Modern-day compatibility is strongly based on individual tastes. If someone rejects me, it's not my fault for not being attractive enough or their fault for not finding me attractive. As much as we like to think we are in control of ourselves, we can't force what we respond to, or on the flip side, dramatically change our personalities. It's in fact easier to change our looks.

Jobs are fit to a personality as well, which is often talked about in terms of entire professions, or big companies versus small companies. What I've seen is that even subtle differences among very similar situations make a big difference in how effective the same person is. I can say that for myself. I felt that at Facebook v. Pinterest, which are on the surface two large social networking companies, but the difference was more pronounced in tiny companies. After leaving 13-person Chorus, I felt I couldn't make a decision on another startup without working at them first, so I did brief contracting with four companies (sizes: 5, 13, 10-20, 4) before joining Instabase (4). It was surprising to me how at certain places, I felt—and I think, was—much more effective than at others. Same person, different types of work, different coworkers and company structures, different styles of communication.

I keep this in mind when recruiting. It makes me more empathetic when things don't work out, and makes me realize the resume and even pure technical interview is only a slice of what makes someone successful at a particular place. More broadly, I hope this mindset will become more common, so people do not view either being rejected in a relationship or being rejected by a company as categorical value judgements or measures of their self-worth. As with finding a fulfilling relationship, finding a fulfilling job is hard, and you should expect to fail a few times and get better at it over time.