Leadership – PM'ing

The PM-o-Matic

At my first software industry job (Cataphora, an enterprise search and NLP startup), the CEO, Elizabeth Charnock, ran an in-house leadership training program, which was mostly just her sharing her thoughts on leadership. One of her main messages was that management was about being willing to make decisions, even though you’re probably wrong. You should try to make an informed, fair, optimal decision, but you very rarely have that privilege. Most people’s decisions are not optimal most of the time, and you should get used to, rather than fear, being wrong. The worst thing you can do in the face of incomplete information was abdicate making a decision. Being afraid of being wrong, and making the implicit or null choice was far more fatal. Her key to getting comfortable as a manager was to get comfortable making decisions even in the face of uncertainty and disagreement.

Fast forward a few years, and I was a first time product manager, in a mid-size mobile startup, where there were no other product managers or pre-existing patterns to follow. People from different functions would come ask me classic product questions, “can this product do this thing we thought of?”, “I need to tell a client this feature will be ready in a month, will it be?”,”whats the status of this bug thats annoying me?”, “can I cut this use case out, it will save days of development”… and so on… and on.

I tried to document and delegate, but when cornered, to answer questions and make decisions the best I could: informed and goal-focused. But I also remembered that leadership training. It was important to me to never abdicate a choice brought to me. Not to always have the answer, but to always be the decider or the delegator. But I also heard, and found to be true, that this was a mentally exhausting way to live. After a month or two my engagement with these small day-to-day decisions began to flag. I also read, around this time, that there is a limited amount of cognitive effort available in a given day, and decision making burns a lot of it. Some execs handle this by wearing identical clothes every day, sticking to strict life patterns, and otherwise trying to minimize the unimportant decisions they make. I decided that my way to handle this would be to take a piece of cardboard about the size of a piece of copy paper, and use a marker to write YES on one side, and NO on the other. Then, when someone came to me with a question, or decision point that I thought was basically a toss up, or where I needed to preserve my mental space and energy, I would flip the PM-o-Matic in the air, like a giant coin, and that would be my answer. Really.

I’m not sure how often it served as just the starting point to a conversation or negotiation, and how often its decisions actually stood, but I do know I felt like I was leading, but that some of the mental burden was off. Oddly, most people didn’t mind, its ridiculousness became a way to diffuse sometimes tense discussions, and mostly they were just happy to have a clear answer.

Two years after I left, I got a text from a former co-worker. It was a picture of the PM-o-matic. She had saved it after I left, and was now leaving too. She said she always appreciated my use of it to resolve questions quickly and with a sense of humor. I don’t use the PM-o-Matic anymore, and it’s certainly not something that would pass muster in a sophisticated product organization. But I’d still recommend it over making no decision.

Essential Cycle Meetings

Although the frequency, length and details may vary, there are some regular gatherings which I think are fundamental to building and maintaining “flow” in a high functioning software team. Here is my list of essential cycle meetings:

Grooming – Triage new tasks from your inbox (your task inbox, I mean). Assign all tasks a priority, and sort into backlog or active development flow. If there are no inbound tasks, review backlogs in priority order, closing or refining tasks only. Grooming can be a PM solo activity, a team leads activity, or open to the full team. Generally, it’s a waste of most people’s time, though. But for PMs and team flow, it is vital.
Planning – I prefer to do this weekly, but bi-weekly can work. This is the core team meeting. You can use it to review planned work, or work in progress. This is also the forum for longer presentations and proposals, and to have medium scale planning discussions. Always track action items and decisions, or have someone who does.
Stand-ups or Syncs – Short meetings to discuss the state of work and identify any blockers to progress. Lots of people like the “yesterday, today, blockers” standup format, where each team member gives a very brief overview of their work yesterday, today and brings up anything blocking their progress on current or upcoming tasks. Slightly longer sync meetings can also be useful. In that format the focus is often on the board and the progress of priority tasks, and burn-down, rather than team member status. This is particularly useful if deadlines are looming or as complex products, features or releases are in the “coming together” phase.
Retros – Facilitated discussions of the good, the bad and the ugly. If your group or organization doesn’t have people who can act as facilitators (scrum masters, project managers, etc), be sure to use a standard format, to avoid the temptation to monopolize the conversation, or play the process “by ear”, and thus bias it. The most important meeting if you want to improve the team, yourself or your product.
Walk-throughs – Walk throughs are a way for the team to “walk in the shoes of the user” together and collectively identify issues. This is especially good for improving “polish” and usability quality, but isn’t necessary for day-to-day changes. See this essay which gets into detail about this process.
1:1s – have at least 30 minute 1:1 with each team member and key partners or stakeholders every week or two. Always have something prepared to talk about, even if its social, but always defer to the other persons agenda, if they have one. Good meetings to have walking, drinking or eating.

Leading without Authority

One of the greatest challenges of PM’ing for people is often leading without authority. Generally, people do not report to you, and in some cases may report to people opposed to you or your goals. How do you get these people to execute? This is something I particularly see more business and analytical PMs struggle with. They know the theory, and they have a vision, but they struggle in the day to day of leading a team. If they can rely on their team leads and the culture, they can still execute, but it makes things hard. So, how do you get people listen to you when you are not their boss?

Power resides where men believe it resides. Its a trick.

There are libraries full of books and years worth of seminars and videos to teach you, but here’s some thoughts, techniques and observations:

Build Trust – This is the most important thing at the beginning. It is a prerequisite for all action and collaboration. It’s a cliche that trust is hard to build but easy to lose. But it is possible to build and rebuild trust: be reliable, be genuine, admit mistakes, don’t gossip or badmouth team members behind their backs, find a common enemy.
Genuinely Listen – If you’ve got a strong outgoing demeanor (a “type A” personality), or a strong vision and sense of self-direction, it can sometimes be difficult to stop, listen and really engage with people. Listen to feedback. Don’t interrupt. Admit where you agree first, before providing any defense. Listen to suggestions with patience, and don’t multitask when team members are giving their suggestions. Listening is not committing, and it is almost always worth the time.
Servant Leadership – It’s a real thing. Be the person who volunteers when no one else does. Clean up after people. Be the first to take blame and the last to take credit. It sets a good example, but it also gets you pile of goodwill.
Persistance – There’s really not much more to it. Be more determined than the others. Outlast any objections, politely declining to give in.
Take People Individually – For example, don’t treat engineers as interchangeable code machines. Learn what people are good at, and what excites or motivates them. Even if you can’t always accommodate them, the fact that you “know” them goes a long way. It also obviously helps in planning and assigning work to have this kind of understanding of your teammates.
The Shit Umbrella – Everyone knows this one, and it’s important to not overly isolate a team that needs context for motivation and planning. But keep out some of the noise of organizational politics. And above all take on the brunt of top down demands and scrutiny.
Trading Goodwill for Favors – Even just among a small core team, in many ways you’re playing very small scale politics. And, like all political systems, the core is the trading of favors. Don’t ask for petty shit and don’t cash in goodwill until you need to. But when you do, don’t be shy or reluctant to do so. Be genuinely kind and helpful, but call in your chits when the time comes.
Handling Dissent – How you handle teammates who disagree with you or your decisions plays a major role in how well the team will collaborate and work with you, rather than for or against you. Never make it personal. If someone is, or is being overly aggressive or persistent, take it to a 1:1, or their boss. Use data and evidence to disagree, when ruling against someone or their position. Never say “because I’m the PM”.
Did I mention persistence? People admire it, as long as you’re also open minded and delegate.

Essentially Metaphor

The intellectual core of managing the development of software is the editing of metaphor and analogy. If you strip away the business and team management components, the job of defining and iterating on a piece of software for people to use is essentially about creating, selecting and enforcing a bundle of metaphors.

This is because software, by its nature, is abstract. Crash Course’s excellent series on Computer Science even has a little recurring animation they play each time they move up a level of abstraction in the computing stack. The fact that this happens so often as to warrant a special bit shows how core this process of intellectual leaping “up” the chain of metaphors is to computing.

From my perspective, as someone trained in cognitive science and linguistics, Lakoff and Johnson‘s observation about the necessity of metaphors in abstract thinking and communication is exemplified in the way computers and humans interface. In this medium, there is almost no physicality (and as voice agents grow, the physical aspect of computing is further reduced into the purely audial). All understanding must map, though metaphors and mental models, to some experience of the real world.

No where is this more clear than the concept of skeuomorphism. This is the application of the visual look of real objects to their software analogs, on the theory that people will recognize and bring their intuitions from the real world into their new experience. This style fell out of fashion, the reasons for which are a whole other essay about dialectics and technology as fashion. But it is the easiest entry point for those looking to understand the importance of analogies to interfaces.

Another pervasive cognitive metaphor used in software is the “___ is a journey” analogy. A user story is a “journey” for the user. This makes some sense, but like all structuring metaphors it has a lot of implications and entailments that people wielding this metaphor are often not aware of. Users may wander on and off the path. They may never make it to a destination and still be satisfied. Not all who wander are lost.

As new interface paradigms become common, or as your UX designer pushes for some new pattern or another flow change, always watch the metaphors. The more consistent and intuitive the metaphor, the more productive the implications, the better. One thing that sets apart “product people” is not necessarily that they are inventive, but that they can crystallize an emergent abstraction. What does that mean? It means they can see the metaphors and analogies others are unconsciously relying on. They can identify the contradictions and tensions between competing analogies. They can empathize with the cognitive effort understanding a metaphor takes, and feel if it serves users well, or just adds confusion. They can look for commonalities, and take stories, features and technologies into a new level of abstraction.

PM’ing in public

I work at a beautifully weird organization. The Wikimedia Foundation is transparent to the outside world in ways most people, even people who know our work (not the projects, but the Foundation) or support it through donations, don’t know.

For a PM, the idea of doing our job in public can be a bit of a challenge. Many PMs operate best in 1:1s and manipulating the flow of information. If things are transparent, not just internally, but, literally, public (as in both free to use/copy and viewable in the internet “commons”), how do you differentiate, prototype or otherwise get the element of surprise, so skillfully deployed by Apple and others? Well, you don’t. You accept that your goal is to be seen and copied, just like our contributors’ photos on Commons, our research, designs and products are to be shared, in the very hope that they will not just be seen and used, but copied and remixed.

But also it means all your tickets, even your teams RETRO NOTES, are there for anyone to see. Dad want to see your teams quarterly update for the executives? Future employer want to see a product proposal you wrote? It’s possible.

At first it weirded me out. I had expected to be reporting regularly to the public (it is a charity, and a place known for advocating transparency on the internet.) I had not expected to have my meeting notes made public by default, or the staff meetings to be streamed live to the world. Now it seems normal. But I had to gain confidence in what I was doing and remember every fucking day that nobody is perfect. My unfinished specs, tasks open and assigned to me way too long, flimsy rationales, sometimes aggressive politicking, they are all there for you to see, but they are not that unique. At least that’s what I tell myself. Plus, what you find is that, like your personality flaws, most people don’t give a shit, or even see the same shortcomings you see in yourself. We’ve had fewer than 50 people ever come comment or get involved with any of the public work my team has produced over 2 years (not counting code contributors). No one has time to read your specs.

And on the other hand, I get to do a job that’s usually among the most “proprietary” in the world, and do it in public. I wish more orgs would let their teams do their process in public. When there is no competitive advantage to secrecy, I think there could be great value to our profession, and the products we create, if more people who make great software could be truly open about their process.

To illustrate the level of transparency I’m talking about, you can see the “dark mode” feature’s development on wiki, Phabricator (our task management system) and public google docs. Not because we set out to do so, but because it is the default. From the planning meeting when the team first prioritized the feature. To the task tree, including the initial design thinking , the interactive prototype, design research presentation, the tech scoping, the implementation and iterations and bugs, the user testing and evaluative research, the QA test plan, the regression testing results, the public mailing list announcement of the beta test, my draft of the App Store text, the release checklist for actually pushing out that version, the clean up tasks in the following bug fix release, a post launch review and analysis I did for my peers, the quarterly report where I took a victory lap for the positive response, and the draft and final the blog post where my team leads wrote about how we approached all this. And that’s not even all the fingerprints of this thing on the public internet. This for a simple (but important) feature. All teams have these kinds of digital artifacts, ours just happen to be public.

If you’re new to product management, curious how it works, or just nosy about Wikipedia and Wikimedia, I recommend checking out some of our easier to digest stuff: our monthly metrics meeting (always streamed live on YouTube), our quarterly meetings, decks and notes, or check out the many links I posted about dark mode. It’s far from a perfect, or exemplary, organization, to be transparent about it. But at least its flaws, like my own as a PM, are all there to be seen, discussed and hopefully improved.

Participatory Product Management

The reasons to make your product management and planning processes more participatory is a subject for another essay. Suffice to say, it’s something I think has powerful payoffs and, for me, is a strong cultural preference. By participatory, I mean involving other people in research, planning and even decision making in a real, genuine way. Anyone can ask for feedback, are you confident that you sold your strategy well internally? Let people vote anonymously, it may surprise you.

I’ve been lucky to work as a cofounder, in small orgs and now in a collaboration focused medium sized org, so I’ve had some practice at it. Here’s some tips for making your product management more broadly participatory.

A Few Ideas

I strongly recommend you adopt a kanban[LINK] or similar queue based work process. Don’t be dogmatic about it, but kanban is based on a pull queue and allows skilled team members to manage their own pace and have a sense of ownership of the tasks they take on. At the same time it allows you to maintain prioritiy and context. I believe scrum systems, in particular any system which requires negotiated sprint commitments is detrimental to the PM’s relationship with the team. It sets you outside the team and is focused on a tension (the scope the product owner wants vs. what the team thinks it can do).
I like to have teams perform a product self-evaluation. We pick a set of aspirations for our product or ourselves, (“sticky”, meaning hitting a certain user retention,”stable” which we’ll define to mean a certain crash rate). Prior to long term planning processes, we anonymously rate the product from 1-10 on these aspirations. This allows everyone to see how their peers feel about what they’re building together. It also can help to focus planning discussions if there is obvious consensus on the areas needing most improvement.
No spectators. All team members should participate in as many process meetings as possible. Design, QA, data analysts, ops, research… anyone who builds, rather than sells, the product should be at stand-ups, planning and retros at minimum. Then, run inclusive meetings. Open up the floor to everyone. Call people out in positive ways, especially if they are marginal (ie. not a lead or core member). Don’t let interrupters and loud mouths dominate. Don’t let men talk over women. Encourage introverts and non-native English speakers to follow up over email or in 1:1s where they might feel more comfortable participating genuinely. It takes work to participate, and it can be a great gauge of engagement and commitment. But in enabling and evaluating participation, be very aware of bias and culture.
In very healthy situations you can actually allow teams to vote on their priorities and it doesn’t turn out horribly for everyone! Here’s how it works: you’ll need a team that has a strategy and is bought into it, has some rough consensus (or a couple is okay), and a reasonable ratio of different functions (ie. this doesn’t work if their are 8 backend engineers, 1 frontend and 1 designer). I have used a weighted voting process to mixed effect, depending on the team, but sometimes resulting in a better plan and very high level of team commitment and deliver.It can be done in person or on a hangout, but in person is more effective at the emotional bonding and buy-in. This is a good activity to do at a retreat or off-site.

I do this after status and strategy presentations and discussions. This puts people in the right frame of mind, and reminds them there are shared goals and constraints they are operating under.
I write up potential epics on large post-its and put them on a wall.
The team write their own proposed epics and post them on the wall. People can ask questions about the scope and meaning of the proposals, and posposals might be edited, split or grouped at this stage.
I move any “must deliver” epics into the “approved” area of the wall. Try to limit these to existing/carry-over commitments and executive mandates.
Assign a budget of dots/stickers/votes to each team member. People can then vote by placing the dot/sticker/vote on a post-it. They can use their votes in any distribution they want, so they could put all their votes on their biggest priority or distribute their votes. Seeing how team members assign their votes and how they allocate their budget can be very revealing of people’s priorities and interests. Don’t forget to vote yourself 🙂
Remove any epics that received no votes. Allow each team member to assign one additional vote.
Guesstimate the capacity for the planning period (weeks of work is a good level of estimation). Order the winners by vote. For each do a very rough on the spot scope and estimate (again a week is a good level of granularity). Do not record these estimates and DO NOT USE THEM as commitments. DO use them to determine how far down the list to go. Move a reasonable number of epics to the approved area.
Review dependencies of the approved epics and identify tasks to be filed and next steps for each. Follow through. When you set up a road map, board or whatever manifestation “planning” has for you, be sure to point out the effect of the voting on the resulting roadmap.

Warnings

Don’t waste time being participatory if you don’t need or want to; only be genuine. It’s worse to tell people they have a say but actually dictate than it is to just dictate and be done with it.
These kinds of approaches and cultures are not great for making deadlines. But that doesn’t mean they are slow. In fact, I would posit that the velocity and agility of participatorily planned teams is greater than command and control or scrum-negotiation teams. Particularly for startups or where pay is lower and thus you need alignment via shared intrinsic motivation, rather than carrot/stick compensation and corporate laddering.
Introduce and practice these things cautiously and iteratively. Always retro. I cannot say that enough. But as you practice and iterate, also learn the nuances and tools available to you to subtly manipulate the outcomes, based on your particular skill, personality and context. Be genuine. Respect the outcomes of votes and take input seriously. Don’t try to damn the river. Learn how to channel it.

First of all, I love it; second of all, no.

One of the hardest parts of being a PM, in my experience, is embracing the needful thing of saying no… all the time.

It’s a sad contradiction that when you employ and empower creative people, you will then often have to stifle the same impulses they also thrive on. This means: the better the team, the more often you may have to tell people who are smarter or better at their jobs than you, “no”.

One aspect of managing this tension is knowing when to when to shut something down or let it play out, especially an early idea or loose talk. There is no formula for this. You have to know your team and the person who’s idea it is. If you constrain all thinking you get mindless pap, and work is a tiresome chore. But ideas can be dangerous. When an idea contradicts or undermines a core strategy or goal, it can be worth pointing that out early. If it’s more ambiguous or tangential, it matters less. Just be aware of who takes ideas too far, or can become obsessed with their own idea at the expense of the team or it’s goals. And, accept that creativity and smart people are risks to rigid plans.

To me, the hardest interpersonal aspect of managing with space for creativity is saying no without crushing people’s dreams. Especially if a shy or introverted team member is making an effort to express an idea. Be direct, don’t lead them on if the idea won’t be pursued. But also be encouraging, use a compliment sandwich, and let them know the reasons, if you can. Giving credit when someone does bring something to the table that ends up having impact, also is key. It’s ethically good, but it’s also a way to encourage similar efforts in their peers.

You might not be able to stand up to people, or to be able to tell the well meaning, shy, engineer his prototype he spent his weekends building won’t be turned into a product. Then you probably need a different career. Being a PM means saying no. If you’re not saying no (nicely), all the time, in all directions (up, down and to peers) you won’t last long.

Of course, don’t always say no! Don’t be a closed minded stubborn ass. Just be comfortable, or at least capable, when you do need to say no. You can also reduce the amount you have to say no by reducing distractions and by having strong buy-in from the team on strategy and goals. The more you can positively constrain their cognitive labor, the less you’ll have to do this. In particular, I have come to dislike open brainstorms. I believe they rarely result in anything useful, and there are many more effective processes for group ideation and creative thinking. They are political minefields in dysfunctional orgs, as well. Similarly, I am a big fan of concepts like hack-a-thons and ideas like 10% time, which encourage safe spaces for creativity, rich in cross-pollination and skill sharing. BUT, I’ve seen them go very wrong when there becomes an expectation that side projects, or hack-a-thon projects, will be incorporated into products. These should be temporary autonomous zones, not feeders for product development. If some new product emerges, that’s only a bonus.

Making software well, and enjoying doing it with talented teammates, means breaking their hearts sometimes. But you can learn how to minimize the chances, and the damage, if you get to know your team, and give them a clear vision.

Debt

One of the perrenial topics at any software org I’ve been in, big, medium, and small, is “tech debt”. How much we have, how much we’re generating, why it’s the root of all evil, how it’s a bullshit engineer excuse. It’s a very popular metaphor, if often poorly considered.

So, let’s look closer at the metaphor, itself. The idea is that there is some level of quality, elegance or completeness that software should be at. However, it is in use at a lower level of quality, elegance or completeness. The work (usually measured in man hours, abstract points or development cycles) to move from the current, to the desired level, is the “tech debt”. You can pay it down, or keep racking it up. You can estimate how much you have. It will naturally grow over time, unless payments are made, akin to compound interest. Oddly, it’s also a kind of “friction”, which “slows” development, causes bugs and makes work less enjoyable. But, let’s set that aside for a moment, and talk about the implications of the debt metaphor.

One implication is that PMs, as the owner of the product with the debt, need to understand how to be comfortable with their debt, and how to manage it properly.

In the late capitalist economy it is not desirable to have no debt. Governments have major debts and will never pay them down (only forward). Citizens are heavily incentivized to get mortgages. Students need loans to make more money in the future. Eight in ten Americans are in debt, and despite what moralists say, that’s not a sign of personal flaws, but a natural result of a system where debt is advantageous. I would argue this all applies to software and technology as well. Being debt free means you passed up an opportunity.

Why? Because debt is moving growth forward in time in exchange for risk. If you can afford zero risk, then yeah, never have tech debt. Building nuclear submarine hardware drivers? Please have no tech debt. But most of us can afford some, managed, risk, and we can often exchange it for growth.

This applies to software very directly. Ship with a few features incomplete? You add risk of bugs, or that a missing feature would have been key to market acceptance. Running on an old, poorly maintained server backend? Risk of mass failure, data breaches, or dev ops revolts. But the flip side of cutting scope short is shipping to meet a sales opportunity. The good side of the old backend stack is that it works, costs nothing to maintain and is a well known quantity.

This is how to “manage” your debt load. Just as you try to fairly consider stakeholders input to come to the best solution, you can, for your team’s goals, step back and look at the benefits and costs of your debt. How bad are your risks? How great is the potential growth moved forward?

So if debt is useful, as long as it’s managed and risk is okay, why do teams, especially technical and design teams often view debt as only a great negative?

I would posit that it’s because of what engineers, and others, mean by debt. They deal with it every day, while for the PM and management it is more abstract, with benefits. But there is a pain to this very productive jargon, that they deal with in their lives. The reality is, they don’t like or understand their own previous, or their predecessors, work. Or they weren’t given time to do something the way they wanted, or as completely as they want. Or they need to refactor based on added features, or functions, or new models, or new best practices. They want something that was done changed, or they want to change something that was left undone. Sometimes they are right. If business imperatives, or you, are overloading them, debt will accrue. Risk will mount. And it will slow things down, and suck for them, and eventually your users. But how much debt to carry, and how risky it is, is for you to manage.

Unknown Unknowns

I fear the day that the MBAs and people that would have become “financial analysts” in the late millennium fully take over the culture of software product management. These are fine people, but they are abstract risk managers and value optimizers. They could be structuring financial instruments, selling jars of pasta sauce, or running software systems with almost identical approaches.

That said, my favorite framework from the finance industry that serves me every day as a PM are the concepts related to risk. Debt, insurance, investment and even team management are often about the accurate evaluation and management of risk.

The future is unknowable and we’re always dealing in probabilities and manipulating the likeliness of outcomes, not guaranteeing them. How do you handle this as the person most responsible for delivering success?

For any major undertaking, it’s important to think through and spend time on likely threats to the project’s success. But that only helps with the known unknowns, what about the unknown unknowns (to quote the wisdom of war criminal Donald Rumsfeld)?

Even when you don’t know the exact cause, it is still possible to manage vague, generic risk. Unknown threats generally come from a limited set of source types. The most common disruptions, in my experience, are the hidden stakeholder and the implicit requirement, both usually discovered late in the development process.

The hidden stakeholder means just that: it becomes clear that there is a function or person who might kill, block, or otherwise limit your success. The implicit requirement, similarly, is a story, feature or capability that limits or threatens your success, which you failed to identify during research and planning.

Think about what you would do to prepare. You’re gonna get hit by something: keep your head up and at least see it coming. Should one of these manifest, triage dispassionately: is it in your control? is it really a blocker or problem? Some things, like personnel losses and context changes should be accepted and accommodated. Some, like exec meddling, team stalemates or nice-to-haves becoming blockers, can be worth fighting to overcome. Some things, like technical risk, dance in the grey area between the two.

Of course, the real solution I always recommend agile development processes, and indeed agile thinking in general. The answer to not knowing the future is just to embrace that things will change, you will learn more and change is as much about opportunity as risk.

do not doing

One of the biggest mistakes I see PMs, and people in general, make is their bias towards action. I don’t come to my job with the protestant work ethic and preference for action in every possible situation. Instead, I find much of my thinking about labor/effort better reflected in the Dao De Jing. Among it’s messages is to act as naturally as possible, to spend effort on identifying the flow and going with it, rather than activity for its own sake. This is sometimes boiled dow to the translation “do not doing”. In product management, I apply this to mean “sometimes it’s okay to CHOOSE not to do something as the best strategy”.

Resist the temptation to view work and activity as a valuable end, in-and-of itself, or as the solution to all problems.

This kind of “inactivity by choice” can be the right strategy in many situations, here are three examples:

Sometimes don’t build, repackage

Often, in software companies the temptation is to keep building new things. There’s a genuine need to deliver new features and updates every cycle for sales and marketing. And we’re paying a lot of engineers, we better keep them busy with interesting work! But I have had some of my biggest successes not with new things, but with old things applied and packaged differently. Often, the desire to do something new is because the existing product is not gaining the market or stakeholder acceptance expected. But if you do your research and listen to what users are saying, you may already have the solution with very little technical work. Instead of 6 months developing a new product, a change in interface emphasis and new marketing story may sell just as well.

don’t overreact to Analytics Noise

I worked in a very data driven organization with a hard driving (but quite effective) chief executive. The PMs and C-levels lived in fear of the email with a screenshot or link to a dashboard: “this number was down, do we know why?”. Many of these were valid queries, and they occasionally uncovered genuine issues. But more often than not, it was an unexplainable short blip, analytics bug, or most often, just a misunderstanding somewhere. And this chief executive was a genius (really). Most of us lesser mortals have an even lower “spot-a-real-problem” hit rate. That’s not to say you shouldn’t care or monitor your numbers (quite the opposite) but also learn how much noise and error exists in your context, and learn to triage these numerical mysteries as you might with bugs. Develop a methodology and intuition to know when to take action, and when to do nothing.

sometimes pass on an opportunity

In dealing with sales, or functions driven by month/quarter bound commissions or bonuses, there is a constant pressure to deliver something for a client or timeframe that does not account for your team’s reality. As with a marathon, just because you can run a 6 minute mile, doesn’t mean you should, if you want to finish the rest of the race. Asking the team to work nights and weekends better pay off, at least more often than not. Rearranging your roadmap for a marquee client can work, but it can also become a golden goose chase, giving the team whiplash and undermining any strategic thinking or product theories. Too many start-ups have been destroyed by taking on too much business or chasing a series of mega-opportunities before they were ready. Sometimes the best answer to inbound business is not “YES!”, but “not yet, but let’s talk”. Don’t go bankrupt “screening” your customers, or rigidly maintaining your scope in the face of product failure, but, also, be willing to be the leader at the table that says, “no, let’s not put in this in our sales proposal”. (Of course, a compelling “and here’s why…” should follow).