Learning by Shipping

products, development, management…

Posts Tagged ‘management

Reaching for harmony in org changes

with 11 comments

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

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

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

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

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

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

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

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

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

Perspective and context

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

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

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

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

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

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

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

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

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

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

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

Why reorg?

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

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

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

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

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

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

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

Challenges

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

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

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

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

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

Tools

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

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

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

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

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

Or not…

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

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

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

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

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

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

Customers

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

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

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

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

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

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

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

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

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

–Steven Sinofsky

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

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

 Here are the results:

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

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

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

Bottom Line:

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

Thanks, Cameron

###

Written by Steven Sinofsky

May 6, 2013 at 9:00 am

Posted in posts

Tagged with ,

Learning by slipping

with 19 comments

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

Slipping

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

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

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

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

What’s a ship date

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

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

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

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

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

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

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

Reasons to slip

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

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

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

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

Reality

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

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

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

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

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

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

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

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

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

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

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

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

What to do

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

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

What else can be done?

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

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

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

–Steven Sinofsky

Written by Steven Sinofsky

May 1, 2013 at 10:00 pm

Posted in posts

Tagged with , ,

A line to see someone is not cool, but is blocking progress

with 5 comments

Gridlock'd movieIt 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.

Accountability

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.

–Steven

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!

Cameron

Written by Steven Sinofsky

April 11, 2013 at 9:00 am

Posted in posts

Tagged with , ,

Being a leader, not a micromanaging editor: 3 patterns to avoid

with 13 comments

12 O'Clock HighAs 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.

  1. 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”.
  2. 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.
  3. 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.

–Steven

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!

–Cameron

Written by Steven Sinofsky

March 21, 2013 at 10:00 am

Posted in posts

Tagged with ,

Benefiting from skip-level one-on-ones

with 9 comments

Scene from the film

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.

Skip-level 1:1s

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.

Some topics

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.

–Steven

 ###

Written by Steven Sinofsky

March 5, 2013 at 10:30 am

Posted in posts

Tagged with ,

Balancing a flexible work environment

with 29 comments

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?

Challenge

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.

Flexibility

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?

Approach

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.

–Steven

###

Written by Steven Sinofsky

February 23, 2013 at 12:45 pm

Posted in posts

Tagged with ,

Focusing on the work, not the methodology

with 25 comments

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.

Methods

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.

Definitions

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.

Reality

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:

  1. 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.
  2. 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.

Approach

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

–Steven

###

Written by Steven Sinofsky

February 7, 2013 at 8:30 am

Posted in posts

Tagged with , , , ,

Managing through disagreement

with 79 comments

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.

–Steven

Reminder – please see the recently added disclosure page.

###

Written by Steven Sinofsky

January 21, 2013 at 10:00 am

Posted in posts

Tagged with ,

%d bloggers like this: