Philosophy Posts

Remote workforce as a superpower
Puzl Coworking Space in Sofia, Bulgaria.

Remote workforce as a superpower

Throughout the year 2017 I found myself working in a half dozen spots across 3 continents and many more timezones. This experience led me to develop an increasingly lucid conviction about the profound benefits that remote workforces can bring to a business.


I feel that often when a company rejects remote hiring, or revokes remote work policies (such as former Yahoo CEO Marissa Mayer famously did in 2013 while kicking off her tenure that ultimately ran the company into the ground) an implicit or explicit dimension of the decision is lack of trust. If you cannot trust your employees to do work when you are not watching, then indeed you should not have a remote team. I would caution that if you find yourself this circumstance it may be a signal of a much larger issue with your team makeup and probably demands urgent introspection.

Defaulting to non-disruptive communication

One of the most profound benefits of having a remote team is that generally team members will default to asynchronous and non-disruptive forms of communication. This can benefit workers in any role but it is particularly valuable for developers, who rely on having blocks of uninterrupted time to focus and think through complex problems.

What gear are you in?
Ironically, I think these are single-speed bikes.

What gear are you in?

I recently read a wonderful profile of a young Larry Ellison by serial entrepreneur and teacher Steve Blank. One passage leapt out at me for its relevance to many recent experiences of my own:

Larry ascribed to the adage, “We don’t do things right, we do the right things.”

I was reminded of another aphorism I’d once heard – a bicycling metaphor:

It’s not how fast you pedal, it’s what gear you’re in.

I’ve seen time and again that one of the most destructive things to a software development team, be their product nascent or mature, is bad prioritization.

Practical vs correct
A low complexity surface area and building atop mature frameworks makes high-leverage wins like moving to dedicated hardware much more achievable.

Practical vs correct

In our work as software developers we regularly have to evaluate architectural tradeoffs. We have voices, either external or internal, telling us to think about, for example:

  • Going API first
  • Building to accommodate horizontal scaling
  • Building with the most modern tools
  • Building with tools and frameworks that let us hire the best (or sometimes “Building with tools and frameworks that let us hire the cheapest”)

There is often a tension in these matters between practical and “correct”.

Estonian E-Residency and refactoring government

Estonian E-Residency and refactoring government

Marshall McLuhan once said “Our Age of Anxiety is, in great part, the result of trying to do today’s jobs with yesterday’s tools”. There’s not a lot of technology that we interact with on a day-to-day basis that’s stayed in continuous operation for 230 years. The faculties by which we interact, gather, and exchange ideas in social and professional realms have dramatically evolved in this span of time. Our systems of government, at both philosophical and practical levels, largely have not.

Every day I work with teammates in Germany, New York, California and British Columbia. “Presence” means something quite different today than it has for much of human history. It is a divided concept, and virtual presence often has equal or greater consequence than physical presence.

Finishing Is Credibility

Finishing Is Credibility

One of the things I am most proud of, and that I am most surprised to find distinguishes me when I look around at other people in my professional circles, is how often I finish things. To me, finishing is credibility, and a person’s record not just of starting or working on projects, but of finishing them, should be a factor in the weight you give to their opinions or the degree of leadership you entrust them with.


I recently read Chad Fowler’s The Passionate Programmer, a book broadly concerned with finding fulfillment through work in software development. The book had an unexpectedly strong impact on me. Many of Fowler’s key points aligned uncannily with recent experiences and observations of my own. One section that leapt out in particular to me concerned practice.

The Empty Vessel Makes the Greatest Sound

I did never know so full a voice issue from so empty a heart. But the saying is true: “The empty vessel makes the greatest sound.”

Shakespeare's Henry V, Act IV, Scene 4

A decade living in New York has conditioned me to have an instinctive skepticism of the loudest voice in the room. The loud people, the pushy people, the bullies, those who take up the most space, whether in the workplace or hooting on the sidewalks at night on the weekend – these are almost always also the people of least consequence, but its a fact that is tragically lost on most.

Chilling Out
Image credit: Victor Cajiao

Chilling Out

Today was a Sunday and for the first time in probably 5 years I guiltlessly did nothing to advance any business initiative of mine. I worked on no personal projects. I did no client work. I walked down to Bleecker Street maybe 10 blocks south of my apartment and I went to Porto Rico, a hundred year old coffee importer I’ve been going to for a decade that has a little coffee bar in the back. I got a coffee, sat on a bench out front, drank my coffee and watched the streets.