Coleman McCormick

Archive of posts with tag 'Teamwork'

February 4, 2024 • #

Look back less →

Jason Fried:

A better path is to reflect forward, not backwards. Develop a loose theory while working on what’s next. Appreciate there’s no certainty to be found, and put all your energy into doing better on an upcoming project. But how will you do better next time if you don’t know what went wrong last time? Nothing is guaranteed other than experience. You’ll simply have more time under the curve, and more moments under tension, to perform better moving forward. Internalize as you go, not as you went.

✦

Process vs. Practice

May 2, 2023 • #

In product development, you can orient a team toward process or practice. Process is about repeatability, scalability, efficiency, execution. Practice is about creativity, inventiveness, searching for solutions.

Choosing between them isn’t purely zero-sum (like more practice = worse process), but there’s a natural tension between the two. And as with most ideas, the right approach varies depending on your product, your stage, your team, your timing. In general, you’re looking for a balance.

Divergence and convergence

I heard about this concept on a recent episode of the Circuit Breaker podcast, with Bob Moesta and Greg Engle. A recommended listen.

In the discussion Bob mentions his experiences in Japan, and how the Japanese see process differently than we do here in the US:

A lot of this for me roots back to some of the early work I did in Japan around process. The interesting part is the difference between the way the Japanese talked about process was around the boundaries by which you have control.

The boundaries of the process basically say that you have responsibility and authority to change things inside that process, and that it was more about continuous improvement, changing, and realizing you know there’s always a way to make it better, but here are the boundaries. When it got translated over to the US, it got turned into “best practices” — to building a process and defining the steps. “These are ways to do it. I don’t want you to think. Stop thinking and just do the process and it works.” And so what happens is that most people equate making a process to not thinking and “just following the steps”. And so that’s where I think there’s this big difference is that at some point time there’s always got to be some deeper thinking inside the process.

Process assumes there’s a linearity to problem-solving — you program the steps in sequence: do step 1, do step 2, do step 3. At a certain stage of maturity, work benefits from this sort of superstructure. Once you’ve nailed the product’s effectiveness (it solves a known problem well), it’s time to swing the other way and start working out a process to bring down costs, speed things up, and optimize.

So what happens when a team over-indexes on process when they should be in creative practice mode?

A key indicator that it’s “practice time” is when you’ve got more unknowns than knowns. When there are still more unanswered questions than answered ones and you try to impose a programmatic process, people get confused and feel trapped. If you start to impose a linear process before it’s time, your team will grind to a halt and (very slowly) deliver a product that won’t solve user problems.

Too much process (or too early process) means you don’t leave room for the creative thinking required to answer the unanswered.

Legendary engineer and management consultant W. Edwards Deming had a saying about process:

“If you can’t describe what you do as a process, then you don’t know what you’re doing.”

But I love that Moesta calls this out, which I agree with. The quip overstates the value of process:

“But that doesn’t mean that if we can describe it as a process that we know what we’re doing. We can have a process and it doesn’t work!

The best position for the process ↔ practice pendulum is a function of your need at a point in time, and the maturity of your particular product (or feature, or function). In general the earlier you are on a given path, the less you should be concerned with process. You need the divergent-thinking creativity to search the problem space. You’re in “solve for unknowns” mode. In contrast, later on once you’ve solved for more of the unknowns and have confidence in your chosen direction, it’s beneficial to create repeatability, to shore up your ability to execute reliably. At that point it’s time to converge on executing, not to keep diverging into new territory.

Back to Bob’s point about process meaning “no thinking inside the process”, perhaps we could contrast process and practice by the size of the boundaries inside which we can be divergent and experimental. When we need to converge on scalability and consistency we don’t want to eliminate all thinking, just shrink down the confines of creativity. Even at this point in a mature cycle, the team will still encounter problems that we need them to think creatively to navigate — but the range of options should be limited (e.g. they can’t “start over”). When our problem space is still rife with unanswered questions, we want a pretty expansive space to wander in search of answers. If our problem space is defined by having Hard Edges and a Soft Middle, at different stages of our work we should size that circle according to how much divergence or convergence we need.

All this isn’t to say that during the creative, divergent thinking period that you should have an unbounded lack of structure to how you conduct the work. Perhaps it’s better to say that at this stage you want to define principles to follow that give you the degrees of freedom you need to explore the solution space.

✦

Against Recurring Meetings

October 5, 2022 • #

I have a bone to pick with recurring meetings. They’ve become a scourge that’s been amplified with fully distributed teams. What may start with clear intent as a space for a team to coordinate continuous work eventually devolves into a purely ceremonial affair. And they’ve gotten 10x worse since the pandemic turned every meeting into a remote one. This effect was visible long before COVID, but I think remoteness has magnified the negatives without adding any positives.

Recurring meetings

Since no one has to book a conference room, the bar to generating tons of ceremony “sync” sessions has dropped to the floor. Even worse, remoteness makes a bloated 15-person meeting not feel any bigger than the 4-person meeting it should’ve been. In person, the bloated attendee list would be an obviously bad idea — very few meetings should leave some attendees with standing-room-only.

These meetings show up on the calendar with positive intentions. A subset of folks from different teams might need to regularly stay in touch with one another on specific projects, or perhaps there’s always some active work to be coordinated. Maybe it’s a stand-up intended to be a high-signal-per-minute short session to sync team members as quickly as possible1. There are good reasons the repeating function exists. But it’s overused. The decision to spawn a cross-functional recurring meeting isn’t considered deeply enough in terms of the cost, and the long-term purpose. Almost every time I’ve seen one appear on my calendar, there’s triggering project or event that compels someone to create it.

The “value per minute” of a recurring meeting might start high, but it decays over subsequent weeks. It’s like there’s a half-life on the value of a particular meeting, with its potency to get work done and problems solved waning substantially by month 3. But why does this happen so often?

For one, they’re too easy to create, and too hard to cancel. It requires the team as a whole to fundamentally not want to have the meeting, to be in favor of a meeting because it needs to happen. Gradually the utility : time ratio degrades, people get less and less out of their weekly session and are less engaged, just going through the motions. The whole group (especially meeting-originators) need to be on the lookout for ways to obsolete the need for having the meeting in the first place. I liked this from Aakash Gupta on Twitter, who says “meetings are like gravity”:

Different personalities and roles have differing preferences for what medium to use for each type of work. Some will always lean toward a meeting to communicate. Some want long-form writing. Some like incessant email chains. Choosing the right medium is Step One to escaping the recurrence gravity well. To quote myself from a previous post, meetings are just one medium for communicating and getting work done. A core contributor to “meeting fatigue” is when we’re choosing the wrong medium for work:

I know when I find myself in a useless meeting, its “meetingness” isn’t the issue; it’s that we could’ve accomplished the goal with a well-written document with inline comments, an internal blog post, an open-ended Slack chat, or a point-to-point phone call between two people. Or, alternately, it could be that a meeting is the optimal medium, but the problem lies elsewhere in planning, preparation, action-orientation, or the who’s who in attendance.

So what to do?

I recall this interview with Shopify founder and CEO Tobi Lutke. He mentions how they periodically mass-delete all recurring meetings from the corporate calendar:

That was a tangent, but to get back to the question you asked, we found that standing meetings were a real issue. They were extremely easy to create, and no one wanted to cancel them because someone was responsible for its creation. The person requesting to cancel would rather stick it out than have a very tough conversation saying, “Hey, this thing that you started is no longer valuable.” It’s just really difficult. So, we ran some analysis and we found out that half of all standing meetings were viewed as not valuable. It was an enormous amount of time being wasted. So we asked, “Why don’t we just delete all meetings?” And so we did. It was pretty rough, but we now operate on a schedule.

I don’t know if this is apocryphal or real, but it’s an interesting experiment in refocusing. Like a brush fire that clears the undergrowth for new life.

A few things we could do to minimize meetings, to force more thoughtful selection of medium for the message:

  • Make fewer in the first place — Seems obvious. Can we just do 1? If one isn’t enough, can we just schedule 3 and go from there?
  • Set end dates - 1 month, 3 months, whatever. This function exists, but I don’t think I’ve seen it used once in my career. The normal move is to say “we’ll cancel it later if we need to.”
  • Don’t make anything? — Do we even need to meet? Could it have been an email? Do you need to write up thoughts/ideas? Maybe record a Loom? Make a Miro board?
  • What if calendar tools let you see how many collective hours you’re scheduling? “For the next 1 month, this schedule will cost 60 hours of human time.” Not that this would stop some people, but may make you do a double-take to see the volume of time you’re about to commit.

Tyler Cowen says “context is that which is scarce”, meaning that we’re never lacking in information in our modern lives, but the means to make productive use of the information. Meetings often stem from people lacking context. The craving for context — to have a window into what’s going on, why it’s happening, and what to do next — generates temptations to “set up a quick meeting”. And if we know something is too big a topic for a single session, it’s too easy to say “let’s sync up weekly on this”.

A lot of coordination between people is about setting or sharing context. “Syncing up” is about sharing context. You can lean on recurring meetings to share context, which is occasionally okay if meeting trade-offs are worth it (in time required, efficiency). But sometimes we choose the wrong method for context-sharing between teams, and the need for too many meetings is merely a symptom of poorly-communicated context.

  1. I think short standup-style meetings, 10-15 minutes, are fine for the most part to recur. Of course there are alternative methods for getting the same job done (mutual info sharing between team members), but a quick call is fine. Tools like Loom show some promise to even make these obsolete, making asynchronous collaboration simpler. ↩

✦

Don't Confuse Motion With Progress

January 13, 2022 • #

When I read Cal Newport’s Deep Work a few years ago, one of my favorite ideas in the book that I keep coming back to in conversations is the idea of “busyness as a proxy for productivity”. Here’s how he puts it:

In the absence of clear indicators of what it means to be productive and valuable in their jobs, many knowledge workers turn back toward an industrial indicator of productivity: doing lots of stuff in a visible manner

We’ve all worked with violators of this. People that always have fully-booked calendars, can never find a time to get tasks done, and constantly talk about how busy they are. One of the reasons people do this, whether subconscious or not, is that in the world of knowledge work, it’s seen as a virtue to be busy. “Man, that guy is always in high demand, it’s impressive how many things he’s doing every day.”

But behind the scenes, the impact of each unit of time spent “being busy” is miniscule. It’s a classic mismanagement of time and attention, but one that has obvious roots given the incentives in business to be seen. And when a behavior is rewarded, in this case with attention and sometimes even respect, it perpetuates.

But we're moving!

So let’s talk about motion. Busyness is a form of motion, usually described in an individual context. Motion and progress are terms that apply more at a team or organizational level. What is progress anyway? Clearly progress isn’t just “Stuff Happening.” There’s got to be an outcome for any of it to be worth it. There should be specific and consistent directionality to goals, and measurable steps to get there.

The motion of the team doesn’t necessarily tie back to an outcome anyone cares about, though.

One example where this happens in practice is the infamous Recurring Coordination Meeting — the Standup, the Check-In, the Sync Meeting. Someone sets up a weekly recurring meeting, often with few specifics as to the outcomes expected from each one. In subsequent weeks, the team now pulls itself away from other duties to distract itself with Another Meeting. Now I’ve rarely met anyone who enjoys these kinds of meetings in the absolute sense. At best we tolerate them, or see them as some form of ritual necessity. But so often some initial hangup or friction point triggers someone to decide “we need to stay in sync on this topic”, and they make the Check-In Meeting. In a snap we’ve committed several people to an unknown number of future hours for an often poorly-defined expectation. We’d have been better off with one-off meetings until we feel the team going wayward again, if we need to regroup.

An aside: I remember an anecdote about Tobi Lutke, CEO of Shopify periodically deleting all recurring meetings to reset commitments. Like a brushfire routinely clearing the corporate undergrowth of recurring time-sinks that may have long since outlived their usefulness.

But let’s get back to the “motion” piece of this. You’re now meeting once a week on a subject, and because the time since the last one is so short, you end up discussing the same topics again and again. You run through a loop with each meeting, repeatedly discussing the same things, with a tad more detail each time. Because we’re touching the topic regularly, sometimes beating the same topic to death in more than one of these meetings with different permutations of attendees, we feel like we’re “doing a lotta stuff”. We’re moving around, Trello cards are getting edited, Jira tickets are moved up and down the list, a few commits get made. But none of these motions are, necessarily, indicators of actual forward progress along the line we want. They might be, but they just as likely make us feel like we’re making progress when we’re really not.

I can get in the car and drive around the block over and over. Motion is happening, but am I getting anywhere?

Just measuring ticket throughput, or cycle time, or stories-per-sprint, or any other metric doesn’t mean you’re making progress in any meaningful sense. Those metrics might be directionally positive, but are they doing the thing you think they’re doing?

It’s imperative to have good yardsticks by which to measure progress, rather than motion.

✦

On Effectiveness vs. Efficiency

July 26, 2021 • #

“Efficiency is doing things right; effectiveness is doing the right things.”

— Peter Drucker

People throw around these two words pretty indiscriminately in business, usually not making a distinction between them. They’re treated as interchangeable synonyms for broadly being “good” at something.

We can think about effectiveness and efficiency as two dimensions on a grid, often (but not always) in competition with one another. More focus on one means less on the other.

That Drucker quote is a pretty solid one-line distinction. But like many quotes, it’s concerned with being pithy and memorable, but not that helpful.

Effectiveness

“Doing things right” is too amorphous. I’d define the two dimensions like this:

  • Efficiency is concerned with being well-run, applying resources with minimal waste; having an economical approach
  • Effectiveness is a focus on fit, fitting the right solution to the appropriate problem, being specific and surgical in approach

Where would speed fit into this? Many people would think of velocity of work as an aspect of efficiency, but it’s also a result of and an input to effectiveness. When a team of SEAL operators swoop in to hit a target, we’d say that’s just about the pinnacle of being “effective”, and swiftness is a key factor in driving that effectiveness.

Let’s look at some differences through the lens of product and company-building. What does it mean to orient on one over the other? Which one matters more, and when?

A company is like a machine — you can have an incredibly efficient machine that doesn’t do anything useful, or you can have a machine that does useful things while wasting a huge amount of energy, money, and time.

With one option, our team leans toward methods and processes that efficiently deploy resources:

  • Use just the right number of people on a project
  • Create infrastructure that’s low-cost
  • Build supportive environments that get out of peoples’ way
  • Instrument processes to measure resource consumption
  • Spend less on tools along the way

With this sort of focus, a team gets lean, minimizes waste, and creates repeatable systems to build scalable products. Which all sounds great!

On the other dimension, we apply more attention on effectiveness, doing the right things:

  • Spend lots of time listening to customers to map out their problems (demand thinking!)
  • Get constant feedback on whether or not what we’re making helps customers make progress
  • Test small, incremental chunks so we stay close to the problem
  • Make deliberate efforts, taking small steps frequently, not going too far down blind alleys with no feedback

Another great-sounding list of things. So what do we do? Clearly there needs to be a balance.

Depending on preferences, personality types, experiences, and skill sets, different people will tend to orient on one of these dimensions more than the other. People have comfort zones they like to operate in. Each stage of product growth requires a different mix of focuses and preferences, and the wrong match will kill your company.

If you’re still in search of the keys to product-market fit — hunting for the right problem and the fitting solution — you want your team focused on the demand side. What specific pains do customers have? When do they experience those pains? What things are in our range that can function as solutions? You want to spend time with customers and rapidly probe small problems with incremental solutions, testing validity of your work. That’s all that matters. This is Paul Graham’s “do things that don’t scale” stage. Perfecting your machine’s efficiency is wasted effort until you’re solving the right problems.

A quick note on speed, and why I think it’s critical to being effective — if you’re laser-focused on moving carefully and deliberately to solve the right problem at the right altitude, but not able to move quickly enough, you won’t have a tight enough feedback loop to run through the iteration cycle enough over a period of time. Essential to the effectiveness problem is the ability to rapidly drive signal back from a user to validate your direction.

When you find the key that unlocks a particular problem-solution pair, then it’s time to consider how efficiently you can expand it to a wider audience. If your hacked-together, duct-taped solution cracks the code and solves problems for customers, you need to address the efficiency with which you can economically expand to others. In the early to mid-stage, effectiveness is far and away the more important thing to focus on.

The traditional definition of efficiency refers to achieving maximum output with the minimum required effort. When you’re still in search of the right solution, the effort:output ratio barely matters. It only matters insofar as you have the required runway to test enough iterations to get something useful before you run out of money, get beat by others, or the environment changes underneath you. But there’s no benefit to getting 100 miles/gallon if you’re driving the wrong way.

Getting this balance wrong is easy. There’s a pernicious aspect to many engineers, particularly so in pre-PM-fit products: they like to optimize things. You need to forcefully resist spending too much time on optimization, rearchitecting, refactoring, et al until it’s the right time (i.e. the go-to-market fit stage, or thereabout). As builders or technologists, most of us bristle at the idea of doing something the quick and dirty way. We have that urge to automate, analyze, and streamline things. It’s not to say that there’s zero space for this. If you spend literally zero time on a sustainable foundation, then your product clicks and it’s time to scale up, you’ll be building on unstable ground (see the extensive literature on technical debt here).

There’s no “correct” approach here. It depends on so many factors. As Tom Sowell says, “there are no solutions, only trade-offs.” In my first-hand experience, and from sideline observations of other teams, companies are made by favoring effectiveness early and broken by ignoring efficiency later.

✦

Team Objectives →

March 13, 2020 • #

Marty Cagan’s SVPG has a good series on team objectives covering a broad range of topics related to product team goal-setting and execution.

As we work on implementing an OKR model internally, I’ve been thinking about how to understand the literature you read out there about various companies and their successes or failures with the framework. In my reading, I like the concept of OKRs for two primary reasons:

  • Clarity & transparency across the entire team, with intertwined, connected goals and targets
  • Using them as a forcing function to think about the road ahead to, most importantly, explicitly define the things you won’t focus on

This bit stuck out in the overview post:

It’s no secret that most of the leading tech product companies use the OKR technique, or one of the variants. And it’s also no secret how much success these companies have had.

Yet people are confusing correlation with causation.

Those successful companies aren’t successful because they use OKR’s. They use OKR’s because it is designed to leverage the empowered product team model.

Seems obvious that a system and set of acronyms doesn’t guarantee success, but it’s easy to gloss over that the real hard work is being thoughtful and explicit about your plans and focuses. An empowered team is a stronger one, able to get their hands around problems and define their own path.

I’m currently in the middle of The Phoenix Project, a novel about an IT department rebuilding their organization in response to business crisis (I know, it sounds weird, but it’s actually an excellent book). One of the best bits so far is the concept of “hidden work” that the characters have to overcome. Without proper transparency and commitment, hidden work runs amok. People asking for “quick favors” across teams, boring tasks, technical debt. There are plenty of these sorts of things in any company — sometimes important, sometimes not so much, and occasionally unavoidable — but if we can reduce, or at least expose the hidden work, we can something about it. It’s like churn in a SaaS business: a hole in the bucket draining out what you’re putting in. Only in most product development work, it’s often invisible.

✦
Browse the full archive →
✦