OPP and that Wardley thread

Just a couple of reads I found very interesting this morning.

First is (OPP) Other People’s Problems posted in Medium by Camille Fournier. I’m a firm believer of how it’s so important to choose your battles because (1) not everything is worth it, (2) time is finite and you have to prioritize, and (3) maybe it’s not even your problem to begin with. That post shares some tips and someone had shared a flow chart for how to decide where you spend your energy on.

Second is this thread in Twitter posted by Simon Wardley (the guy behind Wardley Mapping). It’s about one particular customer making a very unique request, and Mr Wardley saying it’s a bad idea. For those of us who’ve been there–getting that very special, super-specific request that feels like it’s more effort than its worth–then this feels very relatable.

That unfinished podcast (with suggestions on how to improve at work)

I listened to a podcast just last week and I didn’t even get to finish it. I meant to resume it but the link no longer works (here’s the link just in case it ever becomes available again). But within the fifteen minutes I paid attention to, I got to hear the following tips in bold and jotted down a few notes (not so comprehensive as I was only passively listening).

  1. Don’t just learn, loop. – Do your job a little better every day.
  2. Do less, then obsess. – Be brutal in your prioritization. Saying yes to many things -> mediocrity. Master few things. Cut out all that other stuff.
  3. Become a forceful champion. – We achieve through others, we work with people we don’t have authority over… Inspire, build alliance.
  4. Fight and unite. – In good meetings, we are discussing (fight). Unite part is about decision, no undermining. [Link to YouTube video of author explaining Fight and Unite, around 3 mins]
  5. Disciplined collaboration. – Big problem is overcollaboration. Disciple the collaboration — on few things, most important things.
  6. Redesign your work. – Look into how can you do your work differently, better… frequently, not just annually.

The guest in the podcast was the author of the book and I had to google a bit to find out that the guest and book were Morten T. Hansen and Great at Work: The Hidden Habits of Top Performers (2018). I also came across the video of the author explaining “Fight and Unite” (added the link above).

Reaching for goals

Heads up, this is a brain dump! But come to think of it, all my other posts are. 🙂

I think there’s often an emphasis on knowing what the goals are, and even the why behind those goals. We see a roadmap, a strategy plan, some high level visualization of what we’d like to accomplish. But the devil is in the details. It’s in the how where things get muddied (all the more so if intent wasn’t clear to begin with), and which makes all the difference whether we actually reach our goals or not.

One of my favorite quotes has always been:

A goal without a plan is just a wish.

What prompted this post is one of the Medium posts that showed up in my feed today. It’s about The four simple habits of exceptional leaders. And Habit 3 is “Becoming process orientated, not goal orientated.” The post comes with a convenient takeaway point:

“Takeaway point: By focusing on improving the way we and our teamwork to achieve our goals, and forming habits of always seeking to improve how we work, we will ensure our goals are continually met and exceeded.”

And I agree. I’m not dismissing the what and the why aren’t important, because they are! It’s just that the how is just as important. And part of the how includes the nitty-gritty stuff like

  • working agreements
  • communication plans
  • team dynamics
  • good meeting practices
  • plan-do-check-act stuff
  • execution details especially who does what, how to check if on track, etc.
  • retrospectives
  • lessons learned

And generally looking at how you’re working (or not) towards your goals including reevaluating if those goals are still relevant. Half of me feels like these are basic stuff, the other half tells me we don’t know all these by default… we get to realize their importance over the course of many projects and hopefully not too many failures. This is why leadership is so challenging when you want to do it right — it requires experience (not measured in years), knowing to be in the present and at the same time have hindsight and foresight, seeing both the details and the big picture, serving across different levels sometimes with conflicting priorities, the pull of many directions that you somehow need to balance to keep on moving forward.

Read: Clarity First

The book Clarity First: How Smart Leaders and Organizations Achieve Outstanding Performance by Karen Martin is one of the books that often show up among the recommendations whenever I’m shopping for books to read at Amazon. It’s a bit too pricey for me though at $19.25. Luckily, it’s available through our office subscription to Skillport.

As I read it, there was a lot of what feels like a statement of the obvious or the author preaching to the choir. But I guess the value of this is that I get to read better elaborations of stuff that I feel just make sense but couldn’t explain as well. There were also a lot of parts that were good refreshers — stuff that I’m pretty sure most of us know but forego in the rush of being too busy.

For my notes here, I just noted what felt new, was a value add to me, or something that highlighted a point that I often overlook.

  • Chapter 1 is on clarity vs ambiguity
    • Self-assessment link
    • The A in VUCA as different from its three other friends (Volatility, Uncertainty, Complexity) “since ambiguity is a man-made condition that exists within the other three”.
  • Chapter 2 is on Purpose
    • I came across gemba or “the real place” where the action happens again.
    • The chapter also has some guide questions to aid in thinking about purpose.
  • Chapter 3, on Priorities
    • It reiterates the often ignored point on multitasking i.e., that it’s not as productive as most folks think it is.
    • TIL Ishikawa, that I only know for a fishbone diagram, was a Quality Management professor in the 1950s.
    • It has a section on creating a strategy deployment plan, which is a good point of reference to compare with how you’re currently doing it.
    • There’s a reference to “leader standard work” in the footnotes. I’m not sure if that’s a Lean reference thing so it’s something to google for later.
  • Chapter 4, on Process
    • Interesting quote: “A business is the sum of its processes.”
    • In this chapter, she goes into value streams which is also something she had co-authored another book on.
    • TIL of three productivity-robbing “enemies”: muda, muri, and mura. Muda refers to all forms of waste, including overproduction, overprocessing, errors, rework, excessive inventory, waiting, excess motion, excess transportation, and underutilization of people. Muri refers to overburden on equipment and people. Mura refers to unevenness.
    • “A well-designed process creates the potential for success, but execution determines whether the design is fulfilled in such a way that it meets its potential. And execution is wholly dependent upon whether the organization has people with the necessary level of skill, experience, and authority doing the work.”
    • Well-managed processes are documented, current, followed, consistently monitored, and regularly improved.
  • Chapter 5 is on Performance, so concept of KPIs are definitely not far behind.
    • TIL of levels of the scorecard. With Level 3 at the organizational level and usually with a maximum of nine KPIs. Level 2 KPIs are relevant to a business unit, division, or department, depending on organizational structure. And Level 1 KPIs are particular for a department or work team.
    • Hawthorne Effect is where people behave differently when they know what’s being measured.
  • Chapter 6, on Problem Solving
    • Need to differentiate problem solving from problem mitigation.
    • “Problem-solving skill building is the most important aspect of people development. Viewed through this lens, problem-solving coaching is the primary role of the leader.”
    • It highlights why there should be a singular problem owner; when everyone is accountable, no one is accountable.
    • Interesting: ‘One of our common warnings is: “When you automate waste, you get automated waste.”‘
    • The whole sections on CLEAR problem solving (Clarify, Learn, Experiment, Assess, Roll out) is a good refresher.
  • Chapter 7, You, asserts that the hallmarks (the five P’s of Purpose, Priorities, Process, Performance, and Problem Solving) of organizational clarity can also apply at the personal level.
  • Chapter 8 is on Committing to Clarity — it’s something that you take one step at a time, intentionally and consistently practice until it becomes habit.

Read: Where the Action Is

I’ve just finished reading up to Part Three of the book, Where the Action Is: The Meetings that Make or Break Your Organization by J. Elise Keith. The fourth and final part of the book has chapters which can be read separately as each chapter dives deeper into each type of meeting. But even up to just Part Three, there’s so much to takeaway from the book. If I had money to burn (which I don’t) AND I’d be guaranteed that recipients would actually read it, I’d give away copies of this book.

What I find interesting about it is the idea the author shares on how it seems like a cycle that meetings are bad because we’re already resigned to the idea that meetings are bad. So people use it as a crutch or as an excuse. Instead of actually doing something about it, they just think it’s not going to be worth it anyways. There’s also the idea of some individuals misusing meetings to further their egos, as a means to dominate, rather than to advance the team’s goals. So for such individuals who shine in dysfunctional meetings, it’s not in their best interest to “fix” meetings.

Coincidentally, I came across this quote: “For the great doesn’t happen through impulse alone, and is a succession of little things that are brought together.” It’s from a translation of Van Gogh’s letter to his brother, Theo. And I think it highlights intentionality. In the same vein, if you want to have your meetings actually turn out productive, you really ought to take the steps to drive it to that direction.

Something about meetings

I suppose most of us have had our fair share of it-could-have-been-an-email meetings. This is not a totally new topic, but I’ve come across a couple of posts in Medium about it, and I’ve recently taken to reading a book about it.


Wikipedia describes it as: the “informal process of quietly laying the foundation for some proposed change or project, by talking to the people concerned, gathering support and feedback, and so forth.” As opposed to using the actual meeting with the larger group, the alternative is to meet on one-on-ones or separately to set context, provide needed background, and maybe establish some rapport. And by the time the larger group meeting takes place, a lot of the groundwork of bringing people into the same page has already been initiated.

Silent Meetings

This reads like something that sounds like a working session. (Silent, yet sounds like something.) Often times, or at least I think what happens more often, you send out an agenda of something to think about requiring suggestions and ideas. And then people wouldn’t bother. And when the meeting time comes, instead of already discussing ideas or solutions, people are only then thinking about it. By the time the ball is rolling and ideas are being thrown around and reinforced, the time is up.

As an alternative, you hold the “table read” along with discussing and addressing comments as part of the meeting. People will pretty much still need to invest the time to read, review, and address comments. But I guess what you save on is the waiting time. And you’re pretty much guaranteed that Person X actually took the time to read it.

A bit off topic, but the illustration in the 26-minute post for the Silent Meeting Manifesto is just so cute.

I like how this type of meetings is described as more of a “home room”. Because sometimes you just need a common time to go over the same material so that you know it won’t be as disruptive to ask or discuss a comment about it.

Book: Where the Action Is

I’ve only finished up to Part 1 (of 4) of the book. What’s interesting is the idea the author shares of why people hate meetings. I guess obvious reasons would be if it’s such a waste of time. But what she brings up is that hating meetings is being used as a crutch.

Some people are resigned to thinking meetings suck anyway, and use that as “a fabulous excuse for staying ignorant about how to make meetings work well.”

And for some mema* or dominant individuals, meetings can be a chance to showcase themselves or their ideas or might feel “wasteful” if they have to listen to “lesser” ideas (i.e., not their own). Effective, well-structured meetings might take away their time to shine.

*mema = “May masabi lang”; the annoying person who just has to have a very very vocal opinion on anything and everything

Anyways, still three quarters to go, and I suppose that’ll be where she’ll cover what’s needed to go beyond that excuse and actually improve on your meetings.

That measure-manage quote myth

I guess I’ve been working long enough to have come across that Deming/Drucker quote being thrown around, AND to have come across some other material saying the quote has been misattributed to those two. I’ve never really taken the time to look into it any further, but this lazy, rainy quarantiney morning has given me some time to google it.

The quote in question is: If you can’t measure it, you can’t manage it.

And although they may not have said that quote, measurement is still something they had emphasized. Paul Zak (a link to his work is shared below) puts it best: So, measurement, yes. Only measurement, no.

W. Edward Deming’s case

The funny thing is what he actually said was:

It is wrong to suppose that if you can’t measure it, you can’t manage it—a costly myth.

Wow, they literally just got what was in the middle, and totally reversed the meaning. He had written this in The New Economics: For Industry, Government, Education.

Peter Drucker’s case

I came across two blog posts sharing he never actually said it.

They both linked to page in the Drucker Institute website, but that had already been moved. But the title was easy to google for, so I was able to find the page to Measurement Myopia written by Paul Zak in Jul 2013.

Wardley Mapping

I recently got hold of a link for a free course on Wardley Mapping over at the Leading Edge Forum (LEF). It’s a $25 course so that’s equivalent to about 2-5 books. I’ve previously come across Wardley Maps while going over some material in the enterprise GitHub at work, and I’ve also come across a talk from Simon Wardley in YouTube before where I remember him most for this “BLAHS” and the random strategy generator. BLAHS, by the way, stood for “Business Level Abstractions of a Healthy Strategy”. And the link to the random strategy generator is this one: https://strategy-madlibs.herokuapp.com/. So I definitely wasn’t uninterested, so I went ahead and took the online course.

I guess in a nutshell, I’d explain Wardley Mapping as a way to visualize your business (or your application) to illustrate:

  • your users’ needs
  • the components to support those needs
  • the stage or phase of the components (how new or mature)

This can then illustrate a risk like when you’re having too much dependencies on an unstable component (e.g., still in its genesis phase), or when your components are all far down towards the right and so exploring new things might be a gap you need to watch out for. The illustration can also help provide guidance like when you’re still using a custom-built solution for something that’s already highly commodified and in effect it might be costing you more to continue to push for that solution.

Some links on the topic:

On Technical Excellence

I was just thinking about this topic this morning. There’s COVID-19, anxiety on what’s been happening, bills to pay; so sure, add this into the mix. In particular, I’m thinking about how I can’t eloquently put to words or can’t stress enough the importance of technical excellence. In my head, I’m just thinking that if you want us to work fast and produce-produce-produce, what’s going to make us faster is if we actually know what we’re doing and if we’re good at what we’re doing. (I sometimes feel a slight cringe when I use that overused word, “actually”.)

Anyways, just listing out here some of this morning’s reads which I’ll probably revisit when I’m feeling more energized:

Read: War and Peace and IT

I got this book, War and Peace and IT by Mark Schwartz for $0 at Amazon.com. I think IT Revolution was holding some promotions which is how I got it for free back then so I was spared from shelling out $12.99. I bought it last May, but didn’t come around to actually opening it until this June.

We had a rocky start. The author pretending to be Napoleon Bonaparte in the Foreword section was something I found a bit too corny for my taste. So that made me put off reading it for a few more days or so. When I eventually reopened the book, I reached the section in the introduction sharing who the book is for.

Not me:

  • CEO
  • CFO
  • non-IT CXO
  • CIO or IT leader
  • Any category of business leader

And finally me: “For others in the business and IT community”

So mmmkay, I’m definitely not the main audience for this. I read it anyways. And it actually wasn’t so bad after I got over those hurdles. What I particularly like is that there’s a chapter summarizing suggested actions. So if you’re looking for one chapter to read in the whole book, go for Chapter 10: “Action Plan”.

I’ve listed out some bullet points from Chapter 10 below. For the full context though, you’ll still need to read the book. But at least this can give a starting point on whether you find the suggestions interesting enough to push through with checking out the $12.99 book.

Tie IT initiatives to business outcomes.

  • Choose a few objectives for trial.
  • Assign each to a cross-functional business/IT team that is fully empowered to execute.
  • Use impact mapping to brainstorm with the team.
  • Remove impediments.
  • Review progress often and make adjustments.
  • Celebrate success.

Shorten lead times.

  • Emphasize urgency and fast delivery.
  • Your goal is not to make people work faster or harder, but to improve workflow. Make that clear.
  • Take advantage of the cloud.
  • Ask IT to speed up the portion of delivery that is technical. This will probably involve implementing DevOps, creating reusable components, and designing secure “landing zones” in which new work can safely be done.
  • Find bureaucracy that isn’t adding value or that could be made leaner with Occam’s turkey carver. Often this includes sign-offs required from people who have no good basis for making the sign-off decision, forms that ask for unnecessary information, or controls that could be automated.
  • Becoming lean means reducing calendar time. Wait time, for example, should be eliminated, even though no effort is being spent.
  • Task switching is a source of waste and defects. Organize work so that everyone can focus. You can make this easier by keeping tasks small so they can be finished quickly.

Emphasize delivery and results.

  • Ensure that work is organized into very small units, work toward minimum viable products, and experiment to learn and test ideas.
  • Monitor results starting immediately.
  • Remove organizational impediments that resist quick shipping.
  • It may be easier to begin “working small” by modifying an existing system.
  • “Shipping” means that people start using the product. Prototypes and demos aren’t shipping (although they might be valuable steps on the way).
  • Don’t be afraid of disruption from shipping quickly. The idea is that by shipping quickly and frequently, each shipment is very small, and is consequently low-risk.

Treat requirements as hypotheses.

  • Read the Side Glance on humility! [this is another chapter in the book]
  • Question assumptions by asking how they can be tested.
  • It’s better to put effort into testing an idea than to risk not testing it.
  • A/B testing (where some users are shown version A, some version B, then the results are compared) is very effective and might be easy to set up.
  • Be sure that the test subjects are the same people who will be using the product—not, for example, managers or people within the product team.