harder, not smarter

Work Harder, Not Smarter

I know, I know. You’re thinking, “Don’t you have that backwards, Ken?” Shouldn’t you be telling me to “work smarter, not harder”?

I get it. One of the most cherished business clichés on our Cherished Business Cliché List is, “Work smarter, not harder.” Hardly a week goes by in which we do not encounter this aphorism in one form or another.

I would have to say that in most situations, this is sage advice. Cliché’s may be tiresome, but they normally contain a kernel of truth in them. If we can do something more efficiently with the same or better return for our effort, then that is indeed working smarter. Of course, whether we follow this advice in any given situation is another question altogether. But it’s still something worth striving for.

The problem occurs when we try to work smarter on things that require more effort and time to realize a return.

Like learning, for instance.


Here’s a news flash. Thinking is hard. This explains why people avoid it. I’m as guilty as anyone, if not even more so. I remember my dad admonishing me on more than one occasion with a single-word command: “Think!”

Like most people, I want things to be easy. I suppose there’s no virtue in making things more difficult than they need to be, but even when simplified and “easified”, most of the things we encounter in life just don’t go very smoothly.

Learning is no exception. We marvel at people that are adept at picking things up, that seem to acquire knowledge in the same way most of us acquire extra pounds over the holidays: effortlessly. We look at those folks and think, “Why not me?”

It’s especially frustrating because many of us (guilty!) remember things that are of no importance whatsoever. I can quote movies that I saw when I was a child, I can recall stupid comments I and my brothers made 50 years ago, but I can’t remember basic syntax in languages I’ve used for years. It is most frustrating.

We try to alleviate our frustration by searching for a magic formula, a process that will enable us to learn in our sleep, or at least make things easier than they are. We read blog posts, we watch videos, we listen to recordings. We try to figure out “how we learn.” If we decide we’re visual learners we abandon reading to exclusively watch videos. Maybe we hate reading anyway, so this works out perfectly. Or we’re auditory learners, so we focus on listening to audio books.

Play Fetch

This is where I deliver bad news.

There is no way to make learning easy. There is no 5-step process I can give you that will suddenly make you able to effortlessly remember what you study.

If you want to recall what you’ve learned, then you’ll need to…um…recall it.

You’ll need to play fetch.

What experiments by cognitive psychologists have shown, in hundreds of studies across a diverse spectrum of subjects, is that the most effective thing you can do to remember information is to practice recalling it from memory.

This is more effective than reading the same text over and over again. It’s more effective than underlining and highlighting as you read. It’s more effective than going over and over your notes.

It’s more effective than anything else you can do.

I know. Not what you wanted to hear. We want it to be easy. We want to avoid the mental exertion of thinking. It’s just too hard.


What Now

Once we’re done whining, we might wonder to ourselves, “How do I apply this?”

Here are a couple of things you might try the next time you attempt to learn something new (or relearn something you once knew):

  • When you are in a class or at a conference, take notes during class. Then, after the class or presentation, sit in a quiet spot, pull out a blank sheet of paper, and jot down, from memory (no peeking at your notes!), the important points that the speaker made. See if you can reconstruct the argument or list all the main points. Try to remember minor points that the speaker thought were particularly important. Don’t give up when your mind goes blank. Push yourself to remember. When the well finally does go dry, compare what you’ve written with your notes and fill in any blanks.Revisit your notes after a day or two and perform the same exercise. Do not just read your notes. This has been shown to be virtually useless. Recall first, then check your notes to see what you’re leaving out.
  • When you’re reading an article or a text, stop after every section, cover the paper up, and try to remember what you just read. As in number 1, put some real effort into it. After you run out of thoughts, return the section and highlight (or underline) the points that you remembered. Also note important points that you failed to remember.This is going to slow your reading down considerably. Who cares? Is it more important to learn the material or plough through some number of words? If it’s just pleasure reading, by all means, let ‘er rip. But if you are learning as part of deliberate practice, i.e., as part of a program to become better at your profession or some craft, then the time invested is more than worth it.

If you do this once or twice, you probably won’t notice much difference. It’s only as you purposefully apply recall to your learning for a period of time that you notice your retention improving.

No Royal Road

The ancient Greek mathematician, Euclid, is famous for developing the system of geometry we refer to as plane geometry or, in his honor, Euclidean. Working in the third century BCE, he wrote his Elements, one of the most influential books in all of history, a monumental work that has endured to the present day. He lived in Alexandria, and so drew the attention of the ruler, Ptolemy I, who was fascinated by this new area of knowledge, but was daunted by the sheer volume of learning it entailed. He famously wrote to Euclid, asking if there was some short-cut he could take to acquire knowledge of geometry. Euclid’s reply is equally famous:

There is no royal road to geometry.

What Euclid told the king about geometry applies equally to learning in general:

There is no royal road to learning.

It takes effort, and the worst kind of mental effort: recalling from memory without notes or prompts. And this effort is not just an unfortunate byproduct of the process. It’s what makes learning stick.

You’ll be working harder, but you’ll be getting smarter!


Balancing Product Management and Technology Engineering Goals

In product-driven organizations, the engineering team tasked with developing the product often has a different reporting structure than the product team. Engineers fall into a vertical structure reporting to a technology leader.  However, they are assigned to develop products envisioned by a product leader who relies heavily on customer feedback, market demand, and industry trends to shape and define their vision for the final product. With their laser-sharp focus on solving customer problems, these product leaders set their product goals and typically align them with their leadership’s Objectives & Key Results (OKRs)

While engineers are asked to focus on product development and work toward meeting the goals and OKRs laid out by product leadership, they may have additional targets defined by their respective technology leaders. These technology-focused objectives could be addressing upgrades needed for achieving scalability, availability, and performance. In addition, there could be benchmarks to improve the maintenance and quality of software products or pay down technical debt.

Engineering teams are tasked with competing leadership goals and priorities

In a desperate attempt to satisfy both ‘verticals’, the engineering team finds itself pulled by these two priorities – should they focus solely on new product development to meet the product leadership OKRs or should they concentrate on addressing technology initiatives? If they devote their capacity to product-related OKRs — as these usually take the priority in product-driven organizations — technology upgrades are delayed and the effort of technical debt reduction to improve software quality is deprioritized. However, the constant pressure to meet both priorities is not taken off engineers’ shoulders and the team gets caught in the crossfire of competing leadership goals and priorities. As product and technology leadership contend to have their viewpoints, business cases and priorities heard, the inevitable result is confusion, frustration and work overload for the engineering team.

Collaboration between Product and Engineering leadership is critical for success

How can product-driven organizations address both the need to deliver solutions to their customers and keep software performing at a high level without driving their engineering teams to madness? Collaboration and communication between product and engineering leadership is essential. While it is not feasible to have a single set of goals for both, it is possible to set aside agendas and develop engineering team OKRs that reflect both priorities. Collaborative discussions can happen prior to finalizing product-focused goals  where input from engineers is considered by the product manager.. The engineering leader milestones that have a direct or indirect impact on the product can be blended within product-related OKRs. Subsequent team discussions can be held to arrive at a consensus where the entire team agrees and commits to the blended OKRs drafted for the period. 

A balanced team workload addresses the need to deliver products that are technically sound

The need and desire to deliver better products that are both valuable to customers and technically sound is constant and the engineering talent and capacity to build both is finite. Closer collaboration between product and technology leadership is critical to ensure both sets of objectives are considered, addressed and properly prioritized. This creates a balanced team workload with attention given to product enhancement and customer problem solving while allowing teams to keep software scalable, responsive and dependable. Your organization’s engineers will thank you for the clarity and collaboration.

What is your experience with balancing product and technical OKRs? Has your organization found a successful approach to address collaboration between product and technical leadership? How are your engineering teams balancing the needs to deliver product solutions to customers while keeping software technically sound? Please share your thoughts!