Posts Tagged ‘management’
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:
- 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.
- 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.
What 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.
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.
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.
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.
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.
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|
|Hierarchy, top down or middle out||Network, bottom up|
|Internal committees||Internal and external teams, crowds|
|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|
|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!)
- Creation. Quip, Evernote, Paper, Haiku Deck, Lucidchart
- Storage and Sharing. Box, Dropbox, Hightail
- Reporting. Mixpanel, Quantifind
- Communications. WhatsApp, Anchor, Voxer
- Tracking. Asana, Todoist, Relaborate
- Training. Udacity, Thinkful, Codeacademy
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.
Micromanagement 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.
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
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.
# # # # #
Reorgs 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.
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.
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.
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.
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.
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.
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
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.
“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.
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.
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.
It might seem cool if there is a line outside someone’s door (or an inbox full of follow-ups in Outlook or a multi-week wait to “get on the schedule”). ”Boy that person is really important” is what folks might say. In reality this bottleneck is a roadblock to progress and a sign of a team in need of change.
Most of the time we see managers with a line outside a door, but it can also be key leaders on a team of all sorts. Here are some tips to get out of the way and stop the gridlock.
Be sure to take the poll at the end of this post http://www.surveymonkey.com/s/QXR9WLZ. Feel free to use the comments to share your experience with a bottleneck on your team–there are folks out there probably experiencing something similar and benefit from your perspective. At the end of this post are the results from Career: Journey or Destination, which has some very interesting trends.
Why is there a line?
Managers or org leaders are busy. But so are the members of the team that work for the manager or depend on that leader. Unfortunately the way things go, too many folks end up as a bottleneck in getting things done. It might be a sign of importance or genuine workload, but it can also be a sign of a structural challenge. What are some of the reasons for a line?
- Approval. A manager asks to approve work before it can move forward.
- Feedback. Members of the team awaiting feedback from on proposed work.
- Decision. A leader is the decision maker in a situation.
On the face of it, each of these sound like the role of a manager (or leader, we’ll use them interchangeably in this post). The dictionary definition of a manager even supports this, “a person who has control or direction of an institution, business, etc., or of a part, division, or phase of it”. The operative notion is “in charge”.
There are several problems with this approach:
- Demotivating. If a job involves creativity (artistic, design, creation, problem solving, or a million other ways of being creative) then people who do those jobs well don’t generally do their best work under control. At an extreme, highly creative people are notorious for not wanting to be directed. The close cousin of demotivating is disempowering and very quickly creative people on the team lose the motivation to do great work and seek to get by with merely good work.
- Scale. A manager that operates a team as an “extension” of him/herself is not highly scalable. The line out the door represents the scale problem—it is trying to squeeze 64 bits through a 32 bit gate. There’s simply more work than can be done. The manager is overworked trying to do the work of the whole team, which is not sustainable.
- Slow. A manager that inserts him/herself in the middle of the flow of work causes the flow of work to slow down. The reaction time of the whole team no longer represents the capability of the team, but is limited by the ability of one person. Most folks are pretty frustrated by the roadblock to approval and then ultimately approval of the work as initially presented.
- Tactical. Those who operate in the middle of the work like this often justify their style as “adding strategic context”. This is often the exact opposite of what happens as the person is too busy to breath, take a step back, or to think long term because of the line out the door!
There are many justifications for why managers see these downsides as worth the risk. Managers feel like they have the experience to do better, know more, or maybe the team is new, understaffed, and so on. These are juicy rationalizations. Like parents doing homework and school projects for their kids, the short term seems reasonable but the long term becomes problematic.
Beyond gridlock, the deep, long term problem created by a line outside a manager’s door is the transferal of accountability that takes place. Once the manager is in the middle of approving, providing feedback, or deciding then the very best case is that the manager is accountable for the outcome. Wait, you say that’s always the case, right?
A manager should be accountable when things don’t go well and stand up to claim the work of the team that wasn’t what it needed to be. When things go well, the manager should fade away and the team should shine. This isn’t some ideal. This is just the basics of teamwork and what needs to happen. That goes beyond management and is leadership.
But when a manager is in the middle of everything, members of the team have a tough time feeling a sense of pride of ownership. The further the results are from ideal, the less likely individuals feel responsible. It is simply too easy to point to places where each person surrendered accountability to management. And unfortunately, this opens up potential for the worst form of dysfunction which is a manager in the middle of everything stepping back and still assigning accountability to the team when things don’t go well, politics.
Ultimately, any healthy team is about everyone feeling an equal sense of accountability for the groups work and full accountability for their work. The role of the manager is to create a team and workflow that enables everyone to contribute and grow.
Rhythm of the team
The most important thing a manager can do to create a workflow for the team is to foster a continuous rhythm of work on the team. The world of modern products and service means things are in a state of change and adaptation all the time. Stores roll over promotions constantly. Web sites are always being programmed. Social networks provide a constant dialog to contribute to and respond to. Product feedback is available all the time. The team that is standing on a line is not just missing all the action, but is playing a losing strategy.
In his famous book, Flow: the psychology of optimal experience, Mihaly Csikszentmihalyi talks about how important it is to be engaged in self-controlled, goal-related, meaningful actions. That when you’re doing that you are in a flow and things are much better (“happier”) for everyone.
A flow on a business team or product team is about working towards a shared goal and doing so without the starts and stops that interrupt the flow. As a manager there are two simple things you can do:
- Never schedule your full day. As a rule of thumb, you should never schedule more than 50% of your day in structured meetings and other required activities. This leaves your day for “work” which is your work as a contributor (being a manager does not mean you stop having concrete deliverables!) and for keeping things from being blocked by you. If you have time during the day you can interact in an ad hoc manner with the team, find time to participate before things reach a bottleneck, and most importantly you have time to listen and learn. This is the number one crisis prevention tool at your disposal. The more time you have available the more time you can provide feedback when the time is right for action, as an example. You can provide feedback when a plan is a draft and do so casually and verbally, rather than the team “presenting” a draft in a meeting and you needing to react, or sending you an attachment that forms another line in your inbox, all usually too late for substantial feedback anyway.
- Stop approving and deciding. As heretical as this sounds, as an experiment a manager is encouraged to spend a month pushing back on the team when they ask for approval or a decision. Instead just ask them to decide. Ask them what would go wrong if they decided. Ask them if they are prepared for the implications of a decision either way. Ask them if they are comfortable owning and “defending” a decision (knowing you as the manager will still be supporting them anyway).
As a member of the team waiting in line, there’s an option for you too. Instead of asking for approval or the other side of the coin, acting now and worrying later, take the time to frame your choice in a clear and confident manner. Don’t be defensive, aggressive, or shift accountability, but simply say “Here’s what I’m suggesting as a course of action and what we’re prepared to deal with as the risk…” No choice is free of risk. The risky path is simply not being prepared for what could potentially go wrong.
The optimal team is one that is moving forward all the time and operating with a flow and rhythm. A line outside the door of a manager is a sign of a dysfunctional team. It isn’t hard to break the cycle. Give it a shot.
The poll on this post is http://www.surveymonkey.com/s/QXR9WLZ. Let’s share thoughts on those lines outside doors.
Thanks to everyone who responded to our last survey on the “Defining your career path: journey or destination” post. We had an amazing response, with over 800 responses from around the world. Here are a few of the highlights:
- On average (mean), people have spent around 13 years in their career
- In those years, people have held 5.5 jobs or roles; or about 2 years per job/role
- About 26% claimed to be mostly “goal oriented”
- About 60% claimed to be mostly “experience oriented”
- 6% more sought to be “organization leaders” vs. “domain experts” (41% vs. 35%)
- And about 8% more sought to be “breadth leaders” vs. “field experts (42% vs. 34%)
- On average, we’re pretty satisfied with our careers: 3.7 on a 5-point scale
In this survey we had a nice “response variable” to consider: career satisfaction. If we agree that this is a goal we share, we can consider how the other “explanatory variables” contribute to overall career satisfaction:
- Those that claimed to be more “experience oriented” tended to have a higher level of career satisfaction vs. those that were more “goal oriented”; those that reported being “very satisfied” with their careers were >3x more likely to be “experience oriented”
- Those with longer careers tended to be more satisfied: both “career years” and “number of jobs” provided a fractional lift in the 5-point career satisfaction scale
- Pursuing a goal of “organizational leader” tended to provide more lift than “domain expert”
- And pursuing a experiences as a “field expert” tended to provide more lift to satisfaction than experiences as a “breadth leader” (though more consider themselves to be the latter)
- None of the models built in analyzing this data did a great job of explaining all of the variance in your responses; we are all different and find satisfaction in our careers in different ways
Bottom Line: There is no “silver bullet” which guarantees our career satisfaction; people are different and their satisfaction is driven by various factors, at different career stages. That said, as leaders, we generally tend to find satisfaction based on our experiences with other people (as org leaders, experts in our field, more time in our careers/more roles over time) over the specific goals or attained knowledge we encounter through our journey.
Thanks for your responses!
As a manager, big company or small, the opportunities to lead are everywhere. Too often though we can fail to lead and fall into the trap of editing the work of others–critiquing, tweaking, or otherwise mucking with what is discussed or delivered, rather than stepping back and considering if we are truly improving on the work or just imprinting upon the work, or if we are empowering or micromanaging.
Please don’t forget to try the new poll for this post here.
Every manager faces a constant struggle as the work expands and time shrinks—it seems faster to just say “the answer” rather than let “discovery” happen organically. Finding this balance and challenging ourselves to lead not edit is difficult but key to the long term strength of the team and ability to scale as a manager.
The challenge gets to the core responsibilities of management. Management, at every level, is about the effort to frame challenges, define end states, and allocate resources to navigate between them. If the work requires smart, talented, creative people, then more than anything you want to enable folks on the team to create. When people create, they want to show off their creation and keep creating more. Redoing, reworking, and revisiting can not only drain resources and energy, but sap creative people of their desire to create.
Micromanaging by editing
Most would probably agree that the easiest and most damming insult directed at a manager is the dreaded label micromanager.
Looking beyond the rhetoric, the term editor does more to explain the dynamic. Editing the work of those you manage disempowers the team, removes accountability, and in general reduces motivation. Editing the work of others is easy—it seems like anyone can change the UX, add a feature, rewrite some text, or tweak a slide. The creative effort is coming up with the work in the first place from a blank sheet, so to speak. Of course there is a role for editing (which itself is a noble profession), but in the complex works of product development there is a great deal of context. In reality most everything follows an iceberg principle, with far more than meets the eye—the complexities and realities that came to light during creation might not always be visible once the work is packaged up for management.
For a variety of reasons theorized in this Wikipedia entry on micromanagement, managers might resort to an excessive focus on details or dive into details arbitrarily. A common element is the manager taking the work of a team member as a starting point and substituting a flawed process of editing for what could be helpful, insightful, and valued interactions more defined by proper feedback or coaching.
From the perspective of the manager, there are a number of common patterns that arise and are indicative of management needing improvement.
- Receive and rework. You glance at your mobile and that updated specification shows up. While there is an expectation to read the spec and provide feedback, the sender was probably hoping for a job well done reply. Instead, your message back is a quick “did you think of X” or “I don’t like the way you say Y”. This gets even worse if the feedback is about the presentation of the information rather than the information. You hope to be improving the work but inadvertently spin up a PowerPoint or Excel workshop session. There might very well be mistakes or significant missteps in the work. Step back and deliver a clear and focused message on those and just skip the easy adds or tweaks. Suggestion: Make a simple rule for yourself like “never suggest a different format of a report” or “never add more work unless you also take away work” or “save feedback for the critical or strategic elements”.
- Delegate and tweak. When you delegate work to the member of the team, your job is to clearly frame success and describe the objectives. Delegation of work can be as simple as scrubbing the feature list or as complex as asking someone to take on a group-wide stretch assignment. No matter what the scale of delegation, getting out of the way after delegation is key. When the results are in, keep in mind not the results free of context but look at the results in the context of how you delegated the work. If you see mistakes or missteps, ask yourself if you were clear or your delegation caused the problems. Editing the work that ignores the context will tend to alienate folks as they keep thinking “would have been nice if you told me that up front”. Leading is actively taking responsibility for the lack of clarity and triaging the real marginal gain from tweaks at this later stage. Suggestion: Delegate challenges and define success, but don’t delegate the intermediate steps or detailed output, making it clear where creativity is expected.
- Fetch and edit. The best work for creative folks on the team is when the problem is big and the solution escapes everyone. In these cases, as a manager you don’t know the answer. That’s stressful for everyone. The way to increase the stress is to ask a member of the team to build or create an answer for “review” or for a list of options and recommendations. We all know how this process can really go haywire. When one potential solution to an unknown is offered, the next step is to go back and rework it with the new learning, or “no not that rock, a different rock”. We also know that with a big unknown and a list of n possible choices, after a brief dialog the next step is to pick option n+1. Suggestion: Asking creative people solve vaguely defined problems can be the most rewarding work of the team, so don’t drain the energy by thinking you will know the best answer when you see it, driving folks a bit loopy in the process.
Leadership is more than editing
These patterns and others all share a common result—the more you do them, the less creative and engaged your team will be over time. Each time your employ the tools of editor, rather than leader, you encourage people to stop creating and focus their energies on trying to predict your editorial reaction.
Leading is contributing data and experience–share your related experience and let the allegory and discovery do the work.
Leading is coaching–share your observations and offer pros and cons.
Leading is walking through the action/reaction decision tree—share the path, not just the destination.
Leading is reiterating accountability in so many cases.
Leading is knowing when the potential for learning and growing outweigh the risk of failure.
Leading is realizing there a few perfect answers and many great answers.
A goal of leading is to amplify your skills and experience while also growing new leaders. If you’re not giving people room to uncover their own way and ultimately solutions, then you’re creating a staff organization for you, not the next generation of leaders. As valuable as your experience is, don’t forget that the minutes or hour you spend editing compare to days and weeks often spent getting the work into a consumable format. The bigger the investment the more expert people are, even if they would benefit from coaching and experience.
Over time as you work to keep focused on leadership rather than editing, the team grows stronger and more self-reliant. Members of the team worry more about getting the best answers and work and less about wondering what management might be after. More work gets done. Members of the team are more empowered. This positive feedback loop continues to improve every aspect of the team.
Three questions – insights from readers
In the post, Combining guessing and planning in product development, our resident big data researcher at Stanford proposed a few questions in order to reflect what those reading this blog have to say. Considering the overall clicks on posts, we’re seeing about 1-2% of readers participate in this “for entertainment purpose only” poll.
The poll on this new post can be found https://www.surveymonkey.com/s/VLHQSBJ, please participate and share your perspective.
Thanks to those of you that took a minute to answer our three questions. We saw a few noteworthy points from the results:
- Roughly half of you have had skip level meetings in the last six months.
- On average, you spend about one fifth of your project schedule planning.
- Over half of your plans are represented in your final products.
- The most popular planning tool was ‘Short Product Plans’ (61%) and the least popular was ‘Market Requirement Documents’ (31%), though a few of you also mentioned ‘customer stories’ and ‘prototypes’ as key planning tools.
Watch this space for results from the next survey!
Staying connected to your skip level manger and she staying connected to you are valuable for the project, the team, and each of your ongoing development. Rigorously and consistently making the most of skip-levels, whether as the manager or individual employee, is an important skill to master. This post looks at one-on-ones from the perspective of the manager with some tips for the employee/individual.
Time pivot, becoming a manager
One day in your career you might come to work and it will be your first day as a new manager. Many things will seem different. All of a sudden you not only feel responsible for code and features, but you’ve taken on a new responsibility for people. For those that you now manage, a new set of demands are placed on your time. One-on-ones are a key tool for you as a new manager.
One-on-ones are the most precious time you can spend with members of the team—your new direct reports. Much has been written about how to “have a good one-on-one” or techniques for making the most of the time (there is a post in our One Strategy book or check out Ben Horowitz’s nice post). I’m a firm believer that 1:1s are the most important of all scale management tools.
The easiest thing to remember about a 1:1 is that as a manager the meeting is not for you but for the employee. Your opportunity to learn is based on the topics raised and questions asked by the member of the team, only asking questions to draw out the issues if necessary. The first sign of a struggling management chain is when employees on the team start to see one-on-ones as being called to the carpet on a regular basis or when managers view a one-on-one as their time to manage the project or to be the keeper of the agenda.
As a manager, the notion that your time is no longer your own, but is there to serve the folks on your team is significant pivot, and somewhat counter-intuitive. You might have a manager you feel “takes up too much of your time” or you might be thinking “I have real work to do instead of sitting here”. You might be worried about all you need to get done as a team and react by asking more (or too much) of your new direct reports. In other words you’re in for a bit of learning about how you now manage your time, in addition to how you manage your own work and the role of management. So you aspire to do better when you’re on the other side of the table, and effectively using 1:1s is a key step.
As a first step of this new journey, consider how you can live up to the mantra that your role is to take up as little time as possible from your direct reports. This only benefits the organization as a whole because there will be more time for work, fewer meetings, and overall more time building products. The 1:1 is your request for time, but how you turn that into a benefit for the member of the team makes it valuable and not a manager tax.
A rule of thumb you might follow is don’t ask anyone to do things for you, but ask folks what they could do that helps them get the work done they believe they are supposed to do. In other words, status reports, project reviews, and statistics may all be valuable, but only if the folks on the team decide that on their own.
At the same time, 1:1s are a key tool to get a pulse on the team and on the work of folks on the team. Through an unstructured two-way dialog you can likely learn more about what is going on than you can from status reports or other outputs open to obfuscation, unintentional or not. So spend the energy to make your way over to your direct report’s desk, meet there, and let he/she set the agenda.
When your work is operating from a shared view of the goals and open and honest communication is encouraged, there’s a very good chance challenges and issues will find you rather than you needing to ferret them out. If you’re finding you are surprised by issues, then dig into the root cause before falling back on asking folks to spend more time telling you what might be happening.
When you take on the role of managing managers, presumably you have found this balance for one level of management. As a new manager of managers, your ability to stay connected to the work is critical but the challenge is much more difficult. You might react by falling into the traps you worked hard to avoid as a new line manager. You might feel that your need to stay connected or to drive strategy trumps the need for a skip level manager to be heard, to be listened to, and to be treated just like you would like to be treated.
One-on-ones with your direct reports (fellow managers) will not likely feel like enough to get a sense of the project if you’re in the position of managing other managers. A wonderful tool to learn even more about the team is to just continue having 1:1s on the team, but with the direct reports of your direct reports. Personally, I have always found this part of management to be the very best way to learn more about your own team and an incredibly wise investment to make for a number of reasons.
A skip-level 1:1 is exactly like a 1:1 with a direct report in terms of approach. There is no preparation required. The member of the team is not being called to the carpet. The focus is whatever the member of the team wants it to be. Your role as a manager is to listen, perhaps ask a few guiding questions, and to learn by listening.
In fact, the most important part of a skip-level 1:1 is to avoid “making news” or “solving problems”. If something comes up in the meeting that is a surprise, use this as a chance to ask questions and to make sure the member of the team is engaged in addressing the issue through the management in place. A skip-level is not an opportunity for escalation, no more than it is an opportunity to search for decisions you can make or problems you can solve. If someone leaves a 1:1 thinking you decided something or changed course, then that is a good chance to ask yourself if you were stepping on the toes of your direct report.
You might find it helpful to be systematic with skip level 1:1s and work to meet each of your skip level folks once-per month/quarter/year depending on the size of your organization. If you manage a team of 100, it should be possible to have a skip level with every member of the whole team yearly. More than that and you will probably want to structure your skip-levels to include only your directs of directs, perhaps every six months. It can help to have skip-level meetings take place during specific times in the project when they might make most sense (just before or after a milestone for example). As a suggestion, don’t define “skip level 1:1 days (weeks)” as the assembly line can be a bit off-putting to some, especially if scheduled back to back. You might consider a “head’s up” mail with a skip level invitation just so folks don’t panic :-)
It is important to be consistent in the implementation. In other words, it is important to meet with the same frequency and duration with each of the folks. Don’t short change employees that might be further away, in slightly different projects, or just on areas you might find less in need. The more senior you are the more important this consistency becomes as the team looks for signals of your priorities based on who you spend time with.
My own view is that skip levels are so important that I would routinely spend 15% of scheduled meetings in a year in skip level 1:1s. Some find this a surprising use of time given how much might be going on. The reality is that a consistent approach to meeting with people across a team you manage can offer a unique lens on what is going on. It also affords an opportunity for you to reinforce the work you might have been doing with respect to accountability, decision making, and rhythm of the team.
For a skip level 1:1, just as with a regular 1:1, the topics are driven by the attendee and not you. Just as with direct reports, some folks will show up with a long list of topics (or questions). Others will show up assuming you have an agenda. And probably everything in between is possible. Regardless, your role is to facilitate the member of team opening up, to reduce the potential stress of the situation, and to reassure the member of the team that this meeting is not a career moment. This starts with you showing up in the office of the employee, not summoning, the employee to your office.
This latter point is critical. A skip level 1:1 is not a meeting to pass judgment or to evaluate performance, just as it is not a time for “new business”. Folks should know this. While one of you might believe that the meeting should be “confidential”, you should be cautious with that sort of dynamic, not just for skip-levels but in general. Confidentiality is important for matters of personnel but is usually counter-productive when managing a project. If someone requests confidentiality for a personnel issue, it should be handled in the appropriate manner.
If a person shows up with a long list, sometimes it is fine to allow them to work through it. It might also be a good idea to “pace” the dialog and start off by asking “what’s on your mind?” or “how are things going?” In a first 1:1, if you don’t have a history with the member of the team, why not use the time to learn more about each other’s background (as appropriate) and to reciprocate?
There’s likely going to be some interest in hearing answers “from your perspective” – “how are things going”, “did you hear about…”, “what do you think…”? That is interest in topics that are perceived to be talked about at some higher level on the team. It is great to spend some time on those, though it is worth considering how you can put those topics in the context of the project rather than just gossip.
For a larger organization, there’s a benefit to spending time in skip-level dialogs on the efficacy of the work environment. Asking questions about the velocity of code, collaboration, getting things done, and so on. In any organization of size, a manager of managers is where action can (and should) be taken to avoid the perils of a stagnating organization.
Similarly, topics that will surely come up will be related to processes that are corporate wide (compensation, recruiting, and so on). It is probably a good idea to be extra careful about “making news” in how you discuss these—that is different than being guarded and evasive—by focusing on the information previously discussed broadly with the team. You might learn something wasn’t clear, in which case there’s a chance to clear things up for the whole set of folks in a consistent manner.
During different phases of the project, it is great to enable a discussion about that—feedback on pre-release, design challenges, ramping up, and so on.
If you’re the individual
A skip-level 1:1 is a great time to offer your perspectives on what is going well and not. There’s a fine line between offering up all the potentially bad news and sounding like you’re setting expectations, and polishing up all the potentially good news and sounding like you’re showing off. You have to be the judge. A few other potential tips/topics:
- Use right level of detail. Speak the truth and what you know, but match the level of detail that your skip level manager will find valuable. Keep in mind no matter how hands on the manager is, you have a lot more detail in your head :-)
- Ask clarifying questions. Managers often have a tough time with “what is that” or “no I don’t understand” so don’t be afraid to ask questions clarifying if you were clear. Feel free to volunteer to expand acronyms or code names, rather than assume a deep knowledge (without sounding too pedantic).
- Discuss cross-group, collaboration, partnerships. There’s a good chance your skip level manager is pretty tuned in and curious as to how things you are working on contribute to cross-team initiatives. Consider focusing on those topics and if you do, just speak the truth as if your partner is sitting right there with you.
- Limit strategy. There’s a time and place for strategy. While you might be tempted to use the time for big strategy topics, this might not further your goals much and might not be the best use of time. Spend the time thinking about how you could help your contribution to the project with insights and information.
- Don’t make news. It is probably not a good idea to “make news” in this discussion–news about the project, you, or feedback about team/people. You might want to resist the urge to share something for the very first time in this forum and certainly not something you would not share with your manager as if she was sitting right there. If you have candid feedback on your manager, then be clear about what you’re doing and don’t conflate that with the rest of the meeting topics.
Above all, make the most of the time to make sure your skip-level manager is familiar with you and your work in a neutral and constructive way.
When used consistently and effectively, skip-level 1:1s are a great, two-way tool for both of you and the team.
In what could be considered an extremely bold and thoughtful move, according to reports Yahoo recently announced that employees will be required to work from a Yahoo facility rather than “remote”. As one who has spent time on these challenges, the commentary that followed was arguably predictable. With reactions ranging from tone deaf and archaic to downright anti-motherhood, there seems to be a great deal of pushback or at least feedback. Like so many things in managing a large organization there is no clear cut way to manage through this structural and organizational challenge.
What are some of the considerations in attempting to structure a modern product development team?
The key challenge in implementing any policy in a corporation is to balance the needs of the individual, the needs of the team, and the needs of the company and shareholders. As one might expect these needs are not always in alignment at the granular level. Even at the macro level it is not always clear, for example, that everyone comes to work to maximize shareholder value on any given day or that choices each party might make to accomplish that would be aligned.
In balancing these needs, a company also has the obligation to be consistent, and have a view as to why an approach is fair for a set of parties involved. This is about balancing fair across many dimensions—all parts of a company should follow the same basic set of rules/guidelines, rules/guidelines should be the same regardless of your position in the organization or type of role, geography should be implemented consistently (while adhering to local laws as well), and so on. Nothing eats away at an organization as a whole more than the feeling that one part of a company gets a better deal than another part. On the other hand when taken down to an individual level what is consistent is not always viewed as fair by some.
One of the main ways companies tend to deal with controversial or cultural issues is to empower managers throughout an organization to “do the right thing” or as it is called in the military “commander’s intent”. Netflix’s famous expense policy is a supremely good example of this approach (imho). The basic idea with this approach is that deciding at a top-most level is not optimal and so this approach allows for optimal or situational decision making where the only management communication is based on an end-state not the details (“ship great products and have a strong organization”). It also tends to optimize for the least amount of consistency across a large organization and thus potentially causes some amount of underground friction. What is laudable about the Yahoo position is that it is a clear choice from the top of the company, whether you agree with the policy or not you cannot argue that it expresses a clear point of view which is worth noting.
It is extraordinarily difficult to argue against having a flexible workstyle/workforce/team, where flexibility is defined by a whole host of dimensions. A modern product is used by a whole world of people (hundreds of millions) and there is every reason to consider that a product used so broadly should be developed by a team that is representative of the breadth of usage. Flexibility in work location is one dimension and the focus of this post and the Yahoo policy (and this post).
People ask for flexibility for a whole variety of reasons: work better from home, required to live far from an office (across the bay to across the country to across the ocean), special needs more easily serviced at a different location, worked on a project full time and needed to move, spouse/family needs (permanent or part time), or even just a feeling that there’s no need to go into an office. Those are just a few. In fact the list of motivations for working from home/remote is probably at least as long as the number of people on a team who appreciate this arrangement.
Particularly for software projects, and extra-particularly for modern cloud-based products, it seems almost absurd on the face of it not to build the products from a flexible team. In fact most of the products even target the very notion of flexible work environments—so the irony of not following that doctrine to build the product is not lost.
So why all the complexity and challenges?
Ultimately there are a bunch of considerations to take into account, none of which is easily reconciled. The flipside is that all of them can be reconciled in the specific. Therein rests the core challenge faced by a company—what if everyone says they will do the right thing, yet the net result is not the right thing for the company as a whole? What if there are a plethora of examples and counter-examples for a given policy? Everyone who works or supports someone remotely has the very best of intentions. That’s a given. Yet there must be more to this given the changes reported at Yahoo (or policies at other companies) and the dialog.
In an effort to spark some dialog, it seems reasonable to offer some of the challenges that a large organization faces with respect to flexible work. That’s what this post is about, a dialog, and not advocating one point of view or another. In fact I am writing this post living this very challenge personally right now with geographically dispersed commitments and folks willing to support me in those, and I see some of the issues discussed.
I’ve worked on teams which have been geographically split, where people have worked from sites all around the world, and where individuals have had a wide variety of special arrangements. It has never been as easy as “just being modern” and there were always extra work required. And there was always extra benefit as well. Talented people making world class contributions have worked in flexible arrangements on those projects. Some worked temporarily. Some worked permanently. Some set out to work for a short time or permanently and changed paths.
In almost all cases one or more of the following challenges were or became part of the dialog.
Collaboration. Software is a highly collaborative process. To develop software requires collaboration across multiple dimensions. Programmers need to collaborate up and down the stack, across API boundaries, and more. These boundaries evolve rapidly while a system is being developed and the evolution does not often take place through code checkin or over email. Collaboration takes place across disciplines and more often than not those are meetings that take place in person and just as often they are not scheduled. Developers, testers, program managers, operations, designers, and more need to talk frequently in an ad hoc manner. Do you tune the amount of flexible work a team supports based on some measure of how much collaboration the product/project requires? Is it reasonable to assume that the same amount of collaboration can happen between co-located teammates as remote teammates? How much of collaboration is intrinsically based on proximity?
Disciplines. One of the challenges is that different disciplines require different levels of collaboration in a typical project or workday. While every discipline is inherently collaborative, one could (and many do) argue that there are more solitary hours in coding or writing than there might be in design or testing, for example. There are certainly very few solitary hours in being a manager or being a product/program manager. Do you have an approach where some disciplines can have more flexible workstyles than others, for example? How does that feel to the rest of the team when motivations for flexible workstyles arise independent of job function?
Integration / consistency. Customers and reviewers consistently ask for more product integration and better product synergy. By almost all accounts, the “farther apart” members of a project are the more difficult this integration and consistency becomes. You can see this even when it comes to internet discussions about org charts or management structures. The root of this is because consistency and integration come from building highly collaborative give-and-take relationships and those relationships get built and maintained through a great deal of personal contact. Do you tune the amount of flexible workstyles to support based on the measure of integration you want across products or assign people differently (perhaps differently than their skillsets) based on the needs for integration across products?
Ship the org chart. A common phrase used in building software from a large organization is to take care to avoid “shipping the org chart”, which basically means to do what you can to structure a team such that the org chart does not show through in developing the product (a subject of a future post, I promise). Because product development has the potential to evolve differently when people are not in physical proximity there is the potential to mimic what would happen if there was an org design, regardless of the actual line manager. Despite a long history (and requirement) of remote work, even Boeing is reportedly struggling with this aspect of 787 production at the organizational level. When organizing a project, do those members of the team working remotely need to be assigned to projects differently to mitigate the org-distance challenges of remote work?
Turnaround to answers. A big part of a collaborative project is the timeline of asked and answered. Even in the same hallway, you can’t always get an answer from someone (despite the perception, people might not be literally chained to a desk). So the question becomes what is the turnaround time for an answer. If a person is working flexibly 40 hours a week during core working hours, then the expected turnaround should be quick (another source of flexibility is what hours, most every company has some notion of core hours, though the days of at your station by 8:00AM like Intel might be history). On the other hand, some flexible arrangements are 4 days at 10 hours each or even 3 12 hour days (putting aside part time which is another flexible workstyle). The question then becomes one of whether the team is blocked because it is a flex day? Of course this is no different than a person being out sick or on vacation, and some say that it is easier to work around a regular schedule. This challenge extends to teammates in different time zones as well—the further away the less core hours overlap. Should a team be structured with expectations of turnaround, even if it interferes with the stated goals of flexible workstyles?
Shared mindset / point of view. So much of building a software project is about the emotional connection shared by members of a team. The feeling of community, shared goals, and culture are all part of a team. Remote members of a team, by definition will always miss out on elements of this—not just the hallways and meetings, but lunch, voluntary social time, and more. These are just the nature of human beings and how we build community and evolve. As much as we talk about video conferencing, air travel, or just “days on site”, we all know the challenges of just picking up where you left off the last time you saw folks. How does a team continue to develop and evolve a shared point of view with some members of the team not physically present?
Career velocity. If your organization supports flexible work, then it goes without saying that performance appraisal, compensation, promotion, etc. should all be exactly the same whether you are working remotely or not. This is obvious, but not without challenges. For the disciplines that are highly collaborative or projects that are less about individual effort and more about team effort how do you account for the different number of hours spent doing the in-person work these require? Do you structure remote work so it requires less of this type of collaboration? Then do you choose people or projects suite to that? How would you explain the policy regarding approval for remote work?
Peer evaluation. Most employees participate in a peer review process, both offering and receiving feedback. In some sense full-time remote employees can benefit from the most pure form of evaluation in that literally only the work is evaluated. On the other hand, when a large portion of the work involves the process by which choices are made and the way the end-point is reached, the need to participate on equal footing with the team is important to peer feedback. How does peer evaluation work for the “process” or the “how” of the work not just the output?
Management. Managing remote teammates or being managed remotely are both challenging. The more senior you are the less you need (or want!) to interact with your manager, but that is not always a two-way street. Some managers like a high touch team, especially in some disciplines or some phases of a project. Some employees do better work when they can talk with their manager for a few minutes in an ad hoc manner. Newer employees require nearly daily contact/coaching from their manager. What if the manager is not on site or if the employee is not on site? Sometimes “new” does not mean new to the workplace, but just new to the project (or a new project) or just new to the domain. How do you factor in management and being managed into a remote workstyle?
Individual skills. Most any discussion of remote or flexible work hinges on the individual skills of the person working in this style relative to the needs of the team. This makes a ton of sense—any team should be staffed and organized taking into account the capabilities of the individuals on the team. The challenge becomes implementing this in a fair and consistent manner when it comes to remote work. How do you articulate the criteria for being permitted to work remotely? How do you avoid any sort of criteria from being gamed or politicized?
Accountability. Ultimately, any team functions well when accountability is clear and everyone on the team is signed up for their part of the project in terms of delivery, timeliness, and quality. Remote or not, this should not change. But projects do not always go well. When things don’t go well, the team as a whole looks for reasons. One of the darker aspects of remote work is that it becomes a variable that itself gets evaluated in context of work that was not what everyone (including the member of the team) hoped for. How do you account for the variable of remote work when things don’t go well? What happens if you identify working remote as a causal factor? Is it really a causal factor or just a difference? Is the accountability of the manager or the remote employee or the team for not working in a way consistent with the remote employee?
Life changes. Many of the motivations for remote work stem from life changes. Our society is highly mobile these days and so people choose to move to other cities/countries for a whole variety of reasons. Housing prices are crushing in much of the world and so commutes can be awful and wasteful. Spouses also work in most American families and that creates a variety of possible motivations for flexible work. Families grow and the need for one parent to be at home beyond the statutory parental leave is a strong motivator for flexible work. Life happens and perhaps someone needing care moves in with you or you yourself require major life adjustments and flexible work becomes necessary. How do you craft a policy around flexible work that accounts for these life changes that may be temporary or permanent? Given all of the above potential challenges, what is the right way to address the specifics of life? Do these life changes call for a separate policy or approach?
These are some examples. There are many more because there are so many individual circumstances. All of them can be painted in stark terms with obvious answers if that’s your goal. The truth is that at a policy level they can all be dealt with. But at an individual level this always becomes a special case. That’s just the complexity of a large organization. It why there is no easy answer and certainly no right answer. Companies ultimately can choose to differentiate themselves on policies in this regard, as is the case with any workstyle, work culture attribute (dress code, parking, office style), or even compensation or perq.
Proof flexibility works
In any discussion of flexible work, the proof point of large successful open source projects is raised. In some ways this discussion can bubble up to the difference between developing a product in a company and developing a product that by definition and from the start is distributed in nature. It goes without saying that arguing against an existing proven success only adds to the difficulty. Are the challenges of flexible work, some outlined above, due to the very nature of corporate organizations? Or are the successes of the flexible work in open source projects rooted in the very nature of those projects?
There are also whole companies like 37signals or WordPress that are for-profit and foundationally about remote work. What practices do they have that make their experiences work for the team, product, or corporate interests? Are there attributes of the product that make flexible work easier or more supportable? Is that a design or code architecture difference?
Almost all of challenges described add up to expressing that teams build software. The larger the software the larger the team. The need to have a high performance team to build high performance products is obvious. Building and maintaining a high performance team is an incredibly difficult challenge. On the one hand the team wants the very best talent from wherever and however it can find it. On the other hand keeping the team operating in a holistic manner over time is hard enough as it goes through ups and downs of product development.
Whether you argue that a flexible work environment solves the talent side of the challenge or not is just part of the equation. How to manage the challenge of maintaining the team and product over time is the other side. As with so many product development and management challenges, knowing the challenge you face is a huge part of the work. Committing to address the challenges is critical. Just as critical is deciding where energy on the team is best spent—not every challenge is one the team should take on when faced with finite resources, time, and seemingly infinite business needs.
Product development, including team management, is a social science. That means there are no right answers but just approaches or choices in context.
Want to get developers fired up? Kick off a debate about development methodologies – waterfall, agile, lean, extreme, spiral, unified, etc. At any given time it seems one method is the right one to use and the other methods, regardless of previous experience, are wrong. Some talk about having a toolbox of methods to draw on. Others say everyone must adapt to a new state of the art at each generation. Is there a practical way to build good software without first having this debate?
There’s a short answer. Do what feels right until it stops working for the team as a whole, and to do so without debating the issue to death, then iterate on your process in your context. The clock is running all the time and so debating a meta-topic that lacks a right answer isn’t the best use of time. There’s no right methodology any more than there is a right coding convention, right programming language, or right user interface design. Context matters.
We’re all quick to talk about experimentation with code (or on customers) but really the best thing to do is make some quick choices about how to build the software you need and run with it. Tune the methods when you have the project results in the context of your team and business to guide the changes. Don’t spend a ton of time up front on the meta-debate about how to do the work you need to do, since all you’re doing is burning clock time.
Building a software product with more than a couple of people over anything longer than a few months requires some notion of how to coordinate, communicate, and decide. When you’re working by yourself or on a small enough codebase you can just start typing and what happens is pretty much what you would expect to happen.
Add more people or more time (essentially the same thing) or both and a project quickly changes character. The left hand does not know what the right hand is doing or more importantly when. The front and back end are not lining up. The user experience starts to lack a consistency and coherency. Fundamentals such as performance, scale, security, privacy are implemented in an uneven fashion. These are just a natural outcome of projects scaling.
Going as far back as the earliest software projects, practitioners of the art created more formal methods to specify and implement software and become more engineers. Drawing from more mature engineering processes, these methods were greatly influenced by the physical nature of large scale engineering projects like building planes, bridges or the computers themselves.
As software evolved it became clear to many that the soft part of software engineering could potentially support a much looser approach to engineering. This coincided with a desire for more software sooner. Many are familiar with the thesis put forth by Marc Andreessen Why Software is Eating the World (if not, worth a read). With such an incredible demand for software it is no surprise that many would like projects to get more done in less time and look to a methodological approach to doing so. The opportunity for reward for building great software as part of a great business is better than ever. The flexibility of software is a gift engineers in other disciplines would love to have, so there’s every reason to pivot software development around flexibility rather than rigidity.
For this post let’s just narrow the focus to the ends of the spectrum we see in this dialog, though not necessarily in practice. We’ll call the ends of the spectrum agile and waterfall.
In today’s context, waterfall methods are almost always frowned upon. Waterfall implies slow, bureaucratic, micro-managed, incremental, removed from customers and markets, and more. In essence, it feels like if you want to insult a product development effort then just label it with a waterfall approach.
Conversely, agile methods are almost always the positive way to start a project. Agile implies fast, creative, energetic, disruptive, in-touch with customers and markets, and more. In essence, if you want to praise a product development effort then just label it with an agile approach.
These are the stereotypical ends of a spectrum. Anything structured and slow tilts towards waterfall and anything creative and fast tilts towards agile. At each end there are those that espouse the specifics of how to implement a method. These implementations include everything from the templates for documents, meeting agendas, roles and responsibilities, and often include specific software tools to support the workflow.
It is worth for a moment looking in a mirror and stereotyping the negative view of agile and the positive view of waterfall, just for completeness. A waterfall project is thoughtful, architectural, planful, and proceeds from planning to execution to completion like a ballet. On the other hand, agile projects can substitute chaos and activity for any form of progress—“we ship every week” even if it doesn’t move customers forward and might move them backwards.
Of course these extremes are not universally or necessarily true. Even defining methodologies can turn into a time sink, so it is better to focus on reality of getting code written, tested, deployed/shipped and not debugging the process for doing so…prematurely.
In practice, no team maintains the character of the ends of this spectrum for very long, if ever. There is no such thing as a pure waterfall project any more than there is a pure agile project. In reality, projects have characteristics of both of these endpoints. The larger or longer a project is the more it becomes a hybrid of both. Embracing this reality is far better than focusing finite work energy on trying to be a pure expression of a methodology.
In discussions with a bunch of different folks recently I’ve been struck by the zeal at which people describe their projects and offer a contrast (often pointing to me to talk about waterfall projects!). One person’s A/B test is another person’s unfinished code in hands of customers. One person’s architecture for the future is another’s slogging plan. The challenge with the dialog is how it positions something everyone needs to do as a negative relative to the approach being taken. Does anyone think you would release code without testing it with a sample of real people? Does anyone really think that doing something quickly means you always have a poor architecture (or conversely that taking a long time ensures a good architecture)?
We all know the reality is much more subtle. In fact, like so many product development challenges context is everything. In the case of development methodologies the context has a number of important variables, for example some include:
- Skills of team. Your team might be all seasoned and experienced people working in familiar territory. You might be doing your n-th project together or this might be the n-th time building a similar project or update. You know how hand-offs between team members work. You know how to write code that doesn’t break the project. Fundamentals such as scale, perf, quality are second nature.
- Number of engineers / size of team. The more people on a project the more deliberate you will likely need to be. With a larger team you are going to spend time up front—measure twice, cut once. The most expensive and time consuming way to build something in software is to keep rebuilding something—lots of motion, no progress. The size of the team is likely to influence the way the development process evolves. On a larger team, more “tradition” or “convention” will likely be in place to begin with. Questioning that is good, but also keeping in mind the context of the team is important. It might feel like a lot of constraints are in place to a newcomer, especially relative to a smaller previous team. The perspective of top, middle, bottom plays into this–it is likely tops and middles think there is never “enough” and bottoms think “too much”. On a large team there is likely much less uniformity than any member of the team might think, and this diversity is an important part of large teams.
- Certainty of project. You might be working on a project that breaks new ground but in a way that is comfortable for everyone. This type of product is new to the organization but not new to the industry (for example, a new online store for a company). Projects like this have a higher degree of certainty about them than when building something new to the industry.
- Size of code base. Even with a small number of people, if you happen to have a large code base then you probably need to spend time understanding the implications of changes. In an existing body of code, research has consistently shown about a 10% regression rate every time you make changes. And keep in mind that “existing body of code” doesn’t have to mean decade’s old legacy code. It could just mean the brand new code the 5 of you wrote over the past six months but still need to work around.
- Familiarity of domain. The team might have a very high degree of familiarity with a domain. In Dreaming in Code the team was very agile but struggling until they brought in some expertise to assist with the database portion of the project. This person didn’t require the up-front planning one might think, because of the domain expertise they just dove right in building the require database. But note, the project had a ton of challenges and so it isn’t clear this was the best plan as discussed in the book.
- Scale services. Scaling out an existing service or bringing up a new service for the first time is a big deal. Whether you’re hosting it yourself or using a service platform, the methods you use to get to that first real world use might be different than those you would use for an app delivered through a store. The interactions between users, security and privacy, reliability, and so on all have much different profiles when centralized. Since most new offerings are a combination of apps and services, it is likely the methods will have some differences as well.
- Realities of business. Ultimately there is a business goal to a project. It is easy to say “time to market is everything” and many projects often do. But there is a balance to competitive dynamics (needing features) and quality goals (no one needs a buggy product) that really dictate what tolerances the marketplace will have for varying levels of quality and features one delivers. Even the most basic assumption of “continuous updating” needs to be reconciled with business goals (something as straight forward as how to charge for updates to a paid app can have significant business implications for a new company).
The balance with all of these attributes is that they can all be used to justify any methodology. If the team is junior then maybe more planning is in order. If the project feels breakthrough then more agility is in order. Yet as is common with social science, one can easily confuse correlation with causality. The iPad is well-known to be almost a generation in the making (having started years before the iPhone then shelved). Facebook is well-known to favor short cycles to get features into testing. In neither case is it totally clear that one can claim the success of the overall effort is due to the methodology (causal v. correlation). Rather what makes more sense is to say that within the context of those efforts the methodology is what works for the organization.
We don’t often read about the methodology for projects that do well but not spectacular. We do read about projects that don’t do well and often we draw a causal relationship between that lack of success and the development methodology. To me that isn’t quite right—products succeed or fail for a host of reasons. When a product doesn’t do what the marketplace deems successful, the sequence of steps to build the product are probably pretty low down on the list of causal factors—quality, features, positioning, pricing, and more seem more important.
Many assert that you simply get more done using agile methods (or said another way, waterfall methods get less done) in a period of time, and given the social science nature of our work it is challenging to turn this assertion into a testable hypothesis. We don’t build the same product twice (say the same way that carpenters know how to frame a house on schedule). We can’t really measure “amount of work” especially when there can be so much under the hood in software that might not be visible or material for another year or two.
The reality of any project that goes to customers is that a certain amount of work needs to get done. The methodology dictates the ordering of the work, but doesn’t change the amount of work. The code needs to be written and tested. The product needs to work at scale, reliable, secure, accessible, localizable, and more. The user experience needs to meet the design goals for the product. Over time the product needs to maintain compatibility relative to expectations—add-ins and customizations need to be maintained for example.
All of this needs to happen. All of this requires elements of planning, iteration, prototyping, even trial and error. It also requires a lot of engineering effort in terms of architecture and design. On any project of scale, some elements of the project are managed with the work detailed up front. Some elements are best iterated on during the course of the project. And some can wait until the end where rapid change is not a costly endeavor.
There’s no magic to be had, unfortunately. You can always do less work, but it doesn’t always take less time once the project starts. You can’t do more work in less time, even if you add more resources. You can sacrifice quality, polish, details, and more and maybe save some time. You can plan for a long time but it doesn’t change the amount of time to engineer or the value of real people using the product in real situations. You can count of fixing things after the product is available to customers, but that doesn’t change the reality of never getting a second chance to make a first impression. All of this is why product development is so fun—there simply aren’t magic answers.
There are ways to be deliberate in how you approach the challenge.
Checkpoints drive changes
Rather than advocate for a conversion of the whole team to a methodology or debate the best way to do the work, the best bet seems to always be much more organic. On a small project, ask what would work for each of the team members and just do that. On a large project, put some bounding principles in place and some supporting tools but manage by results not the process as best you can.
In all cases, the team should establish a rhythm of checkpoints that let everyone know where the project stands relative to goals. Define a date along with criteria for the project at that date and then do an assessment. This assessment is honest and transparent. If things are working then great, just keep going. If things are not working then that’s a good time to change. The only failure point you can’t deal with on a project is a failure to be honest as a contributor and honest as a team. If the dynamic on the team is such that it is better to gloss over or even hide the truth then no methodology will ever yield the results the team needs.
In projects I’ve worked on that have spanned from 3 months to 3 years, the only constants relative to methods are:
- Establish the goals of the project, the plan, in such a way that everyone knows the target—execute knowing where you want to end up and adapt when you’re not getting there or you want to adjust the target.
- Create a project schedule with milestones that have measureable criteria and honestly assess things relative to the criteria at each of those milestones.
The bigger the project the more structure you put on what is going on when, but ultimately on even the biggest projects one will find an incredible diversity of “methods”. At least two patterns emerge consistently: (a) that scale services and core “kernel” efforts require much more up front planning relative to other parts of a project and failure to take that into account is extraordinarily difficult to fix later and (b) when done right, user experience implementation benefits enormously from late stage iteration.
Given all that is going on a project what’s the right way to approach tuning a methodology?
Very few software projects are on schedule from start to finish, and even defining “on schedule” can be a challenge. Is a 10% error rate acceptable and does that count as on time? If the product is great but was 25% late, time will probably forget how late it was. If the product was not great but on time, few will remember being on time.
So more important than being on time is being under control. What that means is not as much about hitting 4pm on June 17th, but knowing at any given time that you’re going to be on a predictable path to project completion. Regardless of methodology, projects do reach a completion date—there’s an announcement and people start using what you built. It might be that you’re ready to start fixing things right away but from a customer perspective that first new experience counts as “completing the project”. Some say in the agile era products are never done or always changing. I might suggest that whenever new codepaths are executed by customers the project as experienced some form of completion milestone (remember the engineers releasing the code are acting like they “finished” something).
The approach of defining a milestone and checkpoints against that milestone is the time to look at the methodology. Every project, from the most extreme waterfall to the highest velocity agile project will need to adjust. Methodologies should not constrain whether to adjust or not as all require some information upon which to base changes to the plan, changes to how people work, or changes to the team.
Checkpoints should be a lightweight self-assessment relative to the plan. When the team talks about where they are the real question is not how are things going relative to a methodology but how things are going relative to the goal of the project. The focus on metrics is about the code, not about the path to the code. Rather than a dialog about the process, the dialog is about how much code got done and how well is it working and connecting to the rest of the project.
That said there are a few tell-tale signs that the process is not working and could be the source of challenges:
- Unpredictable. Some efforts become unpredictable. A team says they are going to be done on Friday and miss the date or the team says a feature is working but it isn’t. Unpredictability is often a sign that the work is not fully understood—that the upfront planning was not adequate to begin the task. What contributes to unpredictability is a two-steps forward, one-step back rhythm. Almost always the answer to unpredictability is the need to slow down before speeding up.
- Lots of foundation, not a lot of feature. There’s an old adage that great programmers spend 90% of the time on 10% of the problem (I once interviewed a student who wrote a compiler in a semester project but spent 11 of 12 weeks on the lexical phase). You can overplan the foundation of a project and fail to leave time for the whole point of the foundation. The checkpoint is a great time to take a break and make sure that there is breadth not just depth progress. The luxury of time can often yield more foundation than the project needs.
- Partnerships not coming together. In a project where two different teams are converging on a single goal, the checkpoint is the right time to sanity check their convergence. Since everyone is over-booked you want to make sure that the changes happening on both sides of a partnership are being properly thought through and communicated. It is easy for teams that are heads down to optimize locally and leave another team in a tough spot.
- Unable to make changes. In any project changes need to be made. Surprisingly both ends of the methodology spectrum can make changes difficult. Teams moving at a high velocity have a lot of balls in the air so every new change gets tougher to juggle. Teams that have done a lot of up front work have challenges making changes without going through that process. In any case, if changes need to be made the rigidity of a methodology should not be the obstacle.
- Challenging user experience. User interface is what most people see and judge a product by. It is sometimes very difficult to separate out whether the UI is just not well done from a UI that does not fit well together.
- Throwing out code. If you find you’re throwing out a lot of code you probably want to step back—it might be good or it might be a sign that some better alignment is needed. We’re all aware that the neat part of software is the rapid pace at which you can start, start over, iterate, and so on. At some point this “activity” fails to yield “progress”. If you find all or parts of your project are throwing out more code, particularly in the same part/area of a project then it is a good time to check the methodology. Are the goals clear? Is there enough knowledge of the outcome or constraints?
- Missing the market. The biggest criticism of any “long” project schedule is the potential to miss the market. You might be heads down executing when all of a sudden things change relative to the competition or a new product entry. You can also be caught iterating rapidly in one direction and find competition in another. The methodology used doesn’t prevent either case but a checkpoint offers you a chance to course correct.
It is common and maybe too easy to get into a debate about methodology at the start of a project or when challenges arise. One approach to shy away from debates about characterizing how the work should be done is to just get some work done and iterate on the process based on observations about what is going wrong. In other words, treat the development process much like the goal of learning how to improve the product in the market place through feedback. A time to do this is at deliberate checkpoints in the evolution of the process.
So much of how a product evolves in development is based on the context—the people, the goals, the technologies—using that to your advantage by knowing there is not a high degree of precision can really help you to stay sane in the debates over methods.
This post was challenging to write. It is such a common discussion that comes up and people seem to be certain of both what needs to be done and what doesn’t work. What are some experiences folks have had in implementing a methodology? What are the signs you’ve experienced when regardless of the methodology the project is not going in the right direction? Any ideas for how to turn checkpoints into checking up on the project, not revisiting all the choices? (ok that last one is a favorite of mine and a topic for a future post).