Learning by Shipping

products, development, management…

Posts Tagged ‘management

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.



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?


The key challenge in implementing any policy in a corporation is to balance the needs of the individual, the needs of the team, and the needs of the company and shareholders.  As one might expect these needs are not always in alignment at the granular level.  Even at the macro level it is not always clear, for example, that everyone comes to work to maximize shareholder value on any given day or that choices each party might make to accomplish that would be aligned.

In balancing these needs, a company also has the obligation to be consistent, and have a view as to why an approach is fair for a set of parties involved.  This is about balancing fair across many dimensions—all parts of a company should follow the same basic set of rules/guidelines, rules/guidelines should be the same regardless of your position in the organization or type of role, geography should be implemented consistently (while adhering to local laws as well), and so on.  Nothing eats away at an organization as a whole more than the feeling that one part of a company gets a better deal than another part.  On the other hand when taken down to an individual level what is consistent is not always viewed as fair by some.

One of the main ways companies tend to deal with controversial or cultural issues is to empower managers throughout an organization to “do the right thing” or as it is called in the military “commander’s intent”.   Netflix’s famous expense policy is a supremely good example of this approach (imho).  The basic idea with this approach is that deciding at a top-most level is not optimal and so this approach allows for optimal or situational decision making where the only management communication is based on an end-state not the details (“ship great products and have a strong organization”).  It also tends to optimize for the least amount of consistency across a large organization and thus potentially causes some amount of underground friction.  What is laudable about the Yahoo position is that it is a clear choice from the top of the company, whether you agree with the policy or not you cannot argue that it expresses a clear point of view which is worth noting.


It is extraordinarily difficult to argue against having a flexible workstyle/workforce/team, where flexibility is defined by a whole host of dimensions.  A modern product is used by a whole world of people (hundreds of millions) and there is every reason to consider that a product used so broadly should be developed by a team that is representative of the breadth of usage.  Flexibility in work location is one dimension and the focus of this post and the Yahoo policy (and this post).

People ask for flexibility for a whole variety of reasons: work better from home, required to live far from an office (across the bay to across the country to across the ocean), special needs more easily serviced at a different location, worked on a project full time and needed to move, spouse/family needs (permanent or part time), or even just a feeling that there’s no need to go into an office.  Those are just a few.  In fact the list of motivations for working from home/remote is probably at least as long as the number of people on a team who appreciate this arrangement.

Particularly for software projects, and extra-particularly for modern cloud-based products, it seems almost absurd on the face of it not to build the products from a flexible team.  In fact most of the products even target the very notion of flexible work environments—so the irony of not following that doctrine to build the product is not lost.

So why all the complexity and challenges?

Ultimately there are a bunch of considerations to take into account, none of which is easily reconciled.  The flipside is that all of them can be reconciled in the specific.  Therein rests the core challenge faced by a company—what if everyone says they will do the right thing, yet the net result is not the right thing for the company as a whole?   What if there are a plethora of examples and counter-examples for a given policy?  Everyone who works or supports someone remotely has the very best of intentions.  That’s a given.  Yet there must be more to this given the changes reported at Yahoo (or policies at other companies) and the dialog.

In an effort to spark some dialog, it seems reasonable to offer some of the challenges that a large organization faces with respect to flexible work.  That’s what this post is about, a dialog, and not advocating one point of view or another.  In fact I am writing this post living this very challenge personally right now with geographically dispersed commitments and folks willing to support me in those, and I see some of the issues discussed.

I’ve worked on teams which have been geographically split, where people have worked from sites all around the world, and where individuals have had a wide variety of special arrangements.  It has never been as easy as “just being modern” and there were always extra work required.  And there was always extra benefit as well.  Talented people making world class contributions have worked in flexible arrangements on those projects.  Some worked temporarily.  Some worked permanently.  Some set out to work for a short time or permanently and changed paths.

In almost all cases one or more of the following challenges were or became part of the dialog.

Collaboration.  Software is a highly collaborative process.  To develop software requires collaboration across multiple dimensions.  Programmers need to collaborate up and down the stack, across API boundaries, and more.  These boundaries evolve rapidly while a system is being developed and the evolution does not often take place through code checkin or over email.  Collaboration takes place across disciplines and more often than not those are meetings that take place in person and just as often they are not scheduled.  Developers, testers, program managers, operations, designers, and more need to talk frequently in an ad hoc manner.  Do you tune the amount of flexible work a team supports based on some measure of how much collaboration the product/project requires?  Is it reasonable to assume that the same amount of collaboration can happen between co-located teammates as remote teammates?  How much of collaboration is intrinsically based on proximity?

Disciplines.  One of the challenges is that different disciplines require different levels of collaboration in a typical project or workday.  While every discipline is inherently collaborative, one could (and many do) argue that there are more solitary hours in coding or writing than there might be in design or testing, for example.  There are certainly very few solitary hours in being a manager or being a product/program manager.  Do you have an approach where some disciplines can have more flexible workstyles than others, for example? How does that feel to the rest of the team when motivations for flexible workstyles arise independent of job function?

Integration / consistency.  Customers and reviewers consistently ask for more product integration and better product synergy.  By almost all accounts, the “farther apart” members of a project are the more difficult this integration and consistency becomes.  You can see this even when it comes to internet discussions about org charts or management structures.  The root of this is because consistency and integration come from building highly collaborative give-and-take relationships and those relationships get built and maintained through a great deal of personal contact.  Do you tune the amount of flexible workstyles to support based on the measure of integration you want across products or assign people differently (perhaps differently than their skillsets) based on the needs for integration across products?

Ship the org chart.  A common phrase used in building software from a large organization is to take care to avoid “shipping the org chart”, which basically means to do what you can to structure a team such that the org chart does not show through in developing the product (a subject of a future post, I promise).  Because product development has the potential to evolve differently when people are not in physical proximity there is the potential to mimic what would happen if there was an org design, regardless of the actual line manager.  Despite a long history (and requirement) of remote work, even Boeing is reportedly struggling with this aspect of 787 production at the organizational level.  When organizing a project, do those members of the team working remotely need to be assigned to projects differently to mitigate the org-distance challenges of remote work?

Turnaround to answers.  A big part of a collaborative project is the timeline of asked and answered. Even in the same hallway, you can’t always get an answer from someone (despite the perception, people might not be literally chained to a desk).  So the question becomes what is the turnaround time for an answer.  If a person is working flexibly 40 hours a week during core working hours, then the expected turnaround should be quick (another source of flexibility is what hours, most every company has some notion of core hours, though the days of at your station by 8:00AM like Intel might be history).  On the other hand, some flexible arrangements are 4 days at 10 hours each or even 3 12 hour days (putting aside part time which is another flexible workstyle).  The question then becomes one of whether the team is blocked because it is a flex day?  Of course this is no different than a person being out sick or on vacation, and some say that it is easier to work around a regular schedule.  This challenge extends to teammates in different time zones as well—the further away the less core hours overlap.  Should a team be structured with expectations of turnaround, even if it interferes with the stated goals of flexible workstyles?

Shared mindset / point of view. So much of building a software project is about the emotional connection shared by members of a team.  The feeling of community, shared goals, and culture are all part of a team.  Remote members of a team, by definition will always miss out on elements of this—not just the hallways and meetings, but lunch, voluntary social time, and more.  These are just the nature of human beings and how we build community and evolve.  As much as we talk about video conferencing, air travel, or just “days on site”, we all know the challenges of just picking up where you left off the last time you saw folks.  How does a team continue to develop and evolve a shared point of view with some members of the team not physically present?

Career velocity.  If your organization supports flexible work, then it goes without saying that performance appraisal, compensation, promotion, etc. should all be exactly the same whether you are working remotely or not.  This is obvious, but not without challenges.  For the disciplines that are highly collaborative or projects that are less about individual effort and more about team effort how do you account for the different number of hours spent doing the in-person work these require?  Do you structure remote work so it requires less of this type of collaboration?  Then do you choose people or projects suite to that?  How would you explain the policy regarding approval for remote work?

Peer evaluation.  Most employees participate in a peer review process, both offering and receiving feedback.  In some sense full-time remote employees can benefit from the most pure form of evaluation in that literally only the work is evaluated.  On the other hand, when a large portion of the work involves the process by which choices are made and the way the end-point is reached, the need to participate on equal footing with the team is important to peer feedback.  How does peer evaluation work for the “process” or the “how” of the work not just the output?

Management.  Managing remote teammates or being managed remotely are both challenging.  The more senior you are the less you need (or want!) to interact with your manager, but that is not always a two-way street.  Some managers like a high touch team, especially in some disciplines or some phases of a project.  Some employees do better work when they can talk with their manager for a few minutes in an ad hoc manner.  Newer employees require nearly daily contact/coaching from their manager.  What if the manager is not on site or if the employee is not on site?  Sometimes “new” does not mean new to the workplace, but just new to the project (or a new project) or just new to the domain.  How do you factor in management and being managed into a remote workstyle?

Individual skills.  Most any discussion of remote or flexible work hinges on the individual skills of the person working in this style relative to the needs of the team.  This makes a ton of sense—any team should be staffed and organized taking into account the capabilities of the individuals on the team.  The challenge becomes implementing this in a fair and consistent manner when it comes to remote work.  How do you articulate the criteria for being permitted to work remotely?  How do you avoid any sort of criteria from being gamed or politicized?

Accountability.  Ultimately, any team functions well when accountability is clear and everyone on the team is signed up for their part of the project in terms of delivery, timeliness, and quality.  Remote or not, this should not change.  But projects do not always go well.  When things don’t go well, the team as a whole looks for reasons.  One of the darker aspects of remote work is that it becomes a variable that itself gets evaluated in context of work that was not what everyone (including the member of the team) hoped for.  How do you account for the variable of remote work when things don’t go well?  What happens if you identify working remote as a causal factor?  Is it really a causal factor or just a difference?  Is the accountability of the manager or the remote employee or the team for not working in a way consistent with the remote employee?

Life changes.  Many of the motivations for remote work stem from life changes.  Our society is highly mobile these days and so people choose to move to other cities/countries for a whole variety of reasons.  Housing prices are crushing in much of the world and so commutes can be awful and wasteful.  Spouses also work in most American families and that creates a variety of possible motivations for flexible work.  Families grow and the need for one parent to be at home beyond the statutory parental leave is a strong motivator for flexible work.  Life happens and perhaps someone needing care moves in with you or you yourself require major life adjustments and flexible work becomes necessary.  How do you craft a policy around flexible work that accounts for these life changes that may be temporary or permanent?  Given all of the above potential challenges, what is the right way to address the specifics of life?  Do these life changes call for a separate policy or approach?

These are some examples.  There are many more because there are so many individual circumstances.  All of them can be painted in stark terms with obvious answers if that’s your goal.  The truth is that at a policy level they can all be dealt with.  But at an individual level this always becomes a special case.  That’s just the complexity of a large organization.  It why there is no easy answer and certainly no right answer.  Companies ultimately can choose to differentiate themselves on policies in this regard, as is the case with any workstyle, work culture attribute (dress code, parking, office style), or even compensation or perq.

Proof flexibility works

In any discussion of flexible work, the proof point of large successful open source projects is raised.  In some ways this discussion can bubble up to the difference between developing a product in a company and developing a product that by definition and from the start is distributed in nature.  It goes without saying that arguing against an existing proven success only adds to the difficulty.  Are the challenges of flexible work, some outlined above, due to the very nature of corporate organizations?  Or are the successes of the flexible work in open source projects rooted in the very nature of those projects?

There are also whole companies like 37signals or WordPress that are for-profit and foundationally about remote work.  What practices do they have that make their experiences work for the team, product, or corporate interests?  Are there attributes of the product that make flexible work easier or more supportable?  Is that a design or code architecture difference?


Almost all of challenges described add up to expressing that teams build software.  The larger the software the larger the team.  The need to have a high performance team to build high performance products is obvious.  Building and maintaining a high performance team is an incredibly difficult challenge.  On the one hand the team wants the very best talent from wherever and however it can find it.  On the other hand keeping the team operating in a holistic manner over time is hard enough as it goes through ups and downs of product development.

Whether you argue that a flexible work environment solves the talent side of the challenge or not is just part of the equation.  How to manage the challenge of maintaining the team and product over time is the other side.  As with so many product development and management challenges, knowing the challenge you face is a huge part of the work.  Committing to address the challenges is critical.  Just as critical is deciding where energy on the team is best spent—not every challenge is one the team should take on when faced with finite resources, time, and seemingly infinite business needs.

Product development, including team management, is a social science.  That means there are no right answers but just approaches or choices in context.



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.


Building a software product with more than a couple of people over anything longer than a few months requires some notion of how to coordinate, communicate, and decide.  When you’re working by yourself or on a small enough codebase you can just start typing and what happens is pretty much what you would expect to happen.

Add more people or more time (essentially the same thing) or both and a project quickly changes character.  The left hand does not know what the right hand is doing or more importantly when.  The front and back end are not lining up.  The user experience starts to lack a consistency and coherency.  Fundamentals such as performance, scale, security, privacy are implemented in an uneven fashion.  These are just a natural outcome of projects scaling.

Going as far back as the earliest software projects, practitioners of the art created more formal methods to specify and implement software and become more engineers.  Drawing from more mature engineering processes, these methods were greatly influenced by the physical nature of large scale engineering projects like building planes, bridges or the computers themselves.

As software evolved it became clear to many that the soft part of software engineering could potentially support a much looser approach to engineering.  This coincided with a desire for more software sooner.  Many are familiar with the thesis put forth by Marc Andreessen Why Software is Eating the World (if not, worth a read).  With such an incredible demand for software it is no surprise that many would like projects to get more done in less time and look to a methodological approach to doing so.  The opportunity for reward for building great software as part of a great business is better than ever.  The flexibility of software is a gift engineers in other disciplines would love to have, so there’s every reason to pivot software development around flexibility rather than rigidity.


For this post let’s just narrow the focus to the ends of the spectrum we see in this dialog, though not necessarily in practice.  We’ll call the ends of the spectrum agile and waterfall.

In today’s context, waterfall methods are almost always frowned upon.   Waterfall implies slow, bureaucratic, micro-managed, incremental, removed from customers and markets, and more.  In essence, it feels like if you want to insult a product development effort then just label it with a waterfall approach.

Conversely, agile methods are almost always the positive way to start a project.  Agile implies fast, creative, energetic, disruptive, in-touch with customers and markets, and more.  In essence, if you want to praise a product development effort then just label it with an agile approach.

These are the stereotypical ends of a spectrum.  Anything structured and slow tilts towards waterfall and anything creative and fast tilts towards agile.  At each end there are those that espouse the specifics of how to implement a method.  These implementations include everything from the templates for documents, meeting agendas, roles and responsibilities, and often include specific software tools to support the workflow.

It is worth for a moment looking in a mirror and stereotyping the negative view of agile and the positive view of waterfall, just for completeness.  A waterfall project is thoughtful, architectural, planful, and proceeds from planning to execution to completion like a ballet.  On the other hand, agile projects can substitute chaos and activity for any form of progress—“we ship every week” even if it doesn’t move customers forward and might move them backwards.

Of course these extremes are not universally or necessarily true.  Even defining methodologies can turn into a time sink, so it is better to focus on reality of getting code written, tested, deployed/shipped and not debugging the process for doing so…prematurely.


In practice, no team maintains the character of the ends of this spectrum for very long, if ever.  There is no such thing as a pure waterfall project any more than there is a pure agile project.  In reality, projects have characteristics of both of these endpoints.  The larger or longer a project is the more it becomes a hybrid of both.  Embracing this reality is far better than focusing finite work energy on trying to be a pure expression of a methodology.

In discussions with a bunch of different folks recently I’ve been struck by the zeal at which people describe their projects and offer a contrast (often pointing to me  to talk about waterfall projects!).  One person’s A/B test is another person’s unfinished code in hands of customers.  One person’s architecture for the future is another’s slogging plan.  The challenge with the dialog is how it positions something everyone needs to do as a negative relative to the approach being taken.  Does anyone think you would release code without testing it with a sample of real people?  Does anyone really think that doing something quickly means you always have a poor architecture (or conversely that taking a long time ensures a good architecture)?

We all know the reality is much more subtle.  In fact, like so many product development challenges context is everything.  In the case of development methodologies the context has a number of important variables, for example some include:

  • Skills of team. Your team might be all seasoned and experienced people working in familiar territory.  You might be doing your n-th project together or this might be the n-th time building a similar project or update.  You know how hand-offs between team members work.  You know how to write code that doesn’t break the project.  Fundamentals such as scale, perf, quality are second nature.
  • Number of engineers / size of team.  The more people on a project the more deliberate you will likely need to be.  With a larger team you are going to spend time up front—measure twice, cut once.  The most expensive and time consuming way to build something in software is to keep rebuilding something—lots of motion, no progress. The size of the team is likely to influence the way the development process evolves.  On a larger team, more “tradition” or “convention” will likely be in place to begin with.  Questioning that is good, but also keeping in mind the context of the team is important.  It might feel like a lot of constraints are in place to a newcomer, especially relative to a smaller previous team.  The perspective of top, middle, bottom plays into this–it is likely tops and middles think there is never “enough” and bottoms think “too much”.  On a large team there is likely much less uniformity than any member of the team might think, and this diversity is an important part of large teams.
  • Certainty of project.  You might be working on a project that breaks new ground but in a way that is comfortable for everyone.  This type of product is new to the organization but not new to the industry (for example, a new online store for a company).  Projects like this have a higher degree of certainty about them than when building something new to the industry.
  • Size of code base.  Even with a small number of people, if you happen to have a large code base then you probably need to spend time understanding the implications of changes.  In an existing body of code, research has consistently shown about a 10% regression rate every time you make changes.  And keep in mind that “existing body of code” doesn’t have to mean decade’s old legacy code. It could just mean the brand new code the 5 of you wrote over the past six months but still need to work around.
  • Familiarity of domain.  The team might have a very high degree of familiarity with a domain.  In Dreaming in Code the team was very agile but struggling until they brought in some expertise to assist with the database portion of the project.  This person didn’t require the up-front planning one might think, because of the domain expertise they just dove right in building the require database.  But note, the project had a ton of challenges and so it isn’t clear this was the best plan as discussed in the book.
  • Scale services.  Scaling out an existing service or bringing up a new service for the first time is a big deal.  Whether you’re hosting it yourself or using a service platform, the methods you use to get to that first real world use might be different than those you would use for an app delivered through a store.  The interactions between users, security and privacy, reliability, and so on all have much different profiles when centralized.  Since most new offerings are a combination of apps and services, it is likely the methods will have some differences as well.
  • Realities of business.  Ultimately there is a business goal to a project.  It is easy to say “time to market is everything” and many projects often do.  But there is a balance to competitive dynamics (needing features) and quality goals (no one needs a buggy product) that really dictate what tolerances the marketplace will have for varying levels of quality and features one delivers.  Even the most basic assumption of “continuous updating” needs to be reconciled with business goals (something as straight forward as how to charge for updates to a paid app can have significant business implications for a new company).

The balance with all of these attributes is that they can all be used to justify any methodology.  If the team is junior then maybe more planning is in order.  If the project feels breakthrough then more agility is in order.  Yet as is common with social science, one can easily confuse correlation with causality.  The iPad is well-known to be almost a generation in the making (having started years before the iPhone then shelved).  Facebook is well-known to favor short cycles to get features into testing.  In neither case is it totally clear that one can claim the success of the overall effort is due to the methodology (causal v. correlation).  Rather what makes more sense is to say that within the context of those efforts the methodology is what works for the organization.

We don’t often read about the methodology for projects that do well but not spectacular.  We do read about projects that don’t do well and often we draw a causal relationship between that lack of success and the development methodology.  To me that isn’t quite right—products succeed or fail for a host of reasons.  When a product doesn’t do what the marketplace deems successful, the sequence of steps to build the product are probably pretty low down on the list of causal factors—quality, features, positioning, pricing, and more seem more important.

Many assert that you simply get more done using agile methods (or said another way, waterfall methods get less done) in a period of time, and given the social science nature of our work it is challenging to turn this assertion into a testable hypothesis.  We don’t build the same product twice (say the same way that carpenters know how to frame a house on schedule).  We can’t really measure “amount of work” especially when there can be so much under the hood in software that might not be visible or material for another year or two.

The reality of any project that goes to customers is that a certain amount of work needs to get done.  The methodology dictates the ordering of the work, but doesn’t change the amount of work.  The code needs to be written and tested.  The product needs to work at scale, reliable, secure, accessible, localizable, and more.  The user experience needs to meet the design goals for the product.  Over time the product needs to maintain compatibility relative to expectations—add-ins and customizations need to be maintained for example.

All of this needs to happen.  All of this requires elements of planning, iteration, prototyping, even trial and error.  It also requires a lot of engineering effort in terms of architecture and design.  On any project of scale, some elements of the project are managed with the work detailed up front.  Some elements are best iterated on during the course of the project.  And some can wait until the end where rapid change is not a costly endeavor.

There’s no magic to be had, unfortunately.  You can always do less work, but it doesn’t always take less time once the project starts.  You can’t do more work in less time, even if you add more resources. You can sacrifice quality, polish, details, and more and maybe save some time.  You can plan for a long time but it doesn’t change the amount of time to engineer or the value of real people using the product in real situations.  You can count of fixing things after the product is available to customers, but that doesn’t change the reality of never getting a second chance to make a first impression.  All of this is why product development is so fun—there simply aren’t magic answers.

There are ways to be deliberate in how you approach the challenge.

Checkpoints drive changes

Rather than advocate for a conversion of the whole team to a methodology or debate the best way to do the work, the best bet seems to always be much more organic.  On a small project, ask what would work for each of the team members and just do that.  On a large project, put some bounding principles in place and some supporting tools but manage by results not the process as best you can.

In all cases, the team should establish a rhythm of checkpoints that let everyone know where the project stands relative to goals.  Define a date along with criteria for the project at that date and then do an assessment.  This assessment is honest and transparent.  If things are working then great, just keep going.  If things are not working then that’s a good time to change.  The only failure point you can’t deal with on a project is a failure to be honest as a contributor and honest as a team.  If the dynamic on the team is such that it is better to gloss over or even hide the truth then no methodology will ever yield the results the team needs.

In projects I’ve worked on that have spanned from 3 months to 3 years, the only constants relative to methods are:

  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.


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



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


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.


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: