Two lofty but surprisingly insightful Twitter think-pieces caught my attention this week. The first is Jennifer Senior’s description of it as The High School We Can’t Log Off From:

A few years back, the sociologist Robert Faris described high school to me as “a large box of strangers.” The kids don’t necessarily share much in common, after all; they just happen to be the same age and live in the same place. So what do they do in this giant box to give it order, structure? They divide into tribes and resort to aggression to determine status.

The same can be said of Twitter. It’s the ultimate large box of strangers. As in high school, Twitter denizens divide into tribes and bully to gain status; as in high school, too-confessional musings and dumb mistakes turn up in the wrong hands and end in humiliation.

The second is Ezra Klein’s pretty profound Twitter is not your friend. Here’s the crux of it:

We write for an audience we think we know, in a vernacular they’ll understand, using reference points they’re familiar with. Six years later, our tweets are weaponized to an audience we don’t know, thick with terms they understand differently, with the reference points completely absent. […]

Twitter is not your friend. It is built to reward us for snarky in-group communication and designed to encourage unintended out-group readership. It fosters both tribalism and tribal collision. It seduces you into thinking you’re writing for one community but it gives everyone the ability to search your words and project them forward in time and space and outward into another community at the point when it’ll do you maximum damage. It leaves you explaining jokes that can’t be explained to employers that don’t like jokes anyway.

And it’s not just what we write. It’s what we see. Our feeds are filled with reasonable, funny, thoughtful comments from our groups and the most unreasonable, offensive tweets sent by our out-groups.

---

My own experience has been similar recently. For years I used Twitter as a way to share things about product management and design, and in return, learn and get feedback from that community. Also the occasional joke. It was fun, and it played a really big role in my career development.

It’s not fun any more. Don’t get me wrong, I’m not mad about it. There are more important problems to solve right now than how I should approach a specific feature I’m struggling with. I’m not mad about how political Twitter has become. It kind of needs to be that, because that’s what’s important right now.

But I do feel like I’m not sure where to go to share ideas with my product tribe any more. And I’m also too scared to tweet anything personal, for all the reasons Jennifer and Era point out in the essays above.

2018 is so weird.

In a recent blog post about our 4-day work week experiment at Wildbit, Natalie (our CEO) wrote about some things we’re doing to focus our jobs a bit better. The example she used in that post is the exercise I went through to clarify my role as product manager, so I thought it would be interesting to talk about that process a little bit more.

If you’re in a position where you’re a little unsure about the focus of your role, or what exactly you should be working on day-to-day, you might find the process I describe here useful to help you figure it all out.

What exactly would you say you do here?

Even though no one can quite agree on how to define the role of the product manager (but you should totally read my book about that), I think we’re all in agreement that it requires lots of different kinds of tasks—which results in lots of context switching. This means that focus is a constant struggle for PMs. Yes, this is true for many roles, but it is especially true for PMs since the ability to switch between different tasks is so central to what we do to help keep things moving.

The issue is not just that switching contexts all the time is hard, it’s also that knowing what to switch to next can be such a challenge. PM minds are in a constant state of prioritization and reprioritization.

It’s with this as background that Natalie and I had a very long 1:1 a few months ago as we realized I’d drifted away slightly from what my core focus at Postmark needs to be. As we got our development process nailed down, that part of the business needed less involvement from me so I started to spend more time on things like metrics frameworks and improving our prioritization methods. Because that’s just what PMs do—we look for things to fix, and then we jump in.

I had a huge realization that I was starting to spend time on the wrong things when Natalie said to me,

Rian, stop trying to turn us into a big company.

That is arguably the most important thing she has ever told me. Because that is exactly the path I was inadvertently going down. Process improvements aren’t bad, but at that time it was not what the team needed. So we got to work to find out what our team needs in our context and our culture.

Mapping a chaotic role into submission

Natalie encouraged me to go through an exercise she has gone through before. It involves creating a detailed mind map of all the things you do during a particular week, and then using that to identify and prioritize your focus areas. I jumped into MindNode, and after a couple of weeks of working on it with Natalie, we came up with the following map of what my focus areas should be:

It looks all neat and sensible now, but it’s worth mentioning that the process was messy for a quite a while. My natural propensity for order made me want to start at the left with the big buckets of my role, and then expand to the right into more and more detail. In practice it didn’t work like that at all. I ended up starting with cataloging some of the mid-level tasks I spend my time on (such as Regular customer calls and Prioritization). With those things as a starting point I then branched out—sometimes to the right (Customer calls leads to defining that we should talk about Pain points), and sometimes to the left (Prioritization leads back to a larger Planning bucket).

I also ended up deleting a bunch of stuff on the far right during my discussions with Natalie. Specifically, we started to see where I was doing too much of the things that the marketing team was doing already. Once we had a visual picture it was easy to see where I need to scale back, and which areas need more definition.

Bringing order to day-to-day tasks

Once this was done, as I stared at the map for a while, I wondered if I could somehow use it to make my days a feel a little less arbitrary. So I took it one step further and simplified my role as a progression from Listen to Think to Act:

This model now helps me prioritize my days when it comes down to deciding what to work on. If I’m in Listen mode I’m more likely to spend most of the day on calls and discussions with the team and customers. Other days are primarily focused on Act so I tend to spend a bunch of time in JIRA or Basecamp creating the content we need on projects.

This has helped a lot with the scattered feeling I often got when switching contexts too much. I still switch between tasks, but keeping it in the same “family” helps so much with focus and productivity.

In summary—I think you should do this

Creating this mind map has been an eye-opening experience for me. It not only helped me to clarify what I should work on (and when), it also constantly ensures that Natalie and I are on the same page about what I should be spending my time on. This is especially important as a remote employee where we don’t catch up all the time about what I spend my time on.

Natalie and I look at my focus areas together and discuss any changes we might need to make. But other than that, I feel confident that I’m doing the stuff that’s most important for our team, our customers, and the business. I like that feeling a lot.

I’ve been thinking about the topic of my latest A List Apart column for a while, but I was just too scared to write it. I mean, what right do I have to talk about work and privilege? But I ran the idea by my amazing editor, and since she was really supportive and enthusiastic about it, I went for it.

So I wrote Why?:

Why we work—and what kind of work we do—is a function of our privilege and our history as much as it is a function of our choices and our dedication.

I hope you enjoy reading it, and take something from it. This one took a while to get right.

Elea Chang takes on the “full-stack employee” idea in a great critique called The Full-Stack Employee and The Glorification of Generalization:

Hidden inside that “full-stack employee” manifesto is the idea that tech equals work and work equals life. Despite all the talk of learning and growing, the full-stack employee is primarily focused on conquering domains within the tech industry. But there have always been ways to impact the world outside the workplace. Unfortunately, the continuous pursuit of professional skillsets tends to diminish the boundaries between work and everything else, leaving you with less and less time to actually grow as a human being.

I’m very much in agreement with this. Many companies still go out of their way to reward people who work extra long hours, even if that comes at the expense of time spent with family (or, as Elea points out, volunteering outside of work).

Jessica McKellar gives some fantastic career, management, and leadership advice in This Is What Impactful Engineering Leadership Looks Like. The interview goes into detail on three main areas:

“When engineering management is done right, you’re focusing on three big things,” she says. “You’re directly supporting the people on your team; you’re managing execution and coordination across teams; and you’re stepping back to observe and evolve the broader organization and its processes as it grows.” 

Even though the interview is focused primarily on engineering teams, it’s applicable to all types of leadership and management. Highly recommended.

In my latest column for A List Apart I discuss our obsession with “managerial tracks” in career development, and propose something different. From Managing and Making: It Doesn’t Have to Be One or the Other:

I think we need a career system that encourages people to oscillate between individual contributor roles and manager roles. Maybe we provide “manager sabbaticals” where a manager becomes an individual contributor on a team for six to nine months. Maybe when a manager goes on vacation, an individual contributor takes on their role for a period of time (or for the duration of an entire project). I don’t know exactly what this looks like yet, but I think it’s important for us to figure it out.

I explain why in the article. I’d also like to point out that my original title for the piece was “Managing and Making: It Doesn’t Have To Be A Dirty Dance”, and it featured this photo:

I’m really glad my editor talked me out of it. It’s not good to make jokes that only people who grew up in the 80s will appreciate.

It’s a good joke, though.

So I guess it’s quarterly “Designers should learn to code” day on Twitter. This appears to be the crux:

Good discussion today w/ friends who are “designers that code.” It’s no longer even a question of “Should designers learn to code?”

— Nathan Smith (@nathansmith) January 20, 2015

Because that ship has sailed. It’s more like… If you’re a designer that doesn’t code, you’ll just be left behind. Not even a debate anymore.

— Nathan Smith (@nathansmith) January 20, 2015

I have two questions.

1. What is a “designer”?

I don’t mean that in the metaphorical sense. I mean literally, how do you define design in this context? Is it visual design? User experience design? Product design? Content strategy, or any or all of the other things that make up well-rounded design?

Because here are the things I’m currently trying to get better at by reading books and practicing and writing and working it into projects:

• Usability testing and ethnography
• Information architecture across multi-platform experiences
• iOS native app design

I’m a little busy right now, so I’d like to know: which of these things should I drop to learn to code?

2. What does “left behind” mean?

Does it mean designers who don’t code won’t get hired in The Future? I don’t know about that. I spend a lot of time with designers. Some of them code, some don’t. Those who don’t specialize in something else that those who code aren’t good at, and that makes for stronger teams where work can be distributed more evenly and more effectively.

Let me put this another way: once every designer can code (since it’s “not even a debate any more”), who’s going to make sure we build the right things? Who’s going to discover user needs, create IAs that work for target personas, and design scalable holistic systems that work across devices and contexts?

What I mean to say is this:

• Heaven help us if we become a community of executors at the expense of all the planners out there. We need both.
• It’s really, really dangerous to tell people they’ll be “left behind” if they don’t become part of a homogenous group of people all focused on the same thing. That has never worked out well for anyone, in the history of mankind.

So go forth, follow the design thing you’re most interested in. If that’s coding, awesome. If it’s how to best understand user needs and translate that into design systems, go do that. As long as you do it well, you won’t be left behind.