Posts Tagged ‘organization’
That First Sales or Marketing Hire
One of the biggest changes for an early-stage and growing company is when hiring transitions from technical/product founders to the first sales or marketing hires. It is an exciting time of course but also one that can be very stressful. As much as that can be the case, there are a few patterns and practices one can follow to successfully cross that chasm or at the very least reduce the risk to the same as any technical hire.
It goes without saying that the challenge is rooted in learning how to recognize and evaluate talented people that possess talents and skills that you do not have and really can’t relate to from an experience level. Quite a few roles in companies are going to be “close” or adjacent to your own skill set, speaking from the perspective of a technical founder. If you’re an engineer then QA or product management aren’t far off from what you do on a daily basis. If you tilt towards product management, you’re interactions with designers are perfectly natural. In fact for technical founders the spectrum from design to product management to engineering and then QA all feel like your wheelhouse.
Branching out further to sales, marketing, communications, business development, customer service, operations, supply chain, manufacturing, finance, and more can get uncomfortable very quickly. I remember the first time I had to interview a marketing person and I realized I didn’t even know what questions I should ask to do the interview. Yet, I had worked with marketing closely for many years. Fortunately, I had a candidate pipeline and an interview loop of experienced interviewers to draw from. That’s not alway the case with a startup’s first hires.
The following are four challenges worth considering and a step you can take to mitigate the challenges if you find yourself in this spot.
Look only within your network. When sourcing your first potential sales or marketing hire, you might tend to tap into your network the same way you would for an engineering hire. You might have a very broad network but it might not be a first person network. For example with engineering you might know people from the same school program or projects you worked on or are deeply familiar with. But with sales and marketing you probably lack that much common context and your network might reflect people you came across with in work or projects, but not necessarily worked with in the same way you would have with technical hires. You might be worried about taking too much time to source candidates or concerned that you will burn a lot of time on introductions and people you don’t “know” well. Approach. The first step in a breakthrough hire process is to make sure you cast a wide net and tap into other networks. This process itself is an investment in the future as you will broaden your network in a new domain.
Define the job by way you know from the outside. Walk a mile in other’s shoes is an age-old expression and is very fitting for your first sales or marketing hire. Your initial job description for a job you never done might be taken from another company or might be based on your view of what the job needs to get done. The challenge is that your view of what needs to get done is informed by your own “outsider” view of what a job you haven’t done before might mean. Being a sales or marketing person is vastly different from what it looks like from the outside, looking in. If you haven’t done the job you tend to think of the job through the lens of outputs rather than the journey from input to output. Most jobs are icebergs and the real work is the 90% under water. Until you’ve watched and worked with an enterprise sale end to end or developed and executed on a consumer go to market plan, your view of what the job looks like might be a sales presentation or SEO. Getting to those deliverables is a whole different set of motions. Approach. Find a way to have a few “what do you do” conversations with senior people in the job function. Maybe take some time to ask them to define for you what they think the steps would be to get to the outcome you are looking for, rather than to discuss the outcome. These “what would it take” conversations will help you to craft a skills assessment and talent fit.
Hire too senior or too junior. Gauging the seniority of a candidate and matching that to the requirement for the role are often quite tricky early on. In the conversations I’ve had I tend to see founders head to one extreme or another. Some founders take the outcome or deliverable they might want (white paper, quota) and work backwards to find a hire to “execute” on that. Some take the other extreme and act on the basis of not knowing so bringing in a senior person to build out the whole system. The reality is that for a new company you often are best off with someone in the middle. Why is that? If you hire to too junior the person will need supervision on a whole range of details you haven’t done before. This gets back to defining the job based on what you know—your solution set will be informed only by the experience you have had. If you hire someone too senior then they will immediately want to hire in the next round of management. You will quickly find that one hire translates into three and you’re scaling faster than you’re growing. I once talked to a company that was under ten engineers and hired a very senior marketing leader with domain experience who then subsequently spent $200K on consulting to develop a “marketing plan”. Yikes. Approach. Building on the knowledge you gained by casting a wide net and by taking the time to learn the full scope of work required, aim for the right level of hire that will “do the work” while “scaling the team”.
Base feedback on too small a circle. Once you have a robust job description and candidate flow and ways to evaluate, it is not uncommon to “fall back” on a small circle of people to get feedback on and evaluate the candidate. You might not want to take up time of too many people or you might think that it is tricky for too many people to evaluate a candidate. At the other end you might want these first hires to be a consensus based choice among a group that collectively is still learning these multi-disciplinary ropes. Culture fit is always a huge part of hiring, especially early on, but you’re also concerned about bringing in a whole new culture (a “sales culture” or “business culture”) and that contributes to the desire to keep things contained. Approach. Getting feedback from at least one trusted senior person with experience and success making these specific hires is critical. You can tap into your board or investors or network, but be sure to lean on those supporting you for some validation and verification.
One interesting note is that these challenges and approaches aren’t unique to startups. It turns out these follow similar patterns in large companies as well as you rise from engineering/product to business or general management. While you might think in a big company the support network insulates you from these challenges, I’ve seen (and experienced personally) all of the above.
The first sales or marketing hires can be pretty stressful for any technologist. Branching out to hire and manage those that rely more than you on the other side of their brain is a big opportunity for growth and development not only for the company but for you personally. It is a great time to step back and seek out support, advice, and counsel.
Hiring for a job you never did or can’t do
One of the most difficult stages in growing your own skillset is when you have to hire someone for a job you can’t actually do yourself. Whether you’re a founder of a new company, or just growing a company or team, at some point the skills needed for a growing organization exceed your own experience.
Admitting that you don’t really have the skills the business requires is the first, and most difficult step. This is especially true as an engineer where there’s a tendency to think we can just figure things out. It is not uncommon to go through a thought process that basically boils down to: coding must be the hardest job, so all the other jobs can be done by someone with coding skills.
Fight the fear, let go of control, and make moves towards a well-rounded organization.
Nice try.
If you’ve ever tried some simple home repairs or paint touchup you know this logic doesn’t work—you only need to spend an hour watching some cable TV DiY show and you can see how the people with skills are always unraveling the messes created by those who thought they could improvise. The software equivalent can sometimes be seen as a developer attempting to design the user interaction flow in a paint program or PowerPoint. Sure it can be done by a developer (and there are talented developers who can of course do it all), but he or she can quickly reach their limits, and so will the user interaction.
Open up your engineer’s mind to embrace the truth that every other discipline or function you will ever collaborate with has a deep set of skills experiences that you lack. Relative to engineering, the “softer” skills often pose the biggest eye-opening surprise to engineers. Until you’ve seen the magic worked by those skilled in marketing, communications, sales, business development or a host of other disciplines you might not appreciate the levels of success you can achieve by turning over the task to trained professionals.
I have seen this first-hand many times. Most recently it occurred while working with the a16z portfolio company Local Motion when it came time to do some of the early announcements around the fleet-management company. The co-founders possess engineering and design backgrounds from elite institutions, and built the product themselves, hardware and software. Both are experienced mountaineers, and so they have this engrained sense of self-sufficiency, which is valuable both for building companies and scaling mountains.
When it came time to work with the industry press to tell the story of their company, in some ways they had to suppress their self-sufficient instincts. The founders were self-aware enough to know they had not done this before and agreed to enlist the help of those who have depth and breadth of experience. The pros showed up and spent time learning the team, the business, and the story (professionals do that!). They came back with a plan, roles, responsibilities, and defined what success would look like. It was amazing to watch how the founders absorbed and learned at each step all those things which they had not personally experienced before.
This sounds easy and pretty obvious. But if you put yourself in their shoes you know that this is not just bringing in a hired gun to get some press, rather this is hiring on a new member of the team and a new founding member of the family. What is vital to keep in mind, is that this kind of work is as important as every line of code and every circuit board. The lesson of letting go and letting professionals do their work is clear: delegating is never easy for most, but is spectacularly difficult if you don’t know what the other person is going to do and when the outcome matters a whole lot. Still, you need to let the specialists into your carefully engineered world.
There are moments of terror. You’re watching people talk about your product using tools and techniques you are unfamiliar with to connect with your potential customers. Even though it is a product, you are apt to feel as though this is a discussion about yourself. You question every step. You doubt the skills of the person you hired. You are certain everything will go wrong.
It is at that point—right when you start to panic and think that unless you do this yourself things will fail—that you need to let go. You need to say “yes” to hiring a person to do the work, and then let them do their best work.
Just keep reminding yourself that you’ve never done the job before, and that you’re role is to hire someone who knows more than you. Even when you’ve wrapped your head around that, there are a few ways you can get tripped up when you are The key to success here is avoiding these mistakes when you are in the hiring process:
- Asking candidates to teach you. A good candidate will of course know more than you. Their interview is not a time for them to teach you what they do for a living. The interview is for you to learn the specifics of a given candidate, not the job function. The best bet is to do your homework. If you’re hiring your first sales leader then use your network and talk to some subject matter experts and learn the steps of the role ahead of time.
- Expecting a candidate to know or create your strategy. It is fine to expect engineering candidates to know the tools and techniques you use. You wouldn’t expect an engineering candidate to know your unannounced product, of course. It is equally challenging to expect a new marketing person to have a marketing plan for your product. Even if you ask them to brainstorm for hours, keep in mind the inputs into the process—they only know the specifics you have provided them. For example, don’t expect a marketing candidate to magically come up with the right pricing strategy for your product without a chance to really dive in. On the other hand, you can expect a candidate to walk you through in extreme detail their most recent work on a similar topic. You can get to their thought process and how they worked through the details of the problem domain.
- Interviewing too many folks. You will always hear stories about the best hire ever after seeing 100 people. Those stories are legendary. On the other hand, you rarely hear the stories that start with “we could not find the perfect QA leader so we waited and waited until we had a quality crisis.” Yet these latter stories happen far too often. Again, you should not compromise, but if after bringing a dozen or more people through a process you are still searching, consider the patterns you’re seeing and why this is happening. A good practice if you’ve not found right hire after going through a lot of folks is to bring in a new point of view. Consider recruiting the help of a search firm, a board member, or a subject matter advisor to get you over the first hire in a new job function. Do you need the help of a search firm? Would you benefit from the help of a board member or subject matter advisor to get you over the first hire in a new job function?
These add up to the quest for the perfect hire. When it comes to engineering you give yourself a lot of leeway because you feel you can direct a less experienced person and because you can gauge more easily what they know and don’t know. When it comes to other roles you become more reluctant to let go of a dream candidate. This almost always nets out costing you time, and in a new effort time is money. That isn’t saying to settle, but it is saying to use the same techniques of approximation you naturally use when hiring people in your comfort zone.
The most difficult part of hiring for a job you don’t know first-hand is the human side. Every growing organization needs diversity because every product and service is used by a diverse group of people. The different job functions often bring with them diversity of personality types that add to the challenges of hiring. The highly analytical developer looking to hire a strong qualitative thinker for marketing, or the highly empathetic sales leader, is often going to face a challenge just making the human connection.
This human connection is a two-way street. Embrace it. Recognize the leap each of you are taking. Realize that the interpersonal skills required to call on customers every day are just different than the interpersonal skills used when hacking. The challenge of making that human connection is one for the person doing the hiring to overcome. Often that’s the biggest opportunity for personal growth when hiring people to do a job you can’t.
–Steven Sinofsky (@stevesi)
Note: A form of this post originally appeared on FastCo.
Coding through silos (5 tips on sharing code)
We are trying to change a culture of compartmentalized, start-from-scratch style development here. I’m curious if there are any good examples of Enterprise “Open Source” that we can learn from.
—Question from reader with a strong history in engineering management
When starting a new product line or dealing with multiple existing products, there’s always a question about how to share code. Even the most ardent open source developers know the challenges of sharing code—it is easy to pick up a library of “done” code, not so hard to share something that you can snapshot, but remarkably difficult to share code that is also moving at a high velocity like your work.
Developers love to talk about sharing code probably much more than they love to share code in practice. Yet, sharing code happens all the time—everyone uses an OS, web server, programming languages, and more that are all shared code. Where it gets tricky is when the shared code is an integral part of the product you’re developing. That’s when shared code goes from “fastest way to get moving” to “a potential (difficult) constraint” or to “likely a critical path”. Ironically, this is usually more true inside of a single company where one team needs to “depend” on another team for shared code than it is on developers sharing code from outside the company.
Organizationally, sharing code takes on varying degrees of difficulty depending on the “org distance” between developers. For example, two developers working for the same manager don’t even think about “sharing code” as much as they think about “working together”. At the other end of the spectrum, developers on different products with different code bases (perhaps started at different times with early thoughts that the products were unrelated or maybe one code base was acquired) think naturally about shipping their code base and working on their product first and foremost.
This latter case is often viewed as an organizational silo—a team of engineering, testing, product, operations, design, and perhaps even separate marketing or P&L responsibility. This might be the preferred org design (focus on business agility) or it might be because of intrinsic org structures (like geography, history, leadership approach). The larger these types of organizations the more the “needs of the org” tend to trump the “needs of the code”.
Let’s assume everyone is well-meaning and would share code, but it just isn’t happening organically. What are 5 things the team overall can do?
-
Ship together. The most straight-forward attribute two teams can modify in order to effectively share code is to have a release/ship schedule that is aligned. Sharing code is the most difficult when one team is locked down and the other team is just getting started. Things get progressively easier the closer to aligned each team becomes. Even on very short cycles of 30-60 days, the difference in mindset about what code can change and how can quickly grow to be a share-stopper. Even when creating a new product alongside an existing product, picking a scheduling milestone that is aligned can be remarkably helpful in encouraging sharing rather than a “new product silo” which only digs a future hole that will need to be filled.
-
Organize together to engineer together. If you’re looking at trying to share code across engineering organizations that have an org distance that involves general management, revenue or P&L, or different products, then there’s an opportunity to use organization approaches to share code. When one engineering manager can look at a shared code challenge across all of his/her responsibilities there more of a chance that an engineering leader will see this as an opportunity rather than a tax/burden. The dialog about efficacy or reality of sharing code does not span managers or importantly disciplines, and the resulting accountability rests within straight-forward engineering functions. This approach has limits (the graph theory of org size as well as the challenges of organizing substantially different products together).
-
Allocate resources for sharing. A large organization that has enough resources to duplicate code turns out to be the biggest barrier to sharing code. If there’s a desire to share code, especially if this means re-architecting something that works (to replace it with some shared code, presumably with a mutual benefit) then the larger team has a built-in mechanism to avoid the shared code tax. As painful as it sounds, the most straight-forward approach to addressing this challenge is to allocate resources such that a team doesn’t really have the option to just duplicate code. This approach often works best when combined with organizing together, since one engineering manager can simply load balance the projects more effectively. But even across silos, careful attention (and transparency) to how engineering resources are spent will often make this approach attainable.
-
Establish provider/consumer relationships. Often shared code can look like a “shared code library” that needs to be developed. It is quite common and can be quite effective to form a separate team, a provider, that exists entirely to provide code to other parts of the company, a consumer. The consumer team will tend to look at the provider team as an extension to their team and all can work well. On the other hand, there are almost always multiple consumers (otherwise the code isn’t really shared) and then the challenges of which team to serve and when (and where requirements might come from) all surface. Groups dedicated to being the producers of shared code can work, but they can quickly take on the characteristics of yet another silo in the company. Resource allocation and schedules are often quite challenging with a priori shared code groups.
-
Avoid the technical buzz-saw. Developers given a goal to share code and a desire to avoid doing so will often resort to a drawn-out analysis phase of the code and/or team. This will be thoughtful and high-integrity. But one person’s approach to being thorough can also look to another as a delay or avoidance tactic. No matter how genuine the analysis might be, the reality is that it can come across as a technical buzz-saw making all but the most idealized code sharing impossible. My own experience has been that simply avoiding this process is best—a bake-off or ongoing suitability-to-task discussion will only drive a wedge between teams. At some level sharing code is a leap of faith that a lot of folks need to take and when it works everyone is happy and if it doesn’t there’s a good chance someone is likely to say “told you so”. Most every bet one makes in engineering has skeptics. Spending some effort to hear out the skeptics is critical. A winners/losers process is almost always a negative for all involved.
The common thread about all of these is that they all seem impossible at first. As with any initiative, there’s a non-zero cost to obtaining goals that require behavior change. If sharing code is important and not happening, there’s a good chance you’re working against some of the existing constraints in the approach. Smart and empowered teams act with the best intentions to balance a seemingly endless set of inbound issues and constraints, and shared code might just be one of those things that doesn’t make the cut.
Keeping in mind that at any given time an engineering organization is probably overloaded and at capacity just getting stuff done, there’s not a lot of room to just overlay new goals.
Sharing code is like sharing any other aspect of a larger team—from best practices in tools, engineering approaches, team management—things don’t happen organically unless there’s a uniform benefit across teams. The role of management is to put in place the right constraints that benefit the overall goals without compromising other goals. This effort requires ongoing monitoring and feedback to make sure the right balance is achieved.
For those interested in some history, this is a Harvard Business School case on the very early Office (paid article) team and the challenges/questions around organizing around a set of related products (hint, this only seems relatively straight-forward in hindsight).
—Steven
Lessons from org structures
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
Reaching for harmony in org changes
Reorgs are a part of an organization of any size. As business changes, development teams resize, code evolves, or products pivot, the organization can and should change as well. Given the frequency and challenges of reorgs it is worth looking a bit at the complexity, rationale and some challenges of reorganization. While the first reaction to a reorg could range from a sigh of relief to groan or worse, the most important thing is to keep calm and make sure the work continues.
Be sure to take our three question survey on reorgs after reading this post, here (https://www.surveymonkey.com/s/WS8TNMP) and to check out survey results below from the last survey about “Meeting effectively”.
A first-year MBA student I recently met took the occasion of a reorg as time to career pivot and attend business school, which motivated this post.
Reorgs (this post is about structural and management changes, not changes in staffing levels) are sometimes a popular topic in blogs where they take on a certain level of drama or mystique (for example, some blogs talk about org changes as solutions to perceived design challenges). Lacking context, some tend to see reorgs as either the solution to or the cause of a change in strategy or execution. That itself can be the source of reorg angst. In practice, a reorg should be the outcome of a strategic decision not the decision itself-—reorgs don’t cause change or things to happen, but are (hopefully) a better way to execute on strategic changes that have been decided upon.
Reorgs can be a natural way to make sure a team is aligned to deliver on a strategy and a tool to allocate resources effectively towards a shared product plan. When done well, reorgs go from something that happens to you to something that happens with and for you, even if things don’t always feel that way for every member of the team at the start. At the same time, reorgs are enormously challenging by their very nature–organizations are never perfect and there can always be unpredictable outcomes as members of the team implement org changes.
I’ve been part of and executed a few “big” reorgs and always find them incredibly challenging, humbling, stressful, and much more work than is often expected. That’s why I tend to view reorgs as a tool of final resort rather than a tool to routinely drive change, which was something discussed on another blog a while back (and motivated this post). Executing a reorg involves doing everything you can to “precompute” actions, reactions, and further reactions as best you can while also compensating for them in the plan.
Reorgs are complex and can be thought of from many perspectives. As blunt as they might sometimes seem, there is a great deal of subtlety and nuance to reorgs. While we’re focused on product development organizations, the concepts and implications of reorgs are a pretty general topic.
Reaching for harmony is something to strive for in any organizational change.
Do keep in mind, like so many things in the social science of business, organization and reorganization context dependent—there’s no right or wrong outside the context being discussed. By definition, reorgs are forward looking and so past history might not always be the best guide.
Perspective and context
Discussing a (potential) reorg can stretch many in an organization. Much like the group describing an elephant, a reorg can mean very different things to different people. A good way to think of things is to refer to a well-known description of organization dynamics that is often used in training classes: tops, middles, bottoms. We’ll return to this often in this blog as it is always a good reminder of patterns and practices that one can generally (emphasis on generally) see repeated.
Bottoms are the folks that do the work. Of course this is an awful moniker, but is the one chosen in the original work (See http://www.powerandsystems.com/resources-a-thought-starters/books/the-possibilities-of-organization.html). Bottoms also make up the bulk of an organization. In a typical, large, development organization (>100) you usually need fewer than 20% of the team middles and tops, which means more than 80% of your resources are bottoms. Whenever possible, you probably want to be better than that (meaning fewer managers, though one should caution a metric like this should not be abused as a scorecard goal as context matters).
Middles are the line managers in an organization. Middles are where the work and collaboration get defined, where friction is either created or eliminated in getting work done, and where information can flow freely or stop. Healthy middles are an essential part of any organization. It is why practices such as skip-level 1:1s, communication that goes broadly to the middles, and shared view of plans are all such critical tools in a product team-—those are the tools of middles managing up and across a team (emphasis on helping the middles, not the middles helping the tops, which is a common dysfunction). Middles can also be tops. For example, if you are the most senior developer in an organization and your manager is not a developer then when it comes to development stuff you are a top.
Tops are the big bosses in an organization. The top is where a certain organization function “ends”. You can be the boss of product design, the boss of the test schedule, the boss of marketing, or (but not necessarily) the boss of the whole organization or company. It is worth noting that nearly all tops are also middles at some point. It just depends on the context. CEOs are middles relative to the board (and also Customers). Your VP is a middle relative to the CEO even if you don’t think of him/her as a middle.
To be complete, the framework also includes Customers. Their role in will be touched on later in the post.
I would encourage folks to check out this framework and book just because it succinctly sums up many of the core challenges within an organization. While there are many insights and many specifics to teams, a key understanding is that members of a team should do far more to understand each other’s context (and problems) than they do in practice during times of change–simply walk in each other’s shoes. Of course this is blindingly obvious, yet terribly difficult for even the best folks on a team. For example:
- Tops should sometimes spend less time worrying about their big strategic views and needs and consider how their choices (based on those needs) can ripple through an organization and impact execution. Tops would do well to listen more (see this great discussion of 1:1s from Ben Horowitz) and perhaps worry less about what is on their mind.
- Middles might spend more time talking to other middles and sharing what they are actually doing, what are their real execution issues, and how they are really progressing. All too often middles get caught up communicating idealized situations and plans which can cause confusion, misplaced bets, or just poor choices in other parts of a team and organization. Middles might spend too much energy on describing problems rather than solutions, or even trying to account for things not going well. Middles can spend more time informing their tops about what is going on, but that also depends on tops spending time listening or asking to be informed.
- Bottoms might also spend more time listening or asking questions and a little less time feeling like “victims”. It is easy when middles and tops are communicating poorly to assume the worst or to assume folks don’t know what is going on. It is equally challenging if the communication that does take place is not taken advantage of, so more listening here can be beneficial as well.
If you think about these typical patterns (remember, this is a generalized sociology framework not a description of your team/behavior), one can see how any discussion of reorgs can quickly degrade. In fact, few things tap into the typical patterns of this behavior framework better than a reorg. Why is that?
Reorgs, by definition, are usually kicked off by the tops. So out of the gate the assumptions that go into making an org change are from a top perspective. The biggest changes in a reorg generally affect the middles since work is reassigned, people’s responsibility changes, and so on. Middles have a tendency to view reorgs at the extreme of “whatever” or “oh my gosh this is really messed up” — as a middle so much of your role depends on context, connections, and structure changes can significantly impact execution.
For the bottoms, a reorg can appear like a bunch of people rearranging deck chairs on the Titanic since ultimately the organization doesn’t really change all the work of individuals (much of the same code still needs to get written, tested, maintained and changing the people with that expertise seems the opposite of progress). Throughout the process, communication is less than and often later than many would like or expect.
The process of a reorganization is one where perspectives of each on the team need to come together to define the problem, scope the alternatives, and implement the solution. Absent these steps a reorg goes from a potential solution to a certain problem.
Why reorg?
There are many reasons for doing an org change. In fact, the most important first step of a reorg is to be able to articulate to those who ask why you might do a reorg.
It is often in this very first step where most reorgs hit a snag. The reason is because the tops have a set of reasons in their context about what a change is for and what it will accomplish and then quickly find out others don’t share the perspective (or problems) or view it as incomplete. Yet the process often continues.
For the tops, this can be a real pain or just frustrating and worse it can bring out the worst of bottoms and middles in terms of how they dig in their heels and get defensive about the change. They begin to immediately dispense the reasons why a reorg won’t work and the bottoms pick up on these and start to feel like victims. All the while the process keeps moving forward.
Reorgs are typically instituted for a pretty common set of reasons, some of which on their own can cause people to retreat to a defensive or cynical state of mind. Some common drivers include:
- Resource efficiency. The role of management is to effectively allocate resources and in fact is really often the only tool management has. As a product and team evolve, resource allocations that seemed perfect at one point can seem less than optimal. An organization change has the potential to allocate resources more effectively towards the problems as they are today.
- Duplication of efforts. In any organization of size, over time efforts will start to converge or overlap. This is especially true in technology companies. This can be at a very visible level, for example if many groups are working on basic tools for editing photos or user names. This can also be at an infrastructure level such as how many teams have people buying servers or running labs.
- Individual bandwidth. Sometimes teams or responsibility grow and the management of the work becomes too challenging or individuals are spread across multiple projects too frequently. Managers at any level can systematically have too many direct reports, for example. Alternatively, the product line can change or evolve over time and folks on the team find themselves context switching between somewhat unrelated projects more than actually managing. This lack of bandwidth becomes a problem for the team overall as everyone evolves to having more overhead than work.
- Structural challenges. Organizations evolve over time in a way that suits the time, problem space, and skills. Sometimes when you take a step back, the current state ends up being suboptimal going forward. The alignment of resources, decision making, even core roles and responsibilities are not yielding the results. More often than not, this type organizational pain is felt broadly by the team or by customers.
- Synergy / Strategy. The notion of increased synergy or strategic change generally drives the most challenging of org changes. Many are familiar with these challenges-—the effort to move large blocks of work in sort of an architectural view. Motivation is this sort often is about “proximity” or “relationship” and has the feel of architecting a product except it is about the team that builds the product. There’s a tendency to create “portfolios” of products and teams when organizing along these lines.
- Alignment. Alignment is slightly different than synergy/strategy in that it speaks to how the organization should be viewed moving forward. A long time ago, for example, the Office team at Microsoft shifted from building Office “apps” to building the Office “suite”. Alignment also could include many mechanical elements of businesses/products like customer definition, business models, ship dates, and so on.
Even though these have the potential to sound Dilbert-esque, the reality is that when problems are identified that most people on a team share, then these can form the basis of not just a useful reorganization but a reorg that people want to do. Each one of these motivations (and others not listed) can serve as the basis of a successful reorg. That might not reduce the stress, uncertainty, or even dislike of a change but it does say that reorgs do not have to be a priori negative or random for a team.
Ultimately, changes to an organization should be rooted in getting more and better work done. Few would disagree with that. The question is really whether the team believes an org change will do that. It sounds easy enough.
Challenges
Even with the best of initial intentions, reorgs can (and often) do hit rough spots. Rarely are reorgs stopped once started (just as it is rare that products are stopped once under development). It is a good idea to have a taxonomy of why reorgs can hit snags or challenges, since it is likely they will.
The question is not how do you avoid these necessarily, but how do you identify a specific hiccup the reorg is going through (much like how you identify problems in product development and address them) rather than just stopping. This preparation should take on elements of chess-play as changes and reactions are mapped out and reconsidered based on feedback. Some potential challenges include:
- Rushing. A potential failure with any reorg is rushing. The funny thing is that the tops usually don’t think they are rushing and everyone else feels things are going too fast. During a reorg process most tops think it is dragging on forever and are just in closure mode simply because tops have likely been thinking about the reorg for quite some time already and most other people have not. In practice, most people only get a short time to hear, absorb, and reflect on the potential change. Skipping a communication and feedback step or skipping deep 1:1 conversations in a consistent and thoughtful manger can make for a very tricky reorg. When people feel the changes are rushed, the process loses structural integrity.
- Reasoning. Failure to effectively communicate the rationale commonly plagues reorgs. Think of a reorg like any “launch” in that you want to be clear, concise, and appeal the folks with your message. If your message is not the problem your customers have then only challenges follow. The reasoning should appeal to the people who will experience the changes—the organization is what most people in a job and on a team experience day in and day out so reasoning needs to resonate with them. Reorgs announcements that leave too many questions as “exercises for the reader” might be viewed cynically and folks might believe that not enough thought has gone into the change.
- Strategy. Sometimes a reorg is being done in place of a strategy– “when all else fails, lets reorg” is how victims of such a reorg might characterize things. Reorgs are not a substitute for a strategic choice an organization must make. In fact, a reorg is a tool to use after you have made a strategic choice. Hearing objections to reorgs based on differences in strategy is a real warning sign that the first order problem has not been addressed. If the team has a strategic choice to make (less people, fewer managers, align products, etc.) then first make that choice, then decide if a reorg is needed to accomplish the choice. More often than not, clarifying and then making a strategic choice is the more difficult, but useful, way to spend energy.
- Timing. A complaint bottoms and middles might raise about a reorg is when it happens—“the timing isn’t right”. A complaint many tops might have with reorgs is that everyone is always telling them the timing is wrong. In practice reorgs can be like a “stand down” for a product team. For some period of time, proportional to the number of people who change managers and/or responsibility, the team will effectively stop working. Therefore no matter how urgent the rationale, the timing of a reorg needs to minimize the impact on the work. On big teams, org inefficiencies trickle on to a team throughout a product cycle (no matter how long or short) due to people coming/going or even things like acquisitions. Unless the point of the reorg is to pivot the product, the potential loss of time to market due to a reorg is a high price to pay.
- New problems. Any reorg can and will introduce new problems. A common technique for middles is to quickly identify the things that get “more difficult” or for bottoms to ask “well who will do X now”. From a top driving a reorg these often look like self-preservation rather than constructive input. It is a safe bet that almost everything one hears at this time is going to come become issues as middles and bottoms know their jobs. Even if it is presented in a selfish manner, the reality is that tops are not in touch enough with all the details of the work to just keep moving without adjusting. There’s a real balance to understanding what new problems are introduced in any org change and the impact those problems might have on the work.
- Too much change, too little problem. If the reasoning of a change is not sound for most people or there is a lot of feedback about strategy then there’s a chance that the reorg being executed is outsized relative to the problem. The feedback loop in this case is really pointing to an incomplete problem definition or simply a solution that doesn’t match the problem. This is a case where listening to the feedback can be especially enlightening.
- Fatigue. Reorgs can also be too much of a (good) thing. Teams can grow tired of the churn that comes from reorgs and enter a state of reorg fatigue. Finding the right cadence for org changes and finding the ability to get the reorg done and over with are important parts of an effective process. When more than one person starts sending mail saying how many managers or office moves they have had, then it might be time to consider this challenge.
- Org distance. Getting work done every day is how most people will evaluate an org change. The “org distance” between routine collaborators and resources is one measure commonly used. Org changes can potentially run into resistance when people perceive the changes mean they are “further away” from those they work with routinely. Commonly people will just count the org intersection point and see how far it moves or how different it becomes.
- Accountability for the present and future. Ultimately any organization needs to land clearly with who is accountable for what. This is a statement about specific people, code, and job functions. Every accountability has a “30,000 foot” view as well as an “on the ground” view. It is usually accountability at the detail level that matters in terms of selling through an org change. People will naturally want to know who “decides” which is another way of asking who is accountable. To answer who is accountable also requires one to answer where the resources are that “own” the code, designs, tests, etc. The transition from the present and all the work in flight to the future is a key part of any reorg effort.
- Leadership and people. One of the most challenging aspects of reorgs, particularly those that are about restructuring, is the ripple effect on staffing. At each level of the change, leaders need to be put in place. Some might be the existing leaders and others might be new. The image of musical chairs can come to mind, which is always stressful. Alternatively it is entirely possible to create an organization where there are more jobs of a certain type than people to fill them, which is equally stressful. As is always the case, making sure that when roles are created the people filling them are truly the right choice for the intended role is paramount. A new organization that is poorly staffed gets off to a challenging start.
In addition to these conceptual challenges, there are always potential pitfalls with respect to the process of reorganization. The tools of communication, listening, planning, empathy, adapting, are all absolutely critical. My own efforts at blogging started as part of the learning, sharing, and feedback loop for the team as we geared up for Windows 7 development (see our book) and re-organization. Blogging was one tool of many, but an effective way to drive a two-way dialog about changes (many posts were the result of questions or follow-up).
Finally, accountability for a reorg rests with management, specifically the line manager driving the org change. Reorgs are not something HR does for or on behalf of management. HR has valuable tools and a position of objectivity to assist, but they are not accountable or there to drive the process, pick up the pieces, or otherwise appear out in front of a reorg. A way to think of this is that as a manager resource allocation is your primary tool, therefore you can’t really delegate org design and implementation because it is a primary job function—-it is like a developer outsourcing coding (wait didn’t we recently read about the dev that did that?). A common source of frustration is when someone is referred to HR when they raise issues about the goals and execution of a reorg.
Tools
While there are many human resources and management tools to support the communication, feedback, and discussion of a reorg, there are also some specific work management needs to do in order to drive an effective process. A big part of the use of these tools is the contribution from a large set of people on the team who are enrolled in driving the change.
The initial burden for getting things going well falls to the tops to communicate clearly. The reasons for implementing an org change need to be clear and resonate with the team and discussed separately from the solution. This is the problem statement and explains the why behind a reorg. The first sign of skipping steps in a reorg is that the first words, slide or paragraph show a reporting structure. Any reorg that leads with reporting structure is likely to be hit head-on with resistance. Of course most people will be anxious and want to know the structure first anyway, but as a leader of a reorg there is a real responsibility to explain the problems being solved first. This is not burying the real news because the real news is management waking up to a problem that needs to be solved.
With those two tools in place (the why and what), there are a few other tools that can help smooth over what is bound to be an emotional change for a team.
- How. The next thing to identify is how the work will get done. This is not the job of the top at a very gross “whole product” level but at the level down to some granular level that shows the implications of an org change are understood. Even in the largest organization, understanding at a level of 10-15 developers (engineers, marketing people, etc.) is really an acid test for knowing if an org change has been thought through.
- Who. The funny thing about reorgs is that the success of them depends on the most local of variables-—individuals want to know what they work on and how the org affects their work, their career, and their place on the team. This is the “who” of a change. In an information based team (software!) this is your asset, not the code. So failing to really understand the who of an org change is going to make it rough. For this tool you need to enlist the help of managers throughout the team to make sure everyone is clear on who does what.
- When. The timeline of a reorg is critical for everyone. You need to take the time and yet not drag it out. How you balance this depends on the scope of the change and size of the organization.
Whenever a reorg is taking place, whether people agree or not, ultimately the members of the team will want to know about their own careers, skills, knowledge, and place in the new structure. As much as reorgs are about the big picture, successful reorgs are about the individuals that do the bulk of the work on any product team.
Or not…
One more tool for reorgs is simply not to do them. As strange as that sounds, the reality is that no organization is perfect and even if an organization is perfect it won’t remain so for very long just because of the dynamic nature of product development and teams. People move around, features become more or less important as the technology landscape changes, some areas require more resources than planned or some require less, business models change and more.
This is why more often than not a reorg might not be the best place to spend the team’s limited energy. Reorgs have the potential to substitute activity for progress and can cause an organization to be looking inward right when it needs to be outward focused the most.
That’s not always the case, but it certainly is worth considering.
Yet that doesn’t cure any problems a team or organization might be having. What are some changes tops can initiate or help to drive that can be substitutes for addressing the root cause of challenges that might be equally challenging but perhaps focus on the root cause more than an org change? Here are some examples for tech teams:
- Align planning and execution. Any time an organization has more than two products (or projects) that connect to each other (two unique products, front end/back end, etc.) there could be a need for alignment. The easiest way to have alignment is to align the planning and execution calendars. Teams that are joined by a calendar have the easiest time working together when it comes to hard decisions like what code to write and when. This alignment needs to be supported by tops–meaning once the bet is made to align, then you have to work within the constraints of release cadence, scope of product, external communication, and more. The converse of this is that putting teams together that have different schedules does not bring alignment–alignment in product design and code sharing essentially requires some degree of schedule alignment (at least in my experience).
- Process alignment. Teams that do the same things but do them differently will always have a hard time working together. From even abstract things like roles and responsibilities to extremely concrete things like how to categorize bugs or deliver daily builds, differences in processes can really make it hard to work together. A good thing to do is pick the processes that matter most to your orgs and just align (perhaps see Managing through disagreement).
- Strategic choice. Perhaps the real problem is not one that can be solved by organization at all and an org change is a substitute for a strategic choice (exit or enter a business, combine businesses, etc.) In this case, as painful as it may be, the org change only pushes accountability and delegates responsibility for something that should just be decided.
- Decide to share code. The hardest thing for dev teams to do is share code with other dev teams—50 years after the invention of the subroutine. Yet it is magical when teams do commit to doing so. How to share code effectively and how to manage the provider and consumer roles, especially in a complex org in many businesses, is an art form, but one that needs to perfected, locally. As we all know, sharing code is great and also constraining–so again support from the broader perspective regarding additional constraints is critical. Sharing code is also a lot easier if teams are aligned on planning and execution timelines.
Implementing a reorg is a big step. It is always wise to think first about your problem statement and decide if you can attack the root cause in a much less disruptive way. This is especially true in a large organization where changing things “at the top” has much less of an impact on product evolution than many believe.
Customers
The Oshry framework also includes customers. Customers of course define the reason for making products in the first place.
The biggest challenge any multi-product organization faces is that customers want products and technologies (relevant to them, keeping in mind many products serve many different customer types) to appear to work together. From the outside, that is the customer perspective, when products don’t appear to work together or appear to have arbitrary differences/redundancies then the obvious culprit is the org. The org was not structured to work on that problem as an integrated whole. This can be seen as “shipping the org chart”.
In this case, the org chart for the products is not right-—some things need to be “closer” or “one person” needs to be in charge of a couple of products. This goes a step further. When the design or quality is not right according to customers then the org is not right because the designers or testers were not organizationally working closely enough with developers.
You can see this multi-dimensional problem. It all boils down to graph theory and how you can connect all the parts of all of the products with the highest bandwidth and always connected flow of information, decisions, and more. This means it is much more difficult than it appears to use organization to address these perceived challenges. The side-effects of moving some things closer include moving other things farther apart, and the implications of the solution might be worse than the problem.
In the idealized world of small teams you can get everyone in the same conference room and decide everything. This tops out at about 40 -50 people. For example, Excel 5 had about that many developers. After that, organization is a tool that can help you to overcome this limitation. While it would be great to work on product families that always take fewer people, that isn’t always possible just on the basis of the number of features it takes to be competitive in the market place over any period of time.
The substitute of anointing someone to oversee all aspects of a product is also a scale challenge. There are just so many hours in a day and only so many people that might fill such a role (if that is even possible to do). Once a person is managing a large number of related, but different, projects or just a large number of people then the ability for the large/complex team to act like a small team is limited. In other words, just joining two entities at the top does not necessarily mean they will appear to work better together for customers.
Yet, what everyone wants to avoid is a dynamic where your collective efforts result in “shipping the org chart” to customers.
Since you have to have an organization, which might be divided by geography, discipline, products, architectural layer, product release timing, business models, or more, the real tools to avoid shipping the org chart are planning, communication, and accountability. You can really never solve the multi-dimensional matrix of responsibility without making teams so large or structurally complex, or relying on a superhero manager that any value that might come from being on one team is lost. The converse to this is that designing products by a committee doesn’t work either. Just taking a lot of complexity and sort of saying “work it out” usually fails to be optimal for any customer.
Because of the complexity of org changes in a large team, the best lesson I have learned is that a culture that adapts to solving problems turns out to be the best organization structure. Combine that with common views of roles/responsibilities, clear and reliable plans, and accountability and you can have the makings of an agile and flexible organization that can move work around, partner across projects, and deliver without using org structure as a high-order bit for strategic change.
–Steven Sinofsky
Be sure to check out this week’s survey on org changes https://www.surveymonkey.com/s/WS8TNMP.
Thanks for everyone that responded to our survey for “Using meetings to be more effective”. In this survey, we hoped to learn together about the tools and characteristics that make meetings successful.
Here are the results:
- About half of our most recent meetings include a phone bridge, with about one third connecting via Voice over IP (i.e. Skype)
- In about one in six meetings, at least one person joins via a cell phone
- About half of our meetings take advantage of screen sharing and about half involve PowerPoint, though only in about one third was a projector used
- When asked about whether our last meeting was a success, on average (mean and median) we “neither agree nor disagree” that it was a success
In looking at drivers for what made us rate a meeting a success, there were some interesting findings:
- Regarding technologies, of the technologies queried (phone, cell, VoIP, screen sharing, PowerPoint, projector, and meeting software), only the use of a projector had a statistically significant impact on our success rating. However, meetings with a projector ranked half a point lower on a five point scale, than those without projectors
- Interestingly, presenters rated meetings with projectors lower than members of the audience, with a difference of about a half point, it’s worth noting this was not correlated with slideshow software like PowerPoint
- Of the tips for success discussed, “a fully understood context” drove the success factor up a third-point , and a “concise” meeting (brevity) drove success up nearly a half-point.
- Interestingly, presenters rated meetings with “a fully understood context” higher than members of the audience
Bottom Line:
Modern meetings leverage online tools like to get everyone on the same page, though care should be taken during in-person meetings to not let the audio/visuals detract from your message as a presenter. Taking time before and during the meeting to create a shared sense of context and keeping your message concise seem to drive the best outcomes for everyone, presenter and audience alike.
Thanks, Cameron
###
A line to see someone is not cool, but is blocking progress
It might seem cool if there is a line outside someone’s door (or an inbox full of follow-ups in Outlook or a multi-week wait to “get on the schedule”). “Boy that person is really important” is what folks might say. In reality this bottleneck is a roadblock to progress and a sign of a team in need of change.
Most of the time we see managers with a line outside a door, but it can also be key leaders on a team of all sorts. Here are some tips to get out of the way and stop the gridlock.
Be sure to take the poll at the end of this post http://www.surveymonkey.com/s/QXR9WLZ. Feel free to use the comments to share your experience with a bottleneck on your team–there are folks out there probably experiencing something similar and benefit from your perspective. At the end of this post are the results from Career: Journey or Destination, which has some very interesting trends.
Why is there a line?
Managers or org leaders are busy. But so are the members of the team that work for the manager or depend on that leader. Unfortunately the way things go, too many folks end up as a bottleneck in getting things done. It might be a sign of importance or genuine workload, but it can also be a sign of a structural challenge. What are some of the reasons for a line?
- Approval. A manager asks to approve work before it can move forward.
- Feedback. Members of the team awaiting feedback from on proposed work.
- Decision. A leader is the decision maker in a situation.
On the face of it, each of these sound like the role of a manager (or leader, we’ll use them interchangeably in this post). The dictionary definition of a manager even supports this, “a person who has control or direction of an institution, business, etc., or of a part, division, or phase of it”. The operative notion is “in charge”.
There are several problems with this approach:
- Demotivating. If a job involves creativity (artistic, design, creation, problem solving, or a million other ways of being creative) then people who do those jobs well don’t generally do their best work under control. At an extreme, highly creative people are notorious for not wanting to be directed. The close cousin of demotivating is disempowering and very quickly creative people on the team lose the motivation to do great work and seek to get by with merely good work.
- Scale. A manager that operates a team as an “extension” of him/herself is not highly scalable. The line out the door represents the scale problem—it is trying to squeeze 64 bits through a 32 bit gate. There’s simply more work than can be done. The manager is overworked trying to do the work of the whole team, which is not sustainable.
- Slow. A manager that inserts him/herself in the middle of the flow of work causes the flow of work to slow down. The reaction time of the whole team no longer represents the capability of the team, but is limited by the ability of one person. Most folks are pretty frustrated by the roadblock to approval and then ultimately approval of the work as initially presented.
- Tactical. Those who operate in the middle of the work like this often justify their style as “adding strategic context”. This is often the exact opposite of what happens as the person is too busy to breath, take a step back, or to think long term because of the line out the door!
There are many justifications for why managers see these downsides as worth the risk. Managers feel like they have the experience to do better, know more, or maybe the team is new, understaffed, and so on. These are juicy rationalizations. Like parents doing homework and school projects for their kids, the short term seems reasonable but the long term becomes problematic.
Accountability
Beyond gridlock, the deep, long term problem created by a line outside a manager’s door is the transferal of accountability that takes place. Once the manager is in the middle of approving, providing feedback, or deciding then the very best case is that the manager is accountable for the outcome. Wait, you say that’s always the case, right?
A manager should be accountable when things don’t go well and stand up to claim the work of the team that wasn’t what it needed to be. When things go well, the manager should fade away and the team should shine. This isn’t some ideal. This is just the basics of teamwork and what needs to happen. That goes beyond management and is leadership.
But when a manager is in the middle of everything, members of the team have a tough time feeling a sense of pride of ownership. The further the results are from ideal, the less likely individuals feel responsible. It is simply too easy to point to places where each person surrendered accountability to management. And unfortunately, this opens up potential for the worst form of dysfunction which is a manager in the middle of everything stepping back and still assigning accountability to the team when things don’t go well, politics.
Ultimately, any healthy team is about everyone feeling an equal sense of accountability for the groups work and full accountability for their work. The role of the manager is to create a team and workflow that enables everyone to contribute and grow.
Rhythm of the team
The most important thing a manager can do to create a workflow for the team is to foster a continuous rhythm of work on the team. The world of modern products and service means things are in a state of change and adaptation all the time. Stores roll over promotions constantly. Web sites are always being programmed. Social networks provide a constant dialog to contribute to and respond to. Product feedback is available all the time. The team that is standing on a line is not just missing all the action, but is playing a losing strategy.
In his famous book, Flow: the psychology of optimal experience, Mihaly Csikszentmihalyi talks about how important it is to be engaged in self-controlled, goal-related, meaningful actions. That when you’re doing that you are in a flow and things are much better (“happier”) for everyone.
A flow on a business team or product team is about working towards a shared goal and doing so without the starts and stops that interrupt the flow. As a manager there are two simple things you can do:
- Never schedule your full day. As a rule of thumb, you should never schedule more than 50% of your day in structured meetings and other required activities. This leaves your day for “work” which is your work as a contributor (being a manager does not mean you stop having concrete deliverables!) and for keeping things from being blocked by you. If you have time during the day you can interact in an ad hoc manner with the team, find time to participate before things reach a bottleneck, and most importantly you have time to listen and learn. This is the number one crisis prevention tool at your disposal. The more time you have available the more time you can provide feedback when the time is right for action, as an example. You can provide feedback when a plan is a draft and do so casually and verbally, rather than the team “presenting” a draft in a meeting and you needing to react, or sending you an attachment that forms another line in your inbox, all usually too late for substantial feedback anyway.
- Stop approving and deciding. As heretical as this sounds, as an experiment a manager is encouraged to spend a month pushing back on the team when they ask for approval or a decision. Instead just ask them to decide. Ask them what would go wrong if they decided. Ask them if they are prepared for the implications of a decision either way. Ask them if they are comfortable owning and “defending” a decision (knowing you as the manager will still be supporting them anyway).
As a member of the team waiting in line, there’s an option for you too. Instead of asking for approval or the other side of the coin, acting now and worrying later, take the time to frame your choice in a clear and confident manner. Don’t be defensive, aggressive, or shift accountability, but simply say “Here’s what I’m suggesting as a course of action and what we’re prepared to deal with as the risk…” No choice is free of risk. The risky path is simply not being prepared for what could potentially go wrong.
The optimal team is one that is moving forward all the time and operating with a flow and rhythm. A line outside the door of a manager is a sign of a dysfunctional team. It isn’t hard to break the cycle. Give it a shot.
–Steven
The poll on this post is http://www.surveymonkey.com/s/QXR9WLZ. Let’s share thoughts on those lines outside doors.
Thanks to everyone who responded to our last survey on the “Defining your career path: journey or destination” post. We had an amazing response, with over 800 responses from around the world. Here are a few of the highlights:
- On average (mean), people have spent around 13 years in their career
- In those years, people have held 5.5 jobs or roles; or about 2 years per job/role
- About 26% claimed to be mostly “goal oriented”
- About 60% claimed to be mostly “experience oriented”
- 6% more sought to be “organization leaders” vs. “domain experts” (41% vs. 35%)
- And about 8% more sought to be “breadth leaders” vs. “field experts (42% vs. 34%)
- On average, we’re pretty satisfied with our careers: 3.7 on a 5-point scale
In this survey we had a nice “response variable” to consider: career satisfaction. If we agree that this is a goal we share, we can consider how the other “explanatory variables” contribute to overall career satisfaction:
- Those that claimed to be more “experience oriented” tended to have a higher level of career satisfaction vs. those that were more “goal oriented”; those that reported being “very satisfied” with their careers were >3x more likely to be “experience oriented”
- Those with longer careers tended to be more satisfied: both “career years” and “number of jobs” provided a fractional lift in the 5-point career satisfaction scale
- Pursuing a goal of “organizational leader” tended to provide more lift than “domain expert”
- And pursuing a experiences as a “field expert” tended to provide more lift to satisfaction than experiences as a “breadth leader” (though more consider themselves to be the latter)
- None of the models built in analyzing this data did a great job of explaining all of the variance in your responses; we are all different and find satisfaction in our careers in different ways
Bottom Line: There is no “silver bullet” which guarantees our career satisfaction; people are different and their satisfaction is driven by various factors, at different career stages. That said, as leaders, we generally tend to find satisfaction based on our experiences with other people (as org leaders, experts in our field, more time in our careers/more roles over time) over the specific goals or attained knowledge we encounter through our journey.
Thanks for your responses!
Cameron
Benefiting from skip-level one-on-ones
Staying connected to your skip level manger and she staying connected to you are valuable for the project, the team, and each of your ongoing development. Rigorously and consistently making the most of skip-levels, whether as the manager or individual employee, is an important skill to master. This post looks at one-on-ones from the perspective of the manager with some tips for the employee/individual.
Time pivot, becoming a manager
One day in your career you might come to work and it will be your first day as a new manager. Many things will seem different. All of a sudden you not only feel responsible for code and features, but you’ve taken on a new responsibility for people. For those that you now manage, a new set of demands are placed on your time. One-on-ones are a key tool for you as a new manager.
One-on-ones are the most precious time you can spend with members of the team—your new direct reports. Much has been written about how to “have a good one-on-one” or techniques for making the most of the time (there is a post in our One Strategy book or check out Ben Horowitz’s nice post). I’m a firm believer that 1:1s are the most important of all scale management tools.
The easiest thing to remember about a 1:1 is that as a manager the meeting is not for you but for the employee. Your opportunity to learn is based on the topics raised and questions asked by the member of the team, only asking questions to draw out the issues if necessary. The first sign of a struggling management chain is when employees on the team start to see one-on-ones as being called to the carpet on a regular basis or when managers view a one-on-one as their time to manage the project or to be the keeper of the agenda.
As a manager, the notion that your time is no longer your own, but is there to serve the folks on your team is significant pivot, and somewhat counter-intuitive. You might have a manager you feel “takes up too much of your time” or you might be thinking “I have real work to do instead of sitting here”. You might be worried about all you need to get done as a team and react by asking more (or too much) of your new direct reports. In other words you’re in for a bit of learning about how you now manage your time, in addition to how you manage your own work and the role of management. So you aspire to do better when you’re on the other side of the table, and effectively using 1:1s is a key step.
As a first step of this new journey, consider how you can live up to the mantra that your role is to take up as little time as possible from your direct reports. This only benefits the organization as a whole because there will be more time for work, fewer meetings, and overall more time building products. The 1:1 is your request for time, but how you turn that into a benefit for the member of the team makes it valuable and not a manager tax.
A rule of thumb you might follow is don’t ask anyone to do things for you, but ask folks what they could do that helps them get the work done they believe they are supposed to do. In other words, status reports, project reviews, and statistics may all be valuable, but only if the folks on the team decide that on their own.
At the same time, 1:1s are a key tool to get a pulse on the team and on the work of folks on the team. Through an unstructured two-way dialog you can likely learn more about what is going on than you can from status reports or other outputs open to obfuscation, unintentional or not. So spend the energy to make your way over to your direct report’s desk, meet there, and let he/she set the agenda.
When your work is operating from a shared view of the goals and open and honest communication is encouraged, there’s a very good chance challenges and issues will find you rather than you needing to ferret them out. If you’re finding you are surprised by issues, then dig into the root cause before falling back on asking folks to spend more time telling you what might be happening.
When you take on the role of managing managers, presumably you have found this balance for one level of management. As a new manager of managers, your ability to stay connected to the work is critical but the challenge is much more difficult. You might react by falling into the traps you worked hard to avoid as a new line manager. You might feel that your need to stay connected or to drive strategy trumps the need for a skip level manager to be heard, to be listened to, and to be treated just like you would like to be treated.
Skip-level 1:1s
One-on-ones with your direct reports (fellow managers) will not likely feel like enough to get a sense of the project if you’re in the position of managing other managers. A wonderful tool to learn even more about the team is to just continue having 1:1s on the team, but with the direct reports of your direct reports. Personally, I have always found this part of management to be the very best way to learn more about your own team and an incredibly wise investment to make for a number of reasons.
A skip-level 1:1 is exactly like a 1:1 with a direct report in terms of approach. There is no preparation required. The member of the team is not being called to the carpet. The focus is whatever the member of the team wants it to be. Your role as a manager is to listen, perhaps ask a few guiding questions, and to learn by listening.
In fact, the most important part of a skip-level 1:1 is to avoid “making news” or “solving problems”. If something comes up in the meeting that is a surprise, use this as a chance to ask questions and to make sure the member of the team is engaged in addressing the issue through the management in place. A skip-level is not an opportunity for escalation, no more than it is an opportunity to search for decisions you can make or problems you can solve. If someone leaves a 1:1 thinking you decided something or changed course, then that is a good chance to ask yourself if you were stepping on the toes of your direct report.
You might find it helpful to be systematic with skip level 1:1s and work to meet each of your skip level folks once-per month/quarter/year depending on the size of your organization. If you manage a team of 100, it should be possible to have a skip level with every member of the whole team yearly. More than that and you will probably want to structure your skip-levels to include only your directs of directs, perhaps every six months. It can help to have skip-level meetings take place during specific times in the project when they might make most sense (just before or after a milestone for example). As a suggestion, don’t define “skip level 1:1 days (weeks)” as the assembly line can be a bit off-putting to some, especially if scheduled back to back. You might consider a “head’s up” mail with a skip level invitation just so folks don’t panic :-)
It is important to be consistent in the implementation. In other words, it is important to meet with the same frequency and duration with each of the folks. Don’t short change employees that might be further away, in slightly different projects, or just on areas you might find less in need. The more senior you are the more important this consistency becomes as the team looks for signals of your priorities based on who you spend time with.
My own view is that skip levels are so important that I would routinely spend 15% of scheduled meetings in a year in skip level 1:1s. Some find this a surprising use of time given how much might be going on. The reality is that a consistent approach to meeting with people across a team you manage can offer a unique lens on what is going on. It also affords an opportunity for you to reinforce the work you might have been doing with respect to accountability, decision making, and rhythm of the team.
Some topics
For a skip level 1:1, just as with a regular 1:1, the topics are driven by the attendee and not you. Just as with direct reports, some folks will show up with a long list of topics (or questions). Others will show up assuming you have an agenda. And probably everything in between is possible. Regardless, your role is to facilitate the member of team opening up, to reduce the potential stress of the situation, and to reassure the member of the team that this meeting is not a career moment. This starts with you showing up in the office of the employee, not summoning, the employee to your office.
This latter point is critical. A skip level 1:1 is not a meeting to pass judgment or to evaluate performance, just as it is not a time for “new business”. Folks should know this. While one of you might believe that the meeting should be “confidential”, you should be cautious with that sort of dynamic, not just for skip-levels but in general. Confidentiality is important for matters of personnel but is usually counter-productive when managing a project. If someone requests confidentiality for a personnel issue, it should be handled in the appropriate manner.
If a person shows up with a long list, sometimes it is fine to allow them to work through it. It might also be a good idea to “pace” the dialog and start off by asking “what’s on your mind?” or “how are things going?” In a first 1:1, if you don’t have a history with the member of the team, why not use the time to learn more about each other’s background (as appropriate) and to reciprocate?
There’s likely going to be some interest in hearing answers “from your perspective” – “how are things going”, “did you hear about…”, “what do you think…”? That is interest in topics that are perceived to be talked about at some higher level on the team. It is great to spend some time on those, though it is worth considering how you can put those topics in the context of the project rather than just gossip.
For a larger organization, there’s a benefit to spending time in skip-level dialogs on the efficacy of the work environment. Asking questions about the velocity of code, collaboration, getting things done, and so on. In any organization of size, a manager of managers is where action can (and should) be taken to avoid the perils of a stagnating organization.
Similarly, topics that will surely come up will be related to processes that are corporate wide (compensation, recruiting, and so on). It is probably a good idea to be extra careful about “making news” in how you discuss these—that is different than being guarded and evasive—by focusing on the information previously discussed broadly with the team. You might learn something wasn’t clear, in which case there’s a chance to clear things up for the whole set of folks in a consistent manner.
During different phases of the project, it is great to enable a discussion about that—feedback on pre-release, design challenges, ramping up, and so on.
If you’re the individual
A skip-level 1:1 is a great time to offer your perspectives on what is going well and not. There’s a fine line between offering up all the potentially bad news and sounding like you’re setting expectations, and polishing up all the potentially good news and sounding like you’re showing off. You have to be the judge. A few other potential tips/topics:
- Use right level of detail. Speak the truth and what you know, but match the level of detail that your skip level manager will find valuable. Keep in mind no matter how hands on the manager is, you have a lot more detail in your head :-)
- Ask clarifying questions. Managers often have a tough time with “what is that” or “no I don’t understand” so don’t be afraid to ask questions clarifying if you were clear. Feel free to volunteer to expand acronyms or code names, rather than assume a deep knowledge (without sounding too pedantic).
- Discuss cross-group, collaboration, partnerships. There’s a good chance your skip level manager is pretty tuned in and curious as to how things you are working on contribute to cross-team initiatives. Consider focusing on those topics and if you do, just speak the truth as if your partner is sitting right there with you.
- Limit strategy. There’s a time and place for strategy. While you might be tempted to use the time for big strategy topics, this might not further your goals much and might not be the best use of time. Spend the time thinking about how you could help your contribution to the project with insights and information.
- Don’t make news. It is probably not a good idea to “make news” in this discussion–news about the project, you, or feedback about team/people. You might want to resist the urge to share something for the very first time in this forum and certainly not something you would not share with your manager as if she was sitting right there. If you have candid feedback on your manager, then be clear about what you’re doing and don’t conflate that with the rest of the meeting topics.
Above all, make the most of the time to make sure your skip-level manager is familiar with you and your work in a neutral and constructive way.
When used consistently and effectively, skip-level 1:1s are a great, two-way tool for both of you and the team.
–Steven
###
Learning by Shipping 