This Meeting Should’ve Been An Email

Many of us today have jobs that are difficult to explain to our Boomer parents. Product Managers famously have this problem, but so do many flavors of knowledge workers: try explaining to someone who retired twenty years ago what a “social sentiment analyst” or “devops engineer” is. Advances in technology and changes in markets force evolution of job roles and responsibilities, as they always have and always will.

Yet something I find remarkable is how slowly change comes to how we work. I’ve been working in offices of various types for a while now, and can tell you that my office of 2018 is not that terribly different from one in 2003. The phones are all different, but meetings, interviews and most of the modes of working haven’t really changed. When I ask friends in other fields about this, I hear a lot of the same. Older people often point to the types of differences you’d expect – many fields have a somewhat more casual dress code today, workplace conduct is a little more decent, the women aren’t all secretaries. But what you mostly hear is just that things have sped up, or that capital is allocated more efficiently. (The shareholders have won.) But I think someone from your average 1980s office job could pretty quickly figure out one in 2018, at least once they figured out how to use the computer.

Maybe it’s not a lack of the right “work products” that’s holding us back. Maybe it’s us.

Failures of modern work culture are everywhere. One of the most famous (and griped-about on Twitter) is the “this meeting should’ve been an email” (TMSHBAE) problem. Meetings like these usually happen because (1) almost anyone is authorized to call them, and it’s considered a social faux pas to decline, (2) a higher-up called it and everyone feels obligated, at least politically, to attend, and/or (3) what was expected to be a working meeting really turns out to be something of a negotiation or discussion between just a few parties. I suspect that pretty much every person in the modern workplace has experienced all of this.

What is useful about the “TMSHBAE” example is that, at its root, it’s really an illustration of a pernicious coordination problem. Like many coordination problems, it gets harder and harder to deal with as an organization grows, networks become looser, and most colleagues’ relationships are mediated by professional standards and not personal ones. This is where workplace technology is trumped by workplace culture, and in the absence of an intentional set of institutional working practices modeled by leadership, most people default to doing whatever is needed to avoid giving offense.

But “TMSHBAE” is just one example. “Performative work” is another pernicious issue, especially in knowledge industries where even significant efforts might not result in a tangible final product, but rather in “invisible” outputs like ongoing process improvements, iteration and management. Because measuring performance is so difficult in situations like these (and so poorly done, which is the topic of a future blog post), many people default to performing work as much as doing it, either by over-communicating irrelevant updates or creating opportunities (like meetings) to show off what they’ve done.

These are both fundamentally the result of us acting out our inherited expectations of what “work” should look like, because we have no other operating model to go by. Like in almost every other facet of our lives, we absorb the “work culture” of the broader society we live in and belong to and act it out upon request. Part of what’s so cool about observing European, Latin, African, South or East Asian work cultures in person is to see how differently they operate from ours in the U.S., and to discover what we both might learn from each other.

The vast majority of firms unthinkingly adopt the “standard model” of their society’s work culture, right off the shelf, when they get to work building whatever company it is they want to build. In tech, most people aspire to apply new technology in some novel way to solve a problem in the market; but in doing so, they never think about how the same technology can change their own approaches to problems internally.

Probably the best single example of this is my own personal hobbyhorse: distributed teams (or “remote” working). It remains the case that the same modern workplaces that run almost exclusively on electronic communications still insist that most employees drive to and co-locate in the same building pretty much every day. It’s hard to argue that this is due to a technology gap – rather, it’s a cultural one. I’m confident that, like any disruptive technology, distributed working will be the inevitable winning trend, but mostly because adopters will thrive and laggards will stagnate, not because a silver-bullet technology will suddenly make it feasible.

Meeting users where they are

Those of us in enterprise software are sometimes caught in a delicate paradox between trying to make a particular task as effective as possible, but still keeping the tool easily adoptable and workable by a median user in a target job role. Those two objectives can come into conflict when the scopes of either our product or the user’s objectives are misaligned. As product managers, we often see obvious ways in which a target user’s job role or function could be changed to be more efficient or effective; but we don’t make the rules. Our customers do in their firms, and we have to meet them where they are.

I think Domo is a pretty good example here. Domo has plenty of problems, but one of the big ones, in my view, is that most of their target customer firms simply aren’t ready to adopt their tools. The median BI user is a pretty well-known persona at this point, and his/her needs are arguably already over-met in this highly competitive space. Domo’s sweeping value proposition – the ability to see all of your organization’s data, in one place, to do easy analysis – does sound pretty cool, but it’s probably well beyond the remit of most of those median users, who really just need to see a couple of things, which they can do already. Is there value in a Domo-esque panopticon of your company’s data? Definitely! Just most companies don’t really have someone whose job that is – yet.

As I talked about in The Three Types of Enterprise Software, I think some of the most interesting enterprise products out there now are those that help organizations evolve. Just as GitHub changed the way developers work, mostly from the bottom-up, Slack is doing now for how organizations communicate. It’s a hard challenge – how does chat scale for a company of 10,000 people, let alone 100,000 or more? (They’re working on it.) Email scales, but is clearly imperfect (just don’t blame email). No one has more comprehensively embraced the challenge of organizational evolution than Atlassian, whose portfolio (JIRA, Trello, Hipchat, etc.) addresses not just collaboration, but task design and project management, too. In the same way, I think Fog Creek’s Glitch is making a strong play for this area too.

These are interesting problems, but they’re also some of the hardest ones. Persuading people to change their behavior is one of the most difficult things to do.

Everyone wants progress, no one wants change

My guess is that if most people looked around, and were honest, most of their workplace practices wouldn’t be so out of place in 1985. So if that sounds familiar, don’t worry – that’s probably pretty average. One notable exception that comes to mind is Amazon, whose famously idiosyncratic practices have, bizarrely, not been met with widespread adoption.

If working like you’re in the Reagan administration isn’t your thing, here are a few organizational technologies that I would consider adopting:

  • Disagree and commit
  • Banning Powerpoint
  • 30-minute max meetings
  • Banning recurring meetings beyond 1 month
  • Instituting weekly “meeting budgets” (i.e. a limit of time you have available for meetings)
  • The law of 2 feet
  • Radical candor
  • Organizational standardization on 1 collaboration platform

Got some more? I’d love to hear them.

 

Related posts:

 

[mc4wp_form id=”185″]

Standard