Pointless Productivity

Years ago, my friend Doug – one of the smartest engineers I’ve ever worked with – was sitting at his desk at work, leaning back in his chair and thinking hard about the problem he was trying to solve. The CEO of the startup he worked for sauntered past Doug’s office, then stepped back a few steps and looked in at Doug, who appeared to be staring blankly off into the distance. He asked Doug “Why aren’t you typing?”

What the CEO wanted, presumably, was some visible indication of productivity. It may not have even occurred to him that he’d just interrupted his lead engineer’s train of thought to tell him that he didn’t trust him to be doing his job if he wasn’t visibly doing his job.

That CEO is not alone in his obsession with typing. I’ve seen a few YouTube videos by “productivity” gurus, where the YouTuber describes how unbelievably fast he types – as measured by an app that tells him exactly what to type. I’ve tried a couple of those apps, and they’re actually kind of fun. But in the end, typing super fast is just a lot of sound and fury, signifying nothing. (In order to maximize sound and fury, you’ll need a decent mechanical keyboard, of course.)

Productivity

People talk about “productivity” as if getting more things done faster is the goal. It’s not.

Work should be about getting the right things done. Efficiency is nice, but effectiveness is nicer.

There’s a great talk by Klaus Bucka-Lassen at the GOTO 2022 conference called “Is Agility Inefficient?” in which he shows a joke book cover that’s a play on the famous book “Scrum: The Art of Doing Twice the Work in Half the Time” by Jeff Sutherland. Bucka-Lassen’s fake book is called “Scrum: The Art of Delivering the Wrong Product Four Times as Fast”.

How do you increase your odds of getting the right things done? It’s simple: Communicate the problem, not the solution.

The job of the whole team, including the product owner and the engineers, is really to solve a problem. The product manager’s job is to help communicate the problem to the team, including all the constraints and considerations.

In fact, the team may discover that the original problem isn’t the right problem (or the only problem, or the most important one) to solve.

For example, when MailChimp was creating a tool for small businesses to create and send email newsletters, they discovered that the problem wasn’t just sending email, it was also creating the content, and even more importantly, matching the voice and tone of the business. They ended up creating a public Content Style Guide, including voice and tone to help with making communication more empathetic and accessible, and it became a resource for writers and marketers worldwide.

The trick to meaningful team productivity has two parts::

1. Help the team understand the problem (to build the right thing)
2. Help the team work together (to build the right thing fast)

(I know, I know, a good writer is always supposed to have three things. Plus, I need to have a 2x2 matrix, somewhere. They’re going to send me to remedial blog school, for sure.)

This is oversimplified, of course. Any interesting problem is far too big to be done all in one piece, so dividing it up into smaller pieces and incrementally delivering value in a working system is what agile development is all about.

Or, as Einstein said, “Make everything as incremental as possible, but no incrementaler.”

What I mainly want to discuss here is how to make sure the team is working on the right problem. Efficiency without effectiveness is pointless productivity, and all your results are doomed to be washed away by the next wave of change.

Helping the Team Understand the Problem

In the words of Yogi Berra:

“If you don’t know where you are going, you’ll end up someplace else.”

With luck, your product managers will have scampered off and gathered requirements from end users and stakeholders. That’s not easy to do, and you shouldn’t expect to start off with something terribly complete or entirely correct.

“User stories” aren’t just for reading to nerdy toddlers at bedtime - they’re a crucial part of gathering requirements (defining the problem) as well as producing the right product. Here’s a great book that can help:

User Story Mapping: Discover the Whole Story, Build the Right Product by Jeff Patton

A quick summary of some of the points from Patton’s book is:

• The goal is to create an end-to-end view of the ideal user journey before writing code.
• User story mapping brings user perspectives into the conversation early, facilitating collaboration.
• It helps teams build shared understanding by visually mapping out the problem space.
• The technique complements agile development, providing crucial upfront insights before sprint planning.
• Iterating on the map helps validate assumptions and prioritize development.

A great thing to do when starting work on a new product (or significant feature) is to get the whole team together (in person or virtually) and discuss the problem in the form of user stories. By focusing on the user’s experience, you can avoid many common problems, such as making the unbelievably cool thing that nobody actually needs.

Remember the Segway? According to Wikipedia: “John Doerr speculated that it would be more important than the Internet. South Park devoted an episode to making fun of the hype before the product was released. Steve Jobs was quoted as saying that it was “as big a deal as the PC”.

Yes, it was kind of cool. No, it didn’t solve a problem that people actually had.

Getting back to understanding the problem to be solved, Amazon (yes, that place) has a great technique for this part of the process, called “Working Backwards”. The idea is to start with a press release, then a FAQ, then define the user experience, then write the user manual. Most of us don’t have the time and money it would take to do this perfectly, but the idea is that the problem is defined by how you get the user’s attention and what they do then, and why they are motivated to do anything.

In some cases (but not all, or even most), you might decide you need a prototype in order to understand the problem better.

A good deal of experience goes into learning what does and what doesn’t need a prototype. Mostly the things that need a prototype are:

• when you need to show something to users before committing to work that would be expensive to redo
• when you don’t know if the thing will even work, so you need an architectural spike to test it

In my experience, you rarely need a full-blown prototype.

You also don’t need to do BDUF (Big Design Up Front), just spend a short time choosing a good direction before you spend a long time going that way.

Helping the Team Work Together

Spotify attempted to solve the problem of siloed teams by creating a hierarchical structure of “squads” (organized further into tribes, chapters, and guilds). The idea itself (especially squads – cross functional teams of 8 people) gained a lot of traction and was partially adopted by many companies. See the chameleon blog for a great analysis of what they were trying to accomplish and what they learned.

An interesting note from the chameleon blog:

“A big learning from the Spotify Squads framework is that some level of hierarchy is needed—managers exist for a reason. The framework saw product owners manage design and engineering teams without engineering managers—or at least in short supply.”

In other words, they learned that it helps to have some people whose job is to help organize things and improve communication.

A second source for the idea of small cross-functional teams is Amazon (yes, them again). Amazon is structured into “two-pizza” cross-functional teams, which they claim is a big factor in their success. This BusinessInsider blog details how it works.

(Side note: Amazon still hasn’t responded to my idea for Really Big Pizza Ovens. Imagine how many people could be on a team if you had pizzas the size of trampolines? I can’t help it. I’m an idea man…)

The reason Amazon and Spotify want small, cross-functional teams is that they both realized that getting the right things done fast requires removing some of the traditional barriers to communication and decision making.

Productivity and Motivation

The last thing I’ll say for now about productivity is that intrinsic team motivation is the key.

You don’t want your team to grind their way through every day, using raw willpower and grit to force themselves to get things done. You want the job and the team to be so much fun that people love their jobs.

There’s a great framework for improving intrinsic team motivation invented by Paloma Medina that helps with that, called BICEPS, which stands for:

• Belonging
• Improvement
• Choice
• Equality / Fairness
• Predictability
• Significance

I’ll leave more discussion of that and related behavioral economics topics for another post.

Don’t Say How, Say Why

Almost nothing is more demotivating than micromanagement. Defining the problem rather than the solution not only helps get the right thing done, it helps get the right thing done fast, because the team is bought in to the process.

A truly productive team needs to have enough authority to decide how to solve a problem, which comes with the responsibility to solve it. And with responsibility comes accountability. We’re not after “typing”, we’re after results. The good thing is, delegating both the problem and the solution to the team not only improves the quality of the solution, it also improves the team’s motivation and engagement.

Strategy is generally up to the product manager and the company executives, who decide what problems to solve and in what order, but even then it’s important to have communication in both directions so that a better understanding of the problem(s) makes it back into planning.

Summary

I don’t know what the opposite of “pointless productivity” is, precisely, but I imagine it’s something like “meaningful productivity” or “effective productivity”.

I’m pretty sure it has little to do with typing really fast.