Menu

Posts tagged “productivity”

Deep Work and the power of attention

Craig Mod’s How I Got My Attention Back is one of those essays that I think will become a classic. It strikes that rare and difficult balance of talking about technology dependence without falling into the “ALL TECHNOLOGY BAD!” trap we often see in similar pieces. There’s so much that resonated with me, but this part in particular stood out:

The more I thought about my attention the more I thought about the limits to human scale. How technologies inevitably amplify ourselves — the best and worst parts — in a way that is almost impossible for us to comprehend. How that scale is so easily co-opted to attenuate our attention with the worst possible diet of high-sugar, high-carb nothingness.

I also appreciated the point he makes that as much as we tend to blame ourselves for being too “weak-willed” to give up Facebook or Twitter, we have to remember that there are thousands of people on the other side of that product who are trying to figure out new and innovative ways for us not to give it up. He quotes from Bianca Bosker’s Addicted to Your iPhone? You’re Not Alone:

“You could say that it’s my responsibility” to exert self-control when it comes to digital usage, he explains, “but that’s not acknowledging that there’s a thousand people on the other side of the screen whose job is to break down whatever responsibility I can maintain.” In short, we’ve lost control of our relationship with technology because technology has become better at controlling us.

I’ve had my own struggles with this over the past year as I dealt with a huge personal loss. In the end, my re-entry to a more sustainable online presence came from a very unlikely source: a book I would never have read if someone didn’t force me…

Our CEO sent us all a copy of Deep Work: Rules for Focused Success in a Distracted World and asked us to read it. I expected to snigger my way through it but boy, was I wrong. It is a fantastic plea for taking back our attention at work, and it provides some really useful guidelines on how to do that. For my part, the idea of “work blocks” is one I’ve taken to heart, and it’s done wonders for my productivity. I also bit the bullet on RescueTime, and it really is as good and useful as everyone says it is.

Work blocks

For more on work blocks and other non-digital productivity methods, check out Chris Bowler’s excellent resource on Working with Pen & Paper.

So I guess my one recommendation is, read Deep Work. Even if (or maybe especially if?) you don’t usually like business books. You won’t be disappointed.

Effective product management for remote teams

A few months ago I wrote a post about how we build a product vision and roadmap for Postmark. It’s now almost 6 months later, and I just published a big post on the Postmark blog about how things are going. From roadmap to shipping: effective product management for remote teams is about how we moved from vision to execution, and how we dealt with the many challenges that remote teams bring to the equation. For example, on communication:

As a remote team we have to walk a fine line between working in private and working in public. We see this as a basic sine wave, where balance is extremely important. Work in private too much and you become silo’d and isolated. Work in public too much and it gets distracting for the rest of the team (and you never get time to focus). So we ran with the sine wave metaphor to create a diagram that outlines our ideal approach to private/public working and how we gather feedback.

You can view the post to see this diagram as well as a bunch of other topics:

  • How we made the transition from an exciting grand vision to the daily grind of working on projects and features to make that vision a reality.
  • What tools we decided to use on a day-to-day basis to keep everything running smoothly — and how our use of these tools evolved over time.
  • The challenges and opportunities of being a (mostly) remote team, and how we try to make sure we communicate enough without overdoing it.
  • Some remaining challenges we haven’t quite figured out yet.

Product Management is, at its core, a multi-tasking role

Giff Constable writes about The difference between design and product management and makes this good point about the nature of the PM role:

A big difference is where they spend their time. You’ll hear me call design and engineering “deep dive” roles, while PM is a multi-tasking role, which is why it is relatively easier for PMs to assume more of a leadership role. Even though we work in very collaborative ways (“rough draft culture”) at Axial, both design and engineering require getting into a “flow state” on a problem. Design takes a lot of iteration and trial and error to get something right. PMs, on the other hand, are bouncing around a million tasks, from clarifying a user story, to managing communication inside and outside the organization, to doing whatever it takes to un-bottleneck the team, to all the things listed above.

This is one of the things that makes Product Management such a challenging role. It’s not just about switching tasks, it’s about developing the ability to switch focus really quickly as well. There is no time to meander from one task to the next. Once you switch to the next thing you have to be in it right away.

Useful daily standup meetings for remote teams

As with many distributed teams our approach to tools at Wildbit is to try to strike a balance between making sure everyone on the team knows what’s going on, and not having hours of meetings every day. We are very serious about the ability to have a lot of time during the day for focused work, so we sometimes err on the side of not enough meetings. For this reason the team hasn’t done formal daily standups for a while, instead opting for a weekly meeting to do a roundtable of what everyone’s been working on, and what the plan is for the week.

There are a couple of problems with this approach. First and foremost, it doesn’t always feel like time well spent—we shouldn’t be spending an hour a week just talking about what we’re doing. That’s why we have planning tools1. Another side effect is that it’s harder to respond quickly when issues come up. If a team member is having a problem, or we didn’t realize before that two projects are related somehow, it could take up to a week to find out what the issues are. So we wanted something better. Something lightweight, useful, and more frequent.

We realized early on that synchronous standups wouldn’t work for us—we just work across too many time zones to find a convenient time, and it also doesn’t make sense to have a standup at the end of someone’s day. We also didn’t want this to be just an update for everyone else, we wanted to make it a useful planning tool for individual work as well.

So we started looking for Standup bots built for Slack, and of course there are tons of them. We ended up signing up for Geekbot because it met our most important criterium: it’s asynchronous. We set up Geekbot to ask each team member (product, design, engineering, and QA—we’re all in this…) a set of questions at 9am in their time zone. This means each team member can use these questions to be thoughtful about their day and what they want to accomplish.

In order to make this more useful for us we also changed the questions a little bit. Usually the first question in a standup is “What did you accomplish yesterday?” This didn’t feel right to us—it felt too much like checking up on each other. Instead, we ask the question this way:

Did you work on what you wanted to yesterday? If not, what happened?

This might seems like a subtle change, but it shifts the focus quite a bit. Instead of listing out the things we did, this question allows us to tell each other if something happened that distracted us from the work we wanted to do, which helps us solve those issues as well. So here’s what our Geekbot setup looks like:

Geekbot settings

Every time someone answers these 3 questions, Geekbot posts a status in our #pm-standup team room in Slack, where we can all read through it on our own time.

There is, of course, nothing groundbreaking about what we’re doing here. But I wanted to write up our process because I know there are many distributed teams who struggle with this. The issue is always the same: How do we have standups that are useful and that don’t feel like busywork that just takes us away from the jobs we’re supposed to be doing? By using an asynchronous bot and adapting the questions to our needs, we accomplished a few important things:

  • Every member on the team takes a few minutes every morning to plan out their day, and troubleshoot anything that might have gone wrong the previous day.
  • Instead of weekly meetings of an hour long where we discuss what everyone’s working on, we now have focused 30-minute meetings every Monday where we solve problems and discuss issues that came up during the week (I keep an agenda as we progress through the week).
  • I am much more equipped to fulfill my role as Product Manager because our updates are more frequent and the signal to noise ratio is extremely high.

So even if your remote team is against the idea of a standup, I recommend you try something like this. Don’t just do what we did though. Choose your own questions, your own cadence, maybe even your own tool. But do something—start with the question “How can we make frequent checkins useful?” and see what the team comes up with.


  1. I have a whole other post planned about using Jira in small teams… 

Remote work, open offices, and focus

I recently started a new remote role as a Product Manager at Wildbit. And by “recently” I mean I’m on Day 4, so my experiences with full-time remote work is demonstrably limited. That said, there is one thing so far that I appreciate more than anything else about working in a dedicated office space in my basement: The Calm.

I say The Calm with due reverence because I don’t just mean quietness (I have music playing most of the time). I mean the relaxed ability to work focused and uninterrupted for long periods of time. The joy of this kind of work environment is hardly a new discovery, but since I’ve always worked in open offices this is a brand new and extremely joyful thing for me.

I suspect this is also the reason why everyone in our main office in Philly has their own office. It’s not that I (we) don’t like people. It’s that I get so much more done in a day while working in an environment where I’m able to shut everything else out and just work. The problems with open offices are well documented, of course. From The Economist’s Inside the box:

Open-plan offices are noisier and more interruption-prone. Too much noise causes high blood pressure, sleep problems and difficulty in concentrating. And cubicles’ flimsy walls do little to dampen sound. In studies where sound levels were raised from 39 to 51 decibels—roughly equivalent to moving from an average living room to a road with light traffic—participants were more tired and less motivated.

From Maria Konnikova’s The Open-Office Trap:

In 2011, the organizational psychologist Matthew Davis reviewed more than a hundred studies about office environments. He found that, though open offices often fostered a symbolic sense of organizational mission, making employees feel like part of a more laid-back, innovative enterprise, they were damaging to the workers’ attention spans, productivity, creative thinking, and satisfaction. Compared with standard offices, employees experienced more uncontrolled interactions, higher levels of stress, and lower levels of concentration and motivation. When David Craig surveyed some thirty-eight thousand workers, he found that interruptions by colleagues were detrimental to productivity, and that the more senior the employee, the worse she fared.

And yet, despite all the evidence against it, open office plans persist in most companies, and will for a long time to come.

But yeah, it’s Day 4. Let’s see if I go crazy after a couple of weeks…

Meetings and email: maybe they're not so terrible after all

There are two things everybody in business (say they) hate: meetings and email. So the past few years have seen a great many startups that try to re-invent, revolutionize, and strategerize the crap out of meetings and email. However, recently we seem to have come to a disappointing realization: meetings and email are the worst ways to get things done, except for all the other ways.

In Meet Is Murder Virginia Heffernan goes deep on the topic of meetings: why we hate them, what people have tried differently, and how we just can’t seem to quit them. Her resigned conclusion hints at what really might be the source of our meeting hatred:

What’s so bad about meetings, after all? At bottom, they are nothing but time with your fellows. Which suggests that hating meetings might be akin to hating traffic, families or parties—just another way to express our deep ambivalence about that hard fact of existence: other people.

Meanwhile, in Slack, I’m Breaking Up with You Samuel Hulick shares his dismay with Silicon Valley’s latest darling company. These kinds of articles are inevitable at this point—we’re almost certainly approaching 6 PM SVT (Silicon Valley Time) for Slack. Anyway, Samuel wrote a break-up letter to Slack, but at times it reads more like a subtle “Please come back!” letter to email. For example:

While it’s true that email was (and, despite your valiant efforts, still very much is) a barely-manageable firehose of to-do list items controlled by strangers, one of the few things that it did have going for it was that at least everything was in one place.

And this:

When work gets done over email, there’s a general expectation of a response buffer of at least an hour or two. In you, though, people can convene and decide on anything at any time.

Also this:

When I started feeling like our relationship was getting to be just a little too much, I decided to take a few days off. That was never a problem when I was with email—I’d just fire up a vacation autoresponder and be on my merry way.

I’ve always liked email (which, sorry, I know, is like a Portlander saying “Oh you just found out about Kale? I’ve been eating Kale all my life!”), and felt that the bigger problem is not the system but the way we deal with it. I tried Google Inbox and that Mailbox thing that Dropbox bought and shut down, but I could just never get into a groove with a system that tries to sort my email for me. Instead I just do something that works really well for me: I read every email, and file each message in the appropriate place when I’m done dealing with it. That’s it.

I’m also not as against meetings as I used to be. My rules there are equally simple: always walk out of a meeting with an artifact. This could be a whiteboard sketch or a note about a thing you need to go research—it doesn’t really matter. Just walk out of there with something. Meetings should focus on facilitating the things that meetings are good at: collective thinking. Meetings that energize me are the ones where most people are standing, working together on a common goal. From customer journey workshops to design studio sessions to analyzing usability testing results, there are plenty of useful ways to spend our times in meetings. That’s my only criterium for a good meeting: make progress.

These guidelines are probably way too simple for the majority of businesses and people. But I do think that when we try to “reinvent” meetings and email we’re trying to solve a people problem with technology, and that’s just never going to work. Technology can help, for sure, but at its core we need to figure out why we hate email and meetings, and then fix that first. And I think the main problem with meetings and email is that we don’t spend enough time taking personal responsibility to make them more effective. Until we stop trying to offload our personal responsibility on the shoulders of technology, nothing will change.

Why being online is worth the effort

Matthew Malady has an interesting take on the “I went offline and lived to talk about it” essay. In The Useless Agony of Going Offline he discusses one of the biggest benefits of technology—knowing more things:

At the end of the experiment, I wasn’t dying to get my phone back or to access Facebook. I just wanted to get back to being better informed. My devices and the Internet, as much as they are sometimes annoying and frustrating and overflowing with knuckleheads, help me to do that. If getting outside and taking walks, or sitting in silence, or walking dogs, or talking with loved ones on the phone got me to that same place, I’d be more than happy to change things up.

This is similar to Clive Thompson’s main thesis in his excellent book Smarter Than You Think. Our ability to gain knowledge and collaborate more effectively makes all the negative aspects of being online worth the effort.

PowerPoint: Does it suck or is it evil?

In a journal article for Computational Culture Erica Robles-Anderson and Patrik Svensson presents a scholarly critique of PowerPoint, and it is fantastic. It’s long and in-depth and the rare academic article that is a joy to read. From the conclusion of “One Damn Slide After Another”: PowerPoint at Every Occasion for Speech:

PowerPoint is just one example of the oft-overlooked conditioning of knowledge production. The software profoundly shaped basic social expectations, technical conditions, and architectural pre-requisites for speech yet it was uncritically absorbed in nearly every quarter. PowerPoint does not zoom. It does not allow spontaneous comparisons. It does not accommodate several screens, multiple threads, or distributed live collaborations. It makes the analytic move of systematic comparison, so prevalent in late nineteenth and early twentieth century information presentations, extremely difficult to make. Moreover, its expansion has meant that once distinct situations have become more alike. Meetings, sermons, lectures, and talks increasingly employ the technics of commercial demonstration. Twenty-first century occasions for speech are structured by a platform that enforces the paradigm of one-slide-at-a-time.

The handicap of big product teams

Most businesses don’t admit how costly things like company wide announcements, project management, interviewing, internal politics, and large scale collaboration are on productivity. They all work against flow, and should be considered a handicap on product teams. Small teams substitute process with trust, eliminating overhead.

— Kyle Neath, Million Dollar Products

I accidentally made some New Year's resolutions

I’m pretty unsentimental about things like birthdays and new years, but I’m also only human and sometimes things sneak up on you unexpectedly. Earlier this week I was standing in our kitchen, staring into space as I waited for the water to boil, and suddenly my eyes focused on this—a series of guidelines my wife wrote down for our 6-year old daughter during the course of a particular trying day with her:

I looked at it, and then I saw it, and then I read it. And then I read it. And I realized that as silly as I usually think New Year’s Resolutions are, that’s some pretty good advice so what the hell, goals are good, right? So here they are, my 2016 resolutions:

  1. Care less about getting credit for things, care more about sharing victories (and defeats) with the people around me.
  2. Get angry a lot less, because anger just leads to yelling and yelling leads to the Dark Side. Or something.
  3. Be first less. Whether it’s getting on the bus or dividing up work on a project, let others go first. It’s not only the nice thing to do, I’ll probably end up learning a few useful new skills working on things I don’t normally work on.
  4. I should probably not hug my co-workers all the time, but I certainly want them to know how much I appreciate them. So I’ll tell them that more often. And my family will get a lot more hugs.
  5. Actively seek out places and projects where I can lend a helping hand. And—very important—don’t forget #1.
  6. Say “please” and “thank you” all the time—not only with words, but with how I live my life.