Archive for the ‘posts’ Category
Considering a new job with patience and timing
A job “above” you opens up, a friend from a startup comes calling, perhaps the perfect lateral move just appears, or maybe you think it is just time for a change. What’s the right plan or play? This is a really common question, but sometimes even the best intentioned career minded people can fall into some patterns that might not be the best for long term career satisfaction and success.
This post is a checklist of questions to ask yourself and to be prepared to answer when you enter the process of seeking a new role. If you are volunteering yourself for consideration, it is a wise investment in time to thoughtfully prepare your case as to why you would be a good fit. As a first tip, those doing the hiring do not often want to receive a really long email saying all the reasons why you are the perfect fit while reiterating what you can read on your LI profile. A technique that can work is a simply email asking to discuss the “open position” or “I hear your starting something” (and if necessary to meet for the first time).
In a big company it is just as likely, your manager asks you to take on a new role. You don’t necessarily want to say yes right away, but take the time to “formally” organize your thoughts about the move. That’s right, even if you are asked to do a job you should go through a process like this. While it is great for a manager to show faith in you, no matter how good a manager is only you know the answer to these questions and your own career goals. No matter how high integrity or honest a manager might be, managers are not perfect and have their own challenges that arise when filling positions. So don’t assume that being asked to do a job is an automatic yes.
Do you have the right domain skills? One of the most obvious first questions is if you have the domain skills required to do the job. If this is an engineering leadership job, have you demonstrated the expected skills successfully for a long enough time? If you are changing to a new domain, what is it that makes you think you are ready or able to pick up the necessary skills? It is not uncommon to approach a potential role because of the domain. In that case, are you sure about the match between you and the domain?
Do you have the right management skills? One of the biggest career transitions is first to a manager, then to a manager of managers. Being a manager is just as much a skill as domain skills like coding, testing, design. Just like those skills, not everyone has those skills and everyone has their limitations. Management skills required might be the size of the team or might be managing a certain job function, or it might even be a change in geography and managing remotely or moving.
Are you a good match for your future manager? Chances are very good that a hiring manager is spending considerable energy considering if you are a good match for him/her or his/her set of direct reports. If the role involves management, both of you are probably spending a good amount of energy considering if you are a match for the existing team of people. Are you spending enough time considering how good a match you think the manager is for you? Do you really know the manager? Have you asked others who have worked for this manager about style and approach (just has he/she is probably asking about you)? If you’re approaching the potential role because of the manager, can you articulate the reasoning as a positive for the new manager rather than a negative for your current manager?
Do you understand what leaps you are making? Any change in roles involves leaps—whether the move is to a new company, or within a company a lateral move or a promotion. The leaps are the parts of the job that are the big changes from your current role. Of course leaps are usually the reason you are thinking of a job change. There’s a tendency to focus on the largest of leaps, but in thinking through a fit you want to characterize the full set of leaps you’re making. The appropriateness of the new role can be thought of as the accumulation of all the leaps or sometimes it is just that you’re making too big a leap. For example, if are suggesting a change in job scope and a change to management at the same time, this might not give you enough of a “strength anchor” to count on. You might have only a short time of experience as a manager and the leap to managing managers might be coming too soon. You might be amazing at one job function and ready to manage that, but the job might involve managing your job function for the first time and also managing a second or third job function.
Are you pacing yourself? Early in a career is very exciting. Everything is new and you’re anxious to see things play out. These emotions can push you to want more and sooner from your job. This can mean turning the marathon that is a career into a sprint. It can mean applying for jobs that you’re not yet ready for too often and/or too soon. You might consider learning about typical “velocities” and typical tenure in your existing role before considering trying to move “fast”.
Do you have a succession plan that will work? Work needs to continue and whether you’re a manager or not, knowing how your work will get done is key to making a job change. Managers are notoriously anxious or defensive about moves when there is a lot of work to be done. It is always always important to be prepared to talk about how a transition would take place. Failing to do so credibly can really dampen support for a job change. Does your succession plan really work or require you to be in two places at once or require a deus ex machina to assist with the transition?
Did you remind yourself this isn’t the last job opening, ever? It is not uncommon to feel like you’re Waiting for Godot and then one day a job opens, a headhunter calls, or a friend shares the latest funding news. You jump on the chance. You don’t do the due diligence suggested above because the job opened and you want it. A really good reminder is that it is with certainty that there will be other job openings down the road.
Did you seek the job or did it just pop up? One of the crazy ways to change jobs is to not be looking for a job and then one just shows up. Serendipity can be an amazing good fortune. It can also confuse you—it can make you think a job is perfect for you when it isn’t or it can make you look for a job when the timing isn’t right. Just as a job that becomes open is not the last one ever, if you’re doing a good job but the timing isn’t right, other opportunities will come along.
Keep in mind that any job transition is a two-way decision. You are deciding if a job is right for you as much as a manager is deciding if you are right for the job. There’s much more of a balance there than folks often permit. You have the opportunity to clearly make a case as much as you have the opportunity to step back and decide the timing isn’t right.
Finally, always keep in mind that there is an affliction known as the “job bug” and when you’re bit you can really put yourself in a tough spot. Once you start looking for new roles your brain starts to shift away from current work—whether you set out to look for a role or you started to consider a role that just appeared. Your manager and your team also know that you’re on the move or “in play”. If you do the right prep and thoughtful consideration, definitely apply for the right job at the right time. If you don’t get it, you have to cure yourself of the job bug and focus on the work at hand.
The very best preparation for a new job is doing well at your current job.
Patience in job transitions is a remarkable tool for growth. Careers are much longer than you think, especially when you’re first getting started. The value of doing a job super well in the here and now can be extremely high. It is usually a wise choice to be methodical in your career progression.
–Steven Sinofsky
# # # # #
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
“One Strategy” — organization structure and transition (book/blog post reprint)
A recent post by Ben Thompson touched on some of the issues in going from a product focused organization to a discipline focused organization. And while I don’t agree with the broad (and binary) view of orgs, there are several interesting things in general in the post which are worth discussing. Many of these issues are not about a big (or specific) company at all and I’ve seen the same things in startups with 5 people or 100 people. Organizations of all sizes have “seams” or “boundaries” — while one is product, others include disciplines (engineering, marketing, sales), code architecture or subsystems, geographies, target customers, external partners, revenue sources, budgets, ship dates, product cycle lengths, and more all represent places that multiple groups of people might arrive at different optimizations, choices, or decisions while representing ways in which groups of people can be organized.
This topic was on discussed at length in the book, One Strategy: Organization, Planning, and Decision Making (hurry “only 17 copies left”), authored by myself and Marco Iansiti we tackled some of the challenges faced in transitioning the Windows team to a new way of working and organization structure during the 2006-2007 timeframe. The “reprinted” post below is representative of the approach to organization and the transition the team undertook. I think it contributes to the overall dialog of the complexities and challenges one faces in organizing product development teams.
The book features a collection of blog posts from a blog I authored internally along with a broader view provided by Marco. The book focuses a great deal on our journey as a team to (according to the jacket copy):
Aligning a complex organization around one strategy requires all members of a team to participate—learning, sharing, communicating, and contributing to the team’s success. One Strategy provides a unique combination of real-world experience managing a large-scale organization with academic research in strategy and innovation to describe what it takes to align an organization around one strategy, manage its execution, and reach for “strategic integrity.”
Keep in mind that context plays a critical part in looking at how all these variables come together. Organizing a team is doing your best with imperfect information to optimize a seemingly infinite set of variables. Product development and business are both social sciences. In fact in reading this post, you can see the context change as we introduce the book and posts noting just some of the challenges such as moving to bring a regular release cycle to Windows and cut the release time by half, to scale software as a service, or to bring Internet Explorer to current web standards. Context matters as we say.
This post below is from page 25 of our book and talks about the transition the organization was making from a team composed of a large number of “product units” to a “functional” or “discipline” focused organization.
In this jargon, a “product unit” is a team consisting of the engineering disciplines and often related marketing (or at least dedicated marketing) with a general manager. A function or discipline means job functions such as development, testing, program (product) management, and more.
3/20/2007 12 months and about 120,000 words later…
Friday marks the first 12 months of our new Windows and Windows Live organization (and also the 100th post to this blog) so it seems like a good idea to take a step back and look at the progress we have made together and think about the work left to be done.
Before getting started, I wanted to thank everyone on the team and all of those that have been supportive of the team and the work we have been doing for the past year. Together we have embarked on a great deal of change and put in place many new operational methods, and none of that would have been possible without the open-minds and cooperative efforts of those involved. Thank you!
I also want to use this as a chance to reinforce the “open inbox” that I (and all the leaders in WWL) maintain. Some of the best input and best conversations I’ve had have been with people who just send mail or stop me in the halls. It is one thing to see averages and deltas from the mean on an employee survey, but the real improvements in our team come from written comments or conversations. This substance is what really has helped to make a big difference in how our team is evolving.
We have had a year that at times has seemed rather focused on process and operations, which is in a sense by definition, but also at times a bit less than ideal. Last spring we were still months from finishing Vista and our first wave of Live services would start to slip months beyond their originally planned dates. Yet we came through that and through the midst of significant changes in organization and structure we released Vista, a plethora of Live services, a major release of Live Search, and Internet Explorer 7. To a person everyone contributed to delivering an amazing amount of software. At the same time there was a consistently expressed desire to do things better, and so that has been the motivation for the focus on the “how” we get things done. As I said in our announcement in March we will aspire to have the best engineering organization in the company—one that is focused, with modesty, on discipline expertise, agility, creativity and above all is a learning organization. Across every dimension we have been working hard to instill a sense of clear accountability with the resources and framework to be successful. I also committed to help us achieve these goals with transparency of process and this blog has been part of this work. And of course we want to move forward with a renewed emphasis on planning our work, and working those plans.
With all of these changes it is important to point out that it takes time to see the results. Some would have hoped for faster results, and others would have hoped for less change. We are a work in progress for sure. Nothing says that more than the fact that we are just getting started with big releases of software—a new wave of Live services, a new release of Internet Explorer, a new release of Search, and of course a new release of Windows (and SP1). In the hallways, folks ask me every day “how’s it going?” and I generally think it is more than rhetorical—I think people really want to know how things are progressing. Things are progressing well. I am very optimistic. Things are upbeat. I do indeed have the benefit of a broader perspective and some “altitude” which helps. I know that some of the challenges many individuals face on a daily basis—the challenges that seem to get in the way of getting work done—are still there and did not disappear overnight. I know that some new challenges have appeared. But I don’t have to look far to hear feedback about things moving forward and heading in the right direction.
It is worth looking at three of the main areas of feedback that correspond to three of the biggest changes we have made as an organization and provide a “state of the organization” view of organization efficiency, planning, and decision making. It is hard to separate these changes because they are interrelated. We can make changes in our organization structure because we are more focused on executing on a plan. We can create a plan that reflects the whole team because we put in place more empowered decision makers. But I also recognize that for each of these areas we have much work to do, few concrete results, and for some the jury is still out. That’s why I think it is good to take a step back and make sure to communicate and acknowledge that the management team does understand where we are today and also to share the sense of optimism that we each have.
If you want the short version of this post…we have created an organization that is flatter, has fewer managers, and is much more focused on core engineering values. With this organization in place we have embarked on a product planning process that is about bringing the best ideas to our products in a timely and thoughtful manner. And because of our structure and because we are operating with a plan we are in a much better position to make and stick to decisions. Yet this is a work in progress and I recognize that for many the changes have not been enough or fast enough, or that the changes have not yet erased the challenges in daily work. It takes time for these changes to pay off and time for them to move through the whole organization. With the evidence of early results, such as the Live and Search plans and the progress we have made as a team on Windows and IE I believe we all have reasons to be optimistic and that we will see results of our efforts as we enter execution mode on our work. Our software will be used by over a billion people by the time we finish this next wave of products—that is an awesome responsibility and an amazing opportunity for us all in our careers.
Organization Efficiency and Engineering Focus
In many posts to this blog and in many of our team meetings we have talked a great deal about the organization’s statistics such as how many people at what level, how many direct reports managers have, how big teams should be, and how many managers and management layers there should be. This is an area where it is easy to be concrete and so was the first one we acted on as an organization. Across Windows and Windows Live (and COSD, Core OS Division) we have worked hard to put in place a team that values the engineering disciplines and streamlines our engineering organization and I think we have made progress.
Last year on average an individual contributor had 7 managers between him/her and me. On average we have reduced this to 3 or 4. I think that is probably the most dramatic change. It is also one that has come in handy as we recruit from colleges this year. It is amazing how sensitive college candidates are to this detail and how often I was asked on campuses and in email exchanges with candidates—being compared to Google (an organization that has 4000 engineers these days) favorably definitely helps. We are also asking more of our managers, but not as much as some folks might have thought—we do have more reports for most managers now, but on average this is only 1 or 2 more reports (because previously many managers had only 2 reports). I want to give a lot of credit to all of our managers—they have been leading a big change even in the face of some uncertainty. And many people on the team have new managers, which is a two-way street of newness, and everyone has done a great job working through those transitions. I’ve had some conversations with folks where they ask if we are moving to a model where if you are a manager then you are a “pure” manager and only manage people—nothing could be further from the truth and what we have tried to emphasize is the desire to have managers contributing at a much deeper technical level than in the past, and this is possible because of a combination of more managers working within an engineering discipline and a much more focused planning process that frees managers from the burden of “keeping things under control” to focus more on execution of the plan.
The biggest part of our organization’s change has been the focus away from silos of product units to a focus on disciplines working together. It goes without saying that this was controversial and also a change that for many amounted to resetting career goals. We have in place about 30 engineering triads of development, testing, and program management representing our 1000 or so developers. Some are still adjusting—wondering who will ultimately decide (they will) or what happens when dev/test/pm don’t agree (they will work it out, based on consensus), and so on. Until we go through the whole ship cycle, or at least the full planning cycle, it will be the case that some are still waiting for a VP to swoop in and take away the empowerment of the triad (it won’t happen :-)). It is super clear that most people understand the increased level of responsibility that they feel. I’ve had incredible discussions with GPMs who own planning themes or big bets and they are definitely seeing the reality that the buck stops with them—without their plans we simply won’t have features in that area. I’ve had conversations with SDETs (software design engineers in test) who talk about what it is like to be part of the planning process for the very first time. And in talking to developers who for the first time are taking a step back and looking at the code assets during MQ (milestone for quality) and thinking about what we should do. All of this is part of taking a discipline-specific view of the work that needs to happen. We are focused on mastering the crafts of dev, test, and pm rather than everyone gravitating to more generalist roles.
I’ve also talked to some members of the team who think we replaced one type of inefficiency with another—that is we replaced silos of product units with cross-team meetings. On the one hand there is some truth to this, but that comes from the fact that there is no org structure where we develop our products unencumbered by the relationships to other products. On the other hand, we are adjusting to operating in a way that optimizes for executing within a planned framework. We are still building trust across the teams and still learning how to work together. We were used to a manager clearing the way, usually by isolating the team or forging arm’s length relationships with other teams, rather than a focus on collaboration and consensus. Some folks have said it feels like we went from 1 boss to 3. My view is that we are now much more accurately reflecting the specializations and skills necessary to create world class software, but I recognize that this puts a high burden on managers staying in sync with their discipline peers and communicating. This is no different than the expectation in a tiny team of one dev (manager), one pm (manager), one test (manager) – except we are trying to scale this to a larger group. It might seem harder now, especially because we only see the work and not the end-result. I’ve personally experienced this transition before so perhaps that is why I have confidence that once we go through the product cycle it will be much clearer and we will all be surprised at how much more natural collaboration happens.
We are still adjusting to having to incorporate many different perspectives and inputs from our engineering team at each step in the product cycle. We are seeing test involved early on for the first time. We are seeing program management working to get out front while also accountable to development for detailed specifications. It is clear that every discipline is reaching new levels of discipline involvement and if you think about it in terms of the CSPs (Career Stage Profiles) we are seeing more people touch more of those areas than we have had previously. I think this is a good sign for the growth of individuals on our team and our longer term health as an organization.
We start the second year of our organization with a streamlined organization that is much more focused on engineering and collaboration. I know it will take time for every member of the team to experience the positives of these changes and it is easy to focus on the change and see the less than positive elements. It might even be the case that over time some will find this new level of accountability and empowerment to be too challenging. Of all the changes to the team this is the one that will have the biggest long-term benefits for the careers of engineers. If I could pick one thing that we still need to improve it is the communication throughout the team and across the disciplines. We are still not sending around (locally) enough meeting notes and not sharing information more freely. And part of that is asking people to be more receptive to “raw data” and less demanding of “tell me what is important” because with empowerment comes the need to process more data and manage the flow of information. For our process to work smoothly we do need more communication.
Planning
About six weeks after I moved into this new role I remember reading that when asked about the next release of Windows Steve Ballmer said “that will never happen again…it’ll never happen again.” If I wasn’t awake and alert, I definitely was after reading that.
Of course I know that my commitments (as published) were very much focused on planning. The option open to me was to simply put in place the best process we could and hope we could all follow it, without trying to make it seem like it was a “playbook”. That was a big challenge for me. I know many folks thought that I pulled the planning process out of my back pocket, and certainly I had my fair share of stories about Office, but the truth is that the process we embarked on tried to take into account the unique situations of each of our teams. The Live teams wanted to remain as agile as they had been. The Windows team needed to finish Vista. The Search team had monthly improvements and a well-known set of features to work on. Yet it was clear that the team at large was hoping for more of a definitive sense of “what will we accomplish” and “what does success look like”.
A big turning point and in a sense our first real team event was when Marco Iansiti from Harvard came and taught us about the benefits of planning from the perspective of two case studies. While we did not walk away from this day with the magic answers or the specific plans, we did develop a shared sense of the importance of planning and the value that thoughtful planning can bring to product development. Even though that was back in October, people still comment about “not in the direction of goodness” and “we need to be building more keels” in reference to the Challenger case and the Team NZ case. I learned a good lesson about team building in how having those shared experiences, even if not entirely applicable to day-to-day work, is very valuable.
These discussions led to the “WWL Planning Process” slide that we have used dozens of times in offsites and meetings. In a sense this slide made the planning process seem more rote and mechanical than it is in real life. Early on many worried (in email to me) that the process would not yield any creativity and that it squeezes the creativity out of product development. Many worried about the trust we were putting in the teams to develop the plan and had expectations of executives swooping in. And of course the biggest worry people expressed was that it all was going to take too long. We’re behind and need to get ahead so how can we afford the downtime to plan was a common refrain.
The first team to move from planning to plan was the Live Experience team. We made a deliberate choice to focus on getting the plan in place as the highest team priority (perhaps in contrast to the Windows team where we have been focusing more on developing the operational aspects of the larger team and COSD, Core OS Division). In a few short weeks it became clear that we did indeed unleash a lot of creativity. Our first lesson as a team was that the hardest part of the “WWL Planning Process” is figuring out what ideas to decide to do. It was really great to see the prototypes and the detailed feature lists. This creativity culminated in the Vision rollout (jointly presented by the WLP (Windows Live Platform) and WLX (Windows Live Experience) teams) that showed clear commitments to specific scenarios. We have tons of work to do and like any product cycle we will go through milestone checkpoints, recalibration, and so on. But we did learn together than putting the process in place did not constrain our creativity.
The core of the planning process is the idea that good ideas can come from anywhere and that the role of those leading the planning themes is to make sure they go out there and ferret out those ideas, and those with ideas need to seek out those working on the plans. The idea of “middles-out” planning is definitely new. JulieLar and ChrisJo and I have talked many times about how those on the team and others all think we have “the plan” in our Drafts folder waiting to be sent out, and sometimes there are those on the team that are waiting for us to hit send regardless of what others think up. We are deep in the process on the Windows product now and it is definitely the case that people are feeling the sense of accountability for the plans. One GPM who used to be a PUM told me that they feel way more responsible for the plan of their team then they ever have before. They know that the plan will fit within the vision and that they alone are responsible for that, and previously they felt that the “worklist” would just sort of get created and before they knew it their primary job was to avoid having too much work put on them making it impossible to get done the few things they thought should get done. This is just one case, but it is a general theme. Of course I still have to earn the trust of the team and so do all of my direct reports. I was once asked if I plan on [personally] redesigning the [Windows 7] Start button 80% through the project and I took an oath not to do that in front of the WEX (Windows Experience) team, but I still have to follow through on that. Our team is learning how to consider all points of view and bring those together into a plan. It might look a bit chaotic right now and we will iterate and get better. More than most changes, the “what goes into the plan” is likely to be the one that is the most opaque while it is transpiring. If you have any questions and are not sure about what is going on, please ask rather than assume nothing or something worse is going on.
We are also seeing the benefits of “downtime” despite the misnomer. The time is not idle at all—all the teams have done (or are in the progress of doing) some excellent MQ work. Each of the leaders of development has worked hard at documenting development practices that will be used for quality, security, performance, etc. Our test discipline has done some great work on automation and frameworks. On the Windows team we continue to dive into postmortem feedback around test tools and bug tracking and using the MQ time to be concrete about our goals and exit criteria. Yet it is fair to say that some are still frustrated by our lack of “coding” right now—some believe that “we know what features we want to do so we are wasting time not coding”. Of course it could very well be that we might end up doing precisely some of those features, but we also know that developing these features with up front thinking in terms of specifications and test plans will at the very least make delivering those features more reliable, if not make those features better. I know I have to ask for patience for some.
The most challenging area for me in terms of planning has been the expectations of the end result, the plan. By talking so much about the plan, I believe I have inadvertently raised the stakes of the plan (the vision document) too high. I think many are expecting the plan to be the most amazing document with detailed killer features that describe how we deliver a knock-out blow to the competition. The plan will not have that (sorry). I expect the plan to be detailed and to be clear in the value to customers. But the real details of what are home runs or merely solid hits are up to the team. If you could really mastermind a product plan to know you would have a hit then there would be many more successful companies (or maybe many fewer, just the ones with hit products). Perhaps this is the most counter-intuitive part of the plan. The plan is about removing risk (the schedule, the ability to get the work done, the resources, etc.) but it cannot remove the uncertainty (did we pick good features to do, will people like the features we pick, will we have expressed the features well, etc.) In the past few weeks I have definitely heard from people that they expect the plan/vision to be more “exciting” or more “killer”. I’ve never seen a plan that looks like a winner before you start that also looked achievable. The Office 2007 UI was just one pillar of the product and if you would have asked me in 2004 if the UI would be as paradigm shifting as it has been perceived I definitely would not have said that (until beta1, that is). We will all learn together the value of the plan and also how to recognize good plans and feel pumped to begin development even if we know that what we have accomplished is outlining the goals, if not the actual results.
The other area of planning yet to be tested, and the source of concern, has been flexibility. The reality is that when working with a plan our team will be more agile than if there was no plan in place, as counter-intuitive as that sounds. We will have a clear sense of our priorities and the costs of making changes and new decisions. We will be able to adapt to changes in the marketplace or in our progress because we will know what remains to be done. Some are still skeptical of this and so together we will learn and adapt going forward.
There is work to be done. We have to write the vision for Windows and Internet Explorer. We have to develop prototypes and make sure our release meets the business goals we have. In Windows we have had two planning checkpoints and we are zeroing in on the product vision and we can feel excitement building. Perhaps the biggest challenge ahead of us is in doing a detailed development schedule that we require and one that has very high scheduling integrity. This is going to be critical to our success and will ask the most of our disciplines—pm needs to have specifications (that can never be detailed enough), dev needs to have schedules (that can never be granular enough), and test will need to be forgiving that pm and dev are both not 100% certain. I am sure this will stretch the team and our triads in new ways, but we are all in this together.
Decision Making
No topic caused more angst in the Vista product postmortem than decision making. Often this is a code word for “random executive” or “deadlocked managers”. It also described the feeling that almost everyone has when you feel like you know the right answer but can’t get something done. Improving decision making cannot be done by putting in a decision making process (in fact many groups put those processes in place only to see those processes get overridden). Improving decision making takes organizational trust. It takes a common framework. It takes clear roles and responsibilities.
I would say we have the start of all of these in place. But this is also an area where it is easy to find many examples where things are not friction-free. We make big products. We have many competing needs. We will always have challenges in having an environment where one person has 100% control over everything they might do. I know that either frustrates or surprises people. I have been asked by many what it is like to be a “business leader” and I remind people that even at my job I have no say in tons of things that matter a lot to whether our work is successful (when thought of from the 4 P’s of marketing: product, price, promotion, placement I only have say in 25% of the business, at best). But we have built our team, both in terms of feature teams and in terms of engineering structure so that we can have a balance if we all operate from a shared plan. Decision making has the key ingredients of a plan and an engineering structure that reinforces roles and responsibilities. I know the jury is still out.
The first order of business for our team was putting in place the engineering-focused organization so it is super clear that decisions about engineering get made by engineers, and that those decisions can stick because they are grounded in the technical realities of our products. When it comes to the schedule, the test plans, and the architecture I know for sure that we will not be second-guessing these down the road.
The second priority is to establish a common framework for making decisions or a common set of priorities. The product vision that outlines business goals, tenets, and clear scenarios makes it a built-in prioritization tool for the product. The key here is that we agree on the priorities and on what it takes to get done. We agree at the outset that these goals, while aggressive, are achievable and that everyone has a deep understanding to begin the project and the resources necessary to complete the project in a timely manner.
Taken together we have moved from a model of “butts on the line” or the “hero” model of working. We won’t look to a single person to go above and beyond to accomplish our work. In terms of decision making this is very important because those modes of working have a way of tearing down any orderly decision making processes and replacing them with “out of my way this needs to get done” work styles that upend even the most robust plans.
And finally we are going to be clear about work that crosses the whole product we make. We are seeing this as we create the vision where we are going to prioritize the 2 or 3 “big bets” (as we have done with Live Wave 2) and making sure we share these bets and staff them accordingly. We have moved from a model where groups believe they decide their own set of features only to see that burdened by endless inbound reprioritization.
Without a doubt the biggest part of decision making that we are looking to change, and one that still is somewhat “foreign” to people is escalation. It is still the case that we have too many things where people think they need VP approval. If you want to spend $1M then that is probably VP approval, but if you want to decide on the features for your area you have the authority to do so. We also still have many decisions where people do not agree with the decision and escalate to reverse a decision—I hope folks understand that escalating a decision is not a way to reverse things. The hope is, again, that those making decisions have done the work necessary to understand points of view and take into account the full context of a decision. If you learn something new or have new data, then change your mind rather than force members of the team to drive an escalation process. The way to avoid escalation is in communicating and making sure you are taking into account all the stakeholders—freedom to make decisions is not freedom to ignore the landscape.
With our engineering focused organization we are also expecting more from our group managers with respect to decision making. They are on the hook to drive the processes of engineering and do so without pushing the process down the organization. We have minimized the “staff” functions for running our team. We can do so because we are working to make the process of following the plan less challenging by being more consistent and less confrontational. We are still early in this regard, but watching the visions come together gives me reason to believe these changes will come naturally from the work we have done to date.
This next year will be a year of execution. We are about to roll out the plan for the next wave of Search investments. We are approaching M1 completion for Live Wave 2. We will soon have a vision for Internet Explorer. And we are entering MQ for the next release of Windows. The best organizational learning happens while doing actual work and we are doing that now. So we have clearly left the realm of theoretical and meta-discussions and are turning the crank. It is exciting.
A big part of execution mode, so to speak, is that it is now up to the team to succeed. Management, process, and memos can only take us so far. Taking the development foundation we have built together and delivering products is up to every member of the team giving 100%.
This has been a challenging year for just about everyone on the team. It has also been a rewarding year. We are a team ready to execute. We are a team ready for the challenges of execution. And above all, ready to take those on together as a team.
–Steven
Juggling multiple platforms and the bumpy road ahead
Targeting multiple operating systems has been an industry goal or non-goal depending on your perspective since some of the earliest days of computing. For both app developers and platform builders, the evolution of their work follow typical patterns—patterns where their goals might be aligned or manageable in the short term but become increasingly divergent over time.
While history does not always repeat itself, the ingredients for a repeat of cross-platform woes currently exist in the domain of mobile apps (mobile means apps developed for modern sealed-case platforms such as iOS, Android, Windows RT, Windows Phone, Blackberry, etc.) The network effects of platforms and the “winner take all” state that many believe is reached (or perhaps desirable) influences the behavior and outcome of cross-platform app development as well as platform development.
Today app developers generally write apps targeting several of the mobile platforms. If you look at number of “sockets” over the past couple of years there was an early dominance of iOS followed by a large growth of Android. Several other platforms currently compete for the next round of attention. Based on apps in respective app stores these are two leaders for the new platforms. App developers today seeking the most number of client sockets target at least iOS and Android, often simultaneously. It is too early to pick a winner.
Some would say that the role of the cloud services or the browser make app development less about the “client” socket. The data, however, suggests that customers prefer the interaction approach and integration capability of apps and certainly platform builders touting the size of app stores further evidences that perspective. Even the smallest amount of “dependency” (for customers or technical reasons) on the client’s unique capabilities can provide benefits or dramatically improve the quality of the overall experience.
In discussions with entrepreneurs I have had, it is clear the approach to cross-platform is shifting from “obviously we will do multiple platforms” to thinking about which platform comes first, second, or third and how many to do. Chris Dixon recently had some thoughts about this in the context of modern app development in general (tablets and/or phones). I would agree that tablets drive a different type of app over time simply because the scenarios can be quite different even with identically capable devices under the hood. The cross-platform question only gets more difficult if apps take on unique capabilities or user experiences for different sized screens, which is almost certainly the case.
History
The history of cross-platform development is fairly well-known by app developers.
The goal of an app developer is to acquire as many customers as possible or to have the highest quality engagement with a specific set of customers. In an environment where customers are all using one platform (by platform we mean set of APIs, tools, languages that are used to build an app) the choice for a developer is simple, which is to target the platform APIs in a fully exploitive manner.
The goal of being the “best” app for the platform is a goal shared by both app and platform developers. The reason for this is that nearly any app will have app competitors and one approach to differentiation will be to be the app that is best on the platform—at the very least this will garner the attention of the platform builder and result in amplification of the marketing and outreach of a given app (for example, given n different banking apps, the one that is used in demonstrations or platform evangelism will be the one that touts the platform advantages).
Once developers are faced with two or more platforms to target, the discussion typically starts with attempting to measure the size of the customer base for each platform (hence the debate today about whether market share or revenue define a more successful platform). New apps (at startups or established companies) will start with a dialog that depending on time or resources jumps through incredible hoops to attempt to model the platform dynamics. Questions such as which customers use which platforms, velocity of platform adoption, installed base, likelihood of reaching different customers on platforms, geography of usage, and pretty much every variable imaginable. The goal is to attempt to define the market impact of either support multiple platforms or betting on one platform. Of course none of these can be known. Observer bias is inherent in the process only because this is all about forecasting a dynamic system based on the behavior of people. But basing a product plan on a rapidly evolving and hard to define “market share” metric is fraught with problems.
During this market sizing debate, the development team is also looking at how challenging cross platform support can be. While mostly objective, just as with the market sizing studies, bias can sneak in. For example, if the developers’ skills align with one platform or a platform makes certain architectural assumptions that are viewed favorably then different approaches to platform choices become easy or difficult.
Developers that are fluent in HTML might suggest that things be done in a browser or use a mobile browser solution. Even the business might like this approach because it leverages an existing effort or business model (serving ads for example). Some view the choices Facebook made for their mobile apps as being influenced by these variables.
As the dialog continues, developers will tend to start to see the inherent engineering costs in trying to do a great job across multiple platforms. They will start to think about how hard it is to keep code bases in sync or where features will be easier/harder or appear first or even just sim-shipping across platforms. Very quickly developers will generally start to feel pulled in an impossible direction by having to be across multiple platforms and that it is just not viable to have a long-term cross-platform strategy.
The business view will generally continue to drive a view that the more sockets there are the better. Some apps are inherently going to drive the desire or need for cross-platform support. Anything that is about communications for example will generally argue for “going where the people are” or “our users don’t know the OS of their connected endpoints” and thus push for supporting multiple platforms. Apps that are offered as free front ends for services (online banking, buying tickets, or signing up for yoga class) will also feel pressures to be where the customers are and to be device agnostic. As you keep going through scenarios the business folks will become convinced that the only viable approach is to be on all the popular platforms.
That puts everyone in a very tense situation—everyone is feeling stressed about achieving success. Something has to give though.
We’ve all been there.
Pattern
The industry has seen this cross-platform movie several times. It might not always be the same and each generation brings with it new challenges, new technologies, and potentially different approaches that could lead to different outcomes. Knowing the past is important.
Today’s cross-platform challenge can be viewed differently primarily because of a few factors when looking at the challenge from an app developer / ISV:
- App Services. Much of the functionality for today’s apps resides on software as a service infrastructure. The apps themselves might be viewed as fairly lightweight front ends to these services, at least for some class of apps or some approaches to app building. This is especially true today as most apps are still fairly “first generation”.
- Languages and tools. Today’s platforms are more self-contained in that the languages and tools are also part of the platform. In previous generations there were languages that could be used across different platforms (COBOL, C, C++) and standards for those languages even if there were platform-specific language extensions. While there are ample opportunities for shared libraries of “engine” code in many of today’s platforms, most modern platforms are designed around a heavy tilt in favor of one language, and those are different across platforms. Given the first point, it is fair to say that the bulk of the code (at least initially) on the device will be platform specific anyway.
- Integration. Much of what goes on in apps today is about integration with the platform. Integration has been increasing in each generation of platform shifts. For example, in the earliest days there was no cross-application sharing, then came the basics through files, then came clipboard sharing. Today sharing is implicit in nearly every app in some way.
Even allowing for this new context, there is a cycle at work in how multiple, competing platforms evolve.
This is a cycle so you need to start somewhere.
Initially there is a critical mass around one platform. As far as modern platforms go when iOS was introduced it was (and remains) unique in platform and device attributes so mobile apps had one place to go and all the new activity was on that platform. This is a typical first-mover scenario in a new market.
Over time new platforms emerge (with slightly different characteristics) creating a period of time where cross-platform work is the norm. This period is supported by the fact that platforms are relatively new and are each building out the base infrastructure which tends to look similar across the new platforms.
There are solid technical reasons why cross-platform development seems to work in the early days of platform proliferation. When new platforms begin to emerge they are often taking similar approaches to “reinventing” what it means to be a platform. For example, when GUI interfaces first came about the basics of controls, menus, and windows were close enough that knowledge of one platform readily translated to other platforms. It was technically not too difficult to create mapping layers that allowed the same code to be used to target different platforms.
During this phase of platform evolution the platforms are all relatively immature compared to each other. Each is focused on putting in place the plumbing that approaches platform design in this new shared view. In essence the emerging platforms tend to look more similar that different. The early days of web browsers–which many believed were themselves platforms–followed this pattern. There was a degree of HTML that was readily shared and consistent across platforms. At least this was the case for a while.
During this time there is often a lot of re-learning that takes place. The problems solved in the previous generation of platforms become new again. New solutions to old problems arise, sometimes frustrating developers. But this “new growth” also brings with it a chance to revisit old assumptions and innovate in new ways, even if the problem space is the same.
Even with this early commonality, things can be a real challenge. For example, there is a real desire for applications to look and feel “native”. Sometimes this is about placement of functionality such as where settings are located. It could be about the look or style of graphical elements or the way visual aspects of the platform are reflected in your app. It could also be about highly marketed features and how well your app integrates as evidence for supporting the platform.
Along the way things begin to change and the platforms diverge because of two factors. First, once the plumbing common to multiple early platforms is in place, platform builders begin to express their unique point of view of how platform services experiences should evolve. For example, Android is likely to focus on unique services and how the client interacts with and uses those services. To most, iOS has shown substantially more innovation in client-side innovation and first-party experiences. The resulting APIs exposed to developers start to diverge in capabilities and new API surface areas no longer seem so common between platforms.
Second, competition begins to drive how innovation progresses. While the first mover might have one point of view, the second (or third) mover might take the same idea of a service or API but evolve it slightly differently. It might integrate with backends differently or it might have a very different architecture. The role of voice input/reco, maps, or cloud storage are examples of APIs that are appearing on platforms but the expression of those APIs and capabilities they support are evolving in different ways that there are no obvious mappings between them.
Challenges
As the platforms diverge developers start to make choices about what APIs to support on each platform or even which platforms to target. With these choices come a few well known challenges.
- Tools and languages. Initially the tools and languages might be different but things seem manageable. In particular, developers look to put as much code in common languages (“platform agnostic code”) or implement code as a web service (independent of the client device). This is a great strategy but does not allow for the reality that a good deal of code (and differentiation) will serve as platform-specific user experience or integration functionality. Early on tools are relatively immature and maybe even rudimentary which makes it easier to build infrastructure around managing a cross-platform project. Over time the tools themselves will become more sophisticated and diverge in capabilities. New IDEs or tools will be required for the platforms in order to be competitive and developers will gravitate to one toolset, resulting in developers themselves less able to context switch between platforms. At the very least, managing two diverging code bases using different tools becomes highly challenging–even if right now some devs think they have a handle on the situation.
- User interaction and design (assets). Early in platform evolution the basics of human interaction tend to be common and the approaches to digital assets can be fairly straight forward. As device capabilities diverge (DPI, sensors, screen sizes) the ability for the user interaction to be common also diverges. What works on one platform doesn’t seem right on another. Tablet sized screens introduce a whole other level of divergence to this challenge. Alternate input mechanisms can really divide platform elements (voice, vision, sensors, touch metaphors).
- Platform integration. Integrating with a platform early on is usually fairly “trivial”. Perhaps there are a few places you put preferences or settings, or connect to some platform services such as internationalization or accessibility. As platforms evolve, where and how to integrate poses challenges for app developers. Notifications, settings, printing, storage, and more are all places where finding what is “common” between platforms will become increasingly difficult to impossible. The platform services for identity, payment, and even integration with third party services will become increasingly part of the platform API as well. When those APIs are used other benefits will accrue to developers and/or end-users of apps—and these APIs will be substantially different across platforms.
- More code in the service. The new platforms definitely emphasize code in services to provide a way to be insulated from platform changes. This is a perfect way to implement as much of your own domain as you can. Keep in mind that the platforms themselves are evolving and growing and so you can expect services provided by the platform to be part of the core app API as well. Storage is a great example of this challenge. You might choose to implement storage on your own to avoid a platform dependency. Such an approach puts you in the storage business though and probably not very competitively from a feature or cost perspective. Using a third party API can pose the same challenge as any cross-platform library. At the same time, the platforms evolve and likely will implement storage APIs and those APIs will be rich and integrate with other services as well.
- Cross-platform libraries. One of the most common approaches developers attempt (and often provided by third parties as well) is to develop or use a library that abstracts away platform differences or claims to map a unique “meta API” to multiple platforms. These cross—platform libraries are conceptually attractive but practically unworkable over time. Again, early on this can work. Over time the platform divergence is real. There’s nothing you can do to make services that don’t exist on one platform magically appear on another or APIs that are architecturally very different morph into similar architectures. Worse, as an app developer you end up relying on essentially a “shadow” OS provided by a team that has a fraction of the resources for updates, tooling, documentation, etc. even if this team is your own dev team. As a counter example, games commonly use engines across platforms, but they rely on a very narrow set of platform APIs and little integration. Nevertheless, there are those that believe this can be a path (as it is for games). It is important to keep in mind that the platforms are evolving rapidly and the customer desire for well-integrated apps (not just apps that run).
- Multiple teams. Absent the ability to share app client code (because of differing languages), keeping multiple teams in sync on the same app is extremely challenging. Equally challenging is having one team time slice – not only is that mentally inefficient, maintaining up to date skills and knowledge for multiple platforms is challenging. Even beyond the basics of keeping the feature set the same, there are problems to overcome. One example is just timing of releases. It might be hard enough to keep features in sync and sim ship, but imagine that the demand spike for a new release of your app when the platform changes (and maybe even requires a change to your app). You are then in a position to need a release for one platform. But if you are halfway done with new features for your app you have a very tricky disclosure and/or code management challenge. These challenges are compounded non-linearly as the number of platforms increases.
These are a few potential challenges. Not every app will run into these and some might not even be real challenges for a particularly app domain. By and large, these are the sorts of things that have dogged developers working cross-platform approaches across clients, servers, and more over many generations.
What’s next?
The obvious question will continue to be debated, which is if there is a single platform winner or not. Will developers be able to pick a platform and reach their own business and product goals by focusing on one platform as a way of avoiding the issues associated with supporting multiple platforms?
The only thing we know for sure is that the APIs, tools, and approaches of different platforms will continue to evolve and diverge. Working across platforms will only get more difficult, not easier.
The new platforms moved “up the stack” and make it more difficult for developers to isolate themselves from the platform changes. In the old days, developers could re-implement parts of the platform within the app and use that across platforms or even multiple apps. Developers could hook the system and customize the behavior as they saw fit. The more sealed nature of platforms (which delivers amazing benefits for end-users) makes it harder for developers to create their own experience and transport it across platforms. This isn’t new. In the DOS era, apps implemented their own printing subsystems and character-based user models all of which got replaced by GUI APIs all to the advantage of developers willing to embrace the richer platforms and to the advantage of customers that gained a new level of capabilities across apps.
The role of app stores and approval processes, the instant ability for the community to review apps, and the need to break through in the store will continue to drive the need to be great apps on the chosen platforms.
Some will undoubtedly call for standards or some homogonization of platforms. Posix in the OS world, Motif in the GUI world, or even HTML for browsers have all been attempts at this. It is a reasonable goal given we all want our software investments to be on as many devices as possible (and this desire is nothing new). But is it reasonable to expect vendors to pour billions into R&D to support an intentional strategy of commoditization or support for a committee design? Vendors believe we’re just getting started in delivering innovation and so slowing things down this way seems counter-intuitive at best.
Ultimately, the best apps are going to break through and I think the best apps are going to be the ones that work with the platform not in spite of it and the best apps won’t duplicate code in the platform but work with platform.
It means there some interesting choices ahead for many players in these ecosystems.
–Steven
# # # # #
Delegating or micromanaging, threading the needle
Micromanagement can be a reflection of a manager’s feedback and concerns about progress. Empowerment can create a detached or worried manager. Threading the needle between delegation and micromanagement is central to the relationship between a manager and a report. How do you balance this as either a manager or employee?
Be sure to check out the poll results at the end of this post on the topic of why meetings are so ineffective. This week’s poll is https://www.surveymonkey.com/s/NTSCCCK.
A first year MBA student made the following observation:
High-performing people generally want autonomy to get things done without anyone micromanaging them. At the same time, as a midlevel manager, I’ve often had someone above me who’s holding me accountable for whatever my direct reports are working on.
I’m struggling to find the right balance between giving people their autonomy while also asking sufficient questions to get the detail I need in order to feel comfortable with how things are going.
This situation is not uncommon and represents a most fundamental challenge in any management hierarchy. The situation boils down to a manager feeling accountable, employees wanting the freedom to do the work the best way they know how, and those outside this context assuming all is functioning well.
Here are 5 suggestions for improving the delegation process and avoiding the label of micromanagement:
- Delegate the problem, don’t solve it. The first sign of micromanaging is when delegating a project you also delegate the specifics of the solution. While that makes sense in some fields, in creative or information work, being told up front the steps to follow makes one feel like a vendor and not a partner in the work. This type of delegation doesn’t have the feeling that it enhances skills or career. If the steps are well-known then perhaps there is a different view of the problem or delegation that will better suit a creative member of the team.
- Share experiences, don’t instruct. As the work progresses there’s a chance that the manager will see a pattern or similar situation arise. There’s a good chance the way that experience is communicated can come across as either “sage sharing of experiences” or “more micromanaging”. If there are experiences to share then share the story and allow the learning to take place by allegory and not turn the learning into “just do these steps”.
- Listen to progress, don’t review it. Just as managers should be delegating the problem, not the steps to solving it, when it comes time for progress to be reported it is best to let folks report on the progress the way it works best. Micromanaging can also take the form of being specific about how progress should be reported or “summoning” people to review the progress. If folks have been asked to take on a project, make sure they have the freedom to define the mechanics of the project as well.
- Provide feedback, don’t course correct. Things might not be always going as well as everyone wants and when that happens managers can sometimes slip into “gotta get this fixed” mode. This type of course correction can remove many of the downstream benefits of delegation and turn into a big negative for folks. It not only disempowers, but demotivates. When things aren’t going well, the time is right for honest feedback and a two-way dialog.
- Communicate serendipitously, don’t impede progress. All projects have more work and less time than they need. One way to reduce the amount of time available to make forward progress is for management to call for reviews or updates in a formal manner (meetings, written reports). This type of communication can slow things down—the preparation, the review, the general stand-down while these work products are created. If management is concerned about how things are going, then make it a point of finding the balance between serendipitous contact with the team and bugging them too much.
Above all, treat folks as you would like to be treated and validate that approach. If you are the type of person that is eager to request and receive feedback then chances are you won’t see an eager manager as micromanaging you. But if you are the type of person that likes some elbow room and your manager is the eager provider of feedback, then that mismatch is likely to be perceived as micromanagement rather than empowering delegation.
The simple solution to this potential dilemma is to communicate about these stylistic expectations before the work really starts. Even if you’ve worked together for a while and have a rhythm, a new project might come with new approaches for working together.
Delegation can take the form of management asking for work from the team or it can take the form of “we’re all in this together”. The question to ask yourself is if you delegate work so you’re part of “us” or “them”?
What are some tools you use for effective delegation? Check out the poll – https://www.surveymonkey.com/s/NTSCCCK.
–Steven Sinofsky
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 meeting 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
# # # # #
Applying the benefits of Yoga to product development and vice versa
The physiological benefits of exercise are well known, and regular exercise can also bring benefit to your work. Any exercise will do of course, starting with just walking as often as possible. The summer brings with it opportunities for broad ranges of outdoor activities. Almost all health studies point to the need for rigorous exercise to be a regular part of your routine in order to achieve the maximum benefit for health and work productivity.
Please be sure to take the survey on exercise and productivity found here.
Yoga is an especially good exercise for those that value a routine (or require a routine to better stick to a program). Rain or shine, hot or cold, day or night, yoga is always there. Centuries old, the health benefits of yoga are highly regarded by practitioners around the world and many religions, psychologists and biologists agree that taking time to rest, focus and center is an important part of human productivity. In the US, a variety of styles of yoga performed in room heated anywhere from 90 to 105+ degrees F has become increasingly popular. The heat provides additional benefits and an extra level of challenge as well. If you value routine, Bikram yoga is especially good since it is precisely the same every class.
Yoga’s history is rooted in meditation and ritual and for many today the spiritual aspect is the high order bit. For others, the spiritual side of yoga is appreciated in the context of other beliefs or just your daily personal life. Even the aum (om) sign or chant carries with it a deep ritual meaning for some as well as a more personally defined spiritual meaning for others.
I was asked about practicing yoga at the All Things D conference by Katie Boehret and she captured a few seconds on the KatieCam. I wanted to elaborate on the benefits by using 5 sayings/expressions that I’ve learned from many of the wonderful yoga instructors I’ve had over the years.
- Be present. At the start of most yoga classes, instructors will remind everyone to “be present”. That means to set aside all that is going on outside the class and to spend the next 90 minutes present in the room, on your mat, and in the practice–no electronics or distractions. How often at work do things outside the context of what you’re working on interfere with the work—did you bring the challenges from the previous meeting into the next meeting or is something going on outside work showing through how you are at work? Take the time at the start of a day, as a meeting starts, or while coding to be present in what you’re doing.
- All that matters is on your mat. Yoga is not a competitive sport.* Yoga is not a race—you can’t finish first, you can’t be faster or lift more. Yoga is about making sure you are focused on what you can do best and that you are doing your best at that. So when practicing, making sure you’re focused on what you are supposed to be focused on is a path to success. The workplace isn’t a competitive sport either. In the workplace, this can mean doing the work you’re supposed to be doing and assuming those around you are doing the same.
- Drishti. Focus is a big part of Yoga. If you lose focus during some balancing pose you probably just fall over. Or if you lose focus on your breathing you very quickly hyperventilate and get exhausted or just turn blue! Drishti is a Sanskrit word that means focus, but a distinct form of focus. You focus but not so intensely that you lose sight of all around you. Rather it is the opposite, where you focus but with a full awareness of the rest of your mat and body. So rather than staring at a dot on the wall in front of you, you gaze at the dot but focus on breathing, your balance, and more. In software projects it is important to be focused—but if you’re too head’s down you miss important connections to what is going on around you or around the code. The full definition of drishti means vision, point of view, or even intelligence and wisdom. It also means being equal in all directions you look and maintaining self-control. A lot of collaboration in product development can be summed up in drishti.
- Yoga practice is not yoga perfect. Many “Type A” personalities find a way to compete in exercise—running times, weight lifted, miles biked and so on. Yoga is designed for life long exercise. There’s always more to do or a way to connect one pose to another you never thought of. Any yogi who has browsed the advanced videos online is quickly humbled by what they cannot do. During those difficult postures, yoga instructors always remind the class that yoga is a practice and it is not called yoga perfect. You do the best you can with the body you have that day, and you commit to practicing the next day. Product development is like this as well—we often say the enemy of the good is the perfect. No product is perfect, but the least perfect product is one that doesn’t ship. Shipping gives you the right to come back the time with improvements and a better product based on what you learned as a team.
- How you do anything is how you do everything. In class, especially when it is hot, you can easily find a way to slack off or find a way to do a pose that might look like you’re posing but in reality you are missing the benefits. Of course you’re just cheating yourself. When an instructor sees this you might hear the most gentle of reminders, “how you do anything is how you do everything”. Put simply this just means that if you are willing to take a shortcut on one pose then where else in life (or in your product) are you willing to take a shortcut. If you’re willing to cheat yourself out of your best efforts, then won’t you cheat others? Always put forth your best efforts, even when you’re pushed to the point of thinking you can’t possibly continue.
That’s a yoga perspective on exercise and well-being that are critical parts of contributing to your work, your project, and your team. While yoga has been my personal approach, what is really important is that you find your approach to physical and mental well-being. Whatever that might be is sure to be a critical tool in your own success.
What do you do to maintain your physical as well as spiritual health in the workplace? What lessons do you bring back to the workplace from your avocation?
Namaste,
Steven Sinofsky
*While controversial there do exist yoga competitions — check this out.
Sharing some learning – a few observations from “D11”
This past week the 11th All Things D Conference, D11, was held. It is such a great opportunity to attend and to learn from a great combination of interviews, speakers, demonstrations, questions, and attendees. Attending this conference has been a very valuable learning experience for me over the years and I’ve always made it a point to reflect and share some observations or learnings that stuck with me. This year is no different.
As with all events these days, so much of what happens at the event is tweeted, live blogged, re-blogged, etc. That makes it challenging to offer more by way of learning. If you’re interested in the details of the sessions, by all means watch the videos or see the official coverage on the All Things D, D11 Conference site. All the interviews are done by one or both of Walt Mossberg and Kara Swisher. There you’ll also find some behind the scenes “KatieCam” videos shot by WSJ writer Katherine Boehret in a more relaxed setting as speakers left the stage and other behind the scenes videos and articles by teh ATD writing team. Definitely check out the amazing photos from Asa Mathat (and team) that really capture the unique qualities of the conference.
“The Dialog”
For me what separates D from other events, if you had to pick one thing, is the dialog that takes place. While the format is an interview, I see it as more of a dialog. There are no slides, no setup, and after the interview the dialog continues with audience questions and then even more in the hallways during breaks (not to mention the electronic dialog). I feel sometimes in an effort to report the event as news, the back and forth or the dialog itself can get a bit de-prioritized.
The dialog is important because the timing of the conference is the same every year. That means not every speaker has something to announce or launch. In fact some speakers have announcements already scheduled for the future and even with a lot of pushing they still aren’t going to preempt their organization’s efforts. This means that speakers sign up to attend knowing there are definitely questions they will get that must go unanswered. I think that speaks volumes to the appreciation for the dialog and participation that speakers share.
Still, that can be a tiny bit frustrating for folks reading about the accounts—you are hoping for news but don’t get any. There is a slightly different tone “in the room” which I am hoping to convey through these notes. The tone is very much about the nuance and subtlety of the topics being raised. So even if there is not news, the conversation is interesting. It is an important part of innovation and convergence of industries (the original and ongoing theme of the conference was how media, entertainment, and digital technologies are coming together). There are gems in most every session if you watch the video—not necessarily news gems, but articulation of challenges and tradeoffs that everyone is facing as they do their work. Making products is never a stark either/or set of choices and capturing these tradeoffs on stage, in the “hot seat” as it is called, is something I appreciate very much.
Big picture
There were 25 speakers along with demo sessions. The breadth of topics discussed delivers on the promise of the conference. Through the lens of product development there were a number of “themes” that surfaced for me:
- Mobile “era” – No one doubts the era we are in as an industry and across industries. The tech folks were “mobile first” from apps to advertising, not as a place to port to or also support. The entertainment folks see mobile as a place to enjoy entertainment or as the screen that accompanies entertainment, not as a competitor to television. Even attendees were mostly seen on their mobile devices most of the time. While this might not seem newsworthy, observing the changing perspectives over the years of the conference provides a neat context for this change.
- Disruption – Most tech conferences are about disruption in some form or another. This conference came about during a time when disruption was really happening (and to be fair, the WSJ and ATD are/were both part of disruptive dialogs over the years—and the topic of conversation at the show). The interviews always do a good job of confronting speakers who are viewed as participants in a potential disruption.
- Sensors – The role of sensors as part of the baseline experience for computing is front and center. There was a lot of discussion around form factors, wearables, and scenarios but all of this is rooted in devices that know about surroundings, which means products can be designed knowing the computers will have these capabilities.
- Consumerization – Walt Mossberg has always taken the non-techie, consumer approach to looking at technology which, as he said during the show, was somewhat heretical when he first started his column. These days the notion of consumers driving the experience and setting the bar does not seem so far-fetched. You know that is the case when the CEO of Cisco says “bring your own device trumps security”.
- Embrace of digital – In past years the “content” attendees appeared more on the defense than the offense. While the business challenges remain in some parts of the content space, I think there is far more of a sense of embrace and partnering going on between the tech and content parties. In general it felt to me like much more of a healthy dialog rooted in respect than in past years, which is a positive evolution.
Sessions
As mentioned, the sessions are all available on the D11 site along with live blogs done by WSJ/ATD reporters. Check those out for sure. I just wanted to offer some additional observations from a small set of sessions that hit close to home from a product development perspective. Inclusion / omission or number of points below are not indications of quality or importance!
Apple / Tim Cook
- Measuring what counts – There was a strong focus on measuring usage as a way of looking at success. This contrasted with the recent debate about market share (units or revenue). The depth usage of iOS devices is significantly more than competing devices. It is super interesting to think about how to inform product development when balancing existing depth usage, new users, and growth – very interesting.
- Relative to Android – The dialog turned to defining “winning” along the lines of usage, customer satisfaction, and even the amount of commerce done on iOS devices.
- Magic – There was a good discussion about how working across the team needs to focus on the intersection of hardware/software/services as being where the “magic happens”. Everyone in the product space knows that wherever seams exist there is an opportunity to innovate or for there to be challenges–seams can be found all over the place, especially as a product gets larger or an ecosystem around the product develops.
- Tradeoffs – As an example of the nuance/subtlety that is hard to capture, Cook tried to walk through some of the tradeoffs that go into making different sized devices for different “segments” (Walt’s description). He talked about color correctness, white balance, battery life, brightness, and more. A favorite expression from Cook was “customers expect Apple to weigh all these factors and decide things” along with the humble notion that deciding means shipping and learning. I personally love when the dialog turns to these types of issues at this “level” in an organization and also externally—real engineering stuff that is worth talking about in an open way.
- Openness and control – In talking about the difference between iOS and Android (using keyboards as an example), Cook was asked about opening up more. He talked about the challenges and tradeoffs involved in “putting the customer at risk” with some times of APIs and openness but committed to more openness at the upcoming WWDC. Again there was a very interesting and subtle discussion about the tradeoffs involved.
Facebook / Sheryl Sandberg
- Mobile is good for Facebook – There were a lot of numbers and support for how much engagement there is from both users and advertisers on mobile.
- Increasing engagement – Sandberg shared some numbers that were counter-intuitive for many (as evidenced by the reaction in the section I was sitting) when she talked about the increase in engagement. Five years ago 50% of people visited every day. Now 58% visit every day and the number of users is much higher.
- Priorities – I loved when she talked about how they have 5000 people to build and operate a service for a billion people. That puts the product development challenge in perspective.
- Mobile first – There is a strong “pivot” in the development team around mobile first. Whereas the browser used to be the primary target and the mobile teams would be playing catch-up, now nothing gets done without it being mobile first.
- Facebook Home – The challenges of doing an offering that is polarizing for sure. She cited that customer reviews are either 1 star or 5 stars. Home is a V1 and expect to deliver on the commitment to frequent changes/updates.
Disney Parks and Resorts / Tom Staggs
- My Magic Plus – This session was about a new way to enjoy a WDW (Walt Disney World) theme park visit—essentially you wear a “magic band” around your wrist (like a Jawbone Up or Fitbit). As someone who grew up in Orlando watching WDW go from the Magic Kingdom surrounded by orange groves to what it is today, I think the revolution that is going on with this innovation is amazing and far-reaching.
- Features – Wearing the band provides an experience with reduced anxiety, less waiting, more fun, and far more personal. And it is just starting. An amazing example I loved was how you could order the food you want and when you get to the restaurant you sit down and what you ordered just shows up. Neat. But what is really neat is that the employees can focus on being “hosts” and not the transactional elements of ordering and getting things right. Super cool. It certainly makes that summer job at Disney a lot more fun!
- Senses and sensors – Of course this is all about location aware, cloud experienced. But the way Staggs described it was “360-5” as a 360 degree experience for all 5 senses—you’re immersed in the experience beyond the rides. In general, this was a demonstration that unfolded super well—as I thought of questions they got answered moments later. So much opportunity on this platform.
Twitter / Dick Costolo
- “Social soundtrack” – Twitter was described as the second screen for television. It is viewed as a complement to broadcast. This was a statement that gets broadened to mean that Twitter is not itself thinking about making content or distributing it.
- Global town square – The way they think of Twitter is to think about both planned/unplanned events and to provide an unfiltered/inside out platform for the people “the event is happening to”. This town square is public, real-time, conversational, and distributed. From a product point of view, the clarity of this framework is incredibly valuable.
- Advertising – Costolo discussed how advertisers are coming to understand that being part of the conversation is important and how the idea of having a conversation as the canvas versus the ad itself as the canvas is important.
- Design – Another subtle part of the dialog was around where the openness of the Twitter platform will be. The idea is that Twitter does want to own the timeline experience for customers but still be open to thousands (100s of thousands) of developers with fairly lightweight rules. Simplicity is a major focus on the design of the timeline experience.
Glow / Max Levchin
- Demonstration – this was a demonstration of a new product that brings data and mobility to the challenges of procreation and fertility.
- App – The app is focused on being a beautiful source of telemetry and information for both the man and woman planning together to conceive a child.
- Data – Turns out that there is tons of data which is hard for people to get hold of and include in their planning and efforts. Glow is a way to bring this data to the solution space for people.
- Funding – The data shows that with the right use of data “infertility” can drop way down and thus the overall cost to the healthcare system is much lower. To support this the way the product will work is essentially to create a pool for people who are still unable to conceive after using the tool, which is a much smaller number than would be using less data-informed tools.
- Innovation – This is truly innovative when it comes to the problem space–hearing Levchin describe a typical way physicians handle this sounds almost like “country medicine” compared to using the data, telemetry, and an app. Combining data, mobility, and more into this app shows how empowering all the technology can be. We’re all able to start experience this notion of being in so much more control of our lives with these technology tools.
Box / Aaron Levie and Cisco / John Chambers
- What fun – This was such a fun pairing as the contrast between the people and companies was so interesting. Yet at the same time, both organizations are developing products for a new world where individuals are far more empowered. While no one is going to go out and buy their own router, the IT pros that do want to have the capability for you to use the router when you bring in your own device. A fun part of D in general is when you can see widely different perspectives in a dialog about a problem space each is approaching.
- IT control – Chambers asserted that the ability for IT to “say no” really changed 4 or 5 years ago and now enterprises need to catch up to consumer technologies and support them. Chambers even said “BYOD trumps security”.
- Disruption – Levie offered a wonderful example of how companies are handling disruption. He said that the three biggest Box customers are companies formed in the 1800’s. This speaks to how much change is going on among IT pros.
Disney Media / Anne Sweeney and Producer / I. Marlene King
- Twitter integration – It was fascinating to hear the content developer view of creating content knowing that Twitter is part of the viewing equation. There’s a clear perspective that Twitter is contributing to the experience and enjoyment of the show.
- OMG moments – I loved hearing about the way they essentially create the show to support “OMG” or “jump off the couch” moments, and how that plays into Twitter.
- Time zones – Turns out that the audience is pretty self-governing when it comes to spoilers and time zones, which was interesting to think about.
Pinterest / Ben Silbermann
- First appearance – Ben doesn’t often appear or do presentations. It is great to see him.
- Framing – Another great example of framing the goals of the product: Pinterest aims to help people “discover things they really love and inspire them to experience them in real life.”
- Early users – From a product development perspective, he spoke about how early users ended up setting the tone of the product when it comes to passion.
- Last web app? – Kara asked if Silbermann thought that Pinterest might be the “last web first app” or not. The answer focused on starting off where people were but now today of course the goal is to be able to use the service wherever you are and of course a ton of that is mobile which overtook the PC along the lines of industry trends.
Tesla, SpaceX, Hyper Tube / Elon Musk
- Along with everyone at D11 and online, this was an incredible treat.
- “Mars is a fixer upper” – as far as planets go, Musk said Mars is our best bet for life on another planet since it can be fixed up relatively easily.
- Every tech takes 3 or 4 generations to get it to mass market. He walked through the original Tesla plan (high price/low volume, mid-price/mid volume, low price/high volume). He framed this as competing with a hundred years and trillion dollar investment in gas combustion. This is a great example of how disruption gets talked about in early stages – all the focus on whether electric cars can displace gas cars using the criteria gas cars developed over all this time. From a product point of view, this perspective is super interesting.
— Steven Sinofsky
# # # # #
Conversation #38– disrupt or die
Anyone worth their salt in product development knows that listening to customers through any and all means possible is the means to innovation. Wait a minute, anyone worth their salt in product development knows that listening to customers leads to a faster horse.
Deciding your own product choices within these varying perspectives is perhaps the seminal challenge in product development, tech products or otherwise. This truly is a tyranny of or, but one in which changing the rules of the game is the very objective.
In this discussion, which is such a common dialog in the halls of HBS as well tech companies everywhere it should probably be a numbered conversation (for this blog let’s call this Conversation #38 for shorthand—disrupt or die).
For a recent discussion about why it is so difficult for large companies to face changes in the marketplace, see this post Why Corporate Giants Fail to Change.
“Disrupt or die” or “disrupt and die”?
Failure to evolve a product as technologies change or as customer scenarios change is sure to lead to obsolescence or elimination from the marketplace. It is difficult to go a day in tech product development without hearing about technology disruption or “innovator’s dilemma”. The biggest fear we all have in tech is failing to keep up with the changing landscape of technologies and customers, and how those intersect.
At the same time, hopefully we all get to that lucky moment when our product is being used actively by customers who are paying. We’re in that feedback loop. We are improving the product, more is being sold, and we’re on a roll.
That’s when innovation over time looks like this:
In this case as time progresses the product improves in a fairly linear way. Listening to customers becomes a critical skill of the product team. Product improvements are touted as “listening to customers” and things seem to go well. This predictability is comforting for the business and for customers.
That is, until one day when needs change or perhaps in addition a new product from a competitor is released. Seemingly out of nowhere the great feedback loop we had looks like it won’t help. If we’re fortunate enough to be in tune to changing dynamics outside our core (and growing) customer base we have time to react and change our own product’s trajectory.
That’s when innovation looks like this:
This is a time when the market is receptive to a different point of view, and a different product — one that redefines, or reimagines, the category. Sometimes customers don’t even realize they are making a category choice, but all of a sudden they are working differently. People just have stuff to get done and find tools that help.
We’re faced with what seems like an obvious choice—adjust the product feature set and focus to keep up with the new needs of customers. Failing to do so risks losing out on new sales, depth usage, or even marginalization. Of course features/capabilities is a long list that can include price, performance, battery life, reliability, simplicity, APIs, different integration points or service connections, and any other attributes that might be used by a new entrant to deliver a unique point of view around a similar scenario.
Many folks will be quick to point out that such is only the case if a new product is a “substitute” for the product people are newly excited about. There is truth to this. But there is also a reality shown time and time again which gets to the heart of tech bets. It is almost always the case that a new product that is “adjacent” to your product has some elements of more expensive, more complex in some dimensions, less functional, or less than ideal. Then what seems like an obvious choice, which is to adjust your own product, quickly looks like a fool’s bet. Why would you chase an inferior product? Why go after something that can’t really replace you?
The examples of this are too numerous to count. The iPhone famously sucked at making phone calls (a case where the category of “mobile phone” was under reinvention and making calls turned out to be less important). Solid State storage is famously more expensive and lower capacity than spindle drives (a case where the low power, light weight, small size are more valued in mobile devices). Of course tablets are famously unable to provide apps to replace some common professional PC experiences (a case where the value of mobility, all day battery life, always connected seem more valued than a set of platform capabilities). Even within a large organization we can see how limited feature set cloud storage products are being used actively by employees as “substitutes” for enterprise portals and file shares (a case where cross-organization sharing, available on the internet, and mobile access are more valued than the full enterprise feature set). The list goes on and on.
As product managers we all wish it was such a simple choice when we face these situations. Simply leapfrog the limited feature set product with some features on our profitable product. Unfortunately, not every new product that might compete with us is going to disrupt us. So in addition to facing the challenges of evolving the product, we also have to decide which competitors to go after. Often it takes several different attempts by competitive products to offer just enough in the way of new / different approaches to begin to impact an established product.
Consider for example of how much effort the Linux community put into desktop Linux. And while this was going on, Android and iOS were developed and offered a completely different approach that brings new scenarios to life. A good lesson is that usually a head-on alternative will quite often struggle and might even result in missing other disruptive technologies. Having a unique point of view is pretty important.
The reality of this situation is that it is only apparent in hindsight. While it is going on the changes are so small, the product features so minimal, and the base of the customers choosing a new path so narrow that you don’t realize what is going on. In fact, the new product is also on an incremental innovation path, having attained a small amount of traction, and that incremental innovation rapidly accumulates. There is a tipping point.
That is what makes acting during such a “crisis” so urgent. Since no one is first all the time (almost by definition when you’re the leader), deciding when and how to enter a space is the critical decision point. The irony is that the urgency to act comes at a time when it appears from the inside to be the least urgent.
Choosing to innovate means accepting the challenges
We’ve looked at the landscape and we’ve decided as a team that our own product needs to change course. There is a real risk that our product (business) will be marginalized by a new entry adjacent to us.
We get together and we come up with the features and design to go after these new scenarios and capabilities.
The challenge is that some of what we need to do involves changing course—this is by definition what is going on. You’re Apple and you decide that making phone calls is not the number 1 feature of your new mobile phone or your new tablet won’t run OS X apps. Those are product challenges. You also might face all sorts of challenges in pricing, positioning, and all the things that come from having a stable business model. For example, your competitor offers a free substitute for what you are selling.
The problem is your existing customers have become conditioned to expect improvements along the path we were traveling together. Worse, they are by definition not expecting an “different” product in lieu of a new version of their favorite product. These customers have built up not just expectations, but workflows, extensions, and whole jobs around your product.
But this is not about your existing and best customers, no matter how many, it is about the foundation of your product shifting and you’re seeing new customers use a new product or existing customers use your product less and less.
Moving forward the product gets built and it is time to get it into market for some testing or maybe you just release it.
BOOM!
All that work your marketing team has done over the years to establish what it means to “win” in the space that you were winning is now used against you. All the “criteria” you established against every competitor that came along are used to show that the new product is not a winning product. Except it is not winning in the old way. What you’ve done is become your own worst enemy.
But even then, the new way appears to be the less than optimal way—more expensive, less features, more clicks, or simply not the same at doing things the product used to do.
The early adopters or influential users (that was an old term in the literature, “IEU” or sometimes “lead user”) are immediately taken aback by the change in direction. The workflows, keystroke memory, add-ins, and more are just not the same or no longer optimal–there’s no regard for the new scenarios or capabilities when the old ones are different. Worse, they project their views across all customer segments. “I can’t figure this out, so imagine how hard it will be for my parents” or “this will never be acceptable in the enterprise” are common refrains in tech.
This happens no matter who a product is geared towards or how complex the product was in the first place. It is not how it does anything but the change in how it did things people were familiar with. This could be in user experience, pricing, performance, platform requirements or more.
You’re clearly faced with a set of choices that just don’t look good. In Lean Startup, Eric Ries talks in detail about the transition from early users of a new product to a wider audience. In this context, what happens is that the early users expect (or tolerate) a very different set of features and have very different expectations about what is difficult or easy. His conclusion is that it is painful to make the transition, but at some point your learning is complete and it is time to restart the process of learning by focusing on the broader set of customers.
In evolving an existing product, the usage of a pre-release is going to look a lot like the usage of the current release. The telemetry proves this for you, just to make this an even more brutal challenge. In addition, because of the years of effort the enthusiasts put into doing things a certain way and all that work establishing criteria for how a product should work, the obvious thing to do when testing a new release is to try everything out the old release did and compare to the old product (the one you are changing course of) and then maybe some new stuff. This looks a lot like what Eric describes for startups. For products in market, the moment is pretty much like the startup moment since your new product is sort of a startup, but for a new trajectory.
Remember what brought us here, two things:
- The environment of usage or business around the product was changing and a bet was made that changes were material to the team. With enough activity in the market, someone will always argue that this change is different and the old and new will coexist and not cannibalize each other (tell that to PalmPilot owners who swore phones would be separate from calendar and contacts, or GPS makers who believe in stand-alone units, or…).
- A reminder that if Henry Ford had asked customers what they wanted from a car they would have said a faster horse. The market was conditioned to ask for and/or expect improvements along a certain trajectory and no matter what you are changing that trajectory.
All the data is flowing in that shows the new product is not the old product on the old path. Not every customer is interested in doing new things, especially the influential testers who generally focus on the existing ways of doing things, have domain expertise, and are often the most connected to the existing product and all that it encompasses. There is an irony in that for tech these customers are also the most tech-savvy.
Pretty quickly, listening to customers is looking exceedingly difficult.
If you listen to customers (and vector back to the previous path in some way: undo, product modes, multiple products/SKUs, etc.) you will probably cede the market to the new entrants or at least give them more precious time. If technology product history is any guide, pundits will declare you will be roadkill in fairly short order as you lack a strategic response. There’s a good chance your influential customers will rejoice as they can go back and do what they always did. You will then be left without an answer for what comes next for your declining usage patterns.
If you don’t listen to customers (and stick to your guns) you are going to “alienate” folks and cede the market to someone who listens. If technology product history is any guide, pundits will declare that your new product is not resonating with the core audience. Pundits will also declare that you are stubborn and not listening to customers.
All of this is monumentally difficult simply because you had a successful product. Such is the price of success. Disrupting is never easy, but it is easier if you have nothing to lose.
Many folks will be quick to say that new products are fine but they should just have the old product’s way of doing things. This can seem like asking for a Prius with a switch to turn off the battery (my 2002 Prius came with a training DVD, parking attendant reference card, and more!). There are many challenges with the “side by side” approach. The most apparent is that it only delays the change (meaning delays your entry into the new market or meeting of new scenarios). Perhaps in a world of cloud-services this is more routine where you have less of a “choice” in the change, but the operational costs are real. In client code/apps the challenge becomes very quickly doing things twice. The more complex the changes are the more costly this becomes. In software nothing is free.
Product development is a social science.
People and time
In this numbered conversation, “disrupt or die” there are a few factors that are not often discussed in detail when all the debates happen.
First, people adapt. The assumption, especially about complex tech products, is that people have difficulty or lack of desire to change. While you can always overshoot the learning people can or are willing to do, people are the most adaptable part of a system. One way to think about this is that every successful product in use today, those that we all take for granted, were introduced to a customer base that had to change behavior. We would not be where we are today without changing and adapting. If one reflects, the suboptimal change (whether for the people that are customers or the people running a business) is apparent with every transition we have made. Even today’s tablets are evidence of this. Some say they are still for “media consumption” and others say they are “productivity tools”. But behind the scenes, people (and developers) are rapidly and actively changing and adapting to the capabilities of tablets because the value proposition is so significantly improved in some dimensions.
Second, time matters. Change is only relative to knowledge people have at a moment in time and the customers you have at the moment. New people are entering the customer base all the time and there is a renewal in skills, scenarios, and usage patterns. Five years ago almost no one used a touch screen for very much. Today, touch is a universally accepted (and expected) input method. The customer base has adapted and also renewed around touch. Universities are the world’s experts at understanding this notion of renewal. They know that any change to policy at a university is met with student resistance (especially in the spring). They also know that next year, 25% of the “customer base” will be replaced. And in 3 summers all the students on campus will only know the new way. One could call that cynical. One could also call that practical.
Finally time means that major product change, disruption, is always a multi-step process. Whether you make a bet to build a new product that disrupts the market dynamics or change an existing product that disrupts your own product, it rarely happens in one step. Phones added copy/paste and APIs and even got better at the basics. The pivot is the tool of the new endeavor until there is some traction. Feedback, refinement, and balancing the need to move to a new space with the need to satisfy the installed base are the tools of the established product “pivoting” in response to a changed world. It takes time and iteration–just the same way it took time and iteration to get to the first summit. Never lose sight of the fact that disrupting is also product development and all the challenges that come from that remain–just because you’re disrupting does not mean what you do will be perfect–but that’s a given we all work with all the time. We always operate knowing there is more change to come, improvements and fixes, as we all to learn by shipping.
Part of these factors almost always demonstrate, at least in the medium term, that disruption is not synonymous with elimination. Those championing disruption often over-estimate progress towards elimination in the short term. Though history has shown the long term to be fairly predictable. Black cars are still popular. They just aren’t the only cars.
Product development choices are based on social science. There is never a right answer. Context is everything. You cannot A/B test your way to big bets or decisions about technology disruption. That’s what makes all of this so fun!!
Go change the rules of the game!
–Steven Sinofsky
Note. I believe “disrupt or die” is the name of a highly-regarded management class at General Electric’s management school.
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
###
Learning by slipping
“Slipping” or missing the intended completion or milestone date of software projects is as old as software itself. There’s a rich history of our industry tracking intended v. actual ship dates and speculating as to the length of the slip and the cause. Even with all this history, slipping is a complex and nuanced topic worth a bit of discussion about slipping as an engineering concept.
Slipping
I’ve certainly had my fair share of experience slipping. Projects I’ve worked on have run the full spectrum from landing exactly on time to slipping 20-30% from the original date. There’s never a nice or positive way to look at slipping since as an engineer you’re only as good as your word. So you can bet the end of every project includes a healthy amount of introspection about the slip.
Big software projects are pretty unique. The biggest challenge is that large scale projects are rarely “repeated” so the ability to get better through iteration keeping some things constant is limited. This is different than building a bridge or a road where many of the steps and processes can be improvements from previous projects. In large scale software you rarely do the same thing with the same approach a second or third time.
While software is everywhere, software engineering is still a very young discipline that rapidly changes. The tools and techniques are wildly different today than they were just a few years ago. Whether you think about the languages, the operating systems, or the user experience so much of what is new software today is architected and implemented in totally new ways.
Whenever one talks about slipping, at some basic level there is a target date and a reality and slipping just means that the two are not the same (Note: I’ve yet to see a software project truly finish early). There’s so much more to slipping than that.
What’s a ship date
In order to slip you need to know the ship date. For many large scale projects the actual date is speculation and of course there are complexities such as the release date and the availability date to “confuse” people. This means that discussions about slipping might themselves be built on a foundation of speculation.
The first order of business is that a ship date is in fact a single date. When people talk about projects shipping “first quarter” that is about 90 different dates and so that leaves everyone (on the team and elsewhere) guessing what the ship date might be. A date is a date. All projects should have a date. While software itself is not launching to hit a Mars orbit, it is important that everyone agree on a single date. Whether that date is public or not is a different question.
In the world of continuously shipping, there’s even more of a challenge in understanding a slip. Some argue that “shipping” itself is not really a concept as code flows to servers all the time. In reality, the developers on the team are working to a date—they know that one day they come to work and their code is live which is a decidedly different state than the day before. That is shipping.
Interestingly, the error rate in short-term, continuous projects can often (in my experience) be much higher. The view of continuously shipping can lead to a “project” lasting only a month or two. The brain doesn’t think much of missing by a week or two, but that can be a 25 – 50% error rate. On a 12 month project that can mean it would stretch to 15-18 months, which does sound like a disaster.
There’s nothing about having a ship date that says it needs to be far off. Everything about having a date and hitting it or slipping can apply to an 8 week sprint or a 3 year trek. Small errors are a bigger part of a short project but small errors can be amplified over a long schedule. Slipping is a potential reality regardless of the length of the schedule.
The key thing from the team’s perspective about a ship date is that there is one and everyone agrees. The date is supported by the evidence of a plan, specifications, and the tools and resources to support the plan. As with almost all of engineering, errors early in the process get magnified as time goes by. So if the schedule is not believable or credible up front, things will only get worse.
On the other hand, a powerful tool for the team is everyone working towards this date. This is especially true for collaboration across multiple parts of the team or across different teams in a very large organization. When everyone has the same date in mind then everyone is doing the same sorts of work at the same time, making the same sorts of choices, using the same sorts of criteria. Agreeing on a ship date is one of the most potent cross-group collaboration tools I know.
Reasons to slip
Even with a great plan, a team on the same page, and a well-known date, stuff can happen. When stuff happens, the schedule pressure grows. What are some of the reasons for slipping?
- Too much work, aka “we picked too much stuff”. The most common reason for slipping is that the team signed up to do more work than could be done. The most obvious solution is to do less stuff. In practice it is almost impossible to do less once you start (have you ever tried to cut the budget on a kitchen remodel once it starts? You cut and cut and end up saving no money but costing a lot of time.) The challenge is the inter-connected nature of work. You might want to cut a feature, but more often than not it connected to another feature either upstream or downstream.
- Some stuff isn’t working, aka “we picked the wrong architecture”. This causal factor comes from realizing that the approach that is halfway done just won’t work, but to redo things will take more time than is available. Most architecturally oriented developers in this position point to a lack of time up front thinking about the best approach. More agile minded developers assume this is a normal part of “throw away the first version” for implementing new areas. In all cases, there’s not much you can do but stick with what you have or spend the time you don’t have (i.e. slipping).
- Didn’t know what you know now, aka “we picked the wrong stuff”. No matter how long or short a project, you’re learning along the way. You’re learning about how good your ideas were or what your competitors are doing, for example. Sometimes that learning tells you that what you’re doing just won’t fly. The implications for this can run from minimal (if the area is not key) to fairly significant (if the area is a core part of the value). The result in the latter case can be a big impact on the date.
- Change management, aka “we changed too much stuff”. As the project moves forward, things are changing from the initial plans. Features are being added or removed or reworked, for example. This is all normal and expected. But at some point you can get into a position where there’s simply been too much change and the time to get to a known or pre-determined is more than the available time.
The specifics of any slip can also be a combination of these and it should be clear how these are all interrelated. In practice, once the project is not on a schedule all of these reasons for slipping begin to surface. Pretty soon it just looks like there’s too much stuff, too much is changing, and too many things aren’t “right”.
That is the nature of slipping. It is no one single thing or one part of a project. The interrelationships across people, code, and goals mean that a slip is almost always a systemic problem. Recognizing the nature of slipping leads to a better understanding of project realities.
Reality
In reality, slips are what they are and you just have to deal with them. In software, as in most other forms of engineering, once you get in the position of missing your date things get pretty deterministic pretty quickly.
In the collective memories of most large projects that slipped are the heroes or heroic work that saved a project. That could very well happen and does, but from a reliable or repeatable engineering perspective these events are circumstantial and hard to reproduce project over project. Thus the reality of slipping is that you just have to deal with it.
The most famous description of project scheduling comes from Frederic P. Brooks who authored “The Mythical Man-Month” in 1975. While his domain was the mainframe, the ideas and even the metrics are just as relevant almost 40 years later. His most famous aphorism about trying to solve a late project by adding resources is:
When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on schedule. The bearing of a child takes nine months, no matter how many women are assigned.
Software projects are generally poorly partitioned engineering – much like doing a remodel in a tiny place you just can’t have all the different contractors in a tiny place.
There are phases and parts of a project in large scale software that are very amenable to scale with more resources, particularly in testing and code coverage work, for example. Adding resources to make code changes runs right up against the classic man-month reality. Most experienced folks refer to this as “physics” implying that these are relatively immutable laws. Of course as with everything we do, context matters (unlike physics) and so there are ways to make things work and that’s where experience in management and most importantly experience as a team working together on the code matters.
The triad of software projects can be thought of as features, quality, and schedule. At any given point you’re just trading off against each of those. But if it were only that easy.
Usually it is easy to add features at the start, unaware of precisely how much the schedule or quality will be impacted. Conversely, changing features at other times becomes increasingly difficult and obviously so. From a product management/program management perspective, this is why feature selection, feature set understanding, and so on is so critical and why this part of the team must be so crisp at the start of a project. In reality, the features of a product are far less adaptable than one might suspect. Products where features planned are not delivered can sometimes feel incomplete or somehow less coherent.
It is almost impossible to ever shorten a schedule. And once you start missing dates there is almost no way to “make up for time”. If you have an intermediate step you miss by two weeks, there’s a good chance the impact will be more than two weeks by the end of a project. The developers/software engineers of a project are where managing this work is so critical. Their estimates of how long things will take and dependencies across the system can make or break the understanding of reality.
Quality is the most difficult to manage and why the test leadership is such a critical part of the management structure of any project. Quality is not something you think about at the end of the project nor is it particularly malleable. While a great test manager knows quality is not binary at a global level, he/she knows that much like error bars in physics a little bit of sub-par quality across many parts of the project compounds and leads to a highly problematic, or buggy, product. Quality is not just bugs but also includes scale, performance, reliability, security, and more.
Quality is difficult to manage because it is often where people want to cut corners. A product might work for most cases but the boundary conditions or edge cases show much different results. As we all know, you only get one chance to make a first impression.
On a project of any size there are many moving parts. This leads to the reality that when a project is slipping, it is never one thing—one team, one feature, one discipline. A project that is slipping is a product of all aspects of a project. Views of what is “critical path” will need to be reconciled with reality across the whole project, taking into account many factors. Views from other parts of the organization, the rumor mill, or just opinions of what is holding up the project are highly suspect and often as disruptive to the project as the slip itself. That’s why when faced with a slipping project, the role of management and managing through the slip is so critical.
What to do
When faced with a slip, assuming you don’t try to toss some features off the side, throw some more resources at the code, or just settle for lower quality there are a few things to work on.
First and foremost, it is important to make sure the team is not spending energy finger pointing. As obvious as that sounds, there’s a natural human tendency to avoid having the spotlight at moments like this. One way to accomplish that, improperly, is to shine the light on another part of the project. So the first rule of slipping is “we’re all slipping”. What to do about that might be localized, but it is a team effort.
What else can be done?
- Don’t move the goalposts (quality, features, architecture). The first thing to do is to avoid taking drastic actions with hard to measure consequences. Saying you’re going to settle for “lower quality” is impossible to measure. Ripping out code that might not work but you understand has a very different risk profile than the “rewrite”. For the most part, in the face of slipping the best thing to do is keep the goals the same and move the date to accomplish what you set out to do.
- Think globally, act locally. Teams will often take actions that are very local at times of slipping. They look to cut or modify features that don’t seem critical to them but have important upstream or downstream impact, sometimes not well understood on a large project. Or feature changes that might seem small can have a big impact on planned positioning, pricing, partnerships, etc. The approach of making sure everyone is checking/double checking on changes is a way to avoid these “surprises”.
- Everyone focuses on being first, not avoiding being last. When a project has more than a couple of teams contributing and is faced with a tight schedule, there’s a tendency for a team to look around to just make sure they are not the team that is worse off. A great leader I once worked with used to take these moments to remind every part of the project to focus on being first rather than focusing on being “not last”. That’s always good advice, especially when followed in a constructive manner.
- Be calm, carry on. Most of all, slipping is painful and even though it is all too common in software, the most important thing to do during crunch time is to remain calm and carry on. No one does good work in a panic and for the most part the quality of decisions and choices degrades if folks are operating under too many constraints that can’t get met. It is always bad for business, customers, and the team to slip. But if you are slipping you have to work with what you’ve got since most of the choices are usually even less desirable.
Managing a software project is one of the more complex engineering endeavors because of the infinite nature of change, complexity of interactions, and even the “art” that still permeates this relatively new form of engineering. Scheduling is not yet something we have all mastered and slipping is still a part of most large projects. The more that Software Eats the World ($), the more the challenges of software project management will be part of all product and service development.
Given that, this post tried to outline some of the causes, realities, and actions one could take in the face of learning by slipping.
–Steven Sinofsky
Learning by Shipping 