Posts Tagged ‘collaboration’

Smartphones and tablets, along with apps connected to new cloud-computing platforms, are revolutionizing the workplace. We’re still early in this workplace transformation, and the tools so familiar to us will be around for quite sometime. The leaders, managers, and organizations that are using new tools sooner will quickly see how tools can drive cultural changes — developing products faster, with less bureaucracy and more focus on what’s important to the business.

If you’re trying to change how work is done, changing the tools and processes can be an eye-opening first step.

Many of the companies I work with are creating new productivity tools, and every company starting now is using them as a first principle. Companies run their business on new software-as-a-service tools. The basics of email and calendaring infrastructure are built on the tools of the consumerization of IT. Communication and work products between members of the team and partners are using new tools that were developed from the ground up for sharing, collaboration and mobility.

Some of the exciting new tools for productivity that you can use today include: Quip,Evernote, Box and Box Notes, Dropbox, Slack, Hackpad, Asana, Pixxa Perspective, Haiku Deck, and more below. This list is by no means exhaustive, and new tools are showing up all the time. Some tools take familiar paradigms and pivot them for touch and mobile. Others are hybrids of existing tools that take a new view on how things can be more efficient, streamlined, or attuned to modern scenarios. All are easily used via trials for small groups and teams, even within large companies.

Tools drive cultural change

Tools have a critical yet subtle impact on how work gets done. Tools can come to define the work, as much as just making work more efficient. Early in the use of new tools there’s a combination of a huge spike in benefit, along with a temporary dip in productivity. Even with all the improvements, all tools over time can become a drag on productivity as the tools become the end, rather than the means to an end. This is just a natural evolution of systems and processes in organizations, and productivity tools are no exception. It is something to watch for as a team.

The spike comes from the new ways information is acquired, shared, created, analyzed and more. Back when the PC first entered the workplace, it was astounding to see the rapid improvements in basic things like preparing memos, making “slides,” or the ability to share information via email.

There’s a temporary dip in productivity as new individual and organizational muscles are formed and old tools and processes are replaced across the whole team. Everyone individually — and the team has a whole — feels a bit disrupted during this time. Things rapidly return to a “new normal,” and with well-chosen tools and thoughtfully-designed processes, this is an improvement.

As processes mature or age, it is not uncommon for those very gains to become burdensome. When a new lane opens on a highway, traffic moves faster for awhile, until more people discover the faster route, and then it feels like things are back where they started. Today’s most common tools and processes have reached a point where the productivity increases they once brought feel less like improvements and more like extra work that isn’t needed. All too often, the goals have long been lost, and the use of tools is on autopilot, with the reason behind the work simply “because we always did it that way.”

New tools are appearing that offer new ways to work. These new ways are not just different — this is not about fancier reports, doing the old stuff marginally faster, or bigger spreadsheets. Rather, these new tools are designed to solve problems faced by today’s mobile and continuous organization. These tools take advantage of paradigms native to phones and tablets. Data is stored on a cloud. Collaboration takes place in real time. Coordination of work is baked into the tools. Work can be accessed from a broad range of computing devices of all types. These tools all build on the modern SaaS model, so they are easy to get, work outside your firewall and come with the safety and security of cloud-native companies.

The cultural changes enabled by these tools are significant. While it is possible to think about using these tools “the same old way,” you’re likely to be disappointed. If you think a new tool that is about collaboration on short-lived documents will have feature parity with a tool for crafting printed books, then you’re likely to feel like things are missing. If you’re looking to improve your organizational effectiveness at communication, collaboration and information sharing, then you’re also going to want to change some of the assumptions about how your organization works. The fact that the new tools do some things worse and other things differently points to the disruptive innovation that these products have the potential to bring — the “Innovator’s Dilemma” is well known to describe the idea that disruptive products often feel inferior when compared to entrenched products using existing criteria.

Overcoming traps and pitfalls

Based on seeing these tools in action and noticing how organizations can re-form around new ways of working, the following list compiles some of the most common pitfalls addressed by new tools. In other words, if you find yourself doing these things, it’s time to reconsider the tools and processes on your team, and try something new.

Some of these will seem outlandish when viewed through today’s concept. As a person who worked on productivity tools for much of my career, I think back to the time when it was crazy to use a word processor for a college paper; or when I first got a job, and typing was something done by the “secretarial pool.” Even the use of email in the enterprise was first ridiculed, and many managers had assistants who would print out email and then type dictated replies (no, really!). Things change slowly, then all of a sudden there are new norms.

In our Harvard Business School class, “Digital Innovation,” we crafted a notion of “doing it wrong,” and spent a session looking at disruption in the tools of the workplace. In that spirit, “you’re doing it wrong,” if you:

Spend more time summarizing or formatting a document than worrying about the actual content. Time and time again, people over-invest in the production qualities of a work product, only to realize that all that work was wasted, as most people consume it on a phone or look for the summary. This might not be new, but it is fair to say that the feature sets of existing tools and implementation (both right for when they were created, I believe) would definitely emphasize this type of activity.

Aim to “complete” a document, and think your work is done when a document is done. The modern world of business and product development knows that you’re never done with a product, and that is certainly the case for documents that are steps along the way. Modern tools assume that documents continue to exist but fade in activity — the value is in getting the work out there to the cloud, and knowing that the document itself is rarely the end goal.

Figure out something important with a long email thread, where the context can’t be shared and the backstory is lost. If you’re collaborating via email, you’re almost certainly losing important context, and not all the right folks are involved. A modern collaboration tool like Slack keeps everything relevant in the tool, accessible by everyone on the team from everywhere at any time, but with a full history and search.

Delay doing things until someone can get on your calendar, or you’re stuck waiting on someone else’s calendar. The existence of shared calendaring created a world of matching free/busy time, which is great until two people agree to solve an important problem — two weeks from now. Modern communication tools allow for notifications, fast-paced exchange of ideas and an ability to keep things moving. Culturally, if you let a calendar become a bottleneck, you’re creating an opening for a competitor, or an opportunity for a customer or partner to remain unhappy. Don’t let calendaring become a work-prevention tool.

Believe that important choices can be distilled down into a one-hour meeting. If there’s something important to keep moving on, then scheduling a meeting to “bring everyone together” is almost certainly going to result in more delays (in addition to the time to get the meeting going in the first place). The one-hour meeting for a challenging issue almost never results in a resolution, but always pushes out the solution. If you’re sharing information all along, and the right people know all that needs to be known, then the modern resolution is right there in front of you. Speaking as a person who almost always shunned meetings to avoid being a bottleneck, I think it’s worth considering that the age-old technique of having short and daily sync meetings doesn’t really address this challenge. Meetings themselves, one might argue, are increasingly questionable in a world of continuously connected teams.

Bring dead trees and static numbers to the table, rather than live, onscreen data. Live data analysis was invented 20 years ago, but too many still bring snapshots of old data to meetings which then too often digress into analyzing the validity of numbers or debating the slice/view of the data, further delaying action until there’s an update. Modern tools like Tidemark and Apptio provide real-time and mobile access to information. Meetings should use live data, and more importantly, the team should share access to live data so everyone is making choices with all the available information.

Use the first 30 minutes of a meeting recreating and debating the prior context that got you to a meeting in the first place. All too often, when a meeting is scheduled far in advance, things change so much that by the time everyone is in the room, the first half of the hour (after connecting projectors, going through an enterprise log-on, etc.) is spent with everyone reminding each other and attempting to agree on the context and purpose of the gathering. Why not write out a list of issues in a collaborative document like Quip, and have folks share thoughts and data in real time to first understand the issue?

Track what work needs to happen for a project using analog tools. Far too many projects are still tracked via paper and pen which aren’t shared, or on whiteboards with too little information, or in a spreadsheet mailed around over and over again. Asana is a simple example of an easy-to-use and modern tool that decreases (to zero) email flow, allows for everyone to contribute and align on what needs to be done, and to have a global view of what is left to do.

Need to think which computer or device your work is “on.” Cloud storage from Box,Dropbox, OneDrive and others makes it easy (and essential) to keep your documents in the cloud. You can edit, share, comment and track your documents from any device at any time. There’s no excuse for having a document stuck on a single computer, and certainly no excuse risking the use of USB storage for important work.

Use different tools to collaborate with partners than you use with fellow employees. Today’s teams are made up of vendors, contractors, partners and customers all working together. Cloud-based tools solve the problem of access and security in modern ways that treat everyone as equals in the collaboration process. There’s a huge opportunity to increase the effectiveness of work across the team by using one set of tools across organizational boundaries.

Many of these might seem far-fetched, and even heretical to some. From laptops to color printing to projectors in conference rooms to wireless networking to the Internet itself, each of those tools were introduced to skeptics who said the tools currently in use were “good enough,” and the new tools were slower, less efficient, more expensive, or just superfluous.

The teams that adopt new tools and adapt their way of working will be the most competitive and productive teams in an organization. Not every tool will work, and some will even fail. The best news is that today’s approach to consumerization makes trial easier and cheaper than at any other time.

If you’re caught in a rut, doing things the old way, the tools are out there to work in new ways and start to change the culture of your team.

Rather than predict anything that will suddenly appear at the end of 2014, this post offers some trends that are likely to double by some measure this next year.

This will turn out to be an exponential year in many technologies and what seems far-fetched could very easily be trends that are doubling in relatively short periods of time. We humans generally have a tough time modeling things doubling (why so many companies and products did not figure out how to embrace Moore’s law or the rise of mobile).

To fully embrace exponential change means looking at the assumptions in product development and considering how optimizations for the near term might prove to be futile when facing significant change. Within each trend, design or product choices are offered that might be worth considering in light of the trend.

Low-cost/high-function devices. The seemingly endless march of the exponential Moore’s law will continue but include more than compute. Devices will put transistors to work for sensors, rich graphics, and discrete processors. These devices will continue to drop precipitously in price to what seem today like ridiculous levels such as we’ve seen at discount super stores this holiday shopping season in the US. If automobiles are any indication, we should not assume low price is equivalent to low quality for the long-term, as manufacturing becomes more capable of delivering quality at low price. The desire to aspire an even higher level of quality will remain for many and continue to support many price points and volumes. At the same time, the usage patterns across price points will vary dramatically and we will continue to see exponential growth in-depth usage as we have this holiday season with high-value devices. This makes for a fairly dramatic split and leaves a lot open to interpretation when it comes to market share in devices. Design: First, it is worth considering target customers with more granularity when looking at share, as the pure number of devices might not determine how much your service will get used, at least in the near term. Second, don’t expect differences in capability across price points to last very long as the pace of pulling capabilities from higher price points to lower will be relentless.

Cloud productivity. Cloud (SaaS) productivity tools will routinely see exponential growth in active users. Tools that enable continuous productivity will rapidly expand beyond tech early adopters as viral effects of collaboration kick in. Products such as Asana, Quip, Paper, Mixpanel, Lucidchart, Haikudeck or others will see viral expansion kick-in. Established tools such as Evernote, Box, Dropbox, WhatsApp, and more with high active usage will see major increases in cross-organization work as they grow to become essential tools for whole organizations. Design: Don’t assume traditional productivity tools and assume new employees, vendors, and recent grads will default to cloud-first productivity.

Cloud first becomes cloud-only. Enterprise software in 2013 was a dialog about on-premises or cloud. In 2014, the call for on-premises will rapidly shift to a footnote in the evolution of cloud. The capabilities of cloud-based services will have grown to such a degree, particularly in terms of collaboration and sharing, that they will dwarf anything that can be done within the confines of a single enterprise. Enterprises will look at the exponential growth in scale of multi-tenant systems and see these as assets that cannot be duplicated by even the largest enterprises. Design: Don’t distract with attempting to architect or committing to on-premises.

WWAN communication tools. WWAN/4G messaging will come to dominate in usage by direct or integrated tools (WhatsApp, WeChat, iMessage, and more) relative to email and SMS. Email will increasingly be viewed as “fax” and SMS will be used for “official” communications and “form letters” as person to person begins to use much richer and more expressive (fun) tools. This shift contributes to the ability to switch to data-only larger screen devices. Design: Skip email notifications, rely on SMS only when critical (security and verification), and assume heterogeneity for messaging choices. Expect to see more tools building in messaging capabilities with context scoped to the app.

Cross-platform challenge. This is the year that cross-platform development for the major modern platforms will become increasingly challenging and products will need to be developed with this in mind. It will become increasingly unwieldy to develop for both iOS and Android and natively integrate effectively and competitively with the platform. Visual changes and integration functionality will be such that “cross-platform layers” might appear to be a good choice today only to prove to be short-lived and obstacles to rapid and competitive development. New apps that are cross-platform “today” will see increasing gaps between releases on each platform and will see functionality not quite “right” for platforms. Ultimately, developers will need to pick their lead platforms or have substantial code bases across platforms and face the challenge of keeping functionality in sync. Design: Avoid attempting to abstract platforms as these are moving targets, and assume dual-platform is nearly 2X the work of a single platform for any amount of user experience and platform integration.

Small screen/big screen divergence. With increasing use of cloud productivity, more products will arrive that are designed exclusively for larger screen devices. Platform creators will increasingly face challenges of maintaining the identical user experience for “phones” and for phablets and larger. Larger screen tablets will be more able to work with keyboard accessories that will further drive a desire for apps tuned along these lines along with changes to underlying platforms to more fully leverage more screen real estate. The converse will be that scenarios around larger screen tablets will shift away from apps designed for small screen phones–thus resetting the way apps are counted and valued. Design: Productivity scenarios should be considering committing to large screen design and leave room for potential of keyboard or other input peripherals.

Urban living is digital living. With demographic shifts in urban living and new influx of urban residents, we will see a rapid rise in digital-only lives. Mobile platforms will be part of nearly every purchase or transaction. Anything requiring reservations, tickets, physical resources, delivery, or scheduling will only win the hearts and minds of the new urban if available via mobile. While today it seems inconvenient if one needs to resort to “analog” to use a service, 2014 is a year in which every service has a choice and those that don’t exist in a mobile world won’t be picked. Design: Consumer products and services will only exist if they can be acquired via mobile.

Sharing becomes normal. With the resources available for sharing exceeding those available in traditional ways, 2014 will be the year in which sharing becomes normal and preferred for assets that are infrequently used and/or expensive. Government and corporate structures will be re-evaluated relative to sharing from autos to office space and more. Budget pressures, rapid increase in software capabilities, and environmental impact all contribute to this change. Design: Can your business share resources? What are you using that could be shared? Is the asset you sell or rent something that runs the risk of aggregation and sharing by a new entry?

Phablets are normal. Today’s phablets seem like a tweener or oddity to some–between a large phone and a small tablet. In practice the desire to have one device serve as both your legacy phone (voice and SMS) as well as your main “goto” device for productivity and communication will become increasingly important. The reduction in the need for legacy communication will fuel the need to pivot closer to a larger screen all the time. Improvements in voice input and collaboration tools will make this scenario even more practical. In the short-term, the ability to pair a larger screen tablet with your phone-sized device for voice or SMS may arise in an effort to always use one device, and similarly smaller tablets will be able to assume phone functionality. Design: Don’t ignore the potential of this screen size combined with full connectivity as the single device, particularly in mobile first markets where this form has early traction.

Storage quotas go away. While for most any uses today this is true in practice, 2014 will be a year in which any individual will see alternatives for unlimited cloud storage. Email, files, photos, applications, mobile backup and more will be embedded in the price of devices or services with additional capabilities beyond gigabytes. Design: Design for disk space usage in the cloud as you do on a mobile client, which is to say worry much more about battery life and user experience than saving a megabyte.

Amara’s Law states “we tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run”. We will see 2014 not as one year of progress, but as the culmination of the past 15 years of development of the consumer internet as “it all comes together” with incredibly rapid adoption of products and technologies that at once become more affordable, more ubiquitous, and more necessary for our work and personal lives.

It looks like 2014 is shaping up to be the long-term of 2000 that we might have underestimated.

We are trying to change a culture of compartmentalized, start-from-scratch style development here. I’m curious if there are any good examples of Enterprise “Open Source” that we can learn from.

—Question from reader with a strong history in engineering management

When starting a new product line or dealing with multiple existing products, there’s always a question about how to share code. Even the most ardent open source developers know the challenges of sharing code—it is easy to pick up a library of “done” code, not so hard to share something that you can snapshot, but remarkably difficult to share code that is also moving at a high velocity like your work.

Developers love to talk about sharing code probably much more than they love to share code in practice. Yet, sharing code happens all the time—everyone uses an OS, web server, programming languages, and more that are all shared code. Where it gets tricky is when the shared code is an integral part of the product you’re developing. That’s when shared code goes from “fastest way to get moving” to “a potential (difficult) constraint” or to “likely a critical path”. Ironically, this is usually more true inside of a single company where one team needs to “depend” on another team for shared code than it is on developers sharing code from outside the company.

Organizationally, sharing code takes on varying degrees of difficulty depending on the “org distance” between developers. For example, two developers working for the same manager don’t even think about “sharing code” as much as they think about “working together”. At the other end of the spectrum, developers on different products with different code bases (perhaps started at different times with early thoughts that the products were unrelated or maybe one code base was acquired) think naturally about shipping their code base and working on their product first and foremost.

This latter case is often viewed as an organizational silo—a team of engineering, testing, product, operations, design, and perhaps even separate marketing or P&L responsibility. This might be the preferred org design (focus on business agility) or it might be because of intrinsic org structures (like geography, history, leadership approach). The larger these types of organizations the more the “needs of the org” tend to trump the “needs of the code”.

Let’s assume everyone is well-meaning and would share code, but it just isn’t happening organically. What are 5 things the team overall can do?

Ship together. The most straight-forward attribute two teams can modify in order to effectively share code is to have a release/ship schedule that is aligned. Sharing code is the most difficult when one team is locked down and the other team is just getting started. Things get progressively easier the closer to aligned each team becomes. Even on very short cycles of 30-60 days, the difference in mindset about what code can change and how can quickly grow to be a share-stopper. Even when creating a new product alongside an existing product, picking a scheduling milestone that is aligned can be remarkably helpful in encouraging sharing rather than a “new product silo” which only digs a future hole that will need to be filled.

Organize together to engineer together. If you’re looking at trying to share code across engineering organizations that have an org distance that involves general management, revenue or P&L, or different products, then there’s an opportunity to use organization approaches to share code. When one engineering manager can look at a shared code challenge across all of his/her responsibilities there more of a chance that an engineering leader will see this as an opportunity rather than a tax/burden. The dialog about efficacy or reality of sharing code does not span managers or importantly disciplines, and the resulting accountability rests within straight-forward engineering functions. This approach has limits (the graph theory of org size as well as the challenges of organizing substantially different products together).

Allocate resources for sharing. A large organization that has enough resources to duplicate code turns out to be the biggest barrier to sharing code. If there’s a desire to share code, especially if this means re-architecting something that works (to replace it with some shared code, presumably with a mutual benefit) then the larger team has a built-in mechanism to avoid the shared code tax. As painful as it sounds, the most straight-forward approach to addressing this challenge is to allocate resources such that a team doesn’t really have the option to just duplicate code. This approach often works best when combined with organizing together, since one engineering manager can simply load balance the projects more effectively. But even across silos, careful attention (and transparency) to how engineering resources are spent will often make this approach attainable.

Establish provider/consumer relationships. Often shared code can look like a “shared code library” that needs to be developed. It is quite common and can be quite effective to form a separate team, a provider, that exists entirely to provide code to other parts of the company, a consumer. The consumer team will tend to look at the provider team as an extension to their team and all can work well. On the other hand, there are almost always multiple consumers (otherwise the code isn’t really shared) and then the challenges of which team to serve and when (and where requirements might come from) all surface. Groups dedicated to being the producers of shared code can work, but they can quickly take on the characteristics of yet another silo in the company. Resource allocation and schedules are often quite challenging with a priori shared code groups.

Avoid the technical buzz-saw. Developers given a goal to share code and a desire to avoid doing so will often resort to a drawn-out analysis phase of the code and/or team. This will be thoughtful and high-integrity. But one person’s approach to being thorough can also look to another as a delay or avoidance tactic. No matter how genuine the analysis might be, the reality is that it can come across as a technical buzz-saw making all but the most idealized code sharing impossible. My own experience has been that simply avoiding this process is best—a bake-off or ongoing suitability-to-task discussion will only drive a wedge between teams. At some level sharing code is a leap of faith that a lot of folks need to take and when it works everyone is happy and if it doesn’t there’s a good chance someone is likely to say “told you so”. Most every bet one makes in engineering has skeptics. Spending some effort to hear out the skeptics is critical. A winners/losers process is almost always a negative for all involved.

The common thread about all of these is that they all seem impossible at first. As with any initiative, there’s a non-zero cost to obtaining goals that require behavior change. If sharing code is important and not happening, there’s a good chance you’re working against some of the existing constraints in the approach. Smart and empowered teams act with the best intentions to balance a seemingly endless set of inbound issues and constraints, and shared code might just be one of those things that doesn’t make the cut.

Keeping in mind that at any given time an engineering organization is probably overloaded and at capacity just getting stuff done, there’s not a lot of room to just overlay new goals.

Sharing code is like sharing any other aspect of a larger team—from best practices in tools, engineering approaches, team management—things don’t happen organically unless there’s a uniform benefit across teams. The role of management is to put in place the right constraints that benefit the overall goals without compromising other goals. This effort requires ongoing monitoring and feedback to make sure the right balance is achieved.

For those interested in some history, this is a Harvard Business School case on the very early Office (paid article) team and the challenges/questions around organizing around a set of related products (hint, this only seems relatively straight-forward in hindsight).

When starting a new product there’s always so much more you want to do than can be done. In early days this is where a ton of energy comes from in a new company—the feeling of whitespace and opportunity. Pretty soon though the need for prioritized lists and realities of resource/time constraints become all too real. Naturally the founder(s) (or your manager in a larger organization) and others push for more. And just as naturally, the engineering leader starts to feel the pressure and pushes back. All at once there is a push to do more and a pull to prioritize. What happens when “an unstoppable force meets an immovable object”, when the boss is pushing for more and the engineering leader is trying to prioritize?

I had a chance to talk to a couple of folks facing this challenge within early stage companies where a pattern emerges. The engineering leader is trying hard to build out the platform, improve quality, and focus more on details of design. The product-focused founder (or manager) is pushing to add features, change designs, and do that all sooner. There’s pushback between folks. The engineering leader was starting to worry if pushing back was good. The founder was starting to wonder if too much was being asked for. Some say this is a “natural” tension, but my feeling is tension is almost always counter-productive or at least unnecessary.

There’s no precise way to know the level of push or pushback as it isn’t something you can quantify. But it is critically important to avoid a situation that can result in a clash down the road, a loss of faith in leadership, or a let down by engineering.

As with any challenge that boils down to people, communication is the tool that is readily available to anyone. But not every communication style will work. Engineers and other analytical types fall into some common traps when trying to cope with the immense pressure of feeling accountable to get the right things done and meet shared goals:

Setting expectations by always repeating “some of this won’t get done”. This doesn’t help because it doesn’t add anything to the dialog as it is essentially a truism of any plan.

Debating each idea aggressively. This breaks down the collaborative nature of the relationship and can get in the way, even though analytical folks like to make sure important topics are debated.

Acting in a passive aggressive manner and just tabling some inbound requests. This is almost always a reaction to “overflow” like too much sand poured in a funnel—the challenge is just managing all the inbound requests. This doesn’t usually work because most ideas keep coming back.

What you can do is get ahead of the situation and be honest. A suggested approach is all about defining the characteristics of the role you each have and the potential points of “failure” in the relationship.

As the engineering leader, sit down with the founder (or your manager) and kick off a discussion that goes something like this as said from the perspective of the accountable engineering leader:

We both want the best product we can build, as fast as we can.

I share your enthusiasm for the creativity and contributions from you and everyone else.

My role is to provide an engineering cadence that delivers as much as we can, as soon as we can, with the level of quality and polish we can all be proud of.

We’ll work from a transparent plan and a process that decides what to get done.

As part of doing that, I’m going to sometimes feel like I end up saying “no” pretty often.

And even with that, you’re going to push to change or add more. And almost always we’ll agree that absent constraints those are good pushes. But I’m not working without constraints.

But what I worry about is that one day when things are not going perfectly (with the builds or sales), you’ll start to worry that I’m an obstacle to getting more done sooner.

So right then and there, I’d like to come back to this conversation and make sure to walk through where we are and what we’re doing to recalibrate. I don’t want you to feel like I’m being too conservative or that our work to decide what to do in what order isn’t in sync with you.

That’s the basic idea. To get ahead of what is almost certainly to be a conversation down the road and to set up a framework to talk about the challenge that all engineering efforts have—getting enough done, soon enough.

Why is this so critical? Because if you’re not talking to each other, there’s a risk you’re talking about each other.

We all know that in a healthy organization bad news travels fast. Unfortunately, when the pressure is on or there’s a shared feeling of missing expectations often the first thing to go is the very communication that can help. When communication begins to break down there’s a risk trust will suffer.

When trust is reduced and unhealthy cycle potentially starts. The engineering leader starts to feel a bit like an obstacle and might start over-committing or just reduce the voice of pragmatic concerns. The manager or founder might start to feel like the engineering leader is slowing progress and might start to work around him/her to influence the work list.

Regardless of how the efficacy of the relationship begins to weaken, there’s always room for adjustment and learning between the two of you. It just needs to start from a common understanding and a baseline to talk and communicate.

This is such a common challenge, that it is worth an ounce of prevention and an occasional booster conversation.

In the course of figuring out what to do on a project (plan, code, collaborate, marketing, …) inevitably you will get to a point where two parties (two people, two teams, two disciplines) don’t agree. Figuring out how to move forward is not only essential, but is something that can make or break a team or project.

Focusing a discussion on disagreement in the abstract is a good way to approach this, rather than using specific examples. This allows the dynamics to be discussed here without the distractions of picking sides. When it comes to disagreements, even the specifics are usually much less important than the overall context in which the disagreement is taking place. More often than not, a focus on specifics tends to hide what is really the root of a disagreement.

This post was suggested by a reader as a topic worth discussing. Suggestions are welcome and I’m always on the lookout for comments and tweets with suggestions or email me at steven@learningbyshipping.com, perhaps with something going on at your organization right now that is a generally interesting topic (specifics always removed).

Organization

Organization plays a key role in the context of building consensus (more on organization in a follow up post). Is your team managed step by step through a hierarchy, deferring to the management chain? Is your team one where the most senior manager gets involved in many choices? Is your team dominated by a strong de facto leader that leads from within the team? Is your team a small group of peers that seem to usually agree on everything? Is your team subject to swoop and poop from outside, bringing disagreement to you? There are quite a few ways that disagreements can surface and/or get resolved and those are a few.

The first step in working through disagreement is to know how your team is structured to make choices, which might be different than the org chart. You want to know not just how you want to decide things, but how do others in all 360 degrees expect to resolve things.

The 360 degree view has been something I have often worked through (and certainly not perfectly). In a team with a plan and a strong organization, it is the organization working with a decision framework, the plan, that decides. Those new to the team or even those on other teams often see a team operating this way and assume a hierarchical or top down model—otherwise how could things appear to work and stay on track with a large project.

In practice what that means is that there is a mismatch in how to handle disagreement. Some assume that you have to go to the top and “get things changed”, while folks at the top are saying “did you talk to the people doing the work.” This type of cultural mismatch is the first thing to overcome. On a team of empowered creative folks, they have gone to great lengths to say what they will be doing and how they will decide what is yet to be discovered. That’s always been enough for me.

Roles and responsibilities in an organization, not hierarchy, are also important. Are disagreements between people within the same discipline or across disciplines? Often agreements can be settled by recognition of where the responsibility rests. For example, in projects with user interface many people can have opinions about the UI but the team should be operating with acknowledgement that the accountability rests with the discipline (design, program management) that is doing the work to design the UI. Having a clear view of how specialties work in the organization is an important part of knowing how disagreements will be resolved.

Organization can cause disagreement to flourish in two main ways. First, management can structure things such that goals and/or accountability are unclear. This means things need to be integrated or reconciled “up” where there is always less information/data, thus driving meetings, debate, and campaigning for decisions. Second, members of the team can fail to defer to the empowerment and decision making structure in place (plans, disciplines, accountability). This is a case where disagreement exists when individuals on the team could take time to step back and let the organization do the work.

These organizational elements are an important part of the context around disagreements.

Context

What is it that makes disagreement so pervasive and so difficult to work through? Are there really so many arguments to be had while building a product or service once you decide what can and should be built?

I’ve always been fascinated by the dynamic of how something turns into a big decision to be made. For me, work is progressing and sometimes things come up that are hard or unforeseen. Then all of a sudden there is a crisis and something needs to be decided and that decision has expanded to involve a lot of people.

Knowing the context is always the most important first step. The following are some examples of reasons or context behind disagreement:

Decision or an argument. A first consideration is if there is truly a decision to be made or what is really going on is an argument. What this means is to ask if someone questioning your general approach or is this a real challenge to the choices you are making. It is only to your advantage to engage with members of the team who might have a different point of view. You don’t have to accept it or escalate into a fight, but it is always good for everyone on the project to be heard.

Naysayers. Sometimes a decision gets created that is not really all that important, but is being used to drive a wedge for any variety of reasons. Often these look like “let’s take a step back and ask the following question.” So you thought you were having a discussion about a schedule estimate and the next thing you know you are in the weeds debating agile v. waterfall. You have to ask yourself if the real issue is the meta-issue, a lack of faith in everything going on, or if you really have something that is the source of a disagreement.

First of many. There are times when points of difference get raised in a “death by 1000 cuts” sort of way. In other words you might find yourself disagreeing over a specific topic but as you’re talking (constructively) it becomes clear that this is going to be the first of at least a few disagreements. Folks might use this approach to test the waters or to probe for a weakness overall. An approach here is to work to smoke out all the disagreements so you can have a discussion with the full context.

Symbolic or material. Sometimes a disagreement is really an effort to raise a more symbolic disagreement with the broader context of the project. Helping to work through and discuss how material a given disagreement is to the whole project is especially important here. In this context, a disagreement can turn into a broader view of two parties not connecting.

Accountability. Ultimately disagreement needs to factor in accountability. If the first step of a disagreement is “who gets to decide” it is likely the answer will itself become a disagreement. Almost all disagreements I have been part of scream out the person who should be deciding. If it doesn’t the question is really more about accountability—not who should make a specific choice, but who is accountable for a broader set of issues. Is that person not doing a great job incorporating lots of viewpoints and information? Did that person not enroll everyone in a broader framework?

Context is everything. In the heat of a disagreement people, especially for engineers who tend to distill things into concrete facts or algorithms, will often get very focused on the details of winning the argument. It is a good idea to understand the context of the disagreement before trying to win on the merits.

What can go wrong?

As you’re working through a disagreement, there might be a few patterns you run across that are used to resolve the disagreement—patterns that might not be the most productive.

The key thing is to keep the dialog focused on the context of a choice. In a sense, what I think everyone knows is that any disagreement free of context can have a different outcome than if considered in the context. A classic is “add this feature.” Absent the context of schedule, resources, and most importantly the holistic view of a plan/product, almost any feature sounds like a good one to add or any change seems reasonable. The flip side is that just about everyone sounds like an idiot arguing against security, performance, quality absent the context that an engineer might have. No one sounds smart arguing against a revenue opportunity, until you consider the cost, alternatives, and so on.

There are patterns that are bad ways to resolve disagreement because the technique removes the context:

Single choice. Sometimes when there is a disagreement, something that seemed small starts to take on a life of its own. You come to a meeting and you’re all of a sudden having a debate over the color of tooltips in a toolbar (true story) when that is not really the disagreement as all. What has happened is a disagreement over a broad set of issues has morphed into what appears to be a single choice. The context was lost and a complex, multi-dimensional problem space has been replaced by one, seemingly, trivial option.

Escalation. Sometimes disagreements get created as a way to get in front of the boss or as a way to encourage the boss to get in front of the other party. This type of disagreement is never good and my first reaction is to pull back and “de-escalate” like cops do on reality shows. Something I have always tried to practice is the notion that to escalate is to fail. But the real challenge with escalating a disagreement is that the context and knowledge about a situation is reduced as you move up the management chain, so escalation is really a way of saying “decide with less information.” There are subtleties and nuance to this (for example if you haven’t done your work to incorporate the context from outside your specialty in creating a plan). New information can change things and the question is whether you are being too heads down to incorporate new information. The key is that once you escalate you lose the context of the choice. Similarly, to pull a decision up (the organization) creates the same dynamic of deciding with less information than might be available.

Decision maker. One way to remove the context from a disagreement is to introduce a debate over who gets to decide, as mentioned above. I’ve been part of all sorts of “tools” that are supposed to help you decide—tables of who reviews choices, approves things, or “responsibility assignment matrices.” As well-intentioned as these are they don’t really scale and they encourage all choices to get broken out into elaborate decision-making processes. At some point you can rationally ask how to even decide what decisions go through a process like this or is this an attempt to circumvent accountability or an attempt to game the system.

Accountability shift. Accountability gets to the heart of most disagreements. Those disagreeing feel on the hook, accountable, for some outcome and the choice being discussed impacts the potential for achieving the assigned goal. By shifting the dialog from the disagreement to accountability, things get emotional very quickly. The discussion turns into talk of “failure” which is a lot to place on the shoulder of a single choice in a complex product.

Tools and approaches

In practice the tools to reconcile disagreements are rather personal—they rely on the skills, tone, and temperament of the individuals. Most everyone can lose their temper or go silent (essentially the same thing). Most everyone has sent a late night mail they regret (subject line, “thoughts”). Most everyone has behaved the way they criticized someone for behaving. I’m there with you and don’t have magic answers to resolving disagreements. Here are a few tools I have used:

Expertise. Where is the most expertise? As a general rule, too often decisions are made in meetings where people are presenting cases and someone is in the middle trying to referee or decide. At that moment, a decision is being made by a committee or by a group, yet the people that have the expertise might not even be in the room. As a general practice, pushing decisions to those that know the most yields better decisions. Many times teams convince themselves that there are implications that go beyond the expertise (“yes this might be a security problem but the business has different issues”). The best thing then is to figure out how this type of context is not making it to the domain experts—what was missing from the day to day flow of information that got a team in a situation to begin with?

Plan. Most disagreements are essentially disagreements with a broader view—at the highest level or at the level of what a feature or marketing message should accomplish at the core. In other words, while the discussion might be about a specific, it is a disagreement about a broader theme. I return back to the plan (the one you got buy-in about because you talked about it broadly). I try to understand what has changed or what have we learned since the plan. Plans are dynamic of course. But one needs to be careful about changing direction without a real change in the business or product landscape. If you do change plans, you need to think hard about the relationship of one change to the big picture.

Culture. The best tool for resolving disagreements is one you have to put in place upstream, which is a culture that allows and respects the decisions being made by the right people. Developers might not like the advertising, but marketing people decide that. Marketing might not like the wording of a license, but that’s a decision for lawyers to make. But because a team should be operating with a shared view of customers, the decisions should be ones made outside of silos of expertise or narrow views of success. There’s definitely magic in there and in a big project achieving this uniformly is extremely difficult, at best. The tool everyone should ask for in a culture is a management chain that supports the culture. It isn’t about being “backed” in a decision but about being consistent in the notion of delegation and accountability.

Accountability. Related to culture is the notion of accountability. Rather than saying “test is accountable for quality” the tool is really for management to reinforce that everyone is ultimately responsible for the overall result. If something is successful you can bet that everyone on the team will feel they contributed to the success. There’s nothing stopping the team from acting that way while the product is under development.

When to say when. Finally, the best tool any individual can have in the course of a disagreement is knowing when to say when. Projects are marathons (no matter how long a particular coding sprint might be). If you choose to turn every decision into the most important and biggest one, you’ll run out of reserves long before the finish line.

One final consideration is if you agree to disagree then you have to mean it. It means you can’t remind folks at every opportunity that you saw things differently. It also means you’re tabling the disagreement for good and that you’re not inadvertently establishing a dreaded accountability dodge or told you so for later on.

There are innumerable decisions in any project—each person, then each team, then teams, and more each make choices dozens of times a day. Every line of code, every word in a spec, every automated test, every part of a plan, every data sheet, PR script, and more are decisions.

People tend to forget this in the heat of the moment. Time heals, and forgets, most every small decision in a project. In fact, I would bet that any disagreement you are dealing with at this moment will be a distant memory and chances of it determining success and failure of your project are small when viewed in the context of all the work, and decisions, yet to be done. Om.