Learning by Shipping

This post is about a discipline (or sometimes called function-based) org structure.  Like many management “principles”, org structures represent a pendulum that swings back and forth between ends of a spectrum.  In this case the ends are usually characterized as a discipline structure or a product / product line / business structure.  In practice things are more nuanced than these end-of-the-spectrum descriptors.

Some have talked about a discipline org structure as a more modern type of organization than the product line structure.  Given how it mimics historic military structures, as far as management goes, it is probably much older than the “product line” organization often attributed to Alfred Sloan. No matter how new or old, discipline organizations are just one way of compromising on a team structure when you have to pick a way to go—there’s no perfect answer otherwise there would be only one org structure. Context matters.

In our book, One Strategy: organization, planning, and decision making we (co-author Marco Iansiti and I) talk a great deal about the org structure used for the Windows team. The approach was somewhere in the middle of the swinging pendulum between discipline-based and product-based, which was consistent with my own history of the spectrum of choices.  Given the book’s emphasis on this type of structure, it is great to see so much support and enthusiasm for the approaches outlined in recent discussions about organizations.

Org structures might sound like a big company thing, but in spending time with new companies it is clear that the lessons of organization apply to the earliest stages. This post offers some lessons learned from a big organization.  Smaller or new organizations sow the seeds of org structure early on and so these lessons will apply equally to any organization with a complex product architecture, multiple-products, or collaboration required across disciplines.  A great example comes up in the challenges in cross-platform development facing many startups.  Do you organize by platform-specific efforts or do you try to keep the apps together and each team targets multiple platforms?  Early on with one app the choices are easy.  As more apps or different schedules arise, the challenges grow to mimic those in very large organizations.

The reality about org structures is that they rarely cause things to happen—for example, and org structure cannot cause (or prevent) agility.  The work processes or a focus on accountability can impact agility far more.  Org structures cannot cause (or prevent) products from working together as that is a function of a plethora of variables throughout a set of engineers.  Org structures are necessary and can be used to enhance or potentially drown out such attributes, but my experience has been that the causal arrow starts with the details of the work, not the structure of the org which tends to be of a correlation than a causation.

Seams always exist

Some have said that the beauty of a discipline organization is that it removes seams.  Ben Thompson offered some good diagrams of before and after comparing a product organization and a discipline organization.  These are entirely correct within the context of information presented. In practice, however, organizations of any size are more complex than just two dimensions of product or job function.  Each of these attributes is a place you want to find a single approach while making tradeoffs given that you can’t do everything in all possible ways when you’re trying to release one product:

• Product.  It might seem easy to identify a product, but in practice what a product is might be a hardcore technology statement or it might simply be an offering created by the business for business reasons. In My Years with General Motors, Sloan goes into great detail about the creation of product lines and the rationale, which is quite different than the difference between say Search and Android at Google.  GMs product lines were based on a single platform with incremental or even cosmetic differences between essentially identical vehicles (e.g. Trans Am, Firebird, Camaro).  You can define a product as “something people pay for” to yield one approach or you can define a product as “something we build” to yield another approach.
• Geography.  Teams often have people in multiple locations.  This can just be downtown/suburbs, or across the globe.  Sometimes you organize all the people in a geography in one team and other times you place the multiple geographies within the existing structure.  Many studies have shown that the impact on collaboration of even floors of a building can be significant and so the org structure you pick can accentuate the challenges or potentially increase the management burden.
• Sub-disciplines.  At one level you can view a discipline org as engineering, marketing, sales, support or perhaps design, manufacturing, operations or maybe R&D, manufacturing, finance, and so on — these are all high-level views of different disciplines.  Different industries have different high-level job functions.  But within each of those there are functions as well. Marketing is a great example with specialties in inbound marketing, outbound marketing, communications, advertising, research, and more.  If you have multiple products then you need to decide how to staff the next level of function—is that by product or sub-discipline.  The tradeoffs involved can significantly impact the goals one might have in efficiency or agility. So even getting to a shared view of what disciplines are being organized is the first step, and a crucial one since it might result in several layers of management starting at the top.
• Partners or customers.  Delivering a product to a specific set of customers or working with a specific set of partners can often come to define many other attributes of the overall effort.  A product that is tuned to the enterprise might take one approach (to many variables) compared to a product tuned to consumers.  This can impact advertising, features, engineering processes, and more.  Some structures find these variables so important that they come to form a top-level org structure.   There is subtlety and nuance in choosing along these lines since often your best customers or partners have an expectation of senior level people dedicated to their needs.  This can even extend to important customer segments such as education, government, language markets, accessibility, and more.
• Code / architecture. It is quite common to organize a software project’s resources by what amounts to the code architecture.  Engineers understand that and often skills and tools map easily to such a management structure.  One of the most common startup organizations you see is to organize by client app and service back end.  This places the “seam” inside the company to a great degree but also can make for tricky tradeoffs in what gets done and when.  The larger these respective teams become, the more challenging that seam becomes.  Cross-platform, in other words multiple clients of the service team, will confound these challenges to some degree and also create opportunities for seams between the different platform implementations of the apps (organize by multiple app teams each targeting a platform, or by functional areas of code targeting multiple platforms for example). Even the pace of code changes might be different between these two organizations.  Engineering connecting to other disciplines along the code/architecture lines might mean that structure permeates through to support, sales, marketing as well.
• Schedule. By far the most complex variable within an organization is the schedule.  My view is that a schedule defines a team. The project schedule defines everything about how people work, collaborate, and ultimately decide things.  Two people on the same schedule share a world view.  Two people at different parts of a product cycle (start/finish, coding/launching, new project/update) will rarely have the ability to really decide, collaborate, or walk in each other’s shoes.  The more experienced you are the more you understand these different mindsets, but it still doesn’t solve the inherent challenges of being at different stages in a project.  This goes beyond engineering and really is about all the disciplines that need to work together. Marketing focused on a holiday season or sustaining a product while engineering is planning a new product is a great example of this even within a product that calls for a careful balance of accountability and operations.

These are just a few examples of seams that can arise.  Anyone who believes you can use org structures to remove seams just needs to keep making a list of all the ways a product is built, sold, supported, and more—there are seams everywhere.  Ultimately, each of these variable represents a dimension upon which you might choose to build an organization, but you can’t organize around all of them equally and simultaneously, even in the smallest organizations.

Picking an organization is really being clear up front about the various tradeoffs involved.  It might mean letting go of some “motions” or it might mean the result is to put in place process and procedures that can help to avoid mitigate downstream challenges created by a seam.

What’s the upside?

What’s the upside for a discipline organization?  There are three things we talked about quite a bit in the book that led to a conclusion that a (largely) discipline organization is optimal for scaling technology product development:

• Engineering and product development are the high order bit for technology companies.  In tech, tech is what matters most.  Tech rules in a world where the product you built can become not just obsolete but wholly undesirable just a few years after you built it or a product can be disrupted by a competitor seemingly out of the blue.  You want to have the people building things focused on that and the organization needs to lead with technology.  Even in a mature company with global sales, complex pricing and segmentation, demanding installed base, and even with all the pressure to consider all those attributes “up front” you want to have product be top of mind all the time.
• Fewer managers and deeper expertise can only be achieved by discipline.  In practice you want the best developers, designers, or product managers you can find.  It turns out that those people like to be surrounded by others like them.  You don’t often find a lot of world class developers who want to work for marketing (or vice versa) and in particular you definitely can’t hire a lot of folks out of college who can work for (or be successfully managed by) someone who has not walked in their shoes (or preferably is still walking in their shoes).  Everyone knows and respects the other perspectives and skills to deliver an entire product (so this is not about a hierarchy of roles), but when it comes to day-in-day-out surroundings, focusing on discipline expertise yields the best discipline efforts.  Our measure in the book is literally, how far up the org chart do you go before you get to someone who never did your job (literally), regardless of the job discipline.  Mathematically in any other structure, you will significantly increase the number of managers you have when you push down the responsibility for managing multiple disciplines—and by any study or any measure the more managers you have the worse off you are to some level of optimization.  This comes from needing people to bring together multiple disciplines at more places in a structure.  More general management also means just more management in general.
• In practice, in a large global organization you cannot really organize by “business”.  In the General Motors examples you can really see this challenge.  While there were businesses or product lines that really evolved out of a shared “platform”, the reality is that the product line leaders did not get to create new platforms or even have control of many of the resources one might assume were part of a business.  There was always a lot of tension over the platform choices given the number of businesses that depended on the platform capabilities.  Even manufacturing was not completely isolated across product lines (for example there is only one UAW to negotiate with).  There was obviously a spectrum of just how far the business/product line went.  But once you have a global organization, overlaying geography means you usually have the geography dominate the org—it means the people in France work for a person in France, no matter what the discipline organization looks like.  Not only does this reduce the notion of a “product” but it by definition implies there will be managers making decisions across disciplines and products outside the role of the product leader. So the upside of a discipline organization is it removes the illusion of “owning a business” which is a fairly liberating construct as we talked about in the posts in the book when it comes to making product choices.  Even companies that have large teams of manufacturing, sales, marketing, human resources, or more will generally centralize these disciplines and with that comes a reduced view of “the business”.

Some lessons learned

Even with the positives of a discipline organization there are also limitations and “gotchas” that exist.  No system is perfect or universal which is why a combination of methods is something we talked about in the book and put into practice.  The following are some lessons learned and considerations to take into account with a discipline styled tech organization:

Ship dates matter.  The most critical element of collaborating across products/teams/groups/people is the schedule and the integrity of the schedule.  Two entities working together are (essentially infinitely) more effective if they share the same schedule, same schedule vocabulary, and same schedule rigor.  Imagine one group that “depends” on another group.  The first group is planning their new work—the sky’s the limit, the schedule is XYZ, and all is great.  The second group is trying to finish, bug counts are high, known work items exceed allocated time, and resources are tight.  The first group shows up and says “we have some ideas and if we could just work on this together we could have an amazing set of scenarios for customers”.  If you’ve ever been the second group you know how this feels—this is just another thing you can’t get done, you’re degrees of freedom are zero.  You have a choice of saying “of course” knowing you can’t get the work done or of saying “no way” and looking like a jerk.  You can try to help design something now, but that always takes the critical path resources.  Nothing in this dialog ends well for anyone.  Meanwhile the first group is seeing their dreams shattered for lack of collaboration—even though they were just at the idea stage.  Whether you ship every month, year, or decade if you’re looking to work in deep integration that crosses your code bases, then doing so at the same time, with the same schedule is a great tool.  This is a lot trickier than it sounds because different products have different ways to schedule (service deployment, hardware ranging, partner bring up, and more all have different schedule “tails”).  Products can have different deadlines as well as dictated by their channel strategies (shipping for holiday means one thing for hardware, another thing for software delivered to hardware partners, and another thing for enterprise products).

Discipline expertise is everything.  In any team size, but particularly in very small and very large organizations there can be a tendency for “jack of all trades” efforts.  This is where people think or act as experts in a variety of disciplines—engineering crossing over into marketing, marketing crossing over into product management, sales crossing over into support, (or one level down where outbound marketing crosses into advertising, etc.).  The reality is that if you’re going to execute along discipline lines then you really want to respect the skills and abilities of those lines.  It turns out this is often the most difficult thing to pull off in a discipline organization.  Something as “simple” as pricing or advertising, clearly marketing responsibilities, are almost trivial for everyone to have an opinion on, especially the more senior they get (we all buy stuff).  A lot of time can be spent by the discipline experts working to get buy-in from parts of the team that probably have enough to worry about.  The essence of this, which is a big part of our book, is not supporting the culture of escalation—that is making sure management does not allow decisions to percolate up the org structure just because of the desire to get buy-in across the different disciplines or because the choices involve other parts of the organization.  Things should be decided closest to the work and decisions should be made within the context of accountability by disciplines in this structure, and those people are responsible for a global view of the issues and challenges.

Org depth and span are critical. The biggest balancing act in orgs of more than about 100 people is to figure out how many managers to have.  At one extreme you have one engineering manager with like 80 reports.  At the other extreme you can end up with I-formations where managers have one direct report.  Neither is particularly healthy.  When you scale up a discipline organization you are also battling the depth of the org tree for the discipline.  While it is very cool to count up 3 or 4 levels and see an engineer, counting up 7 or 8 can get daunting because at that depth it means, ironically, engineering details might be discussed very high up in the org and you might worry those impact you.  So in a sense, adding a seam of general management is somewhat comforting in that it gives you a clear place where your work “ends”.  The other side of this balancing act is how many reports a manager has.  You want this to be a number such that as high up the org as you can get managers “do work”.  In our book, we talked a bunch about the notion of a “pure manager” which was a phrase that drove me bonkers—in the tech part of a tech company you want as few people as possible who do nothing but manage (work or people).  Numerically, our view is that even with managing upwards of 50 people a dev manager should be contributing actual shipping code to a product routinely.  The more people in a function you have the more you have to figure out where the “no work” seam is, and then take that into account when it comes to deciding things at that level.

Collaboration starts at staff meetings at all levels. At first we all tend to reject meetings of any sort as Dilbert-eseque exercises, when meetings are really an integral part of collaboration (see http://www.slate.com/articles/news_and_politics/readme/2002/04/an_ode_to_managers.html).  In orgs of any size there are two kinds of regularly scheduled “rhythm” meetings.  Looking at engineering as an example, first there is the meeting of all the devs working on an area that goes through the schedule and the details of the implementation.  I would describe this as a dev lead and 5-7 individual contributors working on a feature area.  Second, is a meeting of the sub-disciplines of engineering focused on dev, test, product management, design, operations where the focus is on the complete picture of where the project stands.  Some might do this differently—for example just 1:1s plus the sub-disciplines.  One level up this meeting looks like everyone working in development on a large area, and the sub-discipline leaders for all those areas.  At some point the cross-discipline meeting turns into large functional areas of engineering, marketing, etc.  The most critical thing about the meetings that cross (sub-) disciplines is that everyone needs to be working on the same thing and have the same understanding of what is going on.  In other words, it turns out that staff meetings will naturally be effective tools for collaboration if folks are all working on the same product, schedule, architecture, partnerships and more.  Once someone in the meeting has a different part of the seam or someone is managing a portfolio of products, they will necessarily be working at a level of abstraction that is challenging to make commitments, know the details of issues, or otherwise actually decide things.  This is always a scaling challenge.  Historically, it is what has led me to appreciate a mixed model of org structure so it tends to reduce the number of “product portfolios”.  Said another way, a single manager who sees seams in his/her management domain (i.e. code bases, geographies, products) will naturally (necessarily?) tend to organize their teams along those lines and essentially “break” the discipline model.

One final thought on lessons learned, and that has to do with the reality of how and where work gets done in an organization of any size.  It is really critical to view an organization from the bottom up—that is how things are really done.  In a tech product, features you can see as a human in a product are usually done by a very small number of people.  Those people work together day and night and all the time.  From their perspective they would love to have the same manager, sit next to each other, and otherwise not have to work with other people.  From their perspective, anything less is less than optimal.  Yet at any scale, this just isn’t practical as tradeoffs need to be made (even in something as simple as how far you have to walk to you coworkers).  Being able to articulate a clear understanding of how the work gets done, what expectations there are for cross-group work, and why things will be neither gummed up nor designed by a committee “up in the clouds” are all important questions and lessons learned.

In reference to how work gets done, one challenge I’ve experienced has been the proponents of agile methods who almost by definition did not appreciate a discipline-oriented organization.  The root of those methods is to have all those working on something together in org structure, physical proximity, and management—yet the physics of org structures don’t make it possible to solve exclusively for that.  Imagine proposing an org structure that to some argued against being agile.

That’s why context matters so much and there is not a prescriptive answer to the best or ideal org structure.

–Steven