Learning by Shipping

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

###