Learning by Shipping

products, development, management…

Posts Tagged ‘management

Management Clichés That Work

management mugManaging 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 not 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)

Written by Steven Sinofsky

October 23, 2014 at 12:00 pm

Posted in posts

Tagged with

Don’t ban email—change how you work!

NoEmail1How 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.

Adoption-and-Irritation

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 AsanaDustin 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?

–Steven (@stevesi)

PS: As I finished writing this post, this Forrester report came across twitter: Reality Check: Enterprise Social Does Not Stem Email Overload.

Written by Steven Sinofsky

January 31, 2014 at 7:00 am

Posted in posts

Tagged with ,

steven @ a16z

As a reader of this blog, you probably notice the two big themes of learning (by shipping): (1) learning about new technologies, new ways to do things, and new products and (2) improving how products are made from an engineering and management perspective.  

I’m especially excited to learn by spending more time with entrepreneurs and those creating new technologies and products. Andreessen Horowitz is a VC firm that believes deeply in helping entrepreneurs and helping change the product and business landscape, which is why I am thrilled to join the firm as a board partner.

Board partners are unique at a16z. In this position I will represent the firm on the boards of portfolio companies when the opportunities present themselves, but will not be a full-time member of the firm.

I’m relatively new to the VC world and have a lot of learning to do—and I am very excited to do that. I can’t think of a better place to do this than a16z, as they share the commitment to learning and sharing that learning, for example through all the blog posts the GPs write. I first got to know Ben, Marc, and some of the over 70 people at the firm starting late last year. What was so cool to see was the commitment to fostering innovation, product creation, and working with product-focused entrepreneurs.

More than anything, what I find so cool about a16z are the values clearly articulated and lived day to day by everyone at the firm. From the very first time I got to hang out with folks I saw things that reminded me of the values that contribute to all great product (and company) efforts:

  1. Team effort – Scalable work that “goes big” requires a lot of people. Being part of a team that works to let each person contribute at their highest level is how the resulting whole is greater than the sum of the parts.
  2. Long term – Sustainable efforts take more than one turn of the crank. The commitment to the long term that starts from building strong relationships through supporting entrepreneurs as they create sustainable products and businesses truly differentiates the a16z approach.

My own experience in product development has been focused on learning and changing from within an organization as part of teams—scaling teams, building the first professional GUI dev tools for Windows, marshaling the company around the “InterNet”, bringing together disparate apps to create Office, creating the first collaboration servers, and shifting to the tablet era. Each was decidedly a new effort working to change the rules of the product game while learning along the way. Bringing this relevant experience to new companies is something I’m excited to do.

Among other activities, I will maintain my EIR with Harvard Business School and will continue to pursue other business and product development opportunities that arise.  

As folks following me on Twitter or Facebook know, we’ve been splitting our time between coasts and will do so for a bit more time before transitioning to the Bay Area full time. I will still definitely explore companies out East, but maintain a strong focus on the Bay Area.

Of course I will continue blogging here on learning by shipping (and on LinkedIn Influencers) and you can follow me @stevesi or email me.

–Steven Sinofsky

Written by Steven Sinofsky

August 22, 2013 at 7:15 am

Posted in posts

Tagged with , ,

Continuous Productivity: New tools and a new way of working for a new era

with 43 comments

553698_10101017579649025_101860817_nWhat happens when the tools and technologies we use every day become mainstream parts of the business world?  What happens when we stop leading separate “consumer” and “professional” lives when it comes to technology stacks?  The result is a dramatic change in the products we use at work and as a result an upending of the canon of management practices that define how work is done.

This paper says business must embrace the consumer world and see it not as different, less functional, or less enterprise-worthy, but as the new path forward for how people will use technology platforms, how businesses will organize and execute work, and how the roles of software and hardware will evolve in business. Our industry speaks volumes of the consumerization of IT, but maybe that is not going far enough given the incredible pace of innovation and depth of usage of the consumer software world.  New tools are appearing that radically alter the traditional definitions of productivity and work.  Businesses failing to embrace these changes will find their employees simply working around IT at levels we have not seen even during the earliest days of the PC.   Too many enterprises are either flat-out resisting these shifts or hoping for a “transition”—disruption is taking place, not only to every business, but within every business.

Paradigm shift

Continuous productivity is an era that fosters a seamless integration between consumer and business platforms.  Today, tools and platforms used broadly for our non-work activities are often used for work, but under the radar.  The cloud-powered smartphone and tablet, as productivity tools, are transforming the world around us along with the implied changes in how we work to be mobile and more social. We are in a new era, a paradigm shift, where there is evolutionary discontinuity, a step-function break from the past. This constantly connected, social and mobile generational shift is ushering a time period on par with the industrial production or the information society of the 20th century. Together our industry is shaping a new way to learn, work, and live with the power of software and mobile computing—an era of continuous productivity.

Continuous productivity manifests itself as an environment where the evolving tools and culture make it possible to innovate more and faster than ever, with significantly improved execution. Continuous productivity shifts our efforts from the start/stop world of episodic work and work products to one that builds on the technologies that start to answer what happens when:

  • A generation of new employees has access to the collective knowledge of an entire profession and experts are easy to find and connect with.
  • Collaboration takes place across organization and company boundaries with everyone connected by a social fiber that rises above the boundaries of institutions.
  • Data, knowledge, analysis, and opinion are equally available to every member of a team in formats that are digital, sharable, and structured.
  • People have the ability to time slice, context switch, and proactively deal with situations as they arise, shifting from a world of start/stop productivity and decision-making to one that is continuous.

Today our tools force us to hurry up and wait, then react at all hours to that email or notification of available data.  Continuous productivity provides us a chance at a more balanced view of time management because we operate in a rhythm with tools to support that rhythm.  Rather than feeling like you’re on call all the time waiting for progress or waiting on some person or event, you can simply be more effective as an individual, team, and organization because there are new tools and platforms that enable a new level of sanity.

Some might say this is predicting the present and that the world has already made this shift.  In reality, the vast majority of organizations are facing challenges or even struggling right now with how the changes in the technology landscape will impact their efforts.  What is going on is nothing short of a broad disruption—even winning organizations face an innovator’s dilemma in how to develop new products and services, organize their efforts, and communicate with customers, partners, and even within their own organizations.  This disruption is driven by technology, and is not just about the products a company makes or services offered, but also about the very nature of companies.

Today’s socialplace

The starting point for this revolution in the workplace is the socialplace we all experience each and every day.

We carry out our non-work (digital) lives on our mobile devices.  We use global services like Facebook, Twitter, Gmail, and others to communicate.  In many places in the world, local services such as Weibo, MixIt, mail.ru, and dozens of others are used routinely by well over a billion people collectively.  Entertainment services from YouTube, Netflix to Spotify to Pandora and more dominate non-TV entertainment and dominate the Internet itself.  Relatively new services such as Pinterest or Instagram enter the scene and are used deeply by tens of millions in relatively short times.

While almost all of these services are available on traditional laptop and desktop PCs, the incredible growth in usage from smartphones and tablets has come to represent not just the leading edge of the scenario, but the expected norm.  Product design is done for these experiences first, if not exclusively. Most would say that designing for a modern OS first or exclusively is the expected way to start on a new software experience.  The browser experience (on a small screen or desktop device) is the backup to a richer, more integrated, more fluid app experience.

In short, the socialplace we are all familiar with is part of the fabric of life in much of the world and only growing in importance. The generation growing up today will of course only know this world and what follows. Around the world, the economies undergoing their first information revolutions will do so with these technologies as the baseline.

Historic workplace

Briefly, it is worth reflecting on and broadly characterizing some of the history of the workplace to help to place the dramatic changes into historic context.

Mechanized productivity

The industrial revolution that defined the first half of the 20th century marked the start of modern business, typified by high-volume, large-scale organizations.  Mechanization created a culture of business derived from the capabilities and needs of the time. The essence of mechanization was the factory which focused on ever-improving and repeatable output.  Factories were owned by those infusing capital into the system and the culture of owner, management, and labor grew out of this reality.  Management itself was very much about hierarchy. There was a clear separation between labor and management primarily focused on owners/ownership.

The information available to management was limited.  Supply chains and even assembly lines themselves were operated with little telemetry or understanding of the flow of raw materials through to sales of products. Even great companies ultimately fell because they lacked the ability to gather insights across this full spectrum of work.

Knowledge productivity

The problems created by the success of mechanized production were met with a solution—the introduction of the computer and the start of the information revolution.  The mid-20th century would kick off a revolution in business, business marked by global and connected organizations.  Knowledge created a new culture of business derived from the information gathering and analysis capabilities of first the mainframe and then the PC.

The essence of knowledge was the people-centric office which focused on ever-improving analysis and decision-making to allocate capital, develop products and services, and coordinate the work across the globe.  The modern organization model of a board of directors, executives, middle management, and employees grew out of these new capabilities.  Management of these knowledge-centric organizations happened through an ever-increasing network of middle-managers.  The definition of work changed and most employees were not directly involved in making things, but in analyzing, coordinating, or servicing the products and services a company delivered.

The information available to management grew exponentially.  Middle-management grew to spend their time researching, tabulating, reporting, and reconciling the information sources available.  Information spanned from quantitative to qualitative and the successful leaders were expert or well versed in not just navigating or validating information, but in using it to effectively influence the organization as a whole.  Knowledge is power in this environment.  Management took over the role of resource allocation from owners and focused on decision-making as the primary effort, using knowledge and the skills of middle management to inform those choices.

A symbol of knowledge productivity might be the meeting.  Meetings came to dominate the culture of organizations:  meetings to decide what to meet about, meetings to confirm that people were on the same page, meetings to follow-up from other meetings, and so on.  Management became very good at justifying meetings, the work that went into preparing, having, and following up from meetings.  Power derived from holding meetings, creating follow-up items and more.  The work products of meetings—the pre-reading memos, the presentations, the supporting analytics began to take on epic proportions.  Staff organizations developed that shadowed the whole process.

The essence of these meetings was to execute on a strategy—a multi-year commitment to create value, defend against competition, and to execute.  Much of the headquarters mindset of this era was devoted to strategic analysis and planning.

The very best companies became differentiated by their use of information technologies in now legendary ways such as to manage supply chain or deliver services to customers.  Companies like Wal-Mart pioneered the use of technology to bring lower prices and better inventory management.  Companies like the old MCI developed whole new products based entirely on the ability to write software to provide new ways of offering existing services.

Even with the broad availability of knowledge and information, companies still became trapped in the old ways of doing things, unable to adapt and change.  The role of disruption as a function not just of technology development but as management decision-making showed the intricate relationship between the two. With this era of information technology came the notion of companies too big and too slow to react to changes in the marketplace even with information right there in front of collective eyes.

The impact of software, as we finished the first decade of the 21st century, is more profound than even the most optimistic software people would have predicted.  As the entrepreneur and venture capitalist Marc Andreessen wrote two years ago, “software is eating the world”.  Software is no longer just about the internal workings of business or a way to analyze information and execute more efficiently, but has come to define what products a business develops, offers, and serves.  Software is now the product, from cars to planes to entertainment to banking and more. Every product not only has a major software component but it is also viewed and evaluated through the role of software.  Software is ultimately the product, or at least a substantial part of differentiation, for every product and service.

Today’s workplace: Continuous Productivity

Today’s workplace is as different as the office was from the factory.

Today’s organizations are either themselves mobile or serving customers that are mobile, or likely both.  Mobility is everywhere we look—from apps for consumers to sales people in stores and the cash registers to plane tickets.  With mobility comes an unprecedented degree of freedom and flexibility—freedom from locality, limited information, and the desktop computer.

The knowledge-based organization spent much energy on connecting the dots between qualitative sampling and data sourced on what could be measured. Much went into trying get more sources of data and to seek the exact right answer to important management decisions.  Today’s workplace has access to more data than ever before, but along with that came understanding that just because it came from a computer it isn’t right.  Data is telemetry based on usage from all aspects of the system and goes beyond sampling and surveys.  The use of data today substitutes algorithms seeking exact answers with heuristics informed by data guessing the best answer using a moment’s worth of statistical data.  Today’s answers change over time as more usage generates more data.  We no longer spend countless hours debating causality because what is happening is right there before our eyes.

We see this all the time in the promotion of goods on commerce sites, the use of keyword search and SEO, even the way that search itself corrects spellings or maps use a vast array of data to narrow a potentially very large set of results from queries.  Technologies like speech or vision have gone from trying to compute the exact answer to using real-time data to provide contextually relevant and even more accurate guesses.

The availability of these information sources is moving from a hierarchical access model of the past to a much more collaborative and sharing-first approach.  Every member of an organization should have access to the raw “feeds” that could be material to their role.  Teams become the focus of collaborative work, empowered by the data to inform their decisions.  We see the increasing use of “crowds” and product usage telemetry able to guide improved service and products, based not on qualitative sampling plus “judgment” but on what amounts to a census of real-world usage.

Information technology is at the heart of all of these changes, just as it was in the knowledge era.  The technologies are vastly different.  The mainframe was about centralized information and control.  The PC era empowered people to first take mainframe data and make better use of it and later to create new, but inherently local or workgroup specific information sources.  Today’s cloud-based services serve entire organizations easily and can also span the globe, organizations, and devices.  This is such a fundamental shift in the availability of information that it changes everything in how information is collected, shared, and put to use. It changes everything about the tools used to create, analyze, synthesize, and share information.

Management using yesterday’s techniques can’t seem keep up with this world. People are overwhelmed by the power of their customers with all this information (such as when social networks create a backlash about an important decision, or we visit a car dealer armed with local pricing information).  Within organizations, managers are constantly trying to stay ahead of the curve.  The “young” employees seem to know more about what is going on because of Twitter and Facebook or just being constantly connected.  Even information about the company is no longer the sole domain of management as the press are able to uncover or at least speculate about the workings of a company while employees see this speculation long before management is communicating with employees.  Where people used to sit in important meetings and listen to important people guess about information, people now get real data from real sources in real-time while the meeting is taking place or even before.

This symbol of the knowledge era, the meeting, is under pressure because of the inefficiency of a meeting when compared to learning and communicating via the technology tools of today.  Why wait for a meeting when everyone has the information required to move forward available on their smartphones?  Why put all that work into preparing a perfect pitch for a meeting when the data is changing and is a guess anyway, likely to be further informed as the work progresses?  Why slow down when competitors are speeding up?

There’s a new role for management that builds on this new level of information and employees skilled in using it.  Much like those who grew up with PC “natively” were quick to assume their usage in the workplace (some might remember the novelty of when managers first began to answer their own email), those who grow up with the socialplace are using it to do work, much to the chagrin of management.

Management must assume a new type of leadership that is focused on framing the outcome, the characteristics of decisions, and the culture of the organization and much less about specific decision-making or reviewing work.  The role of workplace technology has evolved significantly from theory to practice as a result of these tools. The following table contrasts the way we work between the historic norms and continuous productivity.

Then Now, Continuous Productivity
Process Exploration
Hierarchy, top down or middle out Network, bottom up
Internal committees Internal and external teams, crowds
Strategy-centric Execution-centric
Presenting packaged and produced ideas, documents Sharing ideas and perspectives continuously, service
Data based on snapshots at intervals, viewed statically Data always real-time, viewed dynamically
Process-centric Rhythm-centric
Exact answers Approximation and iteration
More users More usage

Today’s workplace technology, theory

Modern IT departments, fresh off the wave of PC standardization and broad homogenization of the IT infrastructure developed the tools and techniques to maintain, ne contain, the overall IT infrastructure.

A significant part of the effort involved managing the devices that access the network, primarily the PC.  Management efforts ran the gamut from logon scripts, drive scanning, anti-virus software, standard (or only) software load, imaging, two-factor authentication and more.  Motivating this has been the longstanding reliability and security problems of the connected laptop—the architecture’s openness so responsible for the rise of the device also created this fragility.  We can see this expressed in two symbols of the challenges faced by IT: the corporate firewall and collaboration.  Both of these technologies offer good theories but somewhat backfire in practice in today’s context.

With the rise of the Internet, the corporate firewall occupied a significant amount of IT effort.  It also came to symbolize the barrier between employees and information resources.  At some extremes, companies would routinely block known “time wasters” such as social networks and free email.  Then over time as the popularity of some services grew, the firewall would be selectively opened up for business purposes.  YouTube and other streaming services are examples of consumer services that transitioned to an approved part of enterprise infrastructure given the value of information available.  While many companies might view Twitter as a time-wasting service, the PR departments routinely use it to track news and customer service might use it to understand problems with products so it too becomes an expected part of infrastructure.  These “cracks” in the notion of enterprise v. consumer software started to appear.

Traditionally the meeting came to symbolize collaboration.  The business meeting which occupied so much of the knowledge era has taken on new proportions with the spread of today’s technologies.  Businesses have gone to great lengths to automate meetings and enhance them with services.  In theory this works well and enables remote work and virtual teams across locations to collaborate.  In practical use, for many users the implementation was burdensome and did not support the wide variety of devices or cross-organization scenarios required.  The merger of meetings with the traditional tools of meetings (slides, analysis, memos) was also cumbersome as sharing these across the spectrum of devices and tools was also awkward. We are all familiar with the first 10 minutes of every meeting now turning into a technology timesink where people get connected in a variety of ways and then sync up with the “old tools” of meetings while they use new tools in the background.

Today’s workspace technology, practice

In practice, the ideal view that IT worked to achieve has been rapidly circumvented by the low-friction, high availability of a wide variety of faster-to-use, easier-to-use, more flexible, and very low-cost tools that address problems in need of solutions.  Even though this is somewhat of a repeat of the introduction of PCs in the early 1990’s, this time around securing or locking down the usage of these services is far more challenging than preventing network access and isolating a device.  The Internet works to make this so, by definition.

Today’s organizations face an onslaught of personally acquired tablets and smartphones that are becoming, or already are, the preferred device for accessing information and communication tools.  As anyone who uses a smartphone knows, accessing your inbox from your phone quickly becomes the preferred way to deal with the bulk of email.  How often do people use their phones to quickly check mail even while in front of their PC (even if the PC is not in standby or powered off)?  How much faster is it to triage email on a phone than it is on your PC?

These personal devices are seen in airports, hotels, and business centers around the world.  The long battery life, fast startup time, maintenance-free (relatively), and of course the wide selection of new apps for a wide array of services make these very attractive.

There is an ongoing debate about “productivity” on tablets.  In nearly all ways this debate was never a debate, but just a matter of time.  While many look at existing scenarios to be replicated on a tablet as a measure of success of tablets at achieving “professional productivity”, another measure is how many professionals use their tablets for their jobs and leave their laptops at home or work.  By that measure, most are quick to admit that tablets (and smartphones) are a smashing success.  The idea that tablets are used only for web browsing and light email seems as quaint as claiming PCs cannot do the work of mainframes—a common refrain in the 1980s.  In practice, far too many laptops have become literally desktops or hometops.

While the use of tools such as AutoCAD, Creative Suite, or enterprise line of business tools will be required and require PCs for many years to come, the definition of professional productivity will come to include all the tasks that can be accomplished on smartphones and tablets.  The nature of work is changing and so the reality of the tools in use are changing as well.

Perhaps the most pervasive services for work use are cloud-based storage products such as DropBox, Hightail (YouSendIt), or Box.  These products are acquired easily by consumers, have straightforward browser-based interfaces and apps on all devices, and most importantly solve real problems required by modern information sharing.  The basic scenario of sharing large files with a customers or partners (or even fellow employees) across heterogeneous devices and networks is easily addressed by these tools.  As a result, expensive and elaborate (or often much richer) enterprise infrastructure goes unused for this most basic of business needs—sharing files.  Even the ubiquitous USB memory stick is used to get around the limitations of enterprise storage products, much to the chagrin of IT departments.

Tools beyond those approved for communication are routinely used by employees on their personal devices (except of course in regulated industries).  Tools such as WhatsApp or WeChat have hundreds of millions of users.  A quick look at Facebook or Twitter show that for many of those actively engaged the sharing of work information, especially news about products and companies, is a very real effort that goes beyond “the eggs I had for breakfast” as social networks have sometimes been characterized.  LinkedIn has become the goto place for sales people learning about customers and partners and recruiters seeking to hire (or headhunt) and is increasingly becoming a primary source of editorial content about work and the workplace.  Leading strategists are routinely read by hundreds of thousands of people on LinkedIn and their views shared among the networks employees maintain of their fellow employees.  It has become challenging for management to “compete” with the level and volume of discourse among employees.

The list of devices and services routinely used by workers at every level is endless.  The reality appears to be that for many employees the number of hours of usage in front of approved enterprise apps on managed enterprise devices is on the decline, unless new tablets and phones have been approved.  The consumerization of IT appears to be very real, just by anecdotally observing the devices in use on public transportation, airports, and hotels.  Certainly the conversation among people in suits over what to bring on trips is real and rapidly tilting towards “tablet for trips”, if not already there.

The frustration people have with IT to deliver or approve the use of services is readily apparent, just as the frustration IT has with people pushing to use insecure, unapproved, and hard to manage tools and devices.  Whenever IT puts in a barrier, it is just a big rock in the information river that is an organization and information just flows around it.  Forward-looking IT is working diligently to get ahead of this challenge, but the models used to reign in control of PCs and servers on corporate premises will prove of limited utility.

A new approach is needed to deal with this reality.

Transition versus disruption

The biggest risks organizations face is in thinking the transition to a new way of working will be just that, a transition, rather than a disruption.  While individuals within an organization, particularly those that might be in senior management, will seek to smoothly transition from one style of work to another, the bulk of employees will switch quickly. Interns, new hires, or employees looking for an edge see these changes as the new normal or the only normal they’ve ever experienced.  Our own experience with PCs is proof of how quickly change can take place.

In Only the Paranoid Survive, Andy Grove discussed breaking the news to employees of a new strategy at Intel only to find out that employees had long ago concluded the need for change—much to the surprise of management.  The nature of a disruptive change in management is one in which management believes they are planning a smooth transition to new methods or technologies only to find out employees have already adopted them.

Today’s technology landscape is one undergoing a disruptive change in the enterprise—the shift to cloud based services, social interaction, and mobility.  There is no smooth transition that will take place.  Businesses that believe people will gradually move from yesterday’s modalities of work to these new ways will be surprised to learn that people are already working in these new ways. Technologists seeking solutions that “combine the best of both worlds” or “technology bridge” solutions will only find themselves comfortably dipping their toe in the water further solidifying an old approach while competitors race past them.  The nature of disruptive technologies is the relentless all or nothing that they impose as they charge forward.

While some might believe that continuing to focus on “the desktop” will enable a smoother transition to mobile (or consumer) while the rough edges are worked out or capabilities catch up to what we already have, this is precisely the innovator’s dilemma – hunkering down and hoping things will not take place as quickly as they seem to be for some.  In fact, to solidify this point of view many will point to a lack of precipitous decline or the mission critical nature in traditional ways of working.  The tail is very long, but innovation and competitive edge will not come from the tail.  Too much focus on the tail will risk being left behind or at the very least distract from where things are rapidly heading. Compatibility with existing systems has significant value, but is unlikely to bring about more competitive offerings, better products, or step-function improvements in execution.

Culture of continuous productivity

The culture of continuous productivity enabled by new tools is literally a rewrite of the past 30 years of management doctrine.  Hierarchy, top-down decision making, strategic plans, static competitors, single-sided markets, and more are almost quaint views in a world literally flattened by the presence of connectivity, mobility, and data. The impact of continuous productivity can be viewed through the organization, individuals and teams, and the role of data.

The social and mobile aspects of work, finally, gain support of digital tools and with those tools the realization of just how much of nearly all work processes are intrinsically social.   The existence and paramount importance of “document creation tools” as the nature of work appear, in hindsight, to have served as a slight detour of our collective focus.  Tools can now work more like we like to work, rather than forcing us to structure our work to suit the tools.  Every new generation of tools comes with promises of improvements, but we’ve already seen how the newest styles of work lead to improvements in our lives outside of work. Where it used to be novel for the person with a PC to use those tools to organize a sports team or school function, now we see the reverse and we see the tools for the rest of life being used to improve our work.

This existence proof makes this revolution different.  We already experience the dramatic improvements in our social and non-work “processes”.  With the support and adoption of new tools, just as our non-work lives saw improvements we will see improvements in work.

The cultural changes encouraged or enabled by continuous productivity include:

  • Innovate more and faster.  The bottom line is that by compressing the time between meaningful interactions between members of a team, we will go from problem to solution faster.  Whether solving a problem with an existing product or service or thinking up a new one, the continuous nature of communication speeds up the velocity and quality of work. We all experience the pace at which changes outside work take place compared to the slow pace of change within our workplaces.
  • Flatten hierarchy. The difficulty in broad communication, the formality of digital tools, and restrictions on the flow of information all fit perfectly with a strict hierarchical model of teams.  Managers “knew” more than others.  Information flowed down.  Management informed employees.  Equal access to tools and information, a continuous multi-way dialog, and the ease and bringing together relevant parties regardless of place in the organization flattens the hierarchy.  But more than that, it shines a light on the ineffectiveness and irrelevancy of a hierarchy as a command structure.

  • Improve execution.  Execution improves because members of teams have access to the interactions and data in real-time.  Gone are the days of “game of telephone” where information needed to “cascade” through an organization only to be reinterpreted or even filtered by each level of an organization.
  • Respond to changes using telemetry / data.  With the advent of continuous real-world usage telemetry, the debate and dialog move from deciding what the problems to be solved might be to solving the problem.  You don’t spend energy arguing over the problem, but debating the merits of various solutions.

  • Strengthen organization and partnerships.  Organizations that communicate openly and transparently leave much less room for politics and hidden agendas.  The transparency afforded by tools might introduce some rough and tumble in the early days as new “norms” are created but over time the ability to collaborate will only improve given the shared context and information base everyone works from.
  • Focus on the destination, not the journey.  The real-time sharing of information forces organizations to operate in real-time. Problems are in the here and now and demand solutions in the present. The benefit of this “pressure” is that a focus on the internal systems, the steps along the way, or intermediate results is, out of necessity, de-emphasized.

Organization culture change

Continuously productive organizations look and feel different from traditional organizations. As a comparison, consider how different a reunion (college, family, etc.) is in the era of Facebook usage. When everyone gets together there is so much more that is known—the reunion starts from shared context and “intimacy”.  Organizations should be just as effective, no matter how big or how geographically dispersed.

Effective organizations were previously defined by rhythms of weekly, monthly and quarterly updates.  These “episodic” connection points had high production values (and costs) and ironically relatively low retention and usage.  Management liked this approach as it placed a high value on and required active management as distinct from the work.  Tools were designed to run these meetings or email blasts, but over time these were far too often over-produced and tended to be used more for backward looking pseudo-accountability.

Looking ahead, continuously productive organizations will be characterized by the following:

  • Execution-centric focus.  Rather than indexing on the process of getting work done, the focus will shift dramatically to execution. The management doctrine of the late 20th century was about strategy.  For decades we all knew that strategy took a short time to craft in reality, but in practice almost took on a life of its own. This often led to an ever-widening gap between strategy and execution, with execution being left to those of less seniority.  When everyone has the ability to know what can be known (which isn’t everything) and to know what needs to be done, execution reigns supreme.  The opportunity to improve or invent will be everywhere and even with finite resources available, the biggest failure of an organization will be a failure to act.
  • Management framing context with teams deciding. Because information required discovery and flowed (deliberately) inefficiently management tasked itself with deciding “things”. The entire process of meetings degenerated into a ritualized process to inform management to decide amongst options while outside the meeting “everyone” always seemed to know what to do. The new role of management is to provide decision-making frameworks, not decisions.  Decisions need to be made where there is the most information. Framing the problem to be solved out of the myriad of problems and communicating that efficiently is the new role of management.
  • Outside is your friend.  Previously the prevailing view was that inside companies there was more information than there was outside and often the outside was viewed as being poorly informed or incomplete. The debate over just how much wisdom resides in the crowd will continue and certainly what distinguishes companies with competitive products will be just how they navigate the crowd and simultaneously serve both articulated and unarticulated needs.  For certain, the idea that the outside is an asset to the creation of value, not just the destination of value, is enabled by the tools and continuous flow of information.
  • Employees see management participate and learn, everyone has the tools of management.  It took practically 10 years from the introduction of the PC until management embraced it as a tool for everyday use by management.  The revolution of social tools is totally different because today management already uses the socialplace tools outside of work. Using Twitter for work is little different from using Facebook for family.  Employees expect management to participate directly and personally, whether the tool is a public cloud service or a private/controlled service. The idea of having an assistant participate on behalf of a manager with a social tool is as archaic as printing out email and typing in handwritten replies. Management no longer has separate tools or a different (more complete) set of books for the business, but rather information about projects and teams becomes readily accessible.
  • Individuals own devices, organizations develop and manage IP. PCs were first acquired by individual tech enthusiasts or leading edge managers and then later by organizations.  Over time PCs became physical assets of organizations.  As organizations focused more on locking down and managing those assets and as individuals more broadly had their own PCs, there was a decided shift to being able to just “use a computer” when needed.  The ubiquity of mobile devices almost from the arrival of smartphones and certainly tablets, has placed these devices squarely in the hands of individuals. The tablet is mine. And because it is so convenient for the rest of my life and I value doing a good job at work, I’m more than happy to do work on it “for free”.  In exchange, organizations are rapidly moving to tools and processes that more clearly identify the work products as organization IP not the devices.  Cloud-based services become the repositories of IP and devices access that through managed credentials.

Individuals and teams work differently

The new tools and techniques come together to improve upon the way individuals and teams interact.  Just as the first communication tools transformed business, the tools of mobile and continuous productivity change the way interactions happen between individuals and teams.

  • Sense and respond.  Organizations through the PC era were focused on planning and reacting cycles.  The long lead time to plan combined with the time to plan a reaction to events that were often delayed measurements themselves characterized “normal”.  New tools are much more real-time and the information presented represents the whole of the information at work, not just samples and surveys.  The way people will work will focus much more on everyone being sensors for what is going on and responding in real-time.  Think of the difference between calling for a car or hailing a cab and using Uber or Lyft from either a consumer perspective or from the business perspective of load balancing cars and awareness of the assets at hand as representative to sensing and responding rather than planning.
  • Bottom up and network centric.  The idea of management hierarchy or middle management as gatekeepers is being broken down by the presence of information and connectivity.  The modern organization working to be the most productive will foster an environment of bottom up—that is people closest to the work are empowered with information and tools to respond to changes in the environment.  These “bottoms” of the organization will be highly networked with each other and connected to customers, partners, and even competitors.  The “bandwidth” of this network is seemingly instant, facilitated by information sharing tools.
  • Team and crowd spanning the internal and external.  The barriers of an organization will take on less and less meaning when it comes to the networks created by employees.  Nearly all businesses at scale are highly virtualized across vendors, partners, and customers.  Collaboration on product development, product implementation, and product support take place spanning information networks as well as human networks.  The “crowd” is no longer a mob characterized by comments on a blog post or web site, but can be structured and systematically tapped with rich demographic information to inform decisions and choices.
  • Unstructured work rhythm.  The highly structured approach to work that characterized the 20th century was created out of a necessity for gathering, analyzing, and presenting information for “costly” gatherings of time constrained people and expensive computing.  With the pace of business and product change enabled by software, there is far less structure required in the overall work process.  The rhythm of work is much more like routine social interactions and much less like daily, weekly, monthly staff meetings.  Industries like news gathering have seen these radical transformations, as one example.

Data becomes pervasive (and big)

With software capabilities come ever-increasing data and information.  While the 20th century enabled the collection of data and to a large degree the analysis of data to yield ever improving decisions in business, the prevalence of continuous data again transforms business.

  • Sharing data continuously.  First and foremost, data will now be shared continuously and broadly within organizations. The days when reports were something for management and management waited until the end of the week or month to disseminate filtered information are over.  Even though financial data has been relatively available, we’re now able to see how products are used, trouble shoot problems customers might be having, understand the impact of small changes, and try out alternative approaches.  Modern organizations will provide tools that enable the continuous sharing of data through mobile-first apps that don’t require connectivity to corporate networks or systems chained to desktop resources
  • Always up to date.  The implication of continuously sharing information means that everyone is always up to date.  When having a discussion or meeting, the real world numbers can be pulled up right then and there in the hallway or meeting room.  Members of teams don’t spend time figuring out if they agree on numbers, where they came from or when they were “pulled”.  Rather the tools define the numbers people are looking at and the data in those tools is the one true set of facts.
  • Yielding best statistical approach informed by telemetry (induction).  The notion that there is a “right” answer is antiquated as the printed report.  We can now all admit that going to a meeting with a printed out copy of “the numbers” is not worth the debate over the validity or timeframe of those numbers (“the meeting was rescheduled, now we have to reprint the slides.”)  Meetings now are informed by live data using tools such as Mixpanel or live reporting from Workday, Salesforce and others.  We all know now that “right” is the enemy of “close enough” given that the datasets we can work with are truly based on census and not surveys.  This telemetry facilitates an inductive approach to decision-making.
  • Valuing more usage.  Because of the ability to truly understand the usage of products—movies watched, bank accounts used, limousines taken, rooms booked, products browsed and more—the value of having more people using products and services increases dramatically.  Share matters more in this world because with share comes the best understanding of potential growth areas and opportunities to develop for new scenarios and new business approaches.

New generation of productivity tools, examples and checklist

Bringing together new technologies and new methods for management has implications that go beyond the obvious and immediate.  We will all certainly be bringing our own devices to work, accessing and contributing to work from a variety of platforms, and seeing our work take place across organization boundaries with greater ease.  We can look very specifically at how things will change across the tools we use, the way we communicate, how success is measured, and the structure of teams.

Tools will be quite different from those that grew up through the desktop PC era.  At the highest level the implications about how tools are used are profound.  New tools are being developed today—these are not “ports” of existing tools for mobile platforms, but ideas for new interpretations of tools or new combinations of technologies.  In the classic definition of innovator’s dilemma, these new tools are less functional than the current state-of-the-art desktop tools.  These new tools have features and capabilities that are either unavailable or suboptimal at an architectural level in today’s ubiquitous tools.  It will be some time, if ever, before new tools have all the capabilities of existing tools.  By now, this pattern of disruptive technologies is familiar (for example, digital cameras, online reading, online videos, digital music, etc.).

The user experience of this new generation of productivity tools takes on a number of attributes that contrast with existing tools, including:

  • Continuous v. episodic. Historically work took place in peaks and valleys.  Rough drafts created, then circulated, then distributed after much fanfare (and often watering down).  The inability to stay in contact led to a rhythm that was based on high-cost meetings taking place at infrequent times, often requiring significant devotion of time to catching up. Continuously productive tools keep teams connected through the whole process of creation and sharing.  This is not just the use of adjunct tools like email (and endless attachments) or change tracking used by a small number of specialists, but deep and instant collaboration, real-time editing, and a view that information is never perfect or done being assembled.
  • Online and shared information.  The old world of creating information was based on deliberate sharing at points in time.  Heavyweight sharing of attachments led to a world where each of us became “merge points” for work. We worked independently in silos hoping not to step on each other never sure where the true document of record might be or even who had permission to see a document.  New tools are online all the time and by default.  By default information can be shared and everyone is up to date all the time.
  • Capture and continue  The episodic nature of work products along with the general pace of organizations created an environment where the “final” output carried with it significant meaning (to some).  Yet how often do meetings take place where the presenter apologizes for data that is out of date relative to the image of a spreadsheet or org chart embedded in a presentation or memo?  Working continuously means capturing information quickly and in real-time then moving on.  There are very few end points or final documents.  Working with customers and partners is a continuous process and the information is continuous as well.
  • Low startup costs.  Implementing a new system used to be a time consuming and elaborate process viewed as a multi-year investment and deployment project.  Tools came to define the work process and more critically make it impossibly difficult to change the work process.  New tools are experienced the same way we experience everything on the Internet—we visit a site or download an app and give it a try.  The cost to starting up is a low-cost subscription or even a trial.  Over time more features can be purchased (more controls, more depth), but the key is the very low-cost to begin to try out a new way to work.  Work needs change as market dynamics change and the era of tools preventing change is over.
  • Sharing inside and outside.  We are all familiar with the challenges of sharing information beyond corporate boundaries.  Management and IT are, rightfully, protective of assets.  Individuals struggle with the basics of getting files through firewalls and email guards.  The results are solutions today that few are happy with.  Tools are rapidly evolving to use real identities to enable sharing when needed and cross-organization connections as desired.  Failing to adopt these approaches, IT will be left watching assets leak out and workarounds continue unabated.
  • Measured enterprise integration.  The PC era came to be defined at first by empowerment as leading edge technology adopters brought PCs to the workplace.  The mayhem this created was then controlled by IT that became responsible to keep PCs running, information and networks secure, and enforce consistency in organizations for the sake of sharing and collaboration.  Many might (perhaps wrongly) conclude that the consumerization wave defined here means IT has no role in these tasks.  Rather the new era is defined by a measured approach to IT control and integration.  Tools for identity and device management will come to define how IT integrates and controls—customization or picking and choosing code are neither likely nor scalable across the plethora of devices and platforms that will be used by people to participate in work processes. The net is to control enterprise information flow, not enterprise information endpoints.
  • Mobile first.  An example of a transition between the old and new, many see the ability to view email attachments on mobile devices as a way forward.  However, new tools imply this is a true bridge solution as mobility will come to trump most everything for a broad set of people.  Deep design for architects, spreadsheets for analysts, or computation for engineers are examples that will likely be stationary or at least require unique computing capabilities for some time. We will all likely be surprised by the pace at which even these “power” scenarios transition in part to mobile.  The value of being able to make progress while close to the site, the client, or the problem will become a huge asset for those that approach their professions that way.
  • Devices in many sizes. Until there is a radical transformation of user-machine interaction (input, display), it is likely almost all of us will continue to routinely use devices of several sizes and those sizes will tend to gravitate towards different scenarios (see http://blog.flurry.com/bid/99859/The-Who-What-and-When-of-iPhone-and-iPad-Usage), though commonality in the platforms will allow for overlap.  This overlap will continue to be debated as “compromise” by some.  It is certain we will all have a device that we carry and use almost all the time, the “phone”.  A larger screen device will continue to better serve many scenarios or just provide a larger screen area upon which to operate.  Some will find a small tablet size meeting their needs almost all of the time.  Others will prefer a larger tablet, perhaps with a keyboard.  It is likely we will see somewhat larger tablets arise as people look to use modern operating systems as full-time replacements for existing computing devices.  The implications are that tools will be designed for different device sizes and input modalities.

It is worth considering a few examples of these tools.  As an illustration, the following lists tools in a few generalized categories of work processes.  New tools are appearing almost every week as the opportunity for innovation in the productivity space is at a unique inflection point.  These examples are just a few tools that I’ve personally had a chance to experience—I suspect (and hope) that many will want to expand these categories and suggest additional tools (or use this as a springboard for a dialog!)

The architecture and implementation of continuous productivity tools will also be quite different from the architecture of existing tools.  This starts by targeting a new generation of platforms, sealed-case platforms.

The PC era was defined by a level of openness in architecture that created the opportunity for innovation and creativity that led to the amazing revolution we all benefit from today.  An unintended side-effect of that openness was the inherent unreliability over time, security challenges, and general futzing that have come to define the experience many lament.  The new generation of sealed case platforms—that is hardware, software, and services that have different points of openness, relative to previous norms in computing, provide for an experience that is more reliable over time, more secure and predictable, and less time-consuming to own and use.  The tradeoff seems dramatic (or draconian) to those versed in old platforms where tweaking and customizing came to dominate.  In practice the movement up the stack, so to speak, of the platform will free up enormous amounts of IT budget and resources to allow a much broader focus on the business.  In addition, choice, flexibility, simplicity in use, and ease of using multiple devices, along with a relative lack of futzing will come to define this new computing experience for individuals.

The sealed case platforms include iOS, Android, Chromebooks, Windows RT, and others.  These platforms are defined by characteristics such as minimizing APIs that manipulate the OS itself, APIs that enforce lower power utilization (defined background execution), cross-application security (sandboxing), relative assurances that apps do what they say they will do (permissions, App Stores), defined semantics for exchanging data between applications, and enforced access to both user data and app state data.  These platforms are all relatively new and the “rules” for just how sealed a platform might be and how this level of control will evolve are still being written by vendors.  In addition, devices themselves demonstrate the ideals of sealed case by restricting the attachment of peripherals and reducing the reliance on kernel mode software written outside the OS itself.  For many this evolution is as controversial as the transition automobiles made from “user-serviceable” to electronic controlled engines, but the benefits to the humans using the devices are clear.

Building on the sealed case platform, a new generation of applications will exhibit a significant number of the following attributes at the architecture and implementation level.  As with all transitions, debates will rage over the relative strength or priority of one or more attributes for an app or scenario (“is something truly cloud” or historically “is this a native GUI”).  Over time, if history is any guide, the preferred tools will exhibit these and other attributes as a first or native priority, and de-prioritize the checklists that characterized the “best of” apps for the previous era.

The following is a checklist of attributes of tools for continuous productivity:

  • Mobile first. Information will be accessed and actions will be performed mobile first for a vast majority of both employees and customers.  Mobile first is about native apps, which is likely to create a set of choices for developers as they balance different platforms and different form factors.
  • Cloud first.  Information we create will be stored first in the cloud, and when needed (or possible) will sync back to devices.  The days of all of us focusing on the tasks of file management and thinking about physical storage have been replaced by essentially unlimited cloud storage.  With cloud-storage comes multi-device access and instant collaboration that spans networks.  Search becomes an integral part of the user-experience along with labels and meta-data, rather than physical hierarchy presenting only a single dimension.  Export to broadly used interchange formats and printing remain as critical and archival steps, but not the primary way we share and collaborate.
  • User experience is platform native or browser exploitive.  Supporting mobile apps is a decision to fully use and integrate with a mobile platform.  While using a browser can and will be a choice for some, even then it will become increasingly important to exploit the features unique to a browser.  In all cases, the usage within a customer’s chosen environment encourages the full range of support for that platform environment.
  • Service is the product, product is the service.  Whether an internal IT or a consumer facing offering, there is no distinction where a product ends and a continuously operated and improving service begins.  This means that the operational view of a product is of paramount importance to the product itself and it means that almost every physical product can be improved by a software service element.
  • Tools are discrete, loosely coupled, limited surface area.  The tools used will span platforms and form factors.  When used this way, monolithic tools that require complex interactions will fall out of favor relative to tools more focused in their functionality.  Doing a smaller set of things with focus and alacrity will provide more utility, especially when these tools can be easily connected through standard data types or intermediate services such as sharing, storage, and identity.
  • Data contributed is data extractable.  Data that you add to a service as an end-user is easily extracted for further use and sharing.  A corollary to this is that data will be used more if it can also be extracted a shared.  Putting barriers in place to share data will drive the usage of the data (and tool) lower.
  • Metadata is as important as data.  In mobile scenarios the need to search and isolate information with a smaller user interface surface area and fewer “keystrokes” means that tools for organization become even more important.  The use of metadata implicit in the data, from location to author to extracted information from a directory of people will become increasingly important to mobile usage scenarios.
  • Files move from something you manage to something you use when needed.  Files (and by corollary mailboxes) will simply become tools and not obsessions.  We’re all seeing the advances in unlimited storage along with accurate search change the way we use mailboxes.  The same will happen with files.  In addition, the isolation and contract-based sharing that defines sealed platforms will alter the semantic level at which we deal with information.  The days of spending countless hours creating and managing hierarchies and physical storage structures are over—unlimited storage, device replication, and search make for far better alternatives.  
  • Identity is a choice.  Use of services, particularly consumer facing services, requires flexibility in identity.  Being able to use company credentials and/or company sign-on should be a choice but not a requirement.  This is especially true when considering use of tools that enable cross-organization collaboration. Inviting people to participate in the process should be as simple as sending them mail today.
  • User experience has a memory and is aware and predictive.  People expect their interactions with services to be smart—to remember choices, learn preferences, and predict what comes next.  As an example, location-based services are not restricted to just maps or specific services, but broadly to all mobile interactions where the value of location can improve the overall experience.
  • Telemetry is essential / privacy redefined.  Usage is what drives incremental product improvements along with the ability to deliver a continuously improving product/service.  This usage will be measured by anonymous, private, opt-in telemetry.  In addition, all of our experiences will improve because the experience will be tailored to our usage.  This implies a new level of trust with regard to the vendors we all use.  Privacy will no doubt undergo (or already has undergone) definitional changes as we become either comfortable or informed with respect to the opportunities for better products.   
  • Participation is a feature.  Nearly every service benefits from participation by those relevant to the work at hand.  New tools will not just enable, but encourage collaboration and communication in real-time and connected to the work products.  Working in one place (document editor) and participating in another (email inbox) has generally been suboptimal and now we have alternatives.  Participation is a feature of creating a work product and ideally seamless.
  • Business communication becomes indistinguishable from social.  The history of business communication having a distinct protocol from social goes back at least to learning the difference between a business letter and a friendly letter in typing class.  Today we use casual tools like SMS for business communication and while we will certainly be more respectful and clear with customers, clients, and superiors, the reality is the immediacy of tools that enable continuous productivity will also create a new set of norms for business communication.  We will also see the ability to do business communication from any device at any time and social/personal communication on that same device drive a convergence of communication styles.
  • Enterprise usage and control does not make things worse. In order for enterprises to manage and protect the intellectual property that defines the enterprise and the contribution employees make to the enterprise IP, data will need to be managed.  This is distinctly different from managing tools—the days of trying to prevent or manage information leaks by controlling the tools themselves are likely behind us.  People have too many choices and will simply choose tools (often against policy and budgets) that provide for frictionless work with coworkers, partners, customers, and vendors.  The new generation of tools will enable the protection and management of information that does not make using tools worse or cause people to seek available alternatives.  The best tools will seamlessly integrate with enterprise identity while maintaining the consumerization attributes we all love.

What comes next?

Over the coming months and years, debates will continue over whether or not the new platforms and newly created tools will replace, augment, or see occasional use relative to the tools with which we are all familiar.  Changes as significant as those we are experiencing right now happen two ways, at first gradually and then quickly, to paraphrase Hemingway. Some might find little need or incentive to change. Others have already embraced the changes.  Perhaps those right now on the cusp, realize that the benefits of their new device and new apps are gradually taking over their most important work and information needs.  All of these will happen.  This makes for a healthy dialog.

It also makes for an amazing opportunity to transform how organizations make products, serve customers, and do the work of corporations.  We’re on the verge of seeing an entire rewrite of the management canon of the 20th century.  New ways of organizing, managing, working, collaborating are being enabled by the tools of the continuous productivity paradigm shift.

Above all, it makes for an incredible opportunity for developers and those creating new products and services.  We will all benefit from the innovations in technology that we will experience much sooner than we think.

–Steven Sinofsky

Written by Steven Sinofsky

August 20, 2013 at 7:00 am

Delegating or micromanaging, threading the needle

with 14 comments

delegationMicromanagement can be a reflection of a manager’s feedback and concerns about progress.  Empowerment can create a detached or worried manager.  Threading the needle between delegation and micromanagement is central to the relationship between a manager and a report.  How do you balance this as either a manager or employee?

Be sure to check out the poll results at the end of this post on the topic of why meetings are so ineffective.  This week’s poll is https://www.surveymonkey.com/s/NTSCCCK

A first year MBA student made the following observation:

High-performing people generally want autonomy to get things done without anyone micromanaging them.  At the same time, as a midlevel manager, I’ve often had someone above me who’s holding me accountable for whatever my direct reports are working on.

I’m struggling to find the right balance between giving people their autonomy while also asking sufficient questions to get the detail I need in order to feel comfortable with how things are going. 

This situation is not uncommon and represents a most fundamental challenge in any management hierarchy.  The situation boils down to a manager feeling accountable, employees wanting the freedom to do the work the best way they know how, and those outside this context assuming all is functioning well.

Here are 5 suggestions for improving the delegation process and avoiding the label of micromanagement:

  • Delegate the problem, don’t solve it.  The first sign of micromanaging is when delegating a project you also delegate the specifics of the solution.  While that makes sense in some fields, in creative or information work, being told up front the steps to follow makes one feel like a vendor and not a partner in the work.  This type of delegation doesn’t have the feeling that it enhances skills or career.  If the steps are well-known then perhaps there is a different view of the problem or delegation that will better suit a creative member of the team.
  • Share experiences, don’t instruct.  As the work progresses there’s a chance that the manager will see a pattern or similar situation arise.  There’s a good chance the way that experience is communicated can come across as either “sage sharing of experiences” or “more micromanaging”.  If there are experiences to share then share the story and allow the learning to take place by allegory and not turn the learning into “just do these steps”.
  • Listen to progress, don’t review it.  Just as managers should be delegating the problem, not the steps to solving it, when it comes time for progress to be reported it is best to let folks report on the progress the way it works best.  Micromanaging can also take the form of being specific about how progress should be reported or “summoning” people to review the progress.  If folks have been asked to take on a project, make sure they have the freedom to define the mechanics of the project as well.
  • Provide feedback, don’t course correct.  Things might not be always going as well as everyone wants and when that happens managers can sometimes slip into “gotta get this fixed” mode.  This type of course correction can remove many of the downstream benefits of delegation and turn into a big negative for folks.  It not only disempowers, but demotivates.  When things aren’t going well, the time is right for honest feedback and a two-way dialog.
  • Communicate serendipitously, don’t impede progress.  All projects have more work and less time than they need.  One way to reduce the amount of time available to make forward progress is for management to call for reviews or updates in a formal manner (meetings, written reports).  This type of communication can slow things down—the preparation, the review, the general stand-down while these work products are created.  If management is concerned about how things are going, then make it a point of finding the balance between serendipitous contact with the team and bugging them too much.

Above all, treat folks as you would like to be treated and validate that approach.  If you are the type of person that is eager to request and receive feedback then chances are you won’t see an eager manager as micromanaging you.  But if you are the type of person that likes some elbow room and your manager is the eager provider of feedback, then that mismatch is likely to be perceived as micromanagement rather than empowering delegation.

The simple solution to this potential dilemma is to communicate about these stylistic expectations before the work really starts.  Even if you’ve worked together for a while and have a rhythm, a new project might come with new approaches for working together.

Delegation can take the form of management asking for work from the team or it can take the form of “we’re all in this together”.  The question to ask yourself is if you delegate work so you’re part of “us” or “them”?

What are some tools you use for effective delegation?  Check out the poll – https://www.surveymonkey.com/s/NTSCCCK.

–Steven Sinofsky

 

Thanks for everyone that responded to our survey for “Using meetings to be more effective”.  In this survey, we hoped to learn together about the tools and characteristics that make meeting successful.

Here are the results:

  • About half of our most recent meetings include a phone bridge, with about one third connecting via Voice over IP (i.e. Skype)
  • In about one in six meetings, at least one person joins via a cell phone
  • About half of our meetings take advantage of screen sharing and about half involve PowerPoint, though only in about one third was a projector used
  • When asked about whether our last meeting was a success, on average (mean and median) we “neither agree nor disagree” that it was a success

In looking at drivers for what made us rate a meeting a success, there were some interesting findings:

  • Regarding technologies, of the technologies queried (phone, cell, VoIP, screen sharing, PowerPoint, projector, and meeting software), only the use of a projector had a statistically significant impact on our success rating.  However, meetings with a projector ranked half a point lower on a five point scale, than those without projectors
  • Interestingly, presenters rated meetings with projectors lower than members of the audience, with a difference of about a half point, it’s worth noting this was not correlated with slideshow software like PowerPoint
  • Of the tips for success discussed,  “a fully understood context” drove the success factor up a third-point , and  a “concise” meeting (brevity) drove success up nearly a half-point.
  • Interestingly, presenters rated meetings with “a fully understood context” higher than members of the audience

Bottom Line:

Modern meetings leverage online tools like to get everyone on the same page, though care should be taken during in-person meetings to not let the audio/visuals detract from your message as a presenter.  Taking time before and during the meeting to create a shared sense of context and keeping your message concise seem to drive the best outcomes for everyone, presenter and audience alike.

Thanks, Cameron

# # # # #

Written by Steven Sinofsky

June 18, 2013 at 9:30 am

Posted in posts

Tagged with , ,

Reaching for harmony in org changes

with 9 comments

HarmonyReorgs are a part of an organization of any size. As business changes, development teams resize, code evolves, or products pivot, the organization can and should change as well. Given the frequency and challenges of reorgs it is worth looking a bit at the complexity, rationale and some challenges of reorganization. While the first reaction to a reorg could range from a sigh of relief to  groan or worse, the most important thing is to keep calm and make sure the work continues.

Be sure to take our three question survey on reorgs after reading this post, here (https://www.surveymonkey.com/s/WS8TNMP) and to check out survey results below from the last survey about “Meeting effectively”.

A first-year  MBA student I recently met took the occasion of a reorg as time to career pivot and attend business school, which motivated this post. 

Reorgs (this post is about structural and management changes, not changes in staffing levels) are sometimes a popular topic in blogs where they take on a certain level of drama or mystique (for example, some blogs talk about org changes as solutions to perceived design challenges). Lacking context, some tend to see reorgs as either the solution to or the cause of a change in strategy or execution. That itself can be the source of reorg angst. In practice, a reorg should be the outcome of a strategic decision not the decision itself-—reorgs don’t cause change or things to happen, but are (hopefully) a better way to execute on strategic changes that have been decided upon.

Reorgs can be a natural way to make sure a team is aligned to deliver on a strategy and a tool to allocate resources effectively towards a shared product plan. When done well, reorgs go from something that happens to you to something that happens with and for you, even if things don’t always feel that way for every member of the team at the start. At the same time, reorgs are enormously challenging by their very nature–organizations are never perfect and there can always be unpredictable outcomes as members of the team implement org changes.

I’ve been part of and executed a few “big” reorgs and always find them incredibly challenging, humbling, stressful, and much more work than is often expected. That’s why I tend to view reorgs as a tool of final resort rather than a tool to routinely drive change, which was something discussed on another blog a while back (and motivated this post).  Executing a reorg involves doing everything you can to “precompute” actions, reactions, and further reactions as best you can while also compensating for them in the plan.

Reorgs are complex and can be thought of from many perspectives. As blunt as they might sometimes seem, there is a great deal of subtlety and nuance to reorgs. While we’re focused on product development organizations, the concepts and implications of reorgs are a pretty general topic.

Reaching for harmony is something to strive for in any organizational change.

Do keep in mind, like so many things in the social science of business, organization and reorganization context dependent—there’s no right or wrong outside the context being discussed.  By definition, reorgs are forward looking and so past history might not always be the best guide.

Perspective and context

Discussing a (potential) reorg can stretch many in an organization. Much like the group describing an elephant, a reorg can mean very different things to different people. A good way to think of things is to refer to a well-known description of organization dynamics that is often used in training classes: tops, middles, bottoms. We’ll return to this often in this blog as it is always a good reminder of patterns and practices that one can generally (emphasis on generally) see repeated.

Bottoms are the folks that do the work. Of course this is an awful moniker, but is the one chosen in the original work (See http://www.powerandsystems.com/resources-a-thought-starters/books/the-possibilities-of-organization.html). Bottoms also make up the bulk of an organization. In a typical, large, development organization (>100) you usually need fewer than 20% of the team middles and tops, which means more than 80% of your resources are bottoms. Whenever possible, you probably want to be better than that (meaning fewer managers, though one should caution a metric like this should not be abused as a scorecard goal as context matters).

Middles are the line managers in an organization. Middles are where the work and collaboration get defined, where friction is either created or eliminated in getting work done, and where information can flow freely or stop. Healthy middles are an essential part of any organization. It is why practices such as skip-level 1:1s, communication that goes broadly to the middles, and shared view of plans are all such critical tools in a product team-—those are the tools of middles managing up and across a team (emphasis on helping the middles, not the middles helping the tops, which is a common dysfunction). Middles can also be tops. For example, if you are the most senior developer in an organization and your manager is not a developer then when it comes to development stuff you are a top.

Tops are the big bosses in an organization. The top is where a certain organization function “ends”. You can be the boss of product design, the boss of the test schedule, the boss of marketing, or (but not necessarily) the boss of the whole organization or company. It is worth noting that nearly all tops are also middles at some point. It just depends on the context. CEOs are middles relative to the board (and also Customers). Your VP is a middle relative to the CEO even if you don’t think of him/her as a middle.

To be complete, the framework also includes Customers. Their role in will be touched on later in the post.

I would encourage folks to check out this framework and book just because it succinctly sums up many of the core challenges within an organization. While there are many insights and many specifics to teams, a key understanding is that members of a team should do far more to understand each other’s context (and problems) than they do in practice during times of change–simply walk in each other’s shoes. Of course this is blindingly obvious, yet terribly difficult for even the best folks on a team. For example:

  • Tops should sometimes spend less time worrying about their big strategic views and needs and consider how their choices (based on those needs) can ripple through an organization and impact execution. Tops would do well to listen more (see this great discussion of 1:1s from Ben Horowitz) and perhaps worry less about what is on their mind.
  • Middles might spend more time talking to other middles and sharing what they are actually doing, what are their real execution issues, and how they are really progressing. All too often middles get caught up communicating idealized situations and plans which can cause confusion, misplaced bets, or just poor choices in other parts of a team and organization. Middles might spend too much energy on describing problems rather than solutions, or even trying to account for things not going well. Middles can spend more time informing their tops about what is going on, but that also depends on tops spending time listening or asking to be informed.
  • Bottoms might also spend more time listening or asking questions and a little less time feeling like “victims”. It is easy when middles and tops are communicating poorly to assume the worst or to assume folks don’t know what is going on. It is equally challenging if the communication that does take place is not taken advantage of, so more listening here can be beneficial as well.

If you think about these typical patterns (remember, this is a generalized sociology framework not a description of your team/behavior), one can see how any discussion of reorgs can quickly degrade. In fact, few things tap into the typical patterns of this behavior framework better than a reorg. Why is that?

Reorgs, by definition, are usually kicked off by the tops. So out of the gate the assumptions that go into making an org change are from a top perspective. The biggest changes in a reorg generally affect the middles since work is reassigned, people’s responsibility changes, and so on. Middles have a tendency to view reorgs at the extreme of “whatever” or “oh my gosh this is really messed up” — as a middle so much of your role depends on context, connections, and structure changes can significantly impact execution.

For the bottoms, a reorg can appear like a bunch of people rearranging deck chairs on the Titanic since ultimately the organization doesn’t really change all the work of individuals (much of the same code still needs to get written, tested, maintained and changing the people with that expertise seems the opposite of progress). Throughout the process, communication is less than and often later than many would like or expect.

The process of a reorganization is one where perspectives of each on the team need to come together to define the problem, scope the alternatives, and implement the solution. Absent these steps a reorg goes from a potential solution to a certain problem.

Why reorg?

There are many reasons for doing an org change. In fact, the most important first step of a reorg is to be able to articulate to those who ask why you might do a reorg.

It is often in this very first step where most reorgs hit a snag. The reason is because the tops have a set of reasons in their context about what a change is for and what it will accomplish and then quickly find out others don’t share the perspective (or problems) or view it as incomplete. Yet the process often continues.

For the tops, this can be a real pain or just frustrating and worse it can bring out the worst of bottoms and middles in terms of how they dig in their heels and get defensive about the change. They begin to immediately dispense the reasons why a reorg won’t work and the bottoms pick up on these and start to feel like victims. All the while the process keeps moving forward.

Reorgs are typically instituted for a pretty common set of reasons, some of which on their own can cause people to retreat to a defensive or cynical state of mind.  Some common drivers include:

  • Resource efficiency. The role of management is to effectively allocate resources and in fact is really often the only tool management has. As a product and team evolve, resource allocations that seemed perfect at one point can seem less than optimal. An organization change has the potential to allocate resources more effectively towards the problems as they are today.
  • Duplication of efforts. In any organization of size, over time efforts will start to converge or overlap. This is especially true in technology companies. This can be at a very visible level, for example if many groups are working on basic tools for editing photos or user names. This can also be at an infrastructure level such as how many teams have people buying servers or running labs.
  • Individual bandwidth. Sometimes teams or responsibility grow and the management of the work becomes too challenging or individuals are spread across multiple projects too frequently. Managers at any level can systematically have too many direct reports, for example. Alternatively, the product line can change or evolve over time and folks on the team find themselves context switching between somewhat unrelated projects more than actually managing. This lack of bandwidth becomes a problem for the team overall as everyone evolves to having more overhead than work.
  • Structural challenges. Organizations evolve over time in a way that suits the time, problem space, and skills. Sometimes when you take a step back, the current state ends up being suboptimal going forward. The alignment of resources, decision making, even core roles and responsibilities are not yielding the results. More often than not, this type organizational pain is felt broadly by the team or by customers.
  • Synergy / Strategy. The notion of increased synergy or strategic change generally drives the most challenging of org changes. Many are familiar with these challenges-—the effort to move large blocks of work in sort of an architectural view. Motivation is this sort often is about “proximity” or “relationship” and has the feel of architecting a product except it is about the team that builds the product.  There’s a tendency to create “portfolios” of products and teams when organizing along these lines.
  • Alignment.  Alignment is slightly different than synergy/strategy in that it speaks to how the organization should be viewed moving forward.  A long time ago, for example, the Office team at Microsoft shifted from building Office “apps” to building the Office “suite”.  Alignment also could include many mechanical elements of businesses/products like customer definition, business models, ship dates, and so on.

Even though these have the potential to sound Dilbert-esque, the reality is that when problems are identified that most people on a team share, then these can form the basis of not just a useful reorganization but a reorg that people want to do. Each one of these motivations (and others not listed) can serve as the basis of a successful reorg. That might not reduce the stress, uncertainty, or even dislike of a change but it does say that reorgs do not have to be a priori negative or random for a team.

Ultimately, changes to an organization should be rooted in getting more and better work done. Few would disagree with that. The question is really whether the team believes an org change will do that. It sounds easy enough.

Challenges

Even with the best of initial intentions, reorgs can (and often) do hit rough spots. Rarely are reorgs stopped once started (just as it is rare that products are stopped once under development). It is a good idea to have a taxonomy of why reorgs can hit snags or challenges, since it is likely they will.

The question is not how do you avoid these necessarily, but how do you identify a specific hiccup the reorg is going through (much like how you identify problems in product development and address them) rather than just stopping. This preparation should take on elements of chess-play as changes and reactions are mapped out and reconsidered based on feedback. Some potential challenges include:

  • Rushing. A potential failure with any reorg is rushing. The funny thing is that the tops usually don’t think they are rushing and everyone else feels things are going too fast. During a reorg process most tops think it is dragging on forever and are just in closure mode simply because tops have likely been thinking about the reorg for quite some time already and most other people have not. In practice, most people only get a short time to hear, absorb, and reflect on the potential change. Skipping a communication and feedback step or skipping deep 1:1 conversations in a consistent and thoughtful manger can make for a very tricky reorg. When people feel the changes are rushed, the process loses structural integrity.
  • Reasoning. Failure to effectively communicate the rationale commonly plagues reorgs. Think of a reorg like any “launch” in that you want to be clear, concise, and appeal the folks with your message. If your message is not the problem your customers have then only challenges follow. The reasoning should appeal to the people who will experience the changes—the organization is what most people in a job and on a team experience day in and day out so reasoning needs to resonate with them. Reorgs announcements that leave too many questions as “exercises for the reader” might be viewed cynically and folks might believe that not enough thought has gone into the change.
  • Strategy. Sometimes a reorg is being done in place of a strategy– “when all else fails, lets reorg” is how victims of such a reorg might characterize things. Reorgs are not a substitute for a strategic choice an organization must make. In fact, a reorg is a tool to use after you have made a strategic choice. Hearing objections to reorgs based on differences in strategy is a real warning sign that the first order problem has not been addressed. If the team has a strategic choice to make (less people, fewer managers, align products, etc.) then first make that choice, then decide if a reorg is needed to accomplish the choice. More often than not, clarifying and then making a strategic choice is the more difficult, but useful, way to spend energy.
  • Timing. A complaint bottoms and middles might raise about a reorg is when it happens—“the timing isn’t right”. A complaint many tops might have with reorgs is that everyone is always telling them the timing is wrong. In practice reorgs can be like a “stand down” for a product team. For some period of time, proportional to the number of people who change managers and/or responsibility, the team will effectively stop working. Therefore no matter how urgent the rationale, the timing of a reorg needs to minimize the impact on the work. On big teams, org inefficiencies trickle on to a team throughout a product cycle (no matter how long or short) due to people coming/going or even things like acquisitions. Unless the point of the reorg is to pivot the product, the potential loss of time to market due to a reorg is a high price to pay.
  • New problems. Any reorg can and will introduce new problems. A common technique for middles is to quickly identify the things that get “more difficult” or for bottoms to ask “well who will do X now”. From a top driving a reorg these often look like self-preservation rather than constructive input. It is a safe bet that almost everything one hears at this time is going to come become issues as middles and bottoms know their jobs. Even if it is presented in a selfish manner, the reality is that tops are not in touch enough with all the details of the work to just keep moving without adjusting. There’s a real balance to understanding what new problems are introduced in any org change and the impact those problems might have on the work.
  • Too much change, too little problem. If the reasoning of a change is not sound for most people or there is a lot of feedback about strategy then there’s a chance that the reorg being executed is outsized relative to the problem. The feedback loop in this case is really pointing to an incomplete problem definition or simply a solution that doesn’t match the problem. This is a case where listening to the feedback can be especially enlightening.
  • Fatigue. Reorgs can also be too much of a (good) thing. Teams can grow tired of the churn that comes from reorgs and enter a state of reorg fatigue. Finding the right cadence for org changes and finding the ability to get the reorg done and over with are important parts of an effective process.  When more than one person starts sending mail saying how many managers or office moves they have had, then it might be time to consider this challenge.
  • Org distance.  Getting work done every day is how most people will evaluate an org change.  The “org distance” between routine collaborators and resources is one measure commonly used.  Org changes can potentially run into resistance when people perceive the changes mean they are “further away” from those they work with routinely.  Commonly people will just count the org intersection point and see how far it moves or how different it becomes.
  • Accountability for the present and future.  Ultimately any organization needs to land clearly with who is accountable for what.  This is a statement about specific people, code, and job functions.  Every accountability has a “30,000 foot” view as well as an “on the ground” view.  It is usually accountability at the detail level that matters in terms of selling through an org change.  People will naturally want to know who “decides” which is another way of asking who is accountable.  To answer who is accountable also requires one to answer where the resources are that “own” the code, designs, tests, etc.  The transition from the present and all the work in flight to the future is a key part of any reorg effort.
  • Leadership and people.  One of the most challenging aspects of reorgs, particularly those that are about restructuring, is the ripple effect on staffing.  At each level of the change, leaders need to be put in place.  Some might be the existing leaders and others might be new.  The image of musical chairs can come to mind, which is always stressful.  Alternatively it is entirely possible to create an organization where there are more jobs of a certain type than people to fill them, which is equally stressful.  As is always the case, making sure that when roles are created the people filling them are truly the right choice for the intended role is paramount.  A new organization that is poorly staffed gets off to a challenging start.

In addition to these conceptual challenges, there are always potential pitfalls with respect to the process of reorganization. The tools of communication, listening, planning, empathy, adapting, are all absolutely critical. My own efforts at blogging started as part of the learning, sharing, and feedback loop for the team as we geared up for Windows 7 development (see our book) and re-organization. Blogging was one tool of many, but an effective way to drive a two-way dialog about changes (many posts were the result of questions or follow-up).

Finally, accountability for a reorg rests with management, specifically the line manager driving the org change. Reorgs are not something HR does for or on behalf of management. HR has valuable tools and a position of objectivity to assist, but they are not accountable or there to drive the process, pick up the pieces, or otherwise appear out in front of a reorg. A way to think of this is that as a manager resource allocation is your primary tool, therefore you can’t really delegate org design and implementation because it is a primary job function—-it is like a developer outsourcing coding (wait didn’t we recently read about the dev that did that?). A common source of frustration is when someone is referred to HR when they raise issues about the goals and execution of a reorg.

Tools

While there are many human resources and management tools to support the communication, feedback, and discussion of a reorg, there are also some specific work management needs to do in order to drive an effective process. A big part of the use of these tools is the contribution from a large set of people on the team who are enrolled in driving the change.

The initial burden for getting things going well falls to the tops to communicate clearly. The reasons for implementing an org change need to be clear and resonate with the team and discussed separately from the solution. This is the problem statement and explains the why behind a reorg. The first sign of skipping steps in a reorg is that the first words, slide or paragraph show a reporting structure. Any reorg that leads with reporting structure is likely to be hit head-on with resistance. Of course most people will be anxious and want to know the structure first anyway, but as a leader of a reorg there is a real responsibility to explain the problems being solved first. This is not burying the real news because the real news is management waking up to a problem that needs to be solved.

With those two tools in place (the why and what), there are a few other tools that can help smooth over what is bound to be an emotional change for a team.

  • How. The next thing to identify is how the work will get done. This is not the job of the top at a very gross “whole product” level but at the level down to some granular level that shows the implications of an org change are understood. Even in the largest organization, understanding at a level of 10-15 developers (engineers, marketing people, etc.) is really an acid test for knowing if an org change has been thought through.
  • Who. The funny thing about reorgs is that the success of them depends on the most local of variables-—individuals want to know what they work on and how the org affects their work, their career, and their place on the team. This is the “who” of a change. In an information based team (software!) this is your asset, not the code. So failing to really understand the who of an org change is going to make it rough. For this tool you need to enlist the help of managers throughout the team to make sure everyone is clear on who does what.
  • When. The timeline of a reorg is critical for everyone. You need to take the time and yet not drag it out. How you balance this depends on the scope of the change and size of the organization.

Whenever a reorg is taking place, whether people agree or not, ultimately the members of the team will want to know about their own careers, skills, knowledge, and place in the new structure.  As much as reorgs are about the big picture, successful reorgs are about the individuals that do the bulk of the work on any product team.

Or not…

One more tool for reorgs is simply not to do them. As strange as that sounds, the reality is that no organization is perfect and even if an organization is perfect it won’t remain so for very long just because of the dynamic nature of product development and teams. People move around, features become more or less important as the technology landscape changes, some areas require more resources than planned or some require less, business models change and more.

This is why more often than not a reorg might not be the best place to spend the team’s limited energy. Reorgs have the potential to substitute activity for progress and can cause an organization to be looking inward right when it needs to be outward focused the most.

That’s not always the case, but it certainly is worth considering.

Yet that doesn’t cure any problems a team or organization might be having. What are some changes tops can initiate or help to drive that can be substitutes for addressing the root cause of challenges that might be equally challenging but perhaps focus on the root cause more than an org change? Here are some examples for tech teams:

  • Align planning and execution. Any time an organization has more than two products (or projects) that connect to each other (two unique products, front end/back end, etc.) there could be a need for alignment. The easiest way to have alignment is to align the planning and execution calendars. Teams that are joined by a calendar have the easiest time working together when it comes to hard decisions like what code to write and when. This alignment needs to be supported by tops–meaning once the bet is made to align, then you have to work within the constraints of release cadence, scope of product, external communication, and more.  The converse of this is that putting teams together that have different schedules does not bring alignment–alignment in product design and code sharing essentially requires some degree of schedule alignment (at least in my experience).
  • Process alignment. Teams that do the same things but do them differently will always have a hard time working together. From even abstract things like roles and responsibilities to extremely concrete things like how to categorize bugs or deliver daily builds, differences in processes can really make it hard to work together. A good thing to do is pick the processes that matter most to your orgs and just align (perhaps see Managing through disagreement).
  • Strategic choice. Perhaps the real problem is not one that can be solved by organization at all and an org change is a substitute for a strategic choice (exit or enter a business, combine businesses, etc.) In this case, as painful as it may be, the org change only pushes accountability and delegates responsibility for something that should just be decided.
  • Decide to share code. The hardest thing for dev teams to do is share code with other dev teams—50 years after the invention of the subroutine. Yet it is magical when teams do commit to doing so. How to share code effectively and how to manage the provider and consumer roles, especially in a complex org in many businesses, is an art form, but one that needs to perfected, locally. As we all know, sharing code is great and also constraining–so again support from the broader perspective regarding additional constraints is critical.  Sharing code is also a lot easier if teams are aligned on planning and execution timelines.

Implementing a reorg is a big step. It is always wise to think first about your problem statement and decide if you can attack the root cause in a much less disruptive way. This is especially true in a large organization where changing things “at the top” has much less of an impact on product evolution than many believe.

Customers

The Oshry framework also includes customers. Customers of course define the reason for making products in the first place.

The biggest challenge any multi-product organization faces is that customers want products and technologies (relevant to them, keeping in mind many products serve many different customer types) to appear to work together. From the outside, that is the customer perspective, when products don’t appear to work together or appear to have arbitrary differences/redundancies then the obvious culprit is the org. The org was not structured to work on that problem as an integrated whole. This can be seen as “shipping the org chart”.

In this case, the org chart for the products is not right-—some things need to be “closer” or “one person” needs to be in charge of a couple of products. This goes a step further. When the design or quality is not right according to customers then the org is not right because the designers or testers were not organizationally working closely enough with developers.

You can see this multi-dimensional problem. It all boils down to graph theory and how you can connect all the parts of all of the products with the highest bandwidth and always connected flow of information, decisions, and more.  This means it is much more difficult than it appears to use organization to address these perceived challenges.  The side-effects of moving some things closer include moving other things farther apart, and the implications of the solution might be worse than the problem.

In the idealized world of small teams you can get everyone in the same conference room and decide everything. This tops out at about 40 -50 people. For example, Excel 5 had about that many developers. After that, organization is a tool that can help you to overcome this limitation. While it would be great to work on product families that always take fewer people, that isn’t always possible just on the basis of the number of features it takes to be competitive in the market place over any period of time.

The substitute of anointing someone to oversee all aspects of a product is also a scale challenge. There are just so many hours in a day and only so many people that might fill such a role (if that is even possible to do). Once a person is managing a large number of related, but different, projects or just a large number of people then the ability for the large/complex team to act like a small team is limited. In other words, just joining two entities at the top does not necessarily mean they will appear to work better together for customers.

Yet, what everyone wants to avoid is a dynamic where your collective efforts result in “shipping the org chart” to customers.

Since you have to have an organization, which might be divided by geography, discipline, products, architectural layer, product release timing, business models, or more, the real tools to avoid shipping the org chart are planning, communication, and accountability. You can really never solve the multi-dimensional matrix of responsibility without making teams so large or structurally complex, or relying on a superhero manager that any value that might come from being on one team is lost.  The converse to this is that designing products by a committee doesn’t work either. Just taking a lot of complexity and sort of saying “work it out” usually fails to be optimal for any customer.

Because of the complexity of org changes in a large team, the best lesson I have learned is that a culture that adapts to solving problems turns out to be the best organization structure. Combine that with common views of roles/responsibilities, clear and reliable plans, and accountability and you can have the makings of an agile and flexible organization that can move work around, partner across projects, and deliver without using org structure as a high-order bit for strategic change.

–Steven Sinofsky

Be sure to check out this week’s survey on org changes https://www.surveymonkey.com/s/WS8TNMP.

Thanks for everyone that responded to our survey for “Using meetings to be more effective”.  In this survey, we hoped to learn together about the tools and characteristics that make meetings successful.

 Here are the results:

  • About half of our most recent meetings include a phone bridge, with about one third connecting via Voice over IP (i.e. Skype)
  • In about one in six meetings, at least one person joins via a cell phone
  • About half of our meetings take advantage of screen sharing and about half involve PowerPoint, though only in about one third was a projector used
  • When asked about whether our last meeting was a success, on average (mean and median) we “neither agree nor disagree” that it was a success

In looking at drivers for what made us rate a meeting a success, there were some interesting findings:

  • Regarding technologies, of the technologies queried (phone, cell, VoIP, screen sharing, PowerPoint, projector, and meeting software), only the use of a projector had a statistically significant impact on our success rating.  However, meetings with a projector ranked half a point lower on a five point scale, than those without projectors
  • Interestingly, presenters rated meetings with projectors lower than members of the audience, with a difference of about a half point, it’s worth noting this was not correlated with slideshow software like PowerPoint
  • Of the tips for success discussed,  “a fully understood context” drove the success factor up a third-point , and  a “concise” meeting (brevity) drove success up nearly a half-point.
  • Interestingly, presenters rated meetings with “a fully understood context” higher than members of the audience

Bottom Line:

Modern meetings leverage online tools like to get everyone on the same page, though care should be taken during in-person meetings to not let the audio/visuals detract from your message as a presenter.  Taking time before and during the meeting to create a shared sense of context and keeping your message concise seem to drive the best outcomes for everyone, presenter and audience alike.

Thanks, Cameron

###

Written by Steven Sinofsky

May 6, 2013 at 9:00 am

Posted in posts

Tagged with ,

Learning by slipping

with 17 comments

Countdown“Slipping” or missing the intended completion or milestone date of software projects is as old as software itself. There’s a rich history of our industry tracking intended v. actual ship dates and speculating as to the length of the slip and the cause.  Even with all this history, slipping is a complex and nuanced topic worth a bit of discussion about slipping as an engineering concept.

Slipping

I’ve certainly had my fair share of experience slipping.  Projects I’ve worked on have run the full spectrum from landing exactly on time to slipping 20-30% from the original date.  There’s never a nice or positive way to look at slipping since as an engineer you’re only as good as your word.  So you can bet the end of every project includes a healthy amount of introspection about the slip.

Big software projects are pretty unique.  The biggest challenge is that large scale projects are rarely “repeated” so the ability to get better through iteration keeping some things constant is limited.  This is different than building a bridge or a road where many of the steps and processes can be improvements from previous projects.  In large scale software you rarely do the same thing with the same approach a second or third time.

While software is everywhere, software engineering is still a very young discipline that rapidly changes.  The tools and techniques are wildly different today than they were just a few years ago.  Whether you think about the languages, the operating systems, or the user experience so much of what is new software today is architected and implemented in totally new ways.

Whenever one talks about slipping, at some basic level there is a target date and a reality and slipping just means that the two are not the same (Note:  I’ve yet to see a software project truly finish early).  There’s so much more to slipping than that.

What’s a ship date

In order to slip you need to know the ship date.  For many large scale projects the actual date is speculation and of course there are complexities such as the release date and the availability date to “confuse” people.  This means that discussions about slipping might themselves be built on a foundation of speculation.

The first order of business is that a ship date is in fact a single date.  When people talk about projects shipping “first quarter” that is about 90 different dates and so that leaves everyone (on the team and elsewhere) guessing what the ship date might be.  A date is a date.  All projects should have a date.  While software itself is not launching to hit a Mars orbit, it is important that everyone agree on a single date.  Whether that date is public or not is a different question.

In the world of continuously shipping, there’s even more of a challenge in understanding a slip.  Some argue that “shipping” itself is not really a concept as code flows to servers all the time.  In reality, the developers on the team are working to a date—they know that one day they come to work and their code is live which is a decidedly different state than the day before.  That is shipping.

Interestingly, the error rate in short-term, continuous projects can often (in my experience) be much higher.  The view of continuously shipping can lead to a “project” lasting only a month or two.  The brain doesn’t think much of missing by a week or two, but that can be a 25 – 50% error rate.  On a 12 month project that can mean it would stretch to 15-18 months, which does sound like a disaster.

There’s nothing about having a ship date that says it needs to be far off.  Everything about having a date and hitting it or slipping can apply to an 8 week sprint or a 3 year trek.  Small errors are a bigger part of a short project but small errors can be amplified over a long schedule.  Slipping is a potential reality regardless of the length of the schedule.

The key thing from the team’s perspective about a ship date is that there is one and everyone agrees.  The date is supported by the evidence of a plan, specifications, and the tools and resources to support the plan.  As with almost all of engineering, errors early in the process get magnified as time goes by.  So if the schedule is not believable or credible up front, things will only get worse.

On the other hand, a powerful tool for the team is everyone working towards this date.  This is especially true for collaboration across multiple parts of the team or across different teams in a very large organization.  When everyone has the same date in mind then everyone is doing the same sorts of work at the same time, making the same sorts of choices, using the same sorts of criteria.  Agreeing on a ship date is one of the most potent cross-group collaboration tools I know.

Reasons to slip

Even with a great plan, a team on the same page, and a well-known date, stuff can happen.  When stuff happens, the schedule pressure grows.  What are some of the reasons for slipping?

  • Too much work, aka “we picked too much stuff”.  The most common reason for slipping is that the team signed up to do more work than could be done.  The most obvious solution is to do less stuff.  In practice it is almost impossible to do less once you start (have you ever tried to cut the budget on a kitchen remodel once it starts?  You cut and cut and end up saving no money but costing a lot of time.) The challenge is the inter-connected nature of work.  You might want to cut a feature, but more often than not it connected to another feature either upstream or downstream.
  • Some stuff isn’t working, aka “we picked the wrong architecture”.  This causal factor comes from realizing that the approach that is halfway done just won’t work, but to redo things will take more time than is available.  Most architecturally oriented developers in this position point to a lack of time up front thinking about the best approach.  More agile minded developers assume this is a normal part of “throw away the first version” for implementing new areas.  In all cases, there’s not much you can do but stick with what you have or spend the time you don’t have (i.e. slipping).
  • Didn’t know what you know now, aka “we picked the wrong stuff”.  No matter how long or short a project, you’re learning along the way.  You’re learning about how good your ideas were or what your competitors are doing, for example.  Sometimes that learning tells you that what you’re doing just won’t fly.  The implications for this can run from minimal (if the area is not key) to fairly significant (if the area is a core part of the value).  The result in the latter case can be a big impact on the date.
  • Change management, aka “we changed too much stuff”.  As the project moves forward, things are changing from the initial plans.  Features are being added or removed or reworked, for example.  This is all normal and expected.  But at some point you can get into a position where there’s simply been too much change and the time to get to a known or pre-determined is more than the available time.

The specifics of any slip can also be a combination of these and it should be clear how these are all interrelated.  In practice, once the project is not on a schedule all of these reasons for slipping begin to surface.  Pretty soon it just looks like there’s too much stuff, too much is changing, and too many things aren’t “right”.

That is the nature of slipping.  It is no one single thing or one part of a project.  The interrelationships across people, code, and goals mean that a slip is almost always a systemic problem. Recognizing the nature of slipping leads to a better understanding of project realities.

Reality

In reality, slips are what they are and you just have to deal with them.  In software, as in most other forms of engineering, once you get in the position of missing your date things get pretty deterministic pretty quickly.

In the collective memories of most large projects that slipped are the heroes or heroic work that saved a project.  That could very well happen and does, but from a reliable or repeatable engineering perspective these events are circumstantial and hard to reproduce project over project.  Thus the reality of slipping is that you just have to deal with it.

The most famous description of project scheduling comes from Frederic P. Brooks who authored “The Mythical Man-Month” in 1975.  While his domain was the mainframe, the ideas and even the metrics are just as relevant almost 40 years later.  His most famous aphorism about trying to solve a late project by adding resources is:

When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on schedule.  The bearing of a child takes nine months, no matter how many women are assigned.

Software projects are generally poorly partitioned engineering – much like doing a remodel in a tiny place you just can’t have all the different contractors in a tiny place.

There are phases and parts of a project in large scale software that are very amenable to scale with more resources, particularly in testing and code coverage work, for example.  Adding resources to make code changes runs right up against the classic man-month reality. Most experienced folks refer to this as “physics” implying that these are relatively immutable laws.  Of course as with everything we do, context matters (unlike physics) and so there are ways to make things work and that’s where experience in management and most importantly experience as a team working together on the code matters.

The triad of software projects can be thought of as features, quality, and schedule.  At any given point you’re just trading off against each of those.  But if it were only that easy.

Usually it is easy to add features at the start, unaware of precisely how much the schedule or quality will be impacted.  Conversely, changing features at other times becomes increasingly difficult and obviously so.  From a product management/program management perspective, this is why feature selection, feature set understanding, and so on is so critical and why this part of the team must be so crisp at the start of a project.  In reality, the features of a product are far less adaptable than one might suspect.  Products where features planned are not delivered can sometimes feel incomplete or somehow less coherent.

It is almost impossible to ever shorten a schedule.  And once you start missing dates there is almost no way to “make up for time”.  If you have an intermediate step you miss by two weeks, there’s a good chance the impact will be more than two weeks by the end of a project.  The developers/software engineers of a project are where managing this work is so critical.  Their estimates of how long things will take and dependencies across the system can make or break the understanding of reality.

Quality is the most difficult to manage and why the test leadership is such a critical part of the management structure of any project.  Quality is not something you think about at the end of the project nor is it particularly malleable.  While a great test manager knows quality is not binary at a global level, he/she knows that much like error bars in physics a little bit of sub-par quality across many parts of the project compounds and leads to a highly problematic, or buggy, product.  Quality is not just bugs but also includes scale, performance, reliability, security, and more.

Quality is difficult to manage because it is often where people want to cut corners.  A product might work for most cases but the boundary conditions or edge cases show much different results.  As we all know, you only get one chance to make a first impression.

On a project of any size there are many moving parts.  This leads to the reality that when a project is slipping, it is never one thing—one team, one feature, one discipline.  A project that is slipping is a product of all aspects of a project.  Views of what is “critical path” will need to be reconciled with reality across the whole project, taking into account many factors.  Views from other parts of the organization, the rumor mill, or just opinions of what is holding up the project are highly suspect and often as disruptive to the project as the slip itself.  That’s why when faced with a slipping project, the role of management and managing through the slip is so critical.

What to do

When faced with a slip, assuming you don’t try to toss some features off the side, throw some more resources at the code, or just settle for lower quality there are a few things to work on.

First and foremost, it is important to make sure the team is not spending energy finger pointing.  As obvious as that sounds, there’s a natural human tendency to avoid having the spotlight at moments like this.  One way to accomplish that, improperly, is to shine the light on another part of the project.  So the first rule of slipping is “we’re all slipping”.  What to do about that might be localized, but it is a team effort.

What else can be done?

  • Don’t move the goalposts (quality, features, architecture).  The first thing to do is to avoid taking drastic actions with hard to measure consequences.  Saying you’re going to settle for “lower quality” is impossible to measure.  Ripping out code that might not work but you understand has a very different risk profile than the “rewrite”.  For the most part, in the face of slipping the best thing to do is keep the goals the same and move the date to accomplish what you set out to do.
  • Think globally, act locally. Teams will often take actions that are very local at times of slipping.  They look to cut or modify features that don’t seem critical to them but have important upstream or downstream impact, sometimes not well understood on a large project.  Or feature changes that might seem small can have a big impact on planned positioning, pricing, partnerships, etc.  The approach of making sure everyone is checking/double checking on changes is a way to avoid these “surprises”.
  • Everyone focuses on being first, not avoiding being last.  When a project has more than a couple of teams contributing and is faced with a tight schedule, there’s a tendency for a team to look around to just make sure they are not the team that is worse off.  A great leader I once worked with used to take these moments to remind every part of the project to focus on being first rather than focusing on being “not last”.  That’s always good advice, especially when followed in a constructive manner.
  • Be calm, carry on. Most of all, slipping is painful and even though it is all too common in software, the most important thing to do during crunch time is to remain calm and carry on.  No one does good work in a panic and for the most part the quality of decisions and choices degrades if folks are operating under too many constraints that can’t get met.  It is always bad for business, customers, and the team to slip.  But if you are slipping you have to work with what you’ve got since most of the choices are usually even less desirable.

Managing a software project is one of the more complex engineering endeavors because of the infinite nature of change, complexity of interactions, and even the “art” that still permeates this relatively new form of engineering.  Scheduling is not yet something we have all mastered and slipping is still a part of most large projects.  The more that Software Eats the World ($), the more the challenges of software project management will be part of all product and service development.

Given that, this post tried to outline some of the causes, realities, and actions one could take in the face of learning by slipping.

–Steven Sinofsky

Written by Steven Sinofsky

May 1, 2013 at 10:00 pm

Posted in posts

Tagged with , ,