Archive for March 2013
Defining your career path: journey or destination
When asked about career path, some are quick to say things like “VP of … in 10 years” or “world’s expert in ….” Others might say “work in engineering, sales, management, and ….” Or maybe some would say “start 3 companies…IPO.” Taking a step back it is worth putting a framework around how to think about the experiences you build over time. Climbing the corporate or businesses ladders aren’t the only ways to think about careers, even though they occupy much of the energy devoted to talking about careers. Do you view your career as a journey or a destination?
Please be sure to see the three quick questions poll at the end of this post along with results from the last poll and take this post’s survey on career paths here.
For some, a professional career is a destination. From the very start, the goal is to achieve some level of proficiency or stature in your chosen field of work. The destination can be a role, a company, a level of achievement, or other specific and measurable goal.
For others, a professional career is a journey. From the very start, the goal is to experience work from a variety of perspectives in your field and adjacent field. The journey can be different companies or organizations within a big company, job types, geographies, or other varied aspects of your profession.
Destination and journey are different ways to look at career progression. While it is tempting to think of these as mutually exclusive or as a one-time choice, the reality is (as you can expect) a little less clear. Even so, you want to know not just the next step but the reasons behind next steps and how they contribute to a career path.
Destination
Many start careers with a goal of working their way “up” the chain. Going to manager, to general manager or director, to vice president, and more (gaining rank, earning tenure, making partner, etc.) defines progress. This might be exactly right for you. Setting your sights on specific and measurable milestones fits with how many view career progression.
Progression up the corporate ladder is not the only way to about your destination. In planning your next steps, one might consider two views of a destination-oriented path:
- Org leader. As an org leader you follow the path of moving “up”. While your path might involve moving laterally at times, you focus on meeting the objectives as defined by the organization for what skills and experiences enable you to move through the milestones of management.
- Domain expert. As a domain expert you follow the path of being the leader in your area in your company. For many technologists, this is ultimately where the highest satisfaction comes from. You know the ins and outs of a technology, system, or product better than anyone. You do this through years of experience and effort.
Focusing on your destination is not for everyone. This is not just a statement of skills that not everyone might have, but time and place play a role in achieving this type of goal. In most large organizations there is a fraction of the total team at “top” positions. For every VP there might be 100 or even 1000 other employees. Similarly, for every top domain expert, there may be 100 or 1000 other employees not as far along in their domain knowledge.
A destination goal is a long term play and means that during your path you will have periods that feel like you are not moving up, but that should not stop you from moving forward. You might need to take a step left or right sometimes to keep moving up. Most of all, never think that for you to move up, someone needs to move down. Most of the time with a destination oriented career your next steps are visible to you and the organization, and patience and timing play important parts of progression.
When you are set on a destination you also want to be prepared to manage through changes in the landscape.
As an org leader you are ultimately accountable for large projects or budgets, and the people that deliver on those commitments. Sometimes things don’t go as hoped and as an org leader you have to step up and accept responsibility. These become the key learning moments in your career progression.
As a domain expert, technologies change and paradigms change. The long-term domain experts are expert not in the specifics but in the solutions. As an amazing programmer you want to reinvent yourself as new languages and tools emerge. Leading the team through these discontinuities are the key learning moments in your career progression.
Journey
Many people start their careers knowing that the world is a big place waiting to be explored. They see the world through the lens of an adventurer or explorer. Going thoughtfully from one role to another or one organization to another fills your expectations of progressing through your career, or life. Setting your sites on a collection of experiences that you wish to have is the measurable way of managing your career.
Variety is not easy to measure and there is a fine line between variety and job-hopping. If the journey is your goal you want to have a clear understanding of how you intend to assemble a collection of experiences. You will move thoughtfully through these experiences and time your moves based on achieving some level of proficiency, satisfaction, and success.
In planning your journey, you might consider two views of a journey-oriented career path:
- Breadth leader. With breadth leader, you aim to have very different roles over time. You might choose to move between sales, marketing, business, or development in a product area you know and love. You might choose to move to different parts of the world to experience sales and marketing with a local flavor. You might choose to work on a variety of products within a large organization. You might even move from company to company. All of these broaden your experiences, and if you’re focused on the journey you will meet different people, learn from different perspectives, and experience your career from a variety of vantage points, absorbing these along the way as you grow and mature. Along the way you will be in a position to lead more as you gain experiences.
- Field expert. As a field expert, you collect experiences much like a domain expert but you establish breadth expertise by looking at your domain from a 360 degree view. You might be a technical expert with experience implementing such as system at different companies or you might have engineered similar systems from the ground up several times in different contexts. You seek to grow and progress through your career with depth experiences explored from different angles.
A journey career is not for everyone. You substitute the certainty of goals such as ladder levels or career stages, job titles, and pay grades with more substantial transitions. With a journey career your next steps are much more about what you seek out to achieve and less about what “comes next”. As with the explorers from another era, a journey career is driven from within and by your own desires.
On your journey, the transitions are key times you take action and plan on your next steps. Your deliberate next step makes all the difference when you reflect back on your path. Did your next step look “random” or did you have a clear rationale for choosing what you did? Think about how you might explain your steps to someone looking at your resume/CV as you explore the step after the next one.
When you choose your next step, you need to be prepared for a lot of change. You will work for new people, work with new people, and have different processes. You will need to adapt and conform. Things you thought you knew might not be right in the new context. On the other hand you will meet all sorts of new people and experience new ways of approaching the problems and challenges of business. Down the road when you have to define a process for a group, you have all your experiences and contexts to draw from to avoid repeating mistakes you might have experienced.
With a breadth leader path you might feel like you really jumped in the deep end at one transition. You might feel like you made a big mistake, going to work in a far-away place for example. Stick with it. Live through it. Adapt and grow. You will become more valuable to the team as a whole when you can call upon the collected learning. These are the learning moments on your journey.
As a field expert, you might find yourself in a familiar domain but without the resources you became accustomed to at your last role. You might wish you could call on that trusted associate or allocate budget in a way you did before, but these are not available to you. You will need to blaze a new trail or creatively solve the problem using the experience you have but applied differently. Using your domain knowledge and experience in this new context is how you learn as a field expert.
Adapting
You might reach a stage in your career where you want to settle down after many a journey. You might similarly reach a stage where it is time to explore new domains, new organizations, or just different perspectives. In other words you might find a stage in your career where the other of journey or destination becomes your new goal. Resetting your approach can be part of the journey of life.
Of course both paths have room to grow your salary and responsibility. While destination roles have high visibility in terms of material benefits, most organizations strive to have material benefits available for a broad array of people and assignments.
Keeping in mind your path and where you see the moves in your career will help you to have much more informed discussions with your managers and mentors. As a manager (or mentor), helping the members of the team to see their own desires and wishes will assist in coaching them through transitions.
If there is one piece of advice that transcends the description of your path, it is that no matter where you intend to go, the most important thing is to be excellent at what you are currently doing. When you’re doing excellent work, you create alternatives for yourself and open doors to new opportunities and paths.
–Steven Sinofsky
Three quick questions poll by Cameron
In the “Being a Leader…” post we asked three questions about your manager’s behavior and your empowerment/productivity. We had a great response from this popular post, here is what we learned together:
- Over half of you (54%) report that your manager “asks me to solve vaguely defined problems”, while only 14% report that their manager “spells out expectations in detail”
- Nearly half (48%) said that their manager “mostly edits” when reviewing their work and 45% said their manager “adds works without taking work away”
- There is nearly a 10% difference in the % of managers that provide “feedback quickly”(43%) vs. managers that provide “thoughtful, thorough feedback” (34%)
Next, we wanted to look at the relationship between your managers’ traits and your level of productivity and empowerment, both of which you ranked on a scale of 1-5, where 1 is low and 5 is high. The results were interesting:
- Those of you with managers that “mostly edit” when reviewing your work were about a point lower on the empowerment scale
- Those of you with managers that provided “thoughtful, thorough feedback” were about a point higher on the empowerment scale, but on average a half point lower on the productive scale
- Similarly, those of you with managers that use “delegation as a way to give others authority to make decisions” are a half point higher on the empowerment scale, but a half point lower on the productive scale.
- Those of you who had managers that “add work without taking work away” have a half point higher productivity
Bottom line: A consistent theme was that quality and quantity can be a trade-off, in leadership and in our deliverables. Often having both can prove difficult.
Disclaimer: As a caveat, it’s worth noting the subjective nature of these questions, and the potential bias of people taking this survey—those who likely have an interest in being an effective leader themselves.
Take this post’s survey on career paths here. Results reported with the next post. Thank you!
–Cameron
Being a leader, not a micromanaging editor: 3 patterns to avoid
As a manager, big company or small, the opportunities to lead are everywhere. Too often though we can fail to lead and fall into the trap of editing the work of others–critiquing, tweaking, or otherwise mucking with what is discussed or delivered, rather than stepping back and considering if we are truly improving on the work or just imprinting upon the work, or if we are empowering or micromanaging.
Please don’t forget to try the new poll for this post here.
Every manager faces a constant struggle as the work expands and time shrinks—it seems faster to just say “the answer” rather than let “discovery” happen organically. Finding this balance and challenging ourselves to lead not edit is difficult but key to the long term strength of the team and ability to scale as a manager.
The challenge gets to the core responsibilities of management. Management, at every level, is about the effort to frame challenges, define end states, and allocate resources to navigate between them. If the work requires smart, talented, creative people, then more than anything you want to enable folks on the team to create. When people create, they want to show off their creation and keep creating more. Redoing, reworking, and revisiting can not only drain resources and energy, but sap creative people of their desire to create.
Micromanaging by editing
Most would probably agree that the easiest and most damming insult directed at a manager is the dreaded label micromanager.
Looking beyond the rhetoric, the term editor does more to explain the dynamic. Editing the work of those you manage disempowers the team, removes accountability, and in general reduces motivation. Editing the work of others is easy—it seems like anyone can change the UX, add a feature, rewrite some text, or tweak a slide. The creative effort is coming up with the work in the first place from a blank sheet, so to speak. Of course there is a role for editing (which itself is a noble profession), but in the complex works of product development there is a great deal of context. In reality most everything follows an iceberg principle, with far more than meets the eye—the complexities and realities that came to light during creation might not always be visible once the work is packaged up for management.
For a variety of reasons theorized in this Wikipedia entry on micromanagement, managers might resort to an excessive focus on details or dive into details arbitrarily. A common element is the manager taking the work of a team member as a starting point and substituting a flawed process of editing for what could be helpful, insightful, and valued interactions more defined by proper feedback or coaching.
From the perspective of the manager, there are a number of common patterns that arise and are indicative of management needing improvement.
- Receive and rework. You glance at your mobile and that updated specification shows up. While there is an expectation to read the spec and provide feedback, the sender was probably hoping for a job well done reply. Instead, your message back is a quick “did you think of X” or “I don’t like the way you say Y”. This gets even worse if the feedback is about the presentation of the information rather than the information. You hope to be improving the work but inadvertently spin up a PowerPoint or Excel workshop session. There might very well be mistakes or significant missteps in the work. Step back and deliver a clear and focused message on those and just skip the easy adds or tweaks. Suggestion: Make a simple rule for yourself like “never suggest a different format of a report” or “never add more work unless you also take away work” or “save feedback for the critical or strategic elements”.
- Delegate and tweak. When you delegate work to the member of the team, your job is to clearly frame success and describe the objectives. Delegation of work can be as simple as scrubbing the feature list or as complex as asking someone to take on a group-wide stretch assignment. No matter what the scale of delegation, getting out of the way after delegation is key. When the results are in, keep in mind not the results free of context but look at the results in the context of how you delegated the work. If you see mistakes or missteps, ask yourself if you were clear or your delegation caused the problems. Editing the work that ignores the context will tend to alienate folks as they keep thinking “would have been nice if you told me that up front”. Leading is actively taking responsibility for the lack of clarity and triaging the real marginal gain from tweaks at this later stage. Suggestion: Delegate challenges and define success, but don’t delegate the intermediate steps or detailed output, making it clear where creativity is expected.
- Fetch and edit. The best work for creative folks on the team is when the problem is big and the solution escapes everyone. In these cases, as a manager you don’t know the answer. That’s stressful for everyone. The way to increase the stress is to ask a member of the team to build or create an answer for “review” or for a list of options and recommendations. We all know how this process can really go haywire. When one potential solution to an unknown is offered, the next step is to go back and rework it with the new learning, or “no not that rock, a different rock”. We also know that with a big unknown and a list of n possible choices, after a brief dialog the next step is to pick option n+1. Suggestion: Asking creative people solve vaguely defined problems can be the most rewarding work of the team, so don’t drain the energy by thinking you will know the best answer when you see it, driving folks a bit loopy in the process.
Leadership is more than editing
These patterns and others all share a common result—the more you do them, the less creative and engaged your team will be over time. Each time your employ the tools of editor, rather than leader, you encourage people to stop creating and focus their energies on trying to predict your editorial reaction.
Leading is contributing data and experience–share your related experience and let the allegory and discovery do the work.
Leading is coaching–share your observations and offer pros and cons.
Leading is walking through the action/reaction decision tree—share the path, not just the destination.
Leading is reiterating accountability in so many cases.
Leading is knowing when the potential for learning and growing outweigh the risk of failure.
Leading is realizing there a few perfect answers and many great answers.
A goal of leading is to amplify your skills and experience while also growing new leaders. If you’re not giving people room to uncover their own way and ultimately solutions, then you’re creating a staff organization for you, not the next generation of leaders. As valuable as your experience is, don’t forget that the minutes or hour you spend editing compare to days and weeks often spent getting the work into a consumable format. The bigger the investment the more expert people are, even if they would benefit from coaching and experience.
Over time as you work to keep focused on leadership rather than editing, the team grows stronger and more self-reliant. Members of the team worry more about getting the best answers and work and less about wondering what management might be after. More work gets done. Members of the team are more empowered. This positive feedback loop continues to improve every aspect of the team.
–Steven
Three questions – insights from readers
In the post, Combining guessing and planning in product development, our resident big data researcher at Stanford proposed a few questions in order to reflect what those reading this blog have to say. Considering the overall clicks on posts, we’re seeing about 1-2% of readers participate in this “for entertainment purpose only” poll.
The poll on this new post can be found https://www.surveymonkey.com/s/VLHQSBJ, please participate and share your perspective.
Thanks to those of you that took a minute to answer our three questions. We saw a few noteworthy points from the results:
- Roughly half of you have had skip level meetings in the last six months.
- On average, you spend about one fifth of your project schedule planning.
- Over half of your plans are represented in your final products.
- The most popular planning tool was ‘Short Product Plans’ (61%) and the least popular was ‘Market Requirement Documents’ (31%), though a few of you also mentioned ‘customer stories’ and ‘prototypes’ as key planning tools.
Watch this space for results from the next survey!
–Cameron
Designing for scale and the tyranny of choice
A post by Alex Limi, of Mozilla, Checkboxes that kill your product, is a fascinating read for anyone in the position to choose or implement the feature set of a software project. What is fascinating is of course the transparency and admission of the complexity of a modern software product. Along with this is a bit of a realization that those making the choices in a product are in some ways the cause of the challenge. Things are not quite so simple but are also not so difficult.
Simple
By now we are all familiar with the notion that the best designs are the simplest and most focused designs. Personified by Apple and in particular the words of Steve Jobs, so much of what makes good products is distilling them down to their essence. So much of what makes a good product line is only shipping the best products, the smallest set of products. So much has been written, including even in Smithsonian Magazine, about the love of simplicity that inspired and is expressed in the design language of Apple’s products based on a long history of design.
It is exceedingly difficult to argue against a simply designed product…so long as it does what you want or when it does more than competitive products.
In fact it is so difficult to argue against simplicity that this post won’t even attempt to. Let’s state emphatically that software should always do only what you need it to do, with the fewest number of steps, and least potential for errors due to complex choices and options.
On the other hand, good luck with that.
Anyone can look at any software product (or web site or hardware product) and remove things, decide things are not valuable to “anyone” or simply find a new way to prioritize, sort, or display functionality, content, capability. That’s really easy for anyone who can use a product to do. It is laudable when designers look back at their own products and reflect on the choices and rationale behind what, even with the best intentions, became undesired complexity, or paperclips.
The easiest type of simplicity is the kind that you place on a product after it is complete, hindsight is rather good when it comes to evaluating simplicity. This is simplicity by editing. You look at a product and point out the complexity and assume that it is there because someone made some poor assumptions, could not decide, didn’t understand customers, or a whole host of other reasons.
In fact, many choices in products that result in complexity are there because of deliberate choices with a known cost. Having options and checkboxes costs code and code costs time in development in testing. Adding buttons, hinges, or ports is expensive in materials, weight, or even battery life. Yet designers add these anyway. While data is not a substitute for strategy, looking at usage data and seeing that nearly every bit of surface area is executed, validates these choices (one could go through Limi’s post and reverse engineer the rationale and point to the reasons for baggage).
It is enormously difficult in practice to design something with simplicity in mind and express that in a product. It is an order of magnitude more difficult than that to maintain that over time as you hope for your asset to remain competitive and state of the art.
Difficult
Software is a unique product in that the cost of complexity is rarely carried by the customer. The marginal cost for more code is effectively zero. While you can have lots of options, you can also effectively hide them all and not present them front and center. While you can have extra code, it is entirely possible to keep it out of the execution path if you do the work. While you can inherit the combinatorics of a complex test matrix, you can use data and equivalence classing to make good engineering assumptions about what will really matter. Because of these mitigations, software is especially difficult to design simply and maintain in a simple state even if you accomplish a simple design once.
Here are seven reasons why simplicity in software design is incredibly difficult:
- New feature: enable/disable. You add a new feature to your product but are worried about the acceptance of the feature. Perhaps because your new feature is an incredibly innovative, but different, way to do something everyone does or perhaps because your new feature is based on a technology that you know has limits, you decide to add the checkbox. The easy thing to do is to just add a “do you want to use this” or the first time you see the feature in action you offer up an option to “keep doing this”. Of course you also have to maintain a place to undo that choice or offer it again. Play this out over the next release and evolution of the feature and you can see where this leads.
- New feature: can’t decide. You add a new feature and it clearly has a modality where some people think it should go left and others think it should go right (or scroll up or down, for example). So of course the easy thing to do is just add an option to allow people to choose. Play this out over time and imagine what happens if you decide to add a new way or you enhance one of left or right and you can see the combinatorics exploding right before your eyes.
- New way of doing something: enable compatibility. You add a new way to do something to your product as it evolves. Just to be safe you think it would be best to also have the old way of doing something stick around so you add back that option—of course software makes this easy because you just leave the old code around. But it isn’t so easy because you’re also adding new features that rely on the new foundation, so do you add those twice? Play this out as the new way of doing something evolves and people start to ask to evolve the old thing as well and the tyranny of options gets to you quickly.
- Remove feature: re-enable. As your product evolves you realize that a feature is no longer valid, useful, or comes at too high a cost (in complexity, data center operations, etc.) to maintain so you decide to remove it. Just to be safe you think it is a good idea (or customers require it to be a good idea) to leave in an option to re-enable that old feature. No big deal. Of course it is important to do this because telemetry shows that some people used the feature (no feature is used by zero people). Play this out and you have to ask yourself if you can ever really remove a feature, even if there is a material cost to the overall system for it to be there.
- Environmental choice: customize. Your product is used in a wide variety of environments from consumer to enterprise, desktop to mobile, managed to unmanaged, private network to internet, first time to experienced people, developers or end-users, and so on. The remarkable thing about software is the ability to dynamically adjust itself to a different usage style with the simple addition of some code and customization. The depth and breadth of this customization potential makes for a remarkably sticky and useful product so adding these customizations seems like a significant asset. Play this out over time and the combinatorics can overwhelm even the largest of IT administrators or test managers. Even if you do the work to design the use of these customizations so they are simple, the ability to evolve your designs over time with these constraints itself becomes a constraint—one that is likely highly valued by a set of customers.
- Personality: customize. You design a product with a personality that reflects the design language across every aspect of the product from user interface, documentation, packaging, web site, branding and logos, and more. Yet no matter what you do, a modern product should also reflect the personality of the owner or human using it. You see no problem offering some set of options for this (setting some background or color choices), but of course over time as your product evolves there is a constant demand for more of these. At some extremes you have requests to re-skin the entire product and yet no matter what you try to do it might never be enough customization. Play this out over time and you face challenges in evolving your own personality as it needs to incorporate customizations that might not make sense anymore. Personality starts to look a lot like features with code not just data.
- Competitive: just in case. The above design choices reflect complexity added during the development of the product. It is also possible to make choices that do not arise out of your own choices, but out of choices that come from responding to the market. Your main competitor takes a different approach to something you offer and markets the heck out of it. You get a lot of pressure to offer the feature that same way. The natural reaction is to put in a quick checkbox that renders some element of the UI your way as well as competitor’s way. You battle it out, but rest assured you have the objection-handler in place so sales and marketing don’t stress. Play this out and you can see how these quick checkboxes turn into features you have to design around over time.
Of course we all have our favorite illustrations of each of these. You can imagine these at a very gross level or even at a very fine level. The specifics don’t really matter because each of us can see immediately when we’re hitting up against a choice like this. Play the design choice out over the evolution of the product/feature and see where it goes.
It is important to see that at the time these are not dumb motivations. These are all legitimate product design approaches and tradeoffs. Another way people see simple is that while you’re designing it you know how it will definitely not appeal to a set of customers. You can take a bet on convincing people or you can be a bit safer. Product development is uncertain and only hindsight is 20/20. For every successful product that is simple, there are a lot of simplicity approaches that did not pan out over time. Minimal can be simple, or just a minimal number of customers.
What can you do?
Evolution
Software is definitely in a new era. The era of excess configurability or even infinite customization is behind us. The desire for secure, robust, long battery life along with incredible innovations in hardware that bring so many peripherals on board means that designers can finally look at the full package of software+hardware through a different lens.
If you draw an analogy to the evolution of the automobile, then one might see where the software world is today. And because we see software and hardware inextricably connected today, let’s say that this applies to the entire package of the device in your hand or bag.
In the golden era, as some would say, of automobiles it was the height of hip to know the insides of your car. A fun after school project for a guy in high school would be to head home, pop the hood on the Chevy, and tune the engine. Extra money earned on the side would go to custom parts, tools, and tweaking your wheels. You expressed yourself through your car.
Then along came the innovations in quality and reliability from car makers in the 80’s. They saw a different approach.
When I was 16 my father took me to look at cars. We stopped by the dealer and during the pitch he asked the salesman to pop open the hood. I am sure the look on my face was priceless. I had literally no idea what to look for or what to see. Turns out my father didn’t either. Electronic fuel injection, power steering, and a whole host of other things had replaced the analog cars he knew and loved (and currently drove). Times had changed.
I have not looked under the hood of a car since. My expectation of a car is that it just works. I don’t open the hood. I don’t service it myself. I don’t replace parts myself. I can adjust the seats, set the radio presets, and put an Om sticker on the back. I want the car’s design to express my personality, but I don’t want to spend my time and energy worrying if I broke the car doing so. Technology has advanced to the point where popping the hood on a car is no longer a hobby. The reliability of being able to drive a 2002 Prius for over 100,000 miles without worrying comes with fewer options and customizations, but I got a car that cost less to operate, took less time as an owner to maintain, and was safer in every way. Sold.
Today’s sealed Ultrabooks and tablets, app stores, and even signed drivers represent this evolution. Parts that done wear out, peripherals that you don’t need to tune or adjust at the software level, thin, light, robust, reliable. Sold.
Approach – Point of View
How can you approach this in the products you design? As you can imagine there is a balance. The balance is between your point of view and making sure you truly meet customer needs.
A point of view has to be one of the best tools of design A point of view is the reason for being, the essence, the very nature of a product. In a world where just about every product (but not all) is made of similar ingredients and solve problems that can kind-of, sort-of be solved in other ways, what distinguishes one product from another is a unique point of view that is followed through in the design.
A point of view says who the product is for and why. A point of view says the benefits of a product. A point of view says why this product is better, faster, and differentiated in the marketplace.
A point of view also guides you in deciding how to be simple. Simplicity comes from adhering to your point of view. If you have a clear point of view then simplicity follows from that. Is something consistent with your point of view? If so then it sounds like a candidate. If not, then why are you considering it? Is your point of view changing (it can, but be careful)?
But we don’t all have the luxury of declaring a point of view and sticking to it. You can share your point of view with customers, or potential customers. You can articulate your point of view to the market. You can also adapt and change. The market also adapts and changes.
That’s why product development is so exciting and interesting. The answers are not so simple and the journey is complex, even if the goal is product simplicity.
–Steven
PS: Interested in a Harvard Business teaching case study on this topic, then perhaps check out http://www.hbs.edu/faculty/Pages/item.aspx?num=34113 (Microsoft Office 2007). This is a paid link for which I receive no compensation.
Using data to inform strategy
Access to rich usage data is something that is a defining element of modern product development. From cars, to services, to communications the presence of data showing how, why, when products are used is informing how products are built and evolve. To those developing products, data is an essential ingredient to the process. But sometimes, choices made that are informed by data cause a bit of an uproar when there isn’t uniform agreement.
The front page of the Financial Times juxtaposed two data-driven stories that show just how tricky the role of data can be. For Veronica Mars fans (myself included), this past week was an incredible success as a Kickstarter project raised millions to fund a full length movie. Talk about data speaking loud and clear.
This same week Google announced the end of life of Google Reader, and as you can see from the headline there was some controversy (it is noted with irony that the headline points out that the twitterspehere is in a meltdown). For all the 50,000 or more folks happy with the VM movie, it seems at least that many were unhappy about Google reader
Controversy
The role of data in product development is not without controversy. In today’s world with abundant information from product development teams and analysis of that data, there is ample room to debate and dissect choices. A few common arguments around the use of data include:
- Representation. No data can represent all people using (or who will use) a product. So who was represented in the data?
- Forward or backward looking. When looking at product usage, the data looks at how the product was used but not how it will be used down the road (assuming changes). Is the data justifying the choice or informing the choice?
- Contextual. The data depends on context in which it is collected, so if the user interface is sub-optimal or drives a certain pattern the data does not necessarily represent a valid conclusion. Did the data consider that the collection was itself flawed?
- Counter-intuitive. The data is viewed as counter-intuitive and does not follow the conventional wisdom, so something must be wrong. How could the data overlook what is obvious?
- Causation or correlation. With data you can see an end state, but it is not always clear what caused the end-state. If something is used a lot, crashes a lot, or is avoided there might be many reasons, most not readily apparent or at least open to debate, that cause that end-state. Is the end-state coincident with the some variables or do those variables cause the end-state?
When a product makes a seemingly unpopular change, such as Google did with reader, some of more of these or other arguments are brought forward in the discussion of the choice.
In the case of Reader, the official blog stated “usage of Google Reader has declined”. While it does seem obvious that data informed the choice, if one does not agree with the choice there is ample opportunity to dispute the conclusion. Was the usage in absolute or relative decline? Were specific (presumably anonymous) users slowing their usage? What about the usage in a particular customer segment? The counter-intuitive aspect of the data showed, as most dialog pointed out strong first party usage among tech enthusiasts and reporters.
The candid disclosure of the use of data offered some transparency to the choice, but not complete transparency. Could more data be provided? Would that change how the product development choice was received?
Conversely, no one is disputing the success of the VM Kickstarter project (making a movie is similar to product development). The data is clear, there is a high level of demand for the movie. I know that fits my intuition as a fan of the series. The fact that this data came via a popular (and transparent) web service only seems to validate our intuition. In this case, the data is seemingly solid.
While these are just two examples, they happened in the same week and show the challenges of data, transparency, and product development choices. While data can inform choices, no one is saying it is the only way to make a choice or that those making products should only defer to data. Product development is a complex mix of science and intuition. Data represents part of that mix, but not the whole of it.
Data is not strategy
Ultimately, data contributes to product development but does not replace the very unscientific notion of what to build and why. That’s the art of product development and how it intersects with business strategy. This follows from the fact that products are developed today for use in the future. The future is uncertain for your own product’s evolution, but all around you is uncertainty. Data is an input to help you define a strategy or modify it, but cannot replace what is inherently the uncertain side of innovation.
In Eric Ries’ Lean Startup book (or http://en.wikipedia.org/wiki/Lean_Startup), there is an interesting discussion on how the role of data can contribute to an early stage product. While the anecdote and approach are described in the context of a project very close to Eric, I think we can all see parallels to other products as well. My intent is not to restate or recast the book, but to just reflect upon it a bit.
One part of developing a new product, as described, is to develop a minimum viable product (MVP) that does not reflect the final product but is just enough of the product to collect the maximum validated data about potential customers.
An interesting point in the description is how often the people that will use this early version of the product are enthusiasts or those especially motivated and forgiving about a product while under development. The tricky user interface, complex sign-up, or missing error conditions and things like that might not matter to these folks, for example.
Not every product ultimately targets those customers—they are not super large in number relative to the broad consumer world, for example. As you learn and collect validated data about your product strategy you will reach a critical point where you essentially abandon or turn away from the focus on enthusiasts and tilt towards a potentially larger customer base.
This is where your strategy comes into play. You have iterated and validated. Presumably these early users of your product have started to use or like what you have or at least pointed you in a direction. Then you’ll take a significant turn or change—maybe the business model will change, maybe there will be different features, maybe the user interface will be different. This is all part of taking the learning and turning it into a product and business. The data informed these choices, but you did not just follow it blindly. Your product will reflect but not implement your MVP, usually.
But with these choices there will probably not be universal agreement, because even with the best validated data there can be different approaches to implementing the learning.
Data transparency
The use of data is critical to modern product development. Every product of every kind should have mechanisms in place to learn from how the product is used in the real world (note, this is assuming very appropriate policies regarding the collection and usage of this data). This is not just about initial development, but evolution and maturing of the product as well.
If you’re going to use data to design and develop your product, and also talk about how the product was designed and developed, it is worth considering how you bring transparency to the process. Too often, both within an organization and outside, data is used conveniently to support or make a point. Why not consider how you could provide some level of detail that could reduce the obvious ways those that disagree with your approach might better understand things, especially for those that follow along and care deeply. Some ideas:
- Provide absolute numbers for the size of the data set to avoid discussions about sample size.
- Provide a sense of statistical significance across customer types (was the data collected in one country, one type of device, etc.).
- Provide the opportunity for additional follow up discussion or other queries based on dialog.
- Overlay the strategic or social science choices you are making in addition to the data that informed the choices.
Transparency might not remove controversies but might be a useful tool to have an open dialog with those that share your passion for the product.
Using data as part of product development will never be free of debate or even controversy. Products today are used across millions of people worldwide in millions of different ways, yet are often used through one software experience. What works in one context doesn’t always work in another. What works for one type of customer does not always work for another. Yet those that make products need to ship and need to get products to market.
As soft as software is, it is also enormously complex. The design, creation, and maintenance preclude at today’s state of the art an everything for everyone approach. To make those choices a combination of data an intuition make a good approach to the social science of product development.
–Steven
PS: Please click the link on the first use of data for a discussion of data versus datum. :-)
Combining guessing and planning in product development
At the extremes of product development methodology, characterized by waterfall and agile approaches, are different views about planning. Many today would say that planning a product “up front” is nothing more than guessing that locks you into a guess that will be wrong. At the other end, the conventional wisdom is that you should get something to the market soon for testing as a best guess and then iterate and learn to further develop a product. Since no team really practices a method precisely, let’s look at how to get the best out of the planning aspects of your own product development process.
Challenges
Developing a product, new or an update, always faces the same challenge at the start. Using software as an example, folks want to get coding as soon as possible since not coding is clearly wasting time, but the team (and management) want to know that the code will yield the right product (useful, cool, innovative, profitable, whatever). There are usually those on the team that claim instinct tells them what to go build. There are those that are certain they can work out an answer to the right product with enough up front ideation.
To compound these broad challenges, different disciplines have different perspectives. It is likely testers will want to spend more time up front on building a baseline and foundation for the work, but a baseline relative to what? Ops needs to know answers to questions in order to scale and provide the required infrastructure, but those answers require a lot of information you probably don’t know. Designers usually want time to iterate in lower fidelity media in order to hone in on the design language and overall approach. Business folks want to know that their key problems (onboarding, churn, referrals, etc.) will be addressed.
All of these lead to the natural tension between a desire to get started and a desire to pause and make sure the start heads in the right direction.
Waterfall (using this as a positive description) methods argue that an effort should begin with work to identify the problem being solved, available technologies, and proposals for how to go forward. The basic notion is that you should spend the energy considering a wide range of alternatives before you just start down a path that might be fruitless. These days you will be hard-pressed to find proponents of waterfall approaches because of the downsides often associated with waterfall execution.
The downsides of this approach, as critics claim, is that you waste a lot of time building up robust plans that are “going to be wrong (or outdated) anyway”. This criticism essentially states the reality that most plans are still guesses. This is particularly true in a fast-changing, multi-player marketplace where you can wake up one morning to a competitive product or dramatically new approach to solving the problem you identified many moons ago. The ultimate downside of the waterfall approach is that it is viewed as stubborn—so stubborn that even in the face of awareness about a changing market, the team has no choice but to move forward. Proponents will offer tools to mitigate any of these risks and say none of the risks are intrinsic to the methods.
Agile development methods respond to these criticisms by creating an approach where the primary focus is to get enough product work done so you can learn from real customers and then iterate. At the extreme, efforts should actively strip away all non-essential elements of the product development process and focus on the essence of the idea. Agile methods focus on constant iteration, learning, and responding to usage of the product (or lack thereof). Teams focused on iteration work in a tight loop to quickly adapt to the changing landscape and competitive dynamics, in addition to learning.
The downsides of agile methods are actually trickier to pin down right now. These days being critical of agile methods labels one as somewhat of a Luddite in the world of product development. That said, there are understood challenges with agile methods. The pressure to release can often result in a quality bar that is less than customers (or your own testers) would appreciate. A focus on learning might cause you to learn that your service does not scale or scales in a cost-ineffective manner. A large project (people, code, partnerships) is challenging enough to keep coherent and multiple efforts executing in different iterative loops poses a significant architectural and communication challenge. Proponents will offer tools to mitigate any of these risks and say none of the risks are intrinsic to the methods.
It is no surprise that proponents of any method can point to successes, while critics can point to failures of methods as well. In reality, the causal relationship between a project success and the method used is weak at best. Even with examples of success, we need to keep in mind that product development projects are not traditional repeated processes and as such the ability to draw scientific conclusions from them is limited. This should be apparent from the fact that successful products come from both methods, and equally true is that products can be failures from both methods.
It is not unusual for failures in waterfall-styled projects to be ascribed to the methods, but not so with successes. Whereas failures in agile projects usually ascribed to external factors, not the methods. In today’s climate, it is not unusual for agile to be viewed as a causal factor for a successful product.
That’s really why starting the project by declaring the methodology runs the risk of missing the big picture. It runs the risk of spending finite and scarce time on abstract or “meta” concepts and not the work at hand. The best thing is to avoid going down that path in the first place and focus on getting clarity on what work will get done and when that will happen (and why!).
The truth is that starting a product is always a guess. Whether you plan every detail or just start coding, beginning a new product is a leap of faith based on intuition. To those of us that build or have built new products, this leap is the most interesting, terrifying, and rewarding part of product development. It does take a special confidence to make that leap. Planning every last detail can give you a false sense of security. Coding out of the gate can give you a false sense of progress. Guessing is guessing, whether you have 1000 pages of specs and high fidelity model or a whiteboard with a sketch and a functional prototype.
These challenges—choosing between methods and the known challenges of any methods—are real. In product development we are faced with these every time we start a new project. If you have a clear starting point, clear points in time to check on your progress, and a plan so you know what you’re working against then you’ve defined a methodology that works for you.
Where to start?
In a previous post we talked about focusing on the work and not worrying about the label of the methodology. A concrete way to realize this is to take a step back and see how to combine the elements of agile and waterfall in the right amount for your project.
An approach that scales from new projects to next iterations, and small project to big, is to plan to iterate your plans. While this sounds like an obvious cop-out to pick the best of both extremes, it is what reality tends to look like in practice. If you start out knowing you are going to commit time to up front planning, but recognize you will take points in time during development to adjust and learn, then you can mitigate the challenges of both methods.
Of course agile proponents say there are always some plans. And waterfall proponents always say there is room to adjust. Let’s just say those labels and attributes don’t matter and try to arrive at an approach of where to start.
Every project can start with a plan. Legendary products start with a sketch on the back of a placemat at a diner or an all-night coding session. The original plans for some pretty big projects were conceived and documented in pretty short, but articulate, memos or detailed sketches/prototypes. The spark for a plan can come from anywhere and different people have different ways of translating that spark into something more than one person can internalize and visualize.
While a tool like PowerPoint can communicate the gist of the plans, the details will be too open to interpretation. So write down the plan in long form—writing is thinking.
The simple act of writing down a product plan in a couple of dozen pages opens you up to have useful discussions with a broad set of people. If you’ve identified the problem being solved, competitive products/services, technology bets, and overall investments you have the basis of how to talk with marketing, design, development, testing, and product management. Everyone can look at the plan from their perspective and offer insights, advice. You can even package this up as a dialog or exercise with potential customers.
Combining this overview with a functional low-fidelity prototype is a way to visualize the plan for a broader audience. It is usually a good idea for the prototype to support the written description and to lead with the written description. You’ll want to minimize the time you spend on “don’t worry this UX (user experience) isn’t final” or responding to feature suggestions without the context of where you are heading.
This is all a plan needs to be. It is a guess. You can’t prove it is right. You can’t prove it is a good business, great product, or the right thing to do. You can criticize it. You can add more to it. You can find problems. That will be true of any plan (or frankly any product). But you now have a foundation to move forward. To build something that is a “target” that is shared by a group—a vision.
With this plan comes the first chance to iterate. What’s amazing about just writing this down is how much you’ll find you’re iterating on your own thinking. You can think of this somewhat as agile planning. This shouldn’t be new though – anyone who has “told a story” of a product or an idea knows that the story improves quite a bit as you tell it more. This is basically the same thing. Any good product plan is a story—the problem you are solving is the challenge to overcome, the competitors are the antagonists, the technology bets and investments are the plot devices.
Depending on the size of the team/project, the next steps are about the specifics of what to do when. The amount of up front work and the ordering of the tasks is really a choice the team needs to make. Being economical about what you do is of course a key part of ordering. Agile methods often say to do the least possible work to express the unique value of the product. Waterfall methods are about landing all the details early. Different projects will simply have different ideas of what to do at this point and your own intuition as to what makes a good investment of time, relative to quality and time to market, will dominate.
Iteration: Local or globally optimize?
Regardless of the specifics of your development schedule, you are going to iterate. You can choose to iterate after code is in the hands of customers (in a broad or limited way) or just self-hosting until a broader release. The key though is to iterate.
Iteration is as much of an art form as deciding how much of what investments to do up front. It is super easy to fall into a trap of iterating but not making forward progress. You can find yourself rewriting the same code, circling back to previously discarded alternatives, or just changing things but not making them better. As necessary as iteration is, simply iterating does not mean you and the project are moving forward.
The lack of iteration or iteration at only the most fine-grained levels is potentially a sign of a project that won’t learn as it goes. Consider a standard kitchen remodel, something that has been done millions of times. Architects draw up plans and pass them off to contractors. Then you run into existing conditions. You find you’re missing an electrical run or there’s a support wall where one wasn’t expected. It is time to iterate on the plans. You can hack through a solution with your contractor on site. Or you can take a step back and work with the architect to reconsider the design. Either can work depending on your constraints. When you consider the time value of choices, it becomes more interesting to think about taking a step back.
In the heat of the moment with the need to get in market or respond to significant challenges with early customers, a redesign or revisiting decisions seems risky. Maybe the data is poor. Maybe the fear of discovering the need for big changes concerns you. Perhaps you just want to keep moving forward. All too often when problems arise in a project the need to iterate quickly trumps taking a step back. In today’s environment it is often viewed as a positive to iterate and try something different. Activity is not always progress. Change is not always improvement.
Of course the data you use to determine what to try and how to value the feedback is important. It is just as easy to get led astray by the wrong measures of success/failure. Regardless of the quality of data, you’re going to reach a point where you are faced with the need to change something. The question is whether the changes are the right ones.
The point of a change will be to optimize your product. You’re going to have to pick the dimension for which you want to optimize—is it for immediate mitigation or longer term success. It is easy to see mitigating the immediate challenges with some changes. Longer term might feel like another guess. On other hand immediate changes have an obvious fragility relative to broader goals and there’s clearly an appeal to being thoughtful about what to change.
Having a sense of a plan helps you to weigh the alternatives. Are you dealing with a bug or minor design nit or is there a fundamental flaw in the value proposition? There’s no mistaking the reality that you might hit a major reset, especially on a brand new product. There’s also a reality that you will have to revisit a pretty broad set of small design choices—that is steps in a flow or portions of a design, rather than the entire flow or design language.
Defining a time up front when the product is in a state to evaluate all the feedback and make choices about how to optimize is an important part of the process. This checkpoint stage can be a first self-host, private beta, partner beta, public beta or anything in between. Any product today is going to have telemetry and an understanding of how it is used and what you are measuring. This helps you to inform both what is going on and even what you failed to measure correctly.
Armed with a set of potential problems to address—optimizations yet to be done—there’s a simple question to ask of the team, which is “do we need to change/fix this or not, and if we need to take a step back and re-evaluate?”
A way to look at what to change/fix or not is to think of changes relative to the longer term goal, to go beyond the immediate. There’s no doubt the feedback about something is real. The question is really whether the cost to change (hours, risk, churn) gets you closer to the broader goals of the plan or is more reflective of iterative activity.
A checkpoint discussion where members of the team are aware of all the changes going on and what is being prioritized is a way to level-set. Some teams might have bigger challenges or more changes and other teams might be making more local changes. Calibrating these across the team is akin to making sure the whole project is thinking and acting globally, not locally. The plan that was put in place serves as a reminder of what the team was hoping to accomplish. Accountability, aka decision making, can be clear because the roles and responsibilities are clear and communication has been clear. A discussion to inform doesn’t have to be an invitation for everyone else to join in revisiting the choices made by the team.
Is the new data driving you to revisit the plan completely (whether immensely detailed or not)? That could be. For a brand new business and/or a brand new product where the effort is to grow an entirely new customer base, you could be going in a wrong direction. For a product update, there’s always going to be pressure from existing customers to innovate in a more incremental manner versus taking the product in a new direction. The presence of a plan allows you to have an informed dialog as to what went wrong. When you make choices to change things you have a shared foundation upon which to agree about what went wrong.
Is the data driving you to tweak something? That certainly is the case with some changes. The presence of the plan allows you to decide how critical it is to make changes. Too often changes to the code are made because of the presence of feedback even if the change doesn’t really alter the overall outcome. When you choose to keep things a bit more stable it doesn’t have to be viewed as blindly sticking to a plan when it can just be prudent engineering of cost-benefit. The capability to change is not the same as the value of change. Something that might be 10% better might introduce a high risk of change management or might just be 100% different–ask if something really is twice as good (or 10x better) after the change.
There’s a simple view of optimization that one can use in having discussions about changes—whether at the feature level of the whole plan. The idea is to discuss whether the change is a global optimization or a local optimization. When resources are right and time to market critical, optimizing locally is wasteful. When the plan is generally right but has some holes you discover, then making sure you optimize globally leads to an agile view of planning. The following just sketches this conceptual view–believe it or not this can often be a useful visual aid in the discussions around whether a change is needed.
Whether you label the axes performance, suitability to task, conversation rate, success rate, or transactions per second is not really as important as taking a step back and asking the question about whether the change gets you close to where you need to be over time. It is far too easy to get caught optimizing your plan relative to the nearest peak, not the best peak.
Whenever you have more than a few folks working together, having a set of tools to help you make a consistent set of choices across the team is critical. The more there is a shared view of the goals and the way to make choices the easier this becomes—a plan is a way of encapsulating the broader goals and giving you a place to both measure relative success and to decide the target was wrong. The presence of a plan does not enforce rigidity any more than the use of agility guarantees you will iterate to success.
Product development is a lot of guesswork. Planning, checkpointing, and deliberate decision making are tools to help you make the most informed guesses you can make.
This Week’s Poll
This week kicks off a new feature of Learning by Shipping — Three Quick Questions. This is a snap poll to share aggregate (non-scientific) reactions to the topic of this post, which will be reported in the next post. Take the poll – Three Quick Questions. Cameron Turner, an expert in big data and measuring how products are used in the real world is helping with these polls. No identifying information is collected or maintained.
–Steven
###
Benefiting from skip-level one-on-ones
Staying connected to your skip level manger and she staying connected to you are valuable for the project, the team, and each of your ongoing development. Rigorously and consistently making the most of skip-levels, whether as the manager or individual employee, is an important skill to master. This post looks at one-on-ones from the perspective of the manager with some tips for the employee/individual.
Time pivot, becoming a manager
One day in your career you might come to work and it will be your first day as a new manager. Many things will seem different. All of a sudden you not only feel responsible for code and features, but you’ve taken on a new responsibility for people. For those that you now manage, a new set of demands are placed on your time. One-on-ones are a key tool for you as a new manager.
One-on-ones are the most precious time you can spend with members of the team—your new direct reports. Much has been written about how to “have a good one-on-one” or techniques for making the most of the time (there is a post in our One Strategy book or check out Ben Horowitz’s nice post). I’m a firm believer that 1:1s are the most important of all scale management tools.
The easiest thing to remember about a 1:1 is that as a manager the meeting is not for you but for the employee. Your opportunity to learn is based on the topics raised and questions asked by the member of the team, only asking questions to draw out the issues if necessary. The first sign of a struggling management chain is when employees on the team start to see one-on-ones as being called to the carpet on a regular basis or when managers view a one-on-one as their time to manage the project or to be the keeper of the agenda.
As a manager, the notion that your time is no longer your own, but is there to serve the folks on your team is significant pivot, and somewhat counter-intuitive. You might have a manager you feel “takes up too much of your time” or you might be thinking “I have real work to do instead of sitting here”. You might be worried about all you need to get done as a team and react by asking more (or too much) of your new direct reports. In other words you’re in for a bit of learning about how you now manage your time, in addition to how you manage your own work and the role of management. So you aspire to do better when you’re on the other side of the table, and effectively using 1:1s is a key step.
As a first step of this new journey, consider how you can live up to the mantra that your role is to take up as little time as possible from your direct reports. This only benefits the organization as a whole because there will be more time for work, fewer meetings, and overall more time building products. The 1:1 is your request for time, but how you turn that into a benefit for the member of the team makes it valuable and not a manager tax.
A rule of thumb you might follow is don’t ask anyone to do things for you, but ask folks what they could do that helps them get the work done they believe they are supposed to do. In other words, status reports, project reviews, and statistics may all be valuable, but only if the folks on the team decide that on their own.
At the same time, 1:1s are a key tool to get a pulse on the team and on the work of folks on the team. Through an unstructured two-way dialog you can likely learn more about what is going on than you can from status reports or other outputs open to obfuscation, unintentional or not. So spend the energy to make your way over to your direct report’s desk, meet there, and let he/she set the agenda.
When your work is operating from a shared view of the goals and open and honest communication is encouraged, there’s a very good chance challenges and issues will find you rather than you needing to ferret them out. If you’re finding you are surprised by issues, then dig into the root cause before falling back on asking folks to spend more time telling you what might be happening.
When you take on the role of managing managers, presumably you have found this balance for one level of management. As a new manager of managers, your ability to stay connected to the work is critical but the challenge is much more difficult. You might react by falling into the traps you worked hard to avoid as a new line manager. You might feel that your need to stay connected or to drive strategy trumps the need for a skip level manager to be heard, to be listened to, and to be treated just like you would like to be treated.
Skip-level 1:1s
One-on-ones with your direct reports (fellow managers) will not likely feel like enough to get a sense of the project if you’re in the position of managing other managers. A wonderful tool to learn even more about the team is to just continue having 1:1s on the team, but with the direct reports of your direct reports. Personally, I have always found this part of management to be the very best way to learn more about your own team and an incredibly wise investment to make for a number of reasons.
A skip-level 1:1 is exactly like a 1:1 with a direct report in terms of approach. There is no preparation required. The member of the team is not being called to the carpet. The focus is whatever the member of the team wants it to be. Your role as a manager is to listen, perhaps ask a few guiding questions, and to learn by listening.
In fact, the most important part of a skip-level 1:1 is to avoid “making news” or “solving problems”. If something comes up in the meeting that is a surprise, use this as a chance to ask questions and to make sure the member of the team is engaged in addressing the issue through the management in place. A skip-level is not an opportunity for escalation, no more than it is an opportunity to search for decisions you can make or problems you can solve. If someone leaves a 1:1 thinking you decided something or changed course, then that is a good chance to ask yourself if you were stepping on the toes of your direct report.
You might find it helpful to be systematic with skip level 1:1s and work to meet each of your skip level folks once-per month/quarter/year depending on the size of your organization. If you manage a team of 100, it should be possible to have a skip level with every member of the whole team yearly. More than that and you will probably want to structure your skip-levels to include only your directs of directs, perhaps every six months. It can help to have skip-level meetings take place during specific times in the project when they might make most sense (just before or after a milestone for example). As a suggestion, don’t define “skip level 1:1 days (weeks)” as the assembly line can be a bit off-putting to some, especially if scheduled back to back. You might consider a “head’s up” mail with a skip level invitation just so folks don’t panic :-)
It is important to be consistent in the implementation. In other words, it is important to meet with the same frequency and duration with each of the folks. Don’t short change employees that might be further away, in slightly different projects, or just on areas you might find less in need. The more senior you are the more important this consistency becomes as the team looks for signals of your priorities based on who you spend time with.
My own view is that skip levels are so important that I would routinely spend 15% of scheduled meetings in a year in skip level 1:1s. Some find this a surprising use of time given how much might be going on. The reality is that a consistent approach to meeting with people across a team you manage can offer a unique lens on what is going on. It also affords an opportunity for you to reinforce the work you might have been doing with respect to accountability, decision making, and rhythm of the team.
Some topics
For a skip level 1:1, just as with a regular 1:1, the topics are driven by the attendee and not you. Just as with direct reports, some folks will show up with a long list of topics (or questions). Others will show up assuming you have an agenda. And probably everything in between is possible. Regardless, your role is to facilitate the member of team opening up, to reduce the potential stress of the situation, and to reassure the member of the team that this meeting is not a career moment. This starts with you showing up in the office of the employee, not summoning, the employee to your office.
This latter point is critical. A skip level 1:1 is not a meeting to pass judgment or to evaluate performance, just as it is not a time for “new business”. Folks should know this. While one of you might believe that the meeting should be “confidential”, you should be cautious with that sort of dynamic, not just for skip-levels but in general. Confidentiality is important for matters of personnel but is usually counter-productive when managing a project. If someone requests confidentiality for a personnel issue, it should be handled in the appropriate manner.
If a person shows up with a long list, sometimes it is fine to allow them to work through it. It might also be a good idea to “pace” the dialog and start off by asking “what’s on your mind?” or “how are things going?” In a first 1:1, if you don’t have a history with the member of the team, why not use the time to learn more about each other’s background (as appropriate) and to reciprocate?
There’s likely going to be some interest in hearing answers “from your perspective” – “how are things going”, “did you hear about…”, “what do you think…”? That is interest in topics that are perceived to be talked about at some higher level on the team. It is great to spend some time on those, though it is worth considering how you can put those topics in the context of the project rather than just gossip.
For a larger organization, there’s a benefit to spending time in skip-level dialogs on the efficacy of the work environment. Asking questions about the velocity of code, collaboration, getting things done, and so on. In any organization of size, a manager of managers is where action can (and should) be taken to avoid the perils of a stagnating organization.
Similarly, topics that will surely come up will be related to processes that are corporate wide (compensation, recruiting, and so on). It is probably a good idea to be extra careful about “making news” in how you discuss these—that is different than being guarded and evasive—by focusing on the information previously discussed broadly with the team. You might learn something wasn’t clear, in which case there’s a chance to clear things up for the whole set of folks in a consistent manner.
During different phases of the project, it is great to enable a discussion about that—feedback on pre-release, design challenges, ramping up, and so on.
If you’re the individual
A skip-level 1:1 is a great time to offer your perspectives on what is going well and not. There’s a fine line between offering up all the potentially bad news and sounding like you’re setting expectations, and polishing up all the potentially good news and sounding like you’re showing off. You have to be the judge. A few other potential tips/topics:
- Use right level of detail. Speak the truth and what you know, but match the level of detail that your skip level manager will find valuable. Keep in mind no matter how hands on the manager is, you have a lot more detail in your head :-)
- Ask clarifying questions. Managers often have a tough time with “what is that” or “no I don’t understand” so don’t be afraid to ask questions clarifying if you were clear. Feel free to volunteer to expand acronyms or code names, rather than assume a deep knowledge (without sounding too pedantic).
- Discuss cross-group, collaboration, partnerships. There’s a good chance your skip level manager is pretty tuned in and curious as to how things you are working on contribute to cross-team initiatives. Consider focusing on those topics and if you do, just speak the truth as if your partner is sitting right there with you.
- Limit strategy. There’s a time and place for strategy. While you might be tempted to use the time for big strategy topics, this might not further your goals much and might not be the best use of time. Spend the time thinking about how you could help your contribution to the project with insights and information.
- Don’t make news. It is probably not a good idea to “make news” in this discussion–news about the project, you, or feedback about team/people. You might want to resist the urge to share something for the very first time in this forum and certainly not something you would not share with your manager as if she was sitting right there. If you have candid feedback on your manager, then be clear about what you’re doing and don’t conflate that with the rest of the meeting topics.
Above all, make the most of the time to make sure your skip-level manager is familiar with you and your work in a neutral and constructive way.
When used consistently and effectively, skip-level 1:1s are a great, two-way tool for both of you and the team.
–Steven
###
Learning by Shipping 