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.

Kashmir Hill asks an interesting question: Who do we blame when a robot threatens to kill people?

Last week, police showed up at the home of Amsterdam Web developer Jeffry van der Goot because a Twitter account under van der Goot’s control had tweeted, according to the Guardian, “I seriously want to kill people.” But the menacing tweet wasn’t written by van der Goot; it was written by a robot.

He goes on:

Bots will be bots. They won’t know if they’re doing something wrong unless we program them to realize it, and it’s impossible to program them to recognize all possible wrong and illegal behavior. So we’ve got challenges ahead. In the short term, [Clément Hertling, a Paris-based university student who wrote the software that powered the bot] suggested Twitter — and any other platforms bots might live on — could solve the offensive speech problem by allowing bots to self-identify in an obvious way as bots. “That would allow people (law enforcement included) to ignore what they say when it becomes problematic.”

This issue only gets scarier as the question expands to wondering what happens when we put self-driving cars in morally ambiguous situations.

Another possible origin is the president of Kal Kan Pet Food, who was said to eat a can of his dog food at shareholders’ meetings.

— Eating your own dog food on Wikipedia

In software circles dogfooding is usually encouraged — and for good reason. When companies force themselves to use their own products extensively it can have some great benefits. Since internal users visit even the darkest, most neglected corners of a product, bugs tend to be found and fixed much faster than waiting for reports from end users. Employees are also often the most critical users of their own products, so they are driven to make it better and will often have some fantastic ideas.

However, I’ve started to see a dangerous side effect of dogfooding that can sneak up and do huge damage to a product if we’re not careful. Here’s the problem. If we use our own products all the time we become such overly advanced users that we’re eventually unable to separate our own needs for the product from those of our target market.

Most users of our products don’t eat, sleep, and drink the ins and outs of the features we slave over every day. They dip in and out to buy something, or upload something, or quickly edit a photo. So in a really unfair and ironic turn of events, the more we use our own products the less we’re able to think like our users. It sucks, but it’s unfortunately the way it is.

We all repeat the mantra “I am not the user” to each other, but we tend to forget that the way to solve that particular problem is not to morph into advanced users, but to spend more time with actual users. It’s already so hard for us to put ourselves in the minds and shoes of our users. Dogfooding makes this even harder by lulling us into a false sense of security that maybe — just maybe — we are the user after all.

So, be careful. By all means use the crap out of your product — you wouldn’t be pouring your life into it if you didn’t love it. But once you start demanding features that would make your life easier, stop yourself. Be critical of your own motivations. Look at analytics and figure out if yours is a common use case or something reserved for the 1%. Contact your friendly neighborhood user researcher and ask them if they’ve validated the need for said feature. Hold on to your demand with open hands, and let it go if you realize it’s not something that would improve the product for target users.

In short, keep dogfooding — but don’t assume that all dogs will like the new flavors you’re proposing.

Jon Ronson looks into online shaming (and the lives it destroys) in a brilliant piece of journalism called How One Stupid Tweet Blew Up Justine Sacco’s Life:

Eventually I started to wonder about the recipients of our shamings, the real humans who were the virtual targets of these campaigns. So for the past two years, I’ve been interviewing individuals like Justine Sacco: everyday people pilloried brutally, most often for posting some poorly considered joke on social media. Whenever possible, I have met them in person, to truly grasp the emotional toll at the other end of our screens. The people I met were mostly unemployed, fired for their transgressions, and they seemed broken somehow — deeply confused and traumatized.

The conclusion is worth pausing over and pondering:

But perhaps [Sacco] had now come to understand that her shaming wasn’t really about her at all. Social media is so perfectly designed to manipulate our desire for approval, and that is what led to her undoing. Her tormentors were instantly congratulated as they took Sacco down, bit by bit, and so they continued to do so. Their motivation was much the same as Sacco’s own — a bid for the attention of strangers — as she milled about Heathrow, hoping to amuse people she couldn’t see.

We really are terrible at giving people grace — and the benefit of the doubt.

In Don’t Say ‘Cyclists,’ Say ‘People on Bikes’ Sarah Goodyear explains how some deliberate language changes turned a serious conflict in Seattle into a civil debate. Here’s what they did:

“Though the group made no secret of their biking advocacy, they didn’t brand themselves as biking advocates,” writes [PeopleForBikes blogger Michael Andersen]. “They branded themselves as neighborhood advocates.”

[Seattle Neighborhood Greenways] also developed a list of new ways to talk about their concerns and promoted it in handy chart form. Instead of “cyclists,” they suggest, use “people on bikes.” Instead of “drivers,” “people driving.” Instead of technical traffic-engineering terms such as “pedestrian/hybrid beacon,” say “safer ways to cross busy streets.” Replace “pedestrians” with “people walking.”

The result?

[Tom Fucoloro of Seattle Bike Blog] says that talking about streets in a way that emphasizes the common humanity of all users, rather than dividing them into tribes with warring interests, has made a real difference in the way Seattle’s planners discuss possible changes to streets with the community. As a result, he says, the discussion has become much more civil. And Seattle has been installing protected bike lanes (don’t say cycletracks!) at a steadily increasing pace.

I wonder if we need something similar in our industry. Instead of “users,” perhaps we should talk about “people who use websites.” After all, we’re supposed to be all about emphasizing humanity in our products.

Paul Ford wrote a great post about the significance of the blue/green bubbles in the Messages app on iOS. From It’s Kind of Cheesy Being Green:

This spontaneous anti-green-bubble brigade is an interesting example of how sometimes very subtle product decisions in technology influence the way culture works. Apple uses a soothing, on-brand blue for messages in its own texting platform, and a green akin to that of the Android robot logo for people texting from outside its ecosystem. […]

There are all sorts of reasons for them to use different colors. (iMessage texts are seen as data, not charged on a per-text basis, and so the different colors allow people to register how much a given conversation will cost—useful!) However, one result of that decision is that a goofy class war is playing out over digital bubble colors. Their decision has observable social consequences.

This then turns into a post about product management, in a way that only Ford can do. Great stuff.

Kevin Roose and Pendarvis Harshaw wrote a fascinating 3-part series for Fusion on technology in prisons. I was particularly drawn to the part about allowing inmates to use tablets: Can technology and prisons get along? —

He can’t just hand out iPads, of course. The tablets being used in the Napa jail are manufactured by a Chicago start-up called Jail Education Solutions, which runs them on a secure, proprietary software platform called Edovo. The tablets can’t be used to connect to the Internet; instead, inmates can connect to a local intranet administered by the correctional facility itself. Using the tablets, they can stream Khan Academy lectures, run cognitive behavioral therapy apps, study for a GED, or take courses from Narcotics Anonymous and Alcoholics Anonymous. They can also opt for lighter fare – games and movies, which can be “purchased” with points they earn by completing more educational tasks.

I’m intrigued by stories like this because it shows how designing under severe constraints can result in big innovations.

(I know it’s bad form to explain a joke, but I’m pretty happy with the title of this post)

I’m as fascinated with Slack‘s rise to prominence as most people, so I really enjoyed From 0 to $1B – Slack’s Founder Shares Their Epic Launch Strategy (no byline). It’s full of fantastic product strategy advice, including on the importance of user feedback:

As much information as Slack put out to customers, they learned even more themselves. Butterfield and his cofounders are voracious readers of user feedback, and they attribute much of the company’s rapid traction to this skill. From the get-go, Slack made sure that users could respond to every email they received, and approached every help ticket as an opportunity to solidify loyalty and improve the service. As they listened to their ever-growing flock of users, the Slack team iterated accordingly.

And also remember that sometimes people are going to use a product differently than what you had in mind:

“Sometimes you will get feedback that is contrary to your vision,” Butterfield says. “You may be trying to drive in a particular direction that people don’t necessarily understand at first. In our case, we knew the users we had in mind for this product. So in the early days, we looked at our customers, really just testers at that point, and we paid extra attention to the teams we knew should be using Slack successfully.”

It’s worth reminding ourselves that @-mentions and hashtags on Twitter were user inventions, not something the company came up with themselves. Always follow your loyal users…