In Filling the Silence with Digital Noise, Kate Moran and Kim Flaherty share some research-based findings on how people use digital background noise to make sure it’s never quiet around them:

While many participants reported feeling the need to have some sort of audio in the background during their silent moments, others reported a more intense version of this phenomenon: the need to fill all the empty moments in their lives with some activity to avoid boredom or downtime. This behavior fills the ‘silence’ in a figurative way — people use their devices to keep their minds constantly occupied.

I read this article with interest, because I also do this—albeit for a different reason. I have a condition called tinnitus, which is a consistent ringing in the ears. There is no cure for it—the only way to deal with it is to learn to manage and be ok with it. For those of us who suffer from tinnitus, silence is torture. Because there is no silence. Your only choices are (1) the sounds/noises you put on around you, or (2) a loud ringing in your head that comes from nowhere and everywhere and never goes away.

Guess which option we usually go for…

The Netflix Data War is a very interesting post about the internal discussions that happen between Netflix’s content team and their data team. In short, data isn’t everything:

[…] in almost any decision-making situation involving data, there is some non-zero percentage of the process that involves “gut”. The reason is because not all information about a process can be incorporated into a data analysis, and it’s important for data analysts to realize that.

That’s an important point to reflect on. It doesn’t matter how complete a data model is. There are some variables that simply cannot be included, because it’s impossible to know what should be included in any particular model.

Apart from that, it’s also just a fascinating look at the internal workings of Netflix.

The Doist team makes some great points in their article Best Practices for Building and Managing a Remote Team, including something we’re embracing very strongly at Wildbit as well:

Managing a remote team effectively is not about monitoring the amount of time your team members spend online (in fact, that’s a great way to kill employee autonomy and motivation). It’s about building and supporting a team that doesn’t need to be micromanaged in the first place.

We wrote more about our approach to remote work here.

In The ‘Future Book’ Is Here, but It’s Not What We Expected, Craig Mod writes that after years of believing books will fundamentally change in the digital age, it’s simply not happening:

I think we can agree that, in an age of infinite distraction, one of the strongest assets of a “book” as a book is its singular, sustained, distraction-free, blissfully immutable voice.

What has changed, instead, is how books are created:

Instead, technology changed everything that enables a book, fomenting a quiet revolution. Funding, printing, fulfillment, community-building—everything leading up to and supporting a book has shifted meaningfully, even if the containers haven’t. Perhaps the form and interactivity of what we consider a “standard book” will change in the future, as screens become as cheap and durable as paper. But the books made today, held in our hands, digital or print, are Future Books, unfuturistic and inert may they seem.

Or, more succinctly:

Our Future Book is composed of email, tweets, YouTube videos, mailing lists, crowdfunding campaigns, PDF to .mobi converters, Amazon warehouses, and a surge of hyper-affordable offset printers in places like Hong Kong.

You might think that A rocker’s guide to management sounds like one of those “What X can teach us about Y” articles. And it is, I guess, on the surface. But it’s just so well done. As an intro:

The history of rock groups can be viewed as a vast experimental laboratory for studying the core problems of any business: how to make a group of talented people add up to more than the sum of its parts. And, once you’ve done that, how to keep the band together.

The article is less about management, and more about the different ways that teams can be structured, as well as the good things and pitfalls of each approach.

Mike Monteiro isn’t always everyone’s cup of tea, but I really like his views in Design Ethics & the Truth About Who Designers Really Work For. In short, designers need to work for users:

When you hire me as a designer, I do not work for you. I may practice my craft at your service, but you haven’t earned the right to shape how I practice that craft. One, you don’t want me designing at your level, you want me designing at mine, which means you don’t get to pull the strings. I do. Two, you’re hiring someone who performs a service, not a servant. There’s a difference. I’m not there to do your bidding, I’m there to solve a problem or reach a goal that we agreed upon.

More importantly, designers work for all users, not just the ones who look like them…

And your job, the glorious job you signed up for when you said you wanted to be a designer, is to support all of these people. Make sure none of these incredible voices get lost. And to fight against those who see that brilliant cacophony as a bug and not the greatest feature of all time.

You are our protection against monsters.

Chris Jones describes his favorite product manager interview question, but in the spirit of “know thyself” I think this is an exercise everyone should go through for themselves:

The question comes late in the interview, but early in the overall hiring process. The setup goes like this: “Now that I know you a bit, I’d like to give you a list of 4 broad work attributes. You’re a product manager, so I already expect that you’re strong in each. But I highly doubt that you consider yourself equally competent in all of them. So I’m going to ask you to stack rank them in order of strongest to weakest”. This setup should be disarming. The candidate must understand that there is no correct answer to the question, hopefully setting up an honest conversation.

The four attributes are Execution, Creativity, Strategy, and Growth. Chris does a good job of breaking down what each attribute means and why it’s important.

Here’s a pragmatic approach to roadmaps that I can get behind. Escape From the Feature Roadmap to Outcome-driven Development:

You’re exploring new lands. You know where you want to get to — that’s your outcome — but there’s no established route to get there. So you’ll probably set out, and if you’re measuring yourself correctly and you’ve got good feedback loops in place, you’ll be able to course correct and quickly iterate towards your outcome. But you could only draw the complete roadmap with hindsight.

So it’s time to take a new approach: forget the features and focus on the outcomes.

Roadmaps that include a bunch of features are doomed to fail. Instead, say “here’s the problem we want to solve in this iteration.” That allows you to be flexible on scope, and ship solutions to customers quickly.