Posts Tagged ‘management’

A key role of product management (PM), whether as the product-focused founder (CEO, CTO) or the PM leader, is making sure product development efforts are focused. But what does it mean to be focused? This isn’t always as clear as it could be for a team. While everyone loves focus, there’s an equal love for agility, action, and moving “forward”. Keeping the trains running is incredibly important, but just as important and often overlooked is making sure the destination is clear.

It might sound crazy, but it is much easier than one might think for teams to move fast, get stuff done, and break things that might not be helping the overall efforts. In fact, in my experience, this challenge has become even greater in recent years with the availability of data and telemetry. With such, it becomes very easy to find work that needs to be done to improve the app or service — the data is telling you right then and there that something is tripping up customers, performing poorly, or going unused. Taking action makes it easy to feel like the right thing is happening. It feels like moving forward. Everyone loves to get stuff done. Everyone feels focused.

But is the team focused on the right work to achieve the right results?

Just a little process

Two important realities represent a constant balancing act when leading a product. As a PM you are applying finite resources to market needs in the march towards product-market fit or are working furiously to maintain a competitive lead. In addition to the new features there is the work that sales or customer success needs and together those greatly exceed what can be delivered by engineering.

This problem doesn’t ever go away and is at the core of the role of product leadership — getting the right stuff done with the right priority.

In every well-run company there is a strong tendency towards action and a strong dislike (tending to revulsion) of process. In practice, the absence of a process is just as much of a process, just one without clear lines between action and result. A little bit of process (aka product management) can go a long way to having real focus and getting the right things done.

With a little bit of process, everyone on the team can have:

Shared views on what success looks like

Clear understanding of success measures and metrics

Easy mechanism to decide what should be cut or pushed out when things aren’t going as planned

Visible alignment between what work will impact what elements of success and which measures

Honest accounting of resources going into what big picture initiatives

Ample opportunity to participate in deciding what gets done and when

It is very easy to overdo process and go from a helpful tool to a burden people run away from. A personal goal has always been to be as lightweight as possible and to have a way of thinking about these needs that scale from projects that last weeks, months, or even longer.

My guiding principle or golden rule of process is to never ask for something from someone that does not directly help them to get their own work done. Process is not about reports or “management”, but about making sure the work each person does is the most important work to do and the time.

Just a little framework

When most people think of coming up with a product roadmap or plan, they think of ends of a spectrum. At one end there’s commonly the one slide version labeled with months or years and a couple of bullet points at varying levels of granularity and decreasing accuracy as time goes on. There’s also the detailed and long-term strategic plan that most people can’t read through that is often the work of consultants or staff at big companies.

There’s something in between that I’ve found very helpful in terms of framing the product roadmap.

The roadmap can be represented as a hierarchy of increasing detail. It starts with a mission covering years of aspirations for the whole company. From the mission follow the goals representing the 12 months of work supported by specific metrics or measures and the various roles or disciplines in the company. Teams then come together to work on projects (or milestones in a longer term project) that take weeks and are delineated by releasing product or programs to the market. Supporting the creating of projects are the day to day tasks at the feature level representing the work of individuals.

Throughout this whole system there is ongoing telemetry that is called upon to support the company with reliable data upon which to make decisions.

Mission

Whole books have been written about mission statements or the process of developing a mission statement. Nothing makes me groan more than the idea of having a meeting to craft out a mission statement. We’ve all seen the results of these efforts that are an awkward combination of passive voice, comma splices, and breathless language. Companies exist for a reason and that’s the mission.

Missions are aspirational and guide you for years and represent the reason for being. Everything you do should aim towards your mission, and how you do that is the work of the rest of the framework. Missions boldly stating that the goal is to “disrupt” tend to be a bit backward looking or focus on the mechanism versus the outcome. Rather a mission that defines a future state of being or a new world view are often the most enduring and more positive. The most important thing about a mission is that there is just one and it endures. Mission statements are best able to be expressed on t-shirts, or something close.

Goals

Most everyone thinks they already have goals. Too often though goals are expressed as metrics or scorecards, like be the most downloaded app or number, daily users, or bookings. These are easy to express and are the lifeblood of a startup. The challenge is they change frequently. Like any good code when faced with something that changes frequently, the best bet is to add a level of indirection. A goal is the abstract view of metrics or measures.

Goals are strategic concepts such as retention, ease of use, acquisition, manageability, scale, success, and more. Through evolving telemetry you develop metrics to support the goals.

By using these abstractions you might come realize you have more goals than engineers (or marketers, success partners, etc.) or that you end up with every person working on too many goals. This is part of the process of being focused about goals. For any one product there can only be 3–5 goals and those fit on one “slide”, which includes the full spectrum of engineering, sales, and customer outcomes. This is a deliberate attempt to put in place some constraints up front.

Goals are then measured in specific ways over time. Metrics are then the lifeblood of goals. Your goal might be acquisition, but the metric might be a specific mechanism of retention for a period of time; or your goal might be to improve scalability of the service but the measure might be compute usage for some time and then storage usage for another.

When thinking about goals, they almost always fall to a specific function (or role) on the team such as marketing, sales, or engineering. Having a full accounting of the goals and the associated metrics allows you to understand what will change as the team’s work progresses — what is measured will be what changes.

Projects

Projects are easy to understand — they are the releases or programs customers and the marketplace use and hear about. A project might be, for example, a full update to the service, the app, a new entry to the market, a launch, a campaign, or a major infrastructure change. Early on it is trivial to name the projects for a company. Very quickly, however, the number of projects can balloon and become increasingly difficult to track (and potentially to justify). There are SDKs, enterprise tools, segment campaigns, apps for different platforms or support for different browsers, and more.

The key reason to maintain a clear list of active projects is because momentum in continuing some project, failing to re-allocate resources, can often be the biggest constraint in getting the important work done. It common to find yourself in the situation of maintaining a project that no longer fits with the immediate needs but there’s inertia that makes it hard to change. The most important task for product management is to make sure everyone is aware of the projects being undertaken. The more the company scales the more critical it is to know what projects are active and what commitments the team is making to those. Even in the biggest companies, there are just dozens of meaningful projects.

A project has an ending date or deadline date — not a month or a quarter (those are 30 or 90 dates) but a single date — and everyone knows when the project releases or is complete.

Tasks

When you work from mission to goals to projects, the most concrete expression of work on the team is the task. A task is the actual code to be deployed, whitepaper to be written, SEO tools that will be employed, launch event to hold, features that will be designed, and so on. While a few people might care deeply or contribute to the mission, and executives generally focus on goals, and managers live whole projects, everyone is invested in tasks.

Tasks are defined by those that will do the work and those same people (or person) will decide how long it takes. Every person contributing to a project might have dozens of tasks. Tasks should be from 1/2 to 2 days — less and the accounting is too painful and more and it is likely the work is not understood enough to reliably schedule.

There are two main benefits from spending the time to create a list of work items. First, the project overall becomes increasingly predictable which is important because of dependencies (such as front end and back end, or marketing activities). Second, when things aren’t going as well as planned there is a clear view of just how far off things are along with a pre-computed list of potential savings to be had by cutting different tasks. Whether it is Asana, Trello, Sheets, Jira or more the key is just having a system that goes beyond post-its around a monitor.

What is often overlooked is how much more effective everyone is when they know the why behind the what. Everyone will do better work if the worklist flows from specific projects which have goals that are measured in a particular way. Much of the work of this framework will prove to be making the connection from task all the way to mission.

Telemetry

One additional element that permeates all of your efforts is telemetry.

The most successful organizations are also fully instrumented organizations. Everything about code, customers, and overall engagement has telemetry.

Keeping an open mind and open eye to a whole variety of measures is super important. Just that as a matter of scale and operation, you cannot hold everyone accountable or change what is being done in response to every measure. If you’re learning something that concerns you then dig in. Maybe you’ll change your plans. But when you do need to change your plans you can do so in the context of an overall framework, not just single data points.

The combination of a framework and telemetry makes it possible to more globally maximize your return on investment. Telemetry alone risks a more local optimization. A framework by itself is just guessing.

It might seem like doing all this is just too much busy-work. There is an investment to be made. Most of the effort, however, will involve “editing” or “culling” from a list that was already too long or contained a lot of things not getting done. The most time intensive work is in creating the task list and is often the most disliked or difficult to make concrete. Everyone seems to have a feeling for what work needs to be done but resistance to putting it out there. The essence of an accountable organization is taking the team through this framework and making it part of every day work.

Just a small tool

There’s a payoff to all of this that is incredibly important. If you stop here all you’ve really done is document things going on. What is really important is that you assemble information so you can have a system in place to deal with change — unexpected failures in the market place, gain or loss of people on the team, new opportunity in the marketplace, or demands from a customer. Maintaining this information in a simple tool provides the product manager with that.

There’s always too much to do, so by definition we know we are not doing everything we can to be successful. Do we know if everything we are doing is essential to the success we hope to achieve?

Seems like a simple question. In practice this is an exceedingly difficult question to answer at any given time and even more difficult question to answer over time as conditions change. In fact, I might argue it is close to impossible and that the best measure of success is to view the efforts overall as a portfolio. Just like a portfolio, however, you need to spend time digging in to understand at a more granular level where you can do better. Failing to do so too often prevents us from ongoing evaluation of work to make sure it is really helping — if there is more work than can be done, the easy path is to just assume everything going on is helping. That’s not true though!

What is suggested below might be simplistic or you might believe you’re already doing all this and more. I’ve found that most projects, especially before product-market fit, can benefit from a more systematic view connecting work to projects and goals supporting the company mission.

My own experience is that this can be accomplished in a surprisingly straight-forward manner. Doing so illuminates the work of the team and provides a great tool for the shared and ongoing management of the team.

Let’s just assume we’re working with a spreadsheet, simply because we’re going to do some math with the data. Feel free of course to use any structured tool that supports features such as collaborative editing, group-by reports/pivot tables, filters, and some basic math. The specific tool isn’t important and should not be the source of the first debate on the team!

We tend to think of the task list as a literally listing of tasks such as Implement OAUTH, Add new chart type, Create sign-up response mail, etc. Simply getting all of these done can often be helpful enough. Most tasks lists will have a name associated with the work and I’d always encourage a single name, or said differently define the task so it is the work of one person. In addition, include a column for the amount of time the task will take (0.5–2 days). For good measure I would suggest also including the date to start/finish as that allows you to use the spreadsheet to understand the relative schedule.

Then take the extra step of making sure the Project is clear. Is it for the iOS App? Does it support the SEO campaign? Is this the Beta program? Adding this label should be some simple accounting as projects are by definition distinct and represent a single release or customer/market visible effort.

The next step is key which is to add one more column which is what goal the work supports. Is this task about something like retention or scalability, for example? Avoid the temptation to think something applies to many goals or rather force yourself to commit the work to supporting a single goal. Keep in mind you already know the goals so all you are doing here is picking from the 3–5 established goals, which in turn are associated with metrics.

With that in hand you have something that looks like the hypothetical below. You can see a connection between tasks, projects, and goals.

Keep this sheet up to date and you’re able to be ahead of the project. As simple as this seems it is just as often either overlooked or buried in too much detail to be broadly useful.

What can you do with this? There are several key sorts/filters that are enormously useful:

Any given person can look at their own work and know where they are and where it fits in

At any time, one can see how much of the time (resource) overall is going to support a given project or goal

Know which tasks are too far out, too big

Know which resources are over-constrained

And so on. This tool is the right level of complexity for projects from 10 to 5000 people in my experience. While many would love more such as dependency analysis or a task hierarchy, my experience is that is where the tool begins to overwhelm. When the tool overwhelms it isn’t used and so it doesn’t matter. (Quick note, when I first came to manage Microsoft Project I learned that the bulk of usage of the tool was not to track projects but to input a bunch of data at the start of a project just to come up with a nice-looking poster-sized Gantt chart printed out once at the project start.)

Managing projects is very difficult. While the bank account is draining and there’s a strong desire to keep moving is galactically more difficult. The fear of slowing everyone down with tools and processes is real and often justified. With so much riding on being efficient, effective, and focused it is worth investing a small amount in managing the work so as to make better decisions about what work to do and what happens when you get new information from the market.

Like this:

Decision-making is one of the most difficult skills to master as a manager. A startup CEO literally sees a constant stream of decisions to be made: from hiring and firing, to Android or iOS, all the way to Lack or Billy. As the company grows to 10–20 people (usually mostly engineering) the bonds and shared experiences continue support decision-making at the micro-level. Once a team grows larger there is a need for management and delegation. While growth is a positive it also a stressful time for the company and founder/CEO.

Even for the tightest knit group with founding-team trust, the first decisions made without the CEO (or by simply giving a heads up to the CEO) are nail-biting moments for everyone. The closer the decision is to the core of the CEO experience the trickier. Deciding on UX changes or tweeting from the company account all test the ability for the CEO to delegate and the team to be delegated to.

As a company grows to having leaders and groups across different functions (heads of sales, marketing, eng, operations) the need to be systematic in delegating and deciding goes from optional to mandatory. Many founders resist this move. First founders rightfully care about everything — everything matters — and it is very likely he/she is in the best situation to make the best decision for the company. Second, founders that worked at a big company too often experienced dysfunctional decision-making and part of building a new company is to do better than that.

As a manager, I always found deciding to be both trivially easy and impossibly difficult. It is easy because like many, if you ask for an opinion from me you can get one. It is difficult because like many, the implications of sharing that opinion are not really known at the time.

For me, knowing what a decision really is about, understanding the full context of a decision, even just awareness of what is actually being decided are a few of the many challenges. Add to that all the management-speak about delegation and accountability and quickly I came to conclude I could justify any course of action. I could be anything from the center of a command-and-control decision making machine to a completely non-accountable, human-router-delegator of important choices in the name of building an empowered team.

I wrote this post in an effort to create a framework for how to think about decisions from the vantage point of a CEO/founder/exec as an organization grows beyond when the “hub and spoke” is the expected norm, and how to think about the good and crisis times when it comes to decision-making.

Deciding with Dysfunction

Making decisions is easy on paper, but a lot more difficult in practice. Worse, the more one practices the harder it is to make decisions simply because of knowing more and seeing potential downsides of just about everything. One might think experience would make things easier, and often it does, but it can slow down or even just prevent things from happening. When I was young, I could decide to drop in on a 15’ vertical half-pipe without hesitation. That was before I knew the downsides of injury (it was also before YouTube so all we had to look at for examples were photos)!

As the team grows, CEOs (and execs, depending on company size) face many challenges in getting things done or just picking the right things to do. One of the main factors is the increasing number of people involved in any choices. Deciding iOS or Android first will seem easy or “obvious” when resources are very tight and there’s no Android developer anyway.

Fast forward and consider the complexity when there is a newly hired sales leader who knows “works anywhere you do” will close deals, an engineering manager who still can’t hire an Android lead, a QA manager who is all about fragmentation complexity, or a newly hired BD lead who can choose between two partnerships but the better logo requires both iOS and Android. All of a sudden there’s no simple decision to be made and a lot of people contributing who feel their success hinges on going with their point of view. Play out over time the various potential outcomes and who is promoted, gets more responsibility, or is credited with success to see that this challenge is far more than just getting the right answer. That is normal.

As a result of people living this pattern over and over, many decision-making techniques and tools have been created. These codify a “decision making process”. In fact there is a whole Wikipedia article describing responsibility assignment matrix. These have a variety of acronyms like OARP, RACI, ARCI and more. The letters are various ways to define roles in important decisions such as reviewer/approver, recommends/consulted, responsible/accountable and more. These are tools designed to speed decision-making, clarify execution accountability, and ensure robust choices. Leaders figure out what to decide and assign various roles to participants and like magic decisions are made.

In my own experience these tools more often than not slow things down, make no one accountable, and all but guarantee compromises with which no one is satisfied. There are innumerable stories of how a well-intentioned taxonomy like the above can be used to grind work to a halt, push accountability around without establishing it, and turn a specific decision into a general battle over the meta. That’s unfortunate because making the right choices is incredibly important and having tools that add reliability and consistency to the effort would really help.

Rather than dissect a meta-process, I’d propose taking a step back and saying that the most important thing a CEO or executive must do is to keep the output and velocity of the team at the highest levels and focused on doing the right things. The first VP I worked for, way way back, hypothetically suggested “maybe a star could do the work of 3, or 5, or even 10 people” then he went on “the problem is we are doing work with 20, 40, or 50 people”. The implication of that math is clear. No matter how smart, hard-working, on top of things, or just amazing someone is, they need to work with other people and count on their work without actually doing it.

The core problem with a decision-making process starts with defining a decision and related inputs. Almost never is there all the information needed or wanted to make a choice and wait long enough then chances are context and options have changed enough to make the decision framing all wrong. So all that was really accomplished was slow everything down by simply by trying to define the decision to be made and what inputs were needed (apparently this also holds for the Federal Reserve Bank).

We know that almost nothing is made up of a single decision at a single point in time. Ask yourself how many discussions or meetings you had where you thought there was a yes/no, or a choice to be made, and after running over time the only decision was to wait, learn more, or come up with new options? It is only long after clear success or failure does the historic narrative turn into the “big decision” (and associated drama).

The essence of an agile organization is figuring out how to make fast progress against larger goals, learning and adjusting along the way. In that context, many at the company make decisions every day.

Stepping Up For Growth

With so much happening every day, rhythm is the biggest enabler of agility. If a team operates in a Flow, then everyone can do their best work. We all know what it is like to groove. We also know what it is like to have that groove interrupted by questioning the choices made or pausing to have choices validated, reconsidered, or tweaked.

Trying to get ahead of decisions sounds great. This quickly turns into trying to know what isn’t known and worse to prepare for it. Finding a way to codify the set of problems that will trigger a review or joint decision turns into a meta-planning exercise trying to agree on potential challenges.

In my experience, the real challenge is in trying to define decisions, isolate important ones, and then figure out the stakeholders for that once instance. Decisions are everywhere. Deciders are all over the place. Every identifiable decision is made up of many other choices, constraints, and stakeholders.

The following is my own idealization of the role a CEO or exec can play in decisions. Instead of kicking off a process for a single decision, spend the energy up front to decide what and how the CEO will work. Thinking this way allows for a variety of approaches for getting involved, delegating, or empowering. It avoids the complexities of figuring out what it is that is actually being decided and hairsplitting accountabilities among individuals. It introduces agility into a process rather than rigidity.

My own experience led me to believe that before I decided something that was brought to me, I had to have an idea of what role I was playing in the process. It is easy to be a boss and assume people need your wisdom, advice, or context. It can be tricky to know if you are really adding that, affirming the choices of those who work for you, randomizing them, or simply doing their job for them.

With that experience, my view is that before deciding something a CEO or exec should be clear how he/she contributes to a project or work, using one of the following:

Initiator. Kicking off new projects.

Connector. Connecting people to others so the work gets better.

Amplifier. Amplifying the things that are working well or not so there is awareness of success and learning.

Editor. Fixing or changing things while they are being done.

Let’s look at each of these in a little more detail.

Initiator

As a practical matter, assuming the organization is running at > 100% capacity then there’s a finite amount of initiating that can be done. Almost everything kicked off at the exec level looks like the strategy, new projects, new organization, or the prioritization of work. Creating or seizing new opportunities from the leadership vantage point is precisely it means to be the initiator.

Examples: Kicking off something entirely new (hiring process, first sales deck, new product release, opening a new position. Deciding to make a big bet on a new technology, platform. Starting a new strategic or transformative initiative.

Tools: Write it down in a way that someone joining the project later can quickly get up to speed. I believe writing is thinking, so taking the time to gain clarity on what to do and what success looks like only helps. Pro tip: Drafts circulated to a small set of key people, but quickly along with seeking and acting on feedback can be very valuable.

Granularity: Almost always this will be fairly coarse like “launch day” or “new product” but can scale all the way down to being the specific such as “add this feature”, “create a partnership”, “publish APIs”.

Time: When operating in a rhythm (product cycles, launches, adding new leads) initiating becomes a key part of team rhythm. About 10% of overall work is initiating new work or projects.

Mindset. The most important work of an exec is in kicking off a new project so put the most effort into this work product. Initiating is the only time an exec does the work of an individual contributor.

Connector

Most all decision-making challenges happen across domains. Rarely does a solid engineering leader pick the wrong toolset. Rather the toolset is wrong because the full scope of the challenge was not known. Anything crossing functional lines requires a connection. The exec is in a unique position to be constantly connecting functions and work. Helping people to know more about what is going on with others on the team while recognizing this almost never happens by chance.

Examples: There are classic examples across functional lines such as connecting sales and product. Many of the most interesting examples are the non-traditional ones, which can help people to gain more experience such as connecting engineering to customers. Facilitated connections rather than simple introductions afford the chance to see how parties use the connection and to drive an agenda consistent with a rhythm.

Tools: Presence, listening and talking have no substitutes. Even with everyone being online and available, don’t assume everyone or the right people will read everything. With any size team, the amount of “FYI” or automated information will quickly overwhelm even the most diligent. Rather than believing status reports and scorecards will connect, execs must focus on making specific connecting efforts with clear intentions to move things along. Most work has natural points where checking in makes sense. Rather than relying on ad hoc connections, use a structured approach to surface the right issues.

Granularity: The reason connecting is fun is because when it not randomizing or micro-managing, but simply sharing and getting head of potential problems. Connecting peers together is a service to the team.

Time: Spending more than half, perhaps 60%, of the time connecting is routine among CEOs and execs. A useful way to spend time is on structured, periodic checkpoints that connect the status of the current work to the start of the project. Pro tip: Most every interaction can serve as a chance to connect one part of the team to another or a CEO’s external context to what is going on internally while also using the opportunity to demonstrate listening while not trying to solve everything along the way.

Mindset. Connecting is the field work of the exec. Execs should be thinking about what to connect almost all of the time. Connecting skillfully is a force multiplier.

Amplifier

The CEO or exec soapbox is a super valuable tool. Within a company there are not only good things worth letting everyone know about, but lessons learned that could be shared. Since it is a given that not everything can be thought through in advance, seeing and amplifying the creative ideas or great execution seen along the way can be seen as a proxy for initiating new things. When a CEO stands up in front of the team and celebrates success or learning it just matters more.

Examples: The best example is to amplify the good work of the team or to turn failure into a lesson. Amplifying the good work of competitors, sales wins, or collaboration across functions gives leaders a chance to call our efforts that cross many parts of the company.

Tools: The team meeting is the most valuable forum for amplifying and often supporting this with something in writing (or a t-shirt or sticker!) works best. Amplifying work is also related to connecting work and often they are two sides of the same coin. The most compelling efforts to amplify are supported by great stories — when taking the time to amplify something, do so with the whole story and the background that makes it worth amplifying. It is one thing to tell people something important, but another to describe why it is important.

Granularity: Amplify things that apply to many people on the team but do so with a frequency that maintains meaning and impact. Pro tip: When celebrating success, execs should be sure to give the right credit to the right people.

Time: Execs have a unique ability to amplify success, which in turn makes this a high value effort so it is worth spending 10% of time.

Mindset. It is fair to view amplifying as a bit of a tax. As is often said in management, “what’s worth saying is worth repeating”. Ronald Reagan was famous for not veering off important messages because he believed even though it was old news for the press corp, it was new to those in the live audience.

Editor

In a big company, people just wish execs would go away and let them do their jobs. In a new startup, execs are doing the work (i.e. coding, selling specific accounts, designing the UX). Everywhere else many people are doing the work and the exec is figuring out when to contribute. Somewhere between “swoop and poop” and “micro-managing” is the role of contributing editor. I use the term “editor” specifically because this is about changing (or improving) the work created by others. Editing is the right of a boss, but also a privilege in a team made up of smart and creative people. Everything about editing is in how it is done. Poorly done, editing makes people feel bad and never generates the best work (except for Steve Jobs as many like to say). Done well, and editing makes everyone feel better about the collective effort.

Examples: Redlining a document, drilling into a design review, redoing a positioning framework, creating an outline for a blog post or release, designing the 2×2 competitive framework are all examples of editing.

Tools: The most important “tool” to use when editing is to do so in-person. The vast majority of editing feedback comes across as negative and critical. While there is always enough bad work to go around, finding ways to be constructive is always worthwhile. For better or worse, editing without verbal context or worse just being critical over email almost always makes things worse.

Granularity: Chances are the granularity of editorial input is very fine-grained. The question is not really whether to edit or not, but how many times the same thing (even for the same person) is edited. Repetition means there’s a systematic problem with communication or the people doing the work.

Time: Editing is a big time commitment, but not the biggest. It also comes in fits and starts. More important than time is timing. The later in the process or the closer to the deadline the higher “cost” being an editor has. Overall about 20% of exec work is editing.

Mindset. This is the comfort zone for every exec, especially when it is the type of work he/she did individually. The important thing is for the exec to really know the importance of the changes.

With a framework or roles like this, there is clarity in how an exec is working with the team and how work is started, iterated, and completed. I would also encourage using this framework by managers at all levels in a company. One changes the time devoted to each type of interaction.

Diving In For Saves

At this point, you probably think this all sounds well and good, but what about when things are going sideways?

When things go sideways none of this matters.

In fact, none of this really matters if the company are such an early stage that there are no more than a couple of dozen people. It also doesn’t matter if there is not yet product-market fit.

In Ben Horowitz’s Hard Thing About Hard Things, he describes the differences between a “peacetime” and a “wartime” CEO styles (specific post is here). I love his framing of decisions that pose existential questions for the company. That is a fantastic way to know when there really aren’t decision making processes other than whatever the CEO wants to do to survive to another day. Rarely are exec level choices existential at the same level, which is worth noting.

In a startup, the wartime CEO pretty much describes things until there is a solid revenue and profit stream coming from a product that works for the market. Most everything amounts to an existential choice or decision.

In an organization that is more or less working, this is a more subtle challenge. At some point few decisions are truly existential, though it turns out it is tough to know this is the case while everything is happening.

There was a recent Facebook thread among a few of the original leaders of an old Microsoft product. From the outside, most people see only the victory and to read their comments one would think it was all a cakewalk. From inside the team, every day felt existential and every choice seemed to be about the success or failure of the whole. This is the norm at big companies and explains the origin of those questionable “decision support tools”.

This all boils down to product-market fit and deciding when in fact that state was achieved. Before that time, everything is existential. After that time, most decisions are relatively minor. Unfortunately, knowing this dividing line isn’t so straightforward and the clouds of disruption always loom on the horizon. This is the fog of war in a big organization.
Operating all the time in crisis mode or thinking every choice is existential is just not sustainable as a company or leader. As fun as it seems, a whole yoga practice upside down is not a good idea.

As a company scales, the long tail of choices and decisions feels existential from within even if they aren’t. There’s no magic answer as to when one is at war or peace, even in hindsight. My view is that a CEO can decide the one thing no one else can, which is to decide things using a poorly defined process. Just keep in mind that even the most successful CEOs and execs can eventually use up that luxury and either adapt how they work or watch people leave the company.

The original generals, in the military, have evolved their thinking and modern warfare now employs the notion of commander intent as a leadership practice for just these reasons (and more). If you are interested in how the largest and most process-oriented organizations evolve, the report linked to is fascinating.

With the most robust product market fit, there will be existential moments demanding wartime decisions: a major security breach, service outage, failed sale, or losing key members of the team. Don’t ever be worried about deciding in the most top-down, non-empowered, toe-stepping manner when facing a true crisis. That’s what leadership is all about. Using the framework above, a crisis situation just demands a great deal more editorial actions.

Making decisions is something that at first comes naturally, even easily, and then as a company grows the complexity creeps up on CEOs and execs. Some of this is because with experience comes awareness of all the things that can go wrong. Most comes from the challenges of scale and decisions of when and how to let go of some things. Decision making challenges come when an unlimited amount of passion meets a finite amount of time. Taking on this challenge without introducing a mindless bureaucracy is an opportunity for a growing company.

Like this:

Everyone is interested in improving the workplace relative to inclusion, diversity, and equality across many dimensions. Research continues to show that many of the challenges experienced by team members are rooted in the combination of unconscious bias or routine communication approaches that might date back to our earliest development. There are many tools and skills available for everyone (!) to do better and I wanted to share some that I recently experienced. Openness to the variety of tools available is a first step in improving the workplace.

This week I participated in one such workshop, The Ally Skills Workshop, created by the Ada Initiative. The workshop was held at Slack and facilitated by Leigh Honeywell. She works at Slack and is also an advisor to the Ada Initiative who has facilitated this workshop many times. Having participated in a large number of related trainings and workshops over the years, I wanted to offer this one as a low-cost, lightweight, and at the same time highly valuable tool for groups. I believe it is especially relevant and appropriate to the < 50 person startup environment, though of course broadly applicable (and used at many large SV companies).

It isn’t appropriate or possible to recap an experiential workshop. The mechanics of Ally Skills are straight forward. In groups of 15-40 people (men are the primary target but groups of all kinds are encouraged) the facilitator guides the group through 2-3 hours of scenario-based discussions in breakouts and then group dialog. It is very straight forward, low-risk, and eye-opening. For those worried about something being too “heavy” or “HR”, the creators of this workshop are engineers with a great history in technology companies so you can be assured the tone is right.

The resources including facilitator training are all available via Creative Commons on the Ada Initiative site. The Initiative is going through a transition now and soon more information will be available for how you can directly contact the right people for obtaining this training for your company or group. You can contact Valerie Aurora for more information.

Need tips on inclusive event planning? Here’s a collection of resources compile from the experiences at AdaCamp gatherings for making sure you are thinking holistically about inclusion https://adacamp.org/. This covers everything from catering, registering, planning and more.

One super interesting article that Leigh mentioned is a research paper from 1970 about the “Tyranny of Structureless”. I think this is a remarkably relevant work to consider given today’s oft-expressed view that the absence of structure and process is the way to avoid bias and discrimination (TL;DR—the opposite is the case).

All of us should always be in a learning mode when it comes to forming teams and building products that represent the very best work of everyone contributing. I would encourage everyone at every stage in their career to be on the lookout for new tools and techniques or new perspectives that each of us can put to use. No matter where you are in your career or how aware you are of your own behavior, there’s always learning to be done.

Share this:

Like this:

This post is a verbatim reprint from a book I wrote with Marco Iansiti of Harvard Business School, One Strategy: Organization, Planning, and Decision Making (Smile link). The original content was from a Microsoft internal blog post dated April 23, 2008. More context is available in the book (Google Books link). Posts were written for the Windows team but available to the whole company at the same time.

One of the things that is really important to me is making sure working on Windows and Windows Live is a low-stress job. Stress is evil, in fact stress is defined as:

stress: strain felt by somebody: mental, emotional, or physical strain caused, e.g. by anxiety or overwork. It may cause such symptoms as raised blood pressure or depression.

The thing about stress is that it is both physical and emotional. Stress is all about a loss of control (anxiety). Loss of control comes from not really knowing the goals, not understanding what success looks like, and in our vernacular, about being random. Stress comes because the work required is incompatible with your capabilities or your view of success. Stress is about a mismatch between your reality and the reality of your manager or team.

Stress in the workplace is 100% incompatible with building great software.

On the other hand, pressure is all around us. We have pressure to succeed. Pressure to get the build right. Pressure to get the design right. Pressure to go live with content. Pressure is a motivator. Pressure is defined as:

pressure: urgency, as of affairs or business

The thing about pressure is that it comes from within. Pressure is about the plan. Pressure is about your own goals (affairs). By operating with a plan and the details of that plan were created by the team we transform what might be stress into pressure. Pressure comes because you want to be successful against the goals you have set out. Pressure comes because the peers you depend on are expecting you to deliver what was communicated. Pressure is about the constant force in our environment to deliver on the plan we developed together.

Pressure in the workplace is how we stay on our toes and put forth our best efforts. Performing under pressure, while challenging, is what helps us as engineers to make great choices and use the constraints to our (and our customers) advantage.

No one works well under stress—the physical toll is real and provable. Some folks don’t work well under pressure. You don’t have to put yourself under pressure, but we’re a competitive company and like a great athletic team we do want that effort to go above 100%, but we can do so in a constructive way by using pressure to our advantage.

We’ve got some pressure going on now on our team. IE 8 in the final milestone. Integrating the M1 build of Windows Live. Windows 7 moving to M3. We’re excited. The pressure is real. It is pressure like being in the World Cup because we know what got us here and we know what it takes to be successful.

—Steven Sinofsky

PS: Yes these words are similar. The beauty of words are the subtle differences that make them special.
PPS: I’m just excited to use the new build of LiveWriter – and the whole Wave 3 suite!

Like this:

One of the biggest changes for an early-stage and growing company is when hiring transitions from technical/product founders to the first sales or marketing hires. It is an exciting time of course but also one that can be very stressful. As much as that can be the case, there are a few patterns and practices one can follow to successfully cross that chasm or at the very least reduce the risk to the same as any technical hire.

It goes without saying that the challenge is rooted in learning how to recognize and evaluate talented people that possess talents and skills that you do not have and really can’t relate to from an experience level. Quite a few roles in companies are going to be “close” or adjacent to your own skill set, speaking from the perspective of a technical founder. If you’re an engineer then QA or product management aren’t far off from what you do on a daily basis. If you tilt towards product management, you’re interactions with designers are perfectly natural. In fact for technical founders the spectrum from design to product management to engineering and then QA all feel like your wheelhouse.

Branching out further to sales, marketing, communications, business development, customer service, operations, supply chain, manufacturing, finance, and more can get uncomfortable very quickly. I remember the first time I had to interview a marketing person and I realized I didn’t even know what questions I should ask to do the interview. Yet, I had worked with marketing closely for many years. Fortunately, I had a candidate pipeline and an interview loop of experienced interviewers to draw from. That’s not alway the case with a startup’s first hires.

The following are four challenges worth considering and a step you can take to mitigate the challenges if you find yourself in this spot.

Look only within your network. When sourcing your first potential sales or marketing hire, you might tend to tap into your network the same way you would for an engineering hire. You might have a very broad network but it might not be a first person network. For example with engineering you might know people from the same school program or projects you worked on or are deeply familiar with. But with sales and marketing you probably lack that much common context and your network might reflect people you came across with in work or projects, but not necessarily worked with in the same way you would have with technical hires. You might be worried about taking too much time to source candidates or concerned that you will burn a lot of time on introductions and people you don’t “know” well. Approach. The first step in a breakthrough hire process is to make sure you cast a wide net and tap into other networks. This process itself is an investment in the future as you will broaden your network in a new domain.

Define the job by way you know from the outside. Walk a mile in other’s shoes is an age-old expression and is very fitting for your first sales or marketing hire. Your initial job description for a job you never done might be taken from another company or might be based on your view of what the job needs to get done. The challenge is that your view of what needs to get done is informed by your own “outsider” view of what a job you haven’t done before might mean. Being a sales or marketing person is vastly different from what it looks like from the outside, looking in. If you haven’t done the job you tend to think of the job through the lens of outputs rather than the journey from input to output. Most jobs are icebergs and the real work is the 90% under water. Until you’ve watched and worked with an enterprise sale end to end or developed and executed on a consumer go to market plan, your view of what the job looks like might be a sales presentation or SEO. Getting to those deliverables is a whole different set of motions. Approach. Find a way to have a few “what do you do” conversations with senior people in the job function. Maybe take some time to ask them to define for you what they think the steps would be to get to the outcome you are looking for, rather than to discuss the outcome. These “what would it take” conversations will help you to craft a skills assessment and talent fit.

Hire too senior or too junior. Gauging the seniority of a candidate and matching that to the requirement for the role are often quite tricky early on. In the conversations I’ve had I tend to see founders head to one extreme or another. Some founders take the outcome or deliverable they might want (white paper, quota) and work backwards to find a hire to “execute” on that. Some take the other extreme and act on the basis of not knowing so bringing in a senior person to build out the whole system. The reality is that for a new company you often are best off with someone in the middle. Why is that? If you hire to too junior the person will need supervision on a whole range of details you haven’t done before. This gets back to defining the job based on what you know—your solution set will be informed only by the experience you have had. If you hire someone too senior then they will immediately want to hire in the next round of management. You will quickly find that one hire translates into three and you’re scaling faster than you’re growing. I once talked to a company that was under ten engineers and hired a very senior marketing leader with domain experience who then subsequently spent $200K on consulting to develop a “marketing plan”. Yikes. Approach. Building on the knowledge you gained by casting a wide net and by taking the time to learn the full scope of work required, aim for the right level of hire that will “do the work” while “scaling the team”.

Base feedback on too small a circle. Once you have a robust job description and candidate flow and ways to evaluate, it is not uncommon to “fall back” on a small circle of people to get feedback on and evaluate the candidate. You might not want to take up time of too many people or you might think that it is tricky for too many people to evaluate a candidate. At the other end you might want these first hires to be a consensus based choice among a group that collectively is still learning these multi-disciplinary ropes. Culture fit is always a huge part of hiring, especially early on, but you’re also concerned about bringing in a whole new culture (a “sales culture” or “business culture”) and that contributes to the desire to keep things contained. Approach. Getting feedback from at least one trusted senior person with experience and success making these specific hires is critical. You can tap into your board or investors or network, but be sure to lean on those supporting you for some validation and verification.

One interesting note is that these challenges and approaches aren’t unique to startups. It turns out these follow similar patterns in large companies as well as you rise from engineering/product to business or general management. While you might think in a big company the support network insulates you from these challenges, I’ve seen (and experienced personally) all of the above.

The first sales or marketing hires can be pretty stressful for any technologist. Branching out to hire and manage those that rely more than you on the other side of their brain is a big opportunity for growth and development not only for the company but for you personally. It is a great time to step back and seek out support, advice, and counsel.

Like this:

Managing product development and management in general are ripe with clichés. By definition of course a cliché is something that is true, but unoriginal. I like a good cliché because it reminds you that much of management practice boils down to things you need to do but often forget or fail to do often enough.

The following 15 clichés might prove helpful and worth making sure you’re really doing the things in product development that need to get done on a daily basis. Some of these are my own wording of other’s thoughts expressed differently. There’s definitely a personal story behind each of these

Promise and deliver. People love to play expectations games and that is always bad for collaboration internal to a team, with your manager, or externally with customers. The cliché “under promise and over deliver” is one that people often use with pride. If you’re working with another group or with customers, the work of “setting expectations” should not be a game. It is a commitment. Tell folks what you believe, with the best of intentions, what you will do and do everything to deliver that. Over time this is far more valuable to everyone to be known as someone that gets done what you say.

Make sure bad news travels fast. Things will absolutely go wrong. In a healthy team as soon as things go wrong that information should be surfaced. Trying to hide or obscure bad news creates an environment of distrust or lack of transparency. This is especially noticeable on team when the good news is always visible but for some reason less good news lacks visibility. Avoid “crying wolf” of course by making sure you are broadly transparent in the work you do.

Writing is thinking. We’re all faced with complex choices in what to do or how to go about what will get done. While some people are great at spontaneously debating, most people are not and most people are not great at contributing in a structured way on the fly. So when faced with something complex, spend the time to think about some structure write down sentences, think about it some more, and then share it. Even if you don’t send around the writing, almost everyone achieves more clarity by writing. If you don’t then don’t blame writer’s block, but consider that maybe you haven’t formulated your point of view, yet.

Practice transparency within your team. There’s really no reason to keep something from everyone on the team. If you know something and know others want to know, either you can share what you know or others will just make up their own idea of what is going on. Sharing this broad base of knowledge within a team creates a shared context which is incredibly valuable.

Without a point of view there is no point. In our world of A/B testing, MVPs, and iteration we can sometimes lose sight of why a product and company can/should exist. The reason is that a company brings together people to go after a problem space with a unique point of view. Companies are not built to simply take requests and get those implemented or to throw out a couple of ideas and move forward with the ones that get traction. You can do that as work for hire or consulting, but not if you’re building a new product. It is important to maintain a unique point of view as a “north star” when deciding what to do, when, and why.

Know your dilithium crystals. Closely related to your point of view as a team is knowing what makes your team unique relative to competition or other related efforts. Apple uses the term “magic” a lot and what is fascinating is how with magic you can never quite identify the specifics but there is a general feeling about what is great. In Star Trek the magic was dilithium crystals–if you ever needed to call out the ingredient that made things work, that was it. What is your secret (or as Thiel says, what do you believe that no one else does)? It could be branding, implementation, business model, or more.

Don’t ask for information or reports unless they help those you ask to do their jobs. If you’re a manager you have the authority to ask your team for all sorts of reports, slides, analysis, and more. Strong managers don’t exercise that authority. Instead, lead your team to figure out what information helps them to do their job and use that information. As a manager your job isn’t a superset of your team, but the reflection of your team.

Don’t keep two sets of books. We keep track of lots of things in product development: features, budgets, traffic, revenue, dev schedules, to do lists, and more. Never keep two versions of a tracking list or of some report/analysis. If you’re talking with the team about something and you have a different view of things than they do, then you’ll spend all your time reconciling and debating which data is correct. Keeping a separate set of books is also an exercise in opacity which never helps the broader team collaboration.

Showdowns are boring and nobody wins. People on teams will disagree. The worst thing for a team dynamic is to get to a major confrontation. When that happens and things become a win/lose situation, no one wins and everyone loses. Once it starts to look like battle lines are being draw, the strongest members of the team will start to find ways to avoid what seems like an inevitable showdown. (Source: This is a line from the film “Wall Street”.)

Never vote on anything. On paper, when a team has to make a decision it seems great to have a vote. If you’re doing anything at all interesting then there’s almost certainty that at least one person will have a different view. So the question is if you’re voting do you expect a majority rule, 2/3rds, consensus, are some votes more equal? Ultimately once you have a vote then the choice is one where the people that disagree are singled out and probably isolated. My own history is that any choice that was ever voted on didn’t even stick. Leadership is about anticipating and bringing people along to avoid these binary moments. It is also about taking a stand and having a point of view if you happen to reach such a point.

When presenting the boss with n alternatives he/she will always choose option n+1. If you’re asked to come up with a solution to a problem or you run across a problem you have to solve but need buy in from others, you’re taking a huge risk by presenting alternatives. My view is that you present a solution and everything else is an alternative–whether you put it down on paper or not. A table of pros/cons or a list of options like a menu almost universally gets a response of trying to create an alternative that combines attributes that can’t be combined. I love choices that are cost/quality, cheap/profitable, small/fast and then the meeting concludes in search of the alternative that delivers both.

Nothing is ever decided at a meeting so don’t try. If you reach a point where you’re going to decide a big controversial thing at a meeting then there’s a good chance you’re not really going to decide. Even if you do decide you’re likely to end up with an alliterative you didn’t think of beforehand and thus is not as thought through or as possible as you believed it to be by the end of the meeting. At the very least you’re not going to enroll everyone in the decision which means there is more work to do be done. The best thing to do is not to avoid a decision making meeting but figure out how you can keep things moving forward every day to avoid these moments of truth.

Work on things that are important not urgent. Because of mobile tools like email, twitter, SMS, and notifications of all kinds from all sorts of apps have a way of dominating your attention. In times of stress or uncertainty, we all gravitate to working on what we think we can accomplish. It is easier to work towards inbox zero than to actually dive in and talk to everyone on the team about how they are handling things or to walk into that customer situation. President Eisenhower and later Stephen Covey developed amazing tools for helping you to isolate work that is important rather than urgent.

Products don’t ship with a list of features you thought you’d do but didn’t. The most stressful list of any product development effort is the list of things you have to cut because you’re running out of time or resources. I don’t like to keep that list and never did, for two reasons. First, it just makes you feel bad. The list of things you’re not doing is infinitely long–it is literally everything else. There’s no reason to remind yourself of that. Second, whatever you think you will do as soon as you can will change dramatically once customers start using the product you do end up delivering to them. When you do deliver a product it is what you made and you’re not obligated to market or communicate all the things you thought of but didn’t get done!

If you’re interesting someone won’t agree with what you said. Whether you’re writing a blog, internal email, talking to a group, or speaking to the press you are under pressure. You have to get across a unique point of view and be heard. The challenge is that if you only say things everyone believes to already be the case, then you’re not furthering the dialog. The reality is that if you are trying to change things or move a dialog forward, some will not agree with you. Of course you will learn and there’s a good chance you we wrong and that gives you a chance be interesting in new ways. Being interesting is not the same as being offensive, contrarian, cynical, or just negative. It is about articulating a point of view that acknowledges a complex and dynamic environment that does not lend itself to simple truths. Do make sure you have the right mechanisms in place to learn just how wrong you were and with how many people.

Like for example, if you write a post of 15 management tips, most people won’t agree with all of them :)
–Steven Sinofsky (@stevesi)

Share this:

Like this:

How often do you hear things like “let’s ban email”, “no more attachments”, “death to PowerPoint decks”, “we’re going paperless”, “meeting free friday” or one of dozens of “bans” designed to do away with something that has become annoying or inefficient in the workplace? If you’re around long enough you can see just about anything cross over from innovative new tool to candidate to be banned. The problem is that banning a tool (or process) in an attempt at simplification never solves the problem. Rather, one should to look at a different approach, an approach that focuses on the work not the tool or process.

What’s the problem?

It is well understood that new technologies go through an adoption curve. In the classic sense it is a normal distribution as described by researchers in the 1950’s. More recently and generally cited in the software world is Geoffrey Moore’s Crossing the Chasm which describes a slightly different path. These models all share a common view of a group of early adopters followed by a growing base of users of a technology.

While adoption is great, we are all too used to experiencing excess enthusiasm for new technologies. As a technology spreads, so does the enthusiasm. Invariably some folks use the technology to the the point of abusing it. From reply all to massive attachments to elaborate scorecards with more dimensions than anyone can understand, the well-intentioned enthusiastic user turns a game-changing tool into a distraction or worse.

Just as with adoption curves, once can create a conceptual “irritation curve” and overlay it with adoption. Of course what is pictured below is not based on any data or specific to any technology, but consistent with our collective anecdotal point of view.

The key is that at some point the adoption of a new product crosses the chasm and becomes widely used within a company. While there is a time delay, sometimes years, at some point the perceived “abuse” of the technology causes a cross-over where for some set of people the irritation outpaces the utility. Just as there are early adopters, there are also irritation canaries who are the first to feel the utility of the new technology declining with increased usage.

We see this same dynamic not just for tools, but for business processes as well. That status report, dashboard, or checkin mail all start off as well-intentioned and then after some period of time the “just one more thing” or spreading over-usage at all levels of a team turn a positive into a burden.

Then at some point people start to reject the tool or process. Some even call for an outright ban or elimination.

What’s the solution?

The way to break the cycle is to dive into the actual work and not the tool. Historically, tools fade away when the work process changes.

It is tough to find examples of popular tools and processes that were simply banned that did not make a comeback. Companies that ban meetings or email on fridays just have more meetings and email on monday-thursday. I’ve personally seen far too many examples of too much information crammed on to a page (smaller fonts or margins anyone) or slides that need to be printed rather than projected in an effort to squeeze more on a page when there are forced limits on story-telling.

On the other hand, from voice mail to fax machines to pagers to typewriters to voice calls we have examples of tools that achieve high and subsequently irritating usage levels can and do go away because new tools take over. If you were around for any of those then you know that people called for them to be banned and yet they continued, until one day we all just stopped using them.

A favorite historical example is a company that told me they removed all the typewriters when PCs were introduced. The company was trying to save time because typewriters were much more difficult to use than PCs with printers (of course!). The problem was immediately seen by those responsible for the workflows in the company–all of a sudden no one could fill out an expense report, transfer to another department, or pay an invoice. All of these work processes, the blizzard of paperwork that folks thought were caused by typewriters, were rendered inoperable. These processes all required a typewriter to fill out the form and the word processors had no way of navigating pre-printed forms in triplicate. Of course what needed to happen was not a pre-printed form that worked in a word processor (what the administrative folks asked for), but a rethinking of the workflow that could be enabled by new tools (what management needed to do).

This sort of rethinking of work is what is so exciting right now. It is fair to say that the established, and overloaded, desktop work-processes and tools of the past 20 years are being disrupted by a new generation of tools. In addition to re-imagining how work can be done to avoid the problems of the past, these tools are built on a modern, mobile, cloud, and social infrastructure.

For example, Tom Preston-Werner, co-founder of GitHub, tells a great story about the motivations for GitHub that echoes my own personal experience. As software projects grew the communication of code changes/checkins generate an overwhelming blizzard of mail. Rather than just shut down these notifications and hope for the best, what was needed was a better tool so he invented one.

At Asana, Dustin Moskovitz, tells of their goal to eliminate email for a whole set of tracking and task management efforts. We’ve all seen examples of the collaborative process playing out poorly by using email. There’s too much email and no ability to track and manage the overall work using the tool. Despite calls to ban the process, what is really needed is a new tool. So Asana is one of many companies working to build tools that are better suited to the work than one we currently all collectively seem to complain about.

Just because a tool is broadly deployed doesn’t mean it is the right or best way to work.

We’re seeing new tools that are designed from the ground up to enable new ways of working and these are based on the learning from the past two decades of tool abuse.

What are some warning signs for teams and managers?

It is easy to complain about a tool. Sometimes the complaints are about the work itself and the tool is just the scapegoat. There’s value in looking at tool usage or process creation from a team or management perspective. My own experience is that the clarion calls to ban a tool or process have some common warning signs that are worth keeping an eye out for as the team might avoid the jump to banning something, which we know won’t work.

Who is setting expectations for work product / process? If management is mandating the use of a tool the odds of a rebellion against it go up. As a general rule, the more management frames the outcome and the less the mechanism for the outcome the more tolerance there will be for the tool. Conversely, if the team comes up with a way of working that is hard for outsiders to follow or understand, it is likely to see pushback from partners or management. However, if it is working and the goal is properly framed then it seems harmless to keep using a tool. Teams should be allowed to use or abuse tools as they see fit so long as the work is getting done, no matter how things might look from outside.

Does the work product benefit the team doing the work or the person asking? A corollary to above is the tool or process that is mandated but seems to have no obvious benefit is usually a rebellion in-waiting. Document production is notorious for this. From status reports to slides to spreadsheets, the specification by management to create ever more elaborate “work products” for the benefit of management invariably lead to a distaste for the tool. It is always a good idea for management to reduce the need to create work, tools, and processes where the benefit accrues to management exclusively. Once again, the members of the team will likely start to feel like banning the use of the tool is the only way to ease the overload or tax.

Do people get evaluated (explicitly or implicitly) on the quality of the work product/process or the end-result? A sure-fire warning sign to the looming distaste of a tool or process is when a given work product becomes a goal or is itself measured. Are people measured by the completion of a report? Does someone look at how many email notifications get generated by someone? Does someone get kudos for completing a template about the group’s progress? All of these are tools that might be considered valuable in the course of achieving the actual goals of the team, but are themselves the path along the way. Are your status reports getting progressively more elaborate? Are people creating email rules to shunt email notifications to a folder? Are people starting to say “gosh I must have missed that”? All of those are warning signs that there is an impending pushback against the tool or process.

What doesn’t get done if you just stop? The ultimate indicator for a need to change a tool or process is to play out what would happen if you really did ban it. We all know that banning email is really impractical. There are simply too many exceptions and that is exactly the point. Many tools can have a role in the modern workplace. Banning a tool in isolation of the work never works. Taking a systematic look at the work required that uses a tool, those that use the tool, and those that benefit from the output is the best way to approach the desire to use the most appropriate toolset in the workplace.

What tools need to change in your organization? What work needs to change so that the team doesn’t need to rely on inappropriate or inefficient tools?