A 2019 manifesto: analog over digital

I’ve been thinking about Cal Newport’s post called Join Analog Social Media all day, especially as we get to the end of another year:

The dynamic at play here is that digital activities that are mildly positive in isolation, combine to crowd out other real world activities that are potentially much more satisfying. This is what allows you to love Twitter in the moment when you discover a hilarious tweet, but at the end of the day fear that the app is degrading your soul.

Understanding this dynamic is critical because it tells you that you cannot improve your life by focusing exclusively on digital tools. Triaging your apps, or cutting back phone time, will not by itself make you happier. You must also aggressively fill in the space this pruning creates with the type of massively satisfying, real world activities that these tools have been increasingly pushing out of your life.

Simply cutting back on social media time is only going to leave a weird emptiness behind if we don’t fill that gap with some real connection time with the people in our lives.

I’m not sure about New Year’s Resolutions, but if I have any, it would be to look at everything through the lens of a new manifesto: analog over digital. Just as with the Agile Manifesto, the word “over” is of utmost importance here. It doesn’t mean I’m done with digital. It just means that I want to look at the things I do, and critically evaluate whether or not an analog approach could be more meaningful. For example, should I stop tracking my runs on Strava, and just enjoy them instead? Should I have a go at hand journaling instead of putting everything in Day One? The answer may very well be “no”, but I’d like to ask the question more in 2019.

Happy New Year, everyone.

Filling our empty moments with sound and noise

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…

Data-driven vs. data-informed decision-making

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.

Best Practices for Building and Managing a Remote Team

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.

The future of books is how they’re created, not what they are

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.

How team structures are like bands

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.

Who designers work for

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.

How would you rank your own skillset?

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.

When it comes to roadmaps, focus on outcomes, not features

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.

A fluid approach to shipping products

I really like the this Mountainsides approach to software projects from the Postlight team:

It’s sort of like a Gantt chart that was left on the stove too long, leaving all those neat and tidy bars melting into one another.

Mountainside development


  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. ...
  8. 123