Engineering Director in Austin, TX. Formerly of National Instruments, Bazaarvoice, WP Engine, Lawnstarter, and currently at Indeed.
Father of four. Love simple puzzle games, board games, coffee and movies.
I’ve been thinking a lot about friends this week. So many of my friends have reached out to support me and others in this layoff that I’m humbled to have so many great people in my network. Beyond just the network, having friends reach out provides a great support system for this challenging time. These people have met me for coffee, lunch, and beers or even dropped off dinner for my family one evening to show their love and support. I hope that everyone affected by layoffs is getting similar support.
However, I was challenged this week as I realized that I have so many friends, and yet for the last (nearly) seven years, I have never been this intentional about spending quality time with them. I have been very focused on my team, my career, my family, and more, and friends were a distant afterthought. Sure, I wanted to have more time with them, but when they didn’t call and I was super busy, time just got away from us both. I was intentionally scheduling time with friends during the first year of the pandemic, but that slowed down dramatically in 2022 and 2023. I’m bringing back that intentionality with a plan to maintain and grow my friendships even after I find another role, and I encourage you all to do the same.
Looking Back – On Mission With Friends
Indeed inspired me with its mission (“We help people get jobs”) even before I joined the company in 2016. I loved working on products to help job seekers find new roles and others for employers to find the right hire. In the first month, I saw firsthand how the mission would be used to gauge product success as a feature that was good for revenue but bad for job seekers was shuttered to protect the experience.
I’ve been a big believer in intrinsic value for a long time and always tried to help my teams understand the value they were creating, not just the revenue they extracted. Our User Experience teams were also instrumental in regularly refocusing the team on the customer experience, problems we were solving, and how we could help job seekers. Rallying around these problems with coworkers made them much more than peers; it grew so many new friendships. This article in Forbes on the importance of a mission-driven company shows the data behind that intrinsic motivation and a few questions you can ask to understand company culture around motivation/mission. (4 min read)
Looking Forward – Leadership & Worry
Another great article I read this week was on worry by RandsInRepose. (4 min read) Rands lays out that worrying/pessimism may seem engaged, helpful, or even essential but is doing more damage than good. Good leadership is the counter to worry: listening, understanding, staying curious, hoping, and more. I want to work with friends who exhibit this kind of leadership in my next role.
It’s easy in a layoff to move to a place of worry. Will I get another job? Will my budget work out? Will the market continue to get worse before it gets better? If we instead focus on listening to the feedback we’re getting, growing our skills during this downtime, we’ve been given, and most importantly, never losing hope, we will see brighter days.
We were laid off because the company made a mistake. Hiring you was a good decision, not a mistake. The mistake was not aligning hiring to the business needs. Your skills are valuable and are in demand somewhere. You have something unique to give. I hope you find that spot this week!
Today’s Tip – Negotiating
I’ve heard some folks have already gotten offers and are deliberating which to accept (and some have already accepted new roles, congratulations to everyone who’s seeing progress). Let me share a tip I’ve used in previous job searches with those closing in on a decision. Recruiters or hiring managers will ask you what your salary expectations are (where that practice is still allowed, here’s a list of places it is not.)
Preparing for this requires a bit of thinking about your budget, growth, and the longer-term opportunities in this role. My tip (I’ve lost the source for where I originally started this) is to develop three numbers: 1) your must-have salary, e.g., the take-home pay you have to get to make your budget work; 2) your desired salary, a reasonable balance of what you need and some extra to make things more comfortable, and; 3) your “happy place” salary, the amount you’d be very happy to get and would make you stop searching anywhere else.
When you share your desired salary (if you choose to share), share your mid and high numbers as a range. If the company comes within that range, you’ll be able to accept it comfortably. If they come in under your mid-point but above your must-have, you’ll know that the budget works and determine whether you want to negotiate. And, if the offer comes in below your must-have salary, you’re armed to push back and potentially walk away from an offer that won’t work for you.
Fun Stuff
Final Words
If I can help with your search, please get in touch with me. Please give me feedback on what you like or don’t care for in this newsletter, and I’ll adjust. For full transparency, I have no affiliation with any of the tools, companies, or resources I share. These are my impressions, not tainted by any outside influences.
The origin story of our Incubator (the name we gave to the organization fostering all of the Disruptive Innovation teams) started with the exploration into team charters. Amazon (and a number of other notable companies, too) has a culture of creating a team charter for discussion when creating any new team within the company. As we reviewed the past successes and failures of the Labs team, we decided to write a team charter to capture what the team was meant to do. Our main goal was to capture what it meant for the team to be impactful.
Impact is a great tool to guide your teams if you can understand and measure it. Understanding it alone takes time but starts with considering what is essential within your organization. Impact can be any number of things: clicks, revenue, connections, and growth of CPM, but it can also be less tangible things like customer adoption, high-speed execution (coding or experimentation), or collaboration. A clear definition of what is impactful to your organization serves as an invaluable North Star for your teams to guide their decisions.
Initially, our team had already shown a remarkable ability to operate quickly and collaboratively. Our team focused on discovering business value, which was also an asset to leverage. We set out to write a team charter and realized that if we turned this effort towards Disruptive Innovation exclusively, we could create an innovation engine for the company. The first draft of a team charter for our Incubator included statements guiding us to continue to be great partners to the various stakeholders around the company, to be a level playing field for all Disruptive Innovations we were testing, and to ruthlessly prioritize the various investments we were making into those innovations.
Whatever target you set for your Innovation team, you’ll want a measuring stick included in this charter. This can be tricky because you want to avoid simple Ivory Tower innovation, Innovation for the sake of Innovation, or innovation that doesn’t lead to any lasting change in the organization. Our organization knew from the beginning that we wanted to be measured by Innovations that impacted the core business, or as we termed them, “exits.” Thus began our reuse of the various venture capital terminology: angel round, series A, exit, bridge rounds, and more that we’ll explore in the chapters to come. Depending on your organization, exits may not make the most sense; it may be more around the influence of other product areas or creating a repeatable pattern that can be adopted in other product groups, but this measure (even if it seems impossible to guess what the target value should be) will help the team to know what success looks like.
While we didn’t know how to set the total value of every exit in revenue terms as you would for a VC-backed startup, we did know that if we were successful at convincing the other organizations around the business that there was value in our products and that they were worth adopting and merging into their lines of business that we would have produced something Impactful. We gave our team a lofty goal to grow each of their products into something impactful to another business area and to align with the various company metrics that made the most sense to help make it directly comparable. For the program, we picked a somewhat arbitrary goal of having at least one out of every six experiments exit successfully. This could easily have been anything between one out of four or one out of ten, but anything outside of that seemed ludicrous and like sandbagging, respectively.
Measures v2.0
After a few years of building products and running the program, we stepped back and realized we could summarize the organization’s most essential values into three key deliverables. First and foremost was the desire to create “exits.” Exits are the most tangible measure of impact as they are, by definition, your team creating additional business value for another business group. In some cases, you may even be able to do a back-of-the-envelope calculation on the true dollar value created or, to make yourself feel even better, just how much the company would have spent purchasing a similarly sized startup. But of course, that’s not strictly necessary, just a bit of navel-gazing.
Learnings are the second area that demonstrates value, albeit a lesser type. Here you’ll capture the failed experiments and early iterations of various teams trying to find business value. There are a lot of assets shed by the Innovation process we’re describing: original pitch decks, re-funding decks, planned expansions or pivots, and most importantly, the presentation of the final learnings.
This final presentation summarizes all of the key learnings over the timeline of this product experiment, showing both the things that were successful and the things tested which did not work. This is a blameless exercise and should be celebrated (we like cookies, or cake, or cookie cake!) as the team may feel down about the inability to produce a new viable product. The significant part is that if you keep all of these assets in a widely accessible place in your company’s documentation/knowledge-sharing system, you’ll find that it cuts off similar ideas that have not been thoroughly researched and that it also makes any related pitches for new Disruptive Innovation teams that much stronger.
Finally, as your Innovation teams need to quickly and efficiently discover new viable product ideas regularly to continue this investment, using Velocity as a measure of impact is a good idea. This encourages the team to remember that the instinct is to slow down as the product matures, but we must continue investing in ways to keep the product moving forward quickly. This means both the development and deployment of the product to end users and the experiment velocity — the speed at which an idea can be created, deployed, validated, and rolled out to all users, or else invalidated and removed from the codebase. While we didn’t work hard to directly measure the actual Experiment Velocity in any real units (See Goodhart’s law for one reason to consider not directly measuring this), having a number of other measures related to it (delivery lead time, team health, experiment duration, etc.) will give you a good indication as to whether your team has a health Experiment Velocity.
Given our team design and constraints, we had a goal to be the fastest-moving team within the company. We never made the competition with others explicit or denigrated other teams with lower velocity (recognizing that they had very different constraints they were operating under). Still, as a leadership team, we were constantly on the lookout for any tools or techniques that other teams were using that we could leverage to go even faster.
Executive Support
Once you’ve designed your team charter and defined your success metrics, it’s time to get executive support. This will take a number of forms, and you’ll need more than one executive bought in to make it work. These executives will be the board members overseeing each of your Disruptive Innovation teams to make sure they stay on track, helping clear blockers for those teams, and the person who holds the most sway in whether a team continues to innovate on this experiment or moves on to another opportunity.
First and foremost, you’ll need an executive sponsor for the program. This could be the CEO, President, or any other executive, and with their broader reach across the organization, it will be helpful if it is. The first thing they’ll do is provide legitimacy to the program to other senior leadership team members, convincing them to lend a few members of their teams to your program. You’ll also need some regular time with the executive sponsor to discuss a few key topics: cross-functional needs beyond the bounds of your program to ensure that all of the blockers and slow areas of the company are (relatively) smoothed out for your Disruptive Innovation teams. They’ll be essential in helping promote the organization and the opportunities to contribute to the broader company. And finally, the executive sponsor will also be the one to determine who else within the company has the power/privilege of selecting the Disruptive Innovation teams (a role they’ll likely play as well.) We’ll call this role the Product Executive Sponsor to keep it clearer.
Having seen this a few times before, if this program is solely sponsored by the Product or Engineering organization leadership, you’ll miss the larger opportunity to use the force multipliers of Marketing, Sales, Legal, and so much more. Additionally, you’ll limit your learnings from Disruptive Innovations to the Product/Engineering realms. Having Marketing, Legal, Sales, and more involved in the early stages of the project will allow their organizations to learn ways to improve their process and extract additional insights from your team processes.
The Product Executive Sponsors could be heads of various business divisions or their delegates, the heads of Product Management, Sales, or another functional area, or even active board members. What matters here is that they have the authority to green-light a Disruptive Innovation team and the business experience needed to guide it as it seeks to produce additional business value. These sponsors will meet regularly, likely monthly, with each sponsored team to review the current progress, product experiments, and planned work that’s coming up. Additionally, they’ll be the ones to lead the decision around whether or not a Disruptive Innovation team should continue or stop work on this product at seminal moments of the product lifecycle.
Avengers Assemble
Assembling the “perfect” team is another area for much consideration. A few clear elements are needed for a Disruptive Innovation team, namely the Product and Engineering team members. Still, the Innovation Program should provide a number of other cross-functional staff members to help ensure that all of the roadblocks for your Disruptive Innovation teams are eliminated regularly and efficiently.
Product Managers
The Product Manager will act as the CEO of this Disruptive Innovation team. They work with the team and the executive sponsor to establish a vision for where the product will go. They take in all of the user feedback, session data from your web applications, information from various product experiments, and feedback from the team on the return on investment of various features and provide a clear, executable roadmap for the next few steps. We’re not going to go into a ton of detail on the techniques of Product Management that make the most sense here, but “Inspired” by Marty Kagan and “Nail It, Then Scale It” by Nathan Furr and Paul Ahlstrom (especially the Nail It section,) are a great place to start. “Lean Startup” by Eric Ries also has a lot of great resources on this topic.
You may be able to use reasonably junior product managers for some smaller projects. Still, generally speaking, a more senior product manager for any sizable product will probably be necessary to establish the right culture of innovation, experimentation, and measurement, as well as the everyday tasks of keeping a healthy backlog of ideas for the team to keep moving forward.
Very briefly, let’s talk about an anti-pattern in Product Managers. They are not the decision maker. They facilitate the team making decisions. In the worst-case scenario, they cast the tie-breaking vote or override the team with a lean experiment that will shed data on the direction the team should go next. These Product Managers need to partner and lead their team through influence, not the strength of will.
Engineering Team
Engineering teams will be comprised of at least two software engineers, never less. A team of one is no team at all. Having at least two engineers allows individuals to take time off, attend conferences, and work on their career development without feeling bad about the project’s trajectory. Generally speaking, early on, you’ll be able to do a lot of the work with more junior and mid-level engineers, depending on how many integrations you’re using to leverage your core product, but as the product grows and expands, you’ll either need to give more responsibility to your engineers or bring on more senior engineers to help the product grow and scale successfully.
Initially, some of this higher level design and planning can be led by the engineering manager for the team. They’ll be responsible for establishing simple, workable engineering processes that keep the team building and deploying software regularly. Given the overall team size, your engineering managers (unless they’re fairly new to the profession) will likely manage two or even three teams. More than that is possible for short periods, but if the teams have very many ceremonies at all or if the overhead of your organizational processes (security, procurement, privacy, etc.) takes much tax on your engineering managers at all, it will be tricky for them to manage more than three teams at any given time.
Occasionally, as the team grows, you’ll need additional engineers beyond what the project demands to ramp a new engineer up on your technology stack or cross-train an engineer joining the program. This should give your more senior engineers on the team a chance to mentor the new team member. Still, you should encourage them to use the extra time to contribute to your base project definition so that your team’s next experiment will start from an even better place.
User Experience
User Experience Designers are crucial to at least two main parts of the Disruptive Innovation teams. First, they’ll help provide mock-ups and designs for the product’s progress, such as the long-term vision. These mockups will help the team understand the value proposition for this product and how customers are expected to experience the product. But these designs are a vision, not a goal to be achieved necessarily. The second thing the Designer will provide is a clear picture of how the critical feature of the minimum viable product (MVP, see “Lean Startup” if you’re unfamiliar or need a refresher) will work. Engineers should be able to quickly and easily convert these designs into a usable products.
One critical thing is a common design language shared between Engineers and Designers. We recommend something simple and easy to use, like Twitter’s Bootstrap UI framework, but any design library will work. The goal here is to constrain Designers to use “off-the-shelf” components as much as possible so that Engineers can quickly and easily assemble those components and focus on the core business logic that makes the product valuable to your customers. You’ll need to customize it a bit to make it look like the rest of your site, but with minimal overhead, you can have a simple and usable design library.
Another couple of things we’ve tapped our Design teams to help with have been both kickoffs and collecting user feedback. Kickoffs are the first three to five days of a new product and typically involve a Design Sprint (See “Sprint” by Jake Knapp for more information on this technique). Still, historically we used a more home-grown approach of collaborating on a Lean Canvas to identify the product attributes. Having a designer lead this effort is helpful because they’ll become very familiar with the user’s use cases, pain points, jobs to be done, and desires.
Our Design team has also been invaluable in collecting user feedback. We’ve used a number of techniques, from paying for feedback via tools like Usertesting.com to capturing structured data in our own Usability Lab (pre-Covid of course) or other tools like Hotjar and FullStory that allowed us to monitor user sessions after the fact. Teams would often do lunch every week or two and review key user sessions pre-selected by our UX team to help everyone feel connected to the pain and successes of our customers.
Marketing & Sales
The Marketing team will be critical in the early-stage Disruptive Innovation teams. Since it’s a brand-new market or product, user acquisition will be essential. A strong Marketing partnership will allow you to either “buy” users via search engine marketing (SEM) or run successful marketing campaigns via email or other mediums. Additionally, Marketing will be key in testing the messaging on your products’ landing pages, ensuring that the value proposition to users is clear and crisp.
Depending on the product, you may also need some Sales representation. The Sales team will help test the various paths to customer acquisition (direct sales, phone sales, etc.). Sales will also be instrumental in discussions and experiments centered around pricing models and price testing. Some products will not require a Sales team member, but having someone to bounce ideas off of or give other advice will still be helpful.
Program
Program Management plays a vital role in running the Incubation program as a whole and guiding each Disruptive Innovation team through various hurdles that may present themselves. Either way, the Program function will make sure that dates and deliverables are communicated, they’ll help break down some of the larger projects into smaller milestones, they’ll work with various stakeholders to make sure trains keep running on time and equally important, they’ll spearhead capturing the key learnings from each project as it shuts down or exits.
Let’s first examine the program as a whole. Here, Program will manage the group’s calendar to ensure that all executive check-ins, regular and continuation pitches, and learnings presentations where acquired or shut down projects share their learnings with the broader organization and company. Program will also be helpful here in securing various commitments from partner teams around the organization to keep the Incubator program running smoothly. Teams like Procurement, Security, Accessibility, and Privacy will often want both commitments to quality and safety. Still, they will (with some finagling) be willing to give some concessions on speed, knowing that Disruptive Innovation teams will often only last a few quarters.
How Program supports individual teams will vary based on the team’s goals, where in the project lifecycle this team is (newly funded, rapidly growing, preparing to exit, etc.) Program will help ensure that any applications or services the team needs access to are quickly secured. Program will also be the heartbeat pushing the team to capture and share learnings regularly with the teams around them and the company. Program is a bit of a catch-all role, so it would be impossible to list everything they will do, but consider them the conduit through which most interactions with outside teams/organizations will often flow. As such, they play a critical role in helping the team keep their speed of delivery high.
Legal
Depending on your organization’s risk tolerance, your partnership with Legal could vary between a consultant on your projects and a key stakeholder with “veto” power over the Disruptive Innovation teams. The key here is to build a partnership with Legal that helps them understand that your program will work to minimize risk (fewer customers, less revenue, less data, less time, etc.) in exchange for a bit more forgiveness if they push the boundaries too far.
It will be helpful to understand the key risk areas for the company as a whole (e.g., financial or health insurance compliance, Fair Credit Reporting Act or other disclosure requirements, or something else entirely.) We regularly referred to the largest risks for our company as the four horsemen, as they had the potential to end everything. These are critical to understanding and regularly training your team about them so that they can avoid running afoul of them.
Beyond the general company-ending type risks, each of your Disruptive Innovation teams will often face several other risks. Having a partner in Legal who can help navigate these risks and update any terms and conditions, privacy policies, or other legal documents will help maintain smooth operations. Initially, they’ll want to work on language that also protects the company from “beta” products. This umbrella legal coverage gives your team a lot of room to experiment.
Hiring for Disruptive Innovation
Creating and growing this team will require a fair amount of external hiring (and a healthy amount of internal transfers.) The challenge is that your Disruptive Innovation teams will likely have a rather different approach to software development than your other teams. With that in mind, simply reusing your existing hiring approach will not likely provide you with team members who are well-aligned with the Scaling Innovation approach. Hiring for these Disruptive Innovation teams is always tricky, but we’ve found a few techniques to make things a bit easier.
Flexibility
Not surprisingly, Flexibility is a key attribute of Disruptive Innovation teams and team members. You’ll need team members who can flex from their core discipline into customer support, user experience, product strategy, sales, and so much more. Additionally, flexibility will be key in finding team members who can quickly move from one project to another without being overly attached or crestfallen when a project ends.
Finding genuinely flexible people is one of the hardest things to interview for. Of course, typical behavioral interview questions will give you some indication. Still, we’ve found a number of questions like “Tell me about a time when you had to do something that wasn’t in your job description” or “Tell me about a time when you had to ‘hack’ a non-technical system to your benefit” can help you find people who not only are flexible but those who genuinely enjoy flexibility.
Initiative
Gets sh*t done. See’s a problem, kills a problem. Doers. Whatever you want to call them, people with initiative are worth their weight in gold. Initiative is critical for Disruptive Innovation teams because there’s much to be done and many more problems to fix. Of course, initiative on its own is a bit dangerous. You don’t just want people who took initiative on the various inane tasks that cropped up, but instead, those who could discern which items were worth their precious time and attention. Spotting initiative in a typical interview is tricky, but with deep questions about the work they undertook at previous employers or a few behavioral questions like “Tell me about a time when you went above and beyond” or “Tell me about a time when you had an idea and saw it implemented” you’ll be able to spot those who possess more initiative regularly.
Jack of All Trades
Being a “jack of all trades” can be considered a negative in many places, but for Disruptive Innovation, it’s a very strong complement to the flexibility we discussed earlier. Not only are you willing to take on a customer support call, but you also have vital emotional intelligence and can help solve problems to make the customer happy again. Or perhaps you can solve backend business value problems and create a clear user experience. Whatever sets of skills you have, they’ll be useful if put into practice.
There’s a good corollary to this: hiring for diverse experiences and backgrounds will give your team more chances for success. Bringing on diverse talent with varying years of experience, skills, previous company sizes, industries, and other factors will empower your team in ways a monocultural team could never achieve. Yet another win for diversity!
Happy Easter, everyone. I hope you all had a great Easter weekend with your family and friends. It was a beautiful weekend to celebrate, and amazing to see the confluence of Easter, Passover, and Ramadan. I hope all of your celebrations have been equally blessed. This time of year, the grass is starting to grow, the trees are putting out their leaves, and flowers are blooming. It’s a time of rebirth, which seems very apropos, given we’re three weeks into a new start of our own. New growth builds on previous expertise and experiences, so let’s start by looking back at where we’ve been.
Looking back
Another characteristic I appreciated about Indeed was the autonomy in the Engineering organization. I regularly saw teams given the leeway to set their goals, the measures of success, and the methods to accomplish their plans. I know this isn’t the case everywhere within Indeed and isn’t common in other companies I’ve worked at, but it was something I found impressive about Indeed.
We have autonomy in spades now that we’re laid off, but it’s a double-edged sword. We have the freedom to do everything and the opportunity to do nothing. We have to provide the structure for ourselves on how we utilize our time. As for me, I’m trying to balance time spent networking with time spent in self-development. Networking with those laid off and in the workforce rekindles old friendships and opens new opportunities. Self-development means journaling about what’s next in my career and “sharpening the saw” by writing some code again.
Even after you find your next job, this sense of and desire for autonomy will not immediately disappear. In fact, according to this HBR article, autonomy is now a key driver in selecting jobs and staying with companies. I appreciated the suggestion to focus on principles over policies and the breakdown of self-determination into autonomy, competence, and relatedness. (12 min read)
Looking forward
I’m hearing some stories of laid-off employees finding their next role and want to say “Congratulations!” to each of you. I know some roles will take longer, so some will be searching for some time. For you, my advice is “keep your hopes up.” Opportunities are out there even in hard times; they’re harder to find.
When you’re interviewing, most companies will give you several opportunities to ask questions (if they don’t, it’s a pretty big red flag for me.) While this article is specifically about interviewing for a VP of Engineering role, this set of questions to ask when interviewing should be a valuable resource. (8 min read)
Today’s Tip
After two weeks in a row of LinkedIn tips, I wanted to branch out and suggest some new tools. I realized a little too late that with our health insurance expiring at the end of the month last month, I should have decided earlier which insurance to get for this month. I knew I had the fallback option of COBRA coverage which could be reinstated retroactively, but I did not connect the dots that many open-market insurance plans don’t take effect until the start of the next month. It’s not a huge issue to have a one-month gap in insurance; however, since we had several appointments scheduled this month, it is a challenge. So, for those who’ve been putting off this work, if you’re considering a non-COBRA plan and you want coverage next month, be sure you get the selection made before the end of this month.
Fun Stuff
Sorry for the bit of language in this week’s fun stuff, but these are pretty tame and all too appropriate right now.
Editing your resume and …
Finally, getting back to the gym like:
Final Words
If I can help with your search, please get in touch with me. Please give me feedback on what you like or don’t care for in this newsletter, and I’ll adjust. For full transparency, I have no affiliation with any of the tools, companies, or resources I share. These are my impressions, not tainted by any outside influences. https://onlynewmistakes.com/
We’ve written this book to share a strategy for Product and Engineering leaders trying to introduce (or, more likely, re-introduce) innovation to their company’s way of operating. Whether your company is doing fine and you want to future-proof it, or a competitor has already disintermediated the core product and you need to turn the ship around, Scaling Innovation will provide you with a holistic framework for creating an innovation fire within your company. It also offers numerous useful strategies for stoking that fire until your next innovation is wildly successful.
Beyond the strategy, there’s a story playing out on these pages. If you sit back and take it in, you’ll see opportunities to apply principles from Scaling Innovation to any team you run. Every team needs to innovate, and you should filter these ideas into your company and role. So, take what works for you, skip the rest, and share your experiences with others. That’s the beauty of this industry: we’re all a work in progress.
What is Innovation?
Let’s start by clearing up a few things on Innovation. This book presumes three types of Innovation, with the core focus on the final type. There are probably a million more definitions you could use, but one of the things we’ve learned over the years is to keep things simple enough they can be repeated easily and regularly, and three fits nicely on one hand and in people’s brains. The three types of Innovation we will reference owe a lot to the McKinsey study on the three horizons of innovation. That’s a good read when you’ve got the time, but we’ll provide a cliff notes version to get you started today. (Incubator Principle #1 – get started and then get better!)
Merriam-Webster defines Innovation as “the act or process of introducing new ideas, devices, or methods.” For our purposes, we’re heavily focused on software engineering, particularly product innovation, given our backgrounds in both startups and enterprise organizations. So our focus is on new product ideas, new devices to solve customer needs, and new processes to further our business.
The first type of Innovation is Sustaining Innovation. These incremental improvements keep a product functioning well, more flexible for your users, and using the vernacular is often referred to as KTLO (Keeping the Lights On) work. Teams must recognize the impact of these innovations even though they only produce small incremental changes overall since those improvements continue to help keep the core of the company afloat and show users that you still care about this product. A few examples of this type of Innovation include improvements to friend recommendations, improved ad relevancy, new processes that simplify the user flow, features that make the product more usable, or new technologies that dramatically improve the page load time. This work is done by core Product and Engineering teams every single day.
The second type of Innovation is Emerging Innovation. The goal is to leverage your existing product base into a new opportunity. It’s a fairly natural extension of your current product or services into a new but related space that users expected your company to move into. It will likely change some of your business processes, teams, and maybe even business models, but ultimately you are still in the same overall business afterward as you had been previously. Your existing Product and Engineering teams will also accomplish this type of Innovation if you give them the mandate and opportunity to do this work. Examples of Emerging Innovation include techniques like updating the product to move from a pay-as-you-go model to a subscription model, utilizing machine learning techniques to automate previously very manual portions of a task, or changing the delivery mechanism from email to the latest platform that reaches your audience (SMS, Twitter, Facebook, TikTok, or whatever comes along to make these references out of date).
Both types of innovation are still mainly on the S-curve, as described in Clayton Christensen’s book “The Innovator’s Dilemma.” A great read as well, but to butcher a masterwork and keep us moving forward, we’ll summarize it with this: incremental innovation (whether sustaining or emerging) will lead you to a local maximum within your current market but is unlikely to notice and foster the growth necessary to take your company to a new growth curve, in a new market, with a higher maximum. The important part is not to miss the opportunity to innovate and jump to the new curve at the right time.
The third type of Innovation is Disruptive Innovation. Here the innovation will replace your core business or add another more valuable line of business to your existing company. These big ideas are locked up in your organization, and you need to execute them, or else a competitor or a startup will come along and beat you to the punch. These opportunities are yours to lose and are the book’s focus. These processes and techniques can be adjusted to help discover and deliver Sustaining and Emerging Innovations. Still, the goal is to provide a framework for building a Scaling Innovation team that regularly delivers disruptive innovations to your company. Disruptive Innovation can not be done within your existing Product and Engineering teams; you’ll need dedicated and specially equipped teams to do this work. Let’s talk about why.
Killer Innovation or Innovation Killer?
Many teams will discover Disruptive Innovations in the course of their daily work. This happens when a salesperson speaks with a customer, and the customer explains how they wish the company could make something easier. Or when a customer service representative takes a call and listens to an upset customer disappointed that your company’s product doesn’t meet their needs. On the Product and Engineering side, this occurs when a team sees an opportunity to re-think their product and dramatically provide users more value. Unfortunately, most of these ideas aren’t shared with anyone. The lucky few may get started but then die on the vine when a team tries to tackle it, finding that there isn’t organizational support to make it successful, and concludes that the business idea failed.
At a certain size, companies often begin to take on a portfolio approach to the work. Dividing into divisions or general manager areas will simplify decision-making and clarify ownership. Innovation teams often don’t fit nicely into these paradigms, and some corporate structures will work against innovation teams running rogue. Let us look at a few reasons Innovation teams will need different support structures.
Nurturing Growth
Successful Innovation can take off at a new speed, often growing five (or 10, 20, 50) times faster than the core business (while still much smaller). That growth on its own may not be that scary, but when you couple that with some of the other risks, it can be a very scary proposition for teams. Nurturing that growth and turning it into a large new business area will require extra time, attention, and resources to keep it alive.
Coexistence
Disruptive Innovation teams also find it hard to relate to the teams around them as they work on the next new thing and find that none of them are doing anything similar. The Disruptive Innovation team is often on their own to get access to the resources (be those technical tools like APIs, data, or services or cross-functional support like Marketing, Legal, etc.) that they need to be successful because the company has to focus on the core product line.
Transform the Business
Disruptive Innovation teams are often a risk to the core business metrics. They may be challenging the way business has always been done or actively pull users out of your sales funnel to their new (lower margin, higher cost, less proven) product interface. Giving them time to grow and mature (or flounder and fail) will allow the business to see if a new market opportunity is just on the horizon.
Adaptability
In our experience, this is the most common scenario that kills Disruptive Innovation teams. The rest of the business struggles to hire or hit key business metrics, and the Innovation Program is indiscriminately shut down to reallocate those staff members or budget dollars to other projects.
Note, this doesn’t mean we advocate never shutting down Disruptive Innovation teams. On the contrary, we regularly assess the projects in flight and shutdown Disruptive Innovation teams very often, but always because that innovation isn’t likely to pan out or there is a bigger innovation opportunity on the horizon that needs exploration (more on this later.)
So what does work, then?
So if embedding Disruptive Innovation teams into your core business doesn’t work, how should you structure your teams? The rest of this book lays out a structure for building a program, a collection of teams dedicated to Disruptive Innovation. A process for discovering those innovations, incubating them, and seeing them transition successfully into the core business.
Executive Summary, or TL;DR for the younger, hipper crowd
So many business books are written about business, but they fail to demonstrate one of the key successful business communication techniques. In business communication, the executive summary at the top of a document or a TL;DR (too long; didn’t read) section allows those under time pressure to feel like they’ve learned the book’s core message without spending hours reading it. Additionally, a summary up front makes the whole context clear so that the remainder of the content is easier to consume. This follows the adage: “Tell me what you’re going to tell me. Tell me. Tell me what you told me.”
Scaling Innovation establishes a framework for building a program to find, foster, and integrate Disruptive Innovation within your company (or organization.) It draws on the examples and iterations from a program run at Indeed for the last five (more now) years. It will guide you in establishing a program, finding the executive buy-in and budget, and building the organization to execute these Scaling Innovation teams.
You’ll learn what makes the Engineering and Product teams successful and how those teams differ from your typical ones. Additionally, you’ll see how the program’s operation works and learn from some of the most successful products in the first five years of the Indeed Incubator and a few missteps we made along the way.
The core values for this program focused on autonomy (of the program as a whole, but also for each team,) speed of experimentation and learning and a holistic view of each project. Breaking down some of the other keys to this model:
1. A dedicated team to explore ideas.
Disruptive Innovation programs should be detached from your core business. They’ll get oversight from the executives they report to and through the leadership placed in charge of this program but should not be directly responsible for other lines of business or business metrics.
Dedicated teams provide focus. They prevent other work from interrupting this Disruptive Innovation team. Dedicated teams let you hire for the additional skillsets necessary to make this growth and exploration successful (entrepreneurship, flexibility, and others). Separating this program into a separate team with a separate budget allows you to track the costs and revenues attached to this work to understand the return on investment. It also provides a sub-cultural identity that the team can rally behind as they work to re-invent your organization.
2. Executive sponsorship.
Having multiple executive team members, namely the chief executive, head of product, and head of engineering, bought in on building a Disruptive Innovation program will be crucial to the program’s success. The program will require their time regularly. Their input on product ideas, pivots, and other strategic directions to explore will give the team the high-level direction they need, as well as the validation of their current work.
Executive sponsorship also provides these dedicated teams with a “trump card” they can use (sparingly) to keep their project moving forward. Executive sponsorship provides a broader context to a team that could otherwise be very inwardly focused. Having at least one executive buy-in on the new product idea provides an air of legitimacy to the work to the other parts of the organization and a sounding board for pivots.
3. A cross-functionally aligned approach.
One of the biggest challenges of running fast-moving Disruptive Innovation teams is interfacing with other parts of the business. It’s like meshing a set of gears. The Scaling Innovation team is running very quickly (at a very low scale, most likely) and still trying to discover product market fit. The company’s existing parts are used to a much more tried and true (and likely scalable, repeatable, documented) process. Bringing these two things together can cause some friction. Having a cross-functionally aligned team can provide a layer of grease between the Scaling Innovation team and other parts of the organization. For example, having a Marketing person attached to the Scaling Innovation team allows the team to speak “Marketing” and know what systems are there to support the team. They have a liaison in Marketing and someone who can execute various Marketing components of growing this new idea into a full product. Pulling in all of the necessary cross-functional staffing to support these teams will save a ton of time and energy. Examples of the sort of help needed likely include (but are not limited to) Marketing/Growth, Sales, Legal, Security, and Program (beyond the core of Software Engineering, Product, and User Experience.) We’ll talk more about the role each of these plays in later chapters.
4. Minimal overhead, maximum speed.
While Disruptive Innovation teams have to meet your company’s minimum guidelines for data governance, security, privacy, etc., dropping as many of the other limitations on these teams is helpful. Allowing teams to use whatever style or software development lifecycle, customer engagement tracking, email campaign tools, and more will allow them to learn from their customers and discover new businesses quickly.
Additionally, they should only own the product experiments they’re building (no maintenance of legacy projects.) Any legacy products should be shut down to avoid building up a backlog of products that must be updated, measured, monitored, and maintained. Occasionally, Scaling Innovation teams may find it helpful to build a tool or a service to make innovating faster or easier. These should be as small, simple, and low maintenance as possible.
Finally, Scaling Innovation teams should have a bias toward action. They live and breathe moving forward. They leverage processes that get products live as soon as possible and start measuring from day one.
5. Projects are dead unless proven otherwise.
To keep the maintenance burden on legacy products low and ensure the team is always working on the most important things, you’ll need an effective way to shut down projects quickly and move on to newer or more important work. Investing upfront in a process for quickly disabling products, transitioning users out of the product, cleaning up all lingering data or other assets, and capturing learnings from the project will pay dividends. You’ll shut down more projects than you claim success on.
An Example Project
Another way to quickly understand the Scaling Innovation approach would be to walk a fictitious product through the lifecycle from pre-pitch to exit/shutdown. Suppose a Sales Engineer at BigCompany has just discovered a new opportunity adjacent to their core business. They research the idea and discover the Incubation program that allows them to pitch the idea for funding and apply to pitch at the next round in a few months. In the meantime, they meet with a Pitch Coach who helps them think about the total addressable market, minimum viable product (MVP), and competitive differentiation for this idea.
The months fly by, and soon, it’s time to pitch to the Executive team. The Sales Engineer has created a slide deck and comes into the pitch well-prepared for many of the questions the executive(s) will ask. The pitch goes quickly, clocking in at just a bit more than the five minutes allotted, and the questions and answers portion also goes pretty smoothly. They can answer several questions about the competition, how they plan to get started, and the key measures for this new product. They feel good, and the executives can tell the Sales Engineer has done their homework. After the Sales Engineer steps out of the room, the executive team discusses the pitch briefly, and very quickly, one of the executives agrees to fund this product. This executive will be the executive sponsor. They give the team a typical Angel Round of funding – three months, a budget for three-five full-time team members, and a general expenses budget of around $50,000 that they can use for Marketing, customer rewards, contractors, services, or anything else within reason that will help the team go faster or learn more quickly.
In the before COVID-19 times, the Sales Engineer would have relocated to the office where the Incubator team was located. However, since everyone is still working from home, they plan to leave their Sales Engineering role and join the Incubator team as a founder. In the meantime, the Incubator team is a flurry of activity, lining up two (maybe more) engineers, a product manager, and some additional user experience, marketing, sales, and other help to launch this new idea. Most of these people come from other Incubator projects or were working on internal projects until a new Scaling Innovation team was formed, so there is no need to wait for new hires to interview and start getting this project up and running.
The new Founder’s first day on the Incubator team is hectic. They’ve been introduced briefly to their team a bit ahead of the start, but today is the official kickoff. The whole team will be there – all full-time members and a handful of other folks supporting this product alongside others, e.g., User Experience, Marketing, Sales, Legal, etc. They’ll spend the next three or so days in a modified Design Sprint (hat tip to Google Ventures and Jake Knapp for this great process) to learn what this product will look like when it ships to production. They focus on the customer and the pain point the team is trying to attack. Next, they consider how the company and team can help solve this pain, paying special attention to how the company platform can be leveraged to create a competitive advantage. They are going back to the first principles of the design of this product, ensuring that everyone on the team understands the key value the product is meant to provide.
After the kickoff, the Founder moves into an advisory role guiding the team and helping to line up the necessary clients to test the idea. The Engineers, Product Manager, and others set out to build the MVP, ideally shipping it before the end of the first month. This will give the team time to measure and test a few different ideas before they have to pitch for continuation around weeks 10 to 12. The Marketing and Sales team partners for this team kick into high gear to explore messaging and sales models. The User Experience team has already lined up a few user tests of various mockups and other simulated screens to begin getting user feedback.
In a flurry of activity, the MVP goes live one month into this project (after a preliminary review by Security, Legal, Privacy, and a few other teams to ensure compliance.) The team will do a deeper dive with many of those teams in the future, but enough of the boxes were checked for now to start gathering real user feedback. It’s a rough and somewhat embarrassing MVP, but it does provide some value, and customers begin to sign up and use the product. The team regularly gathers to watch user sessions and see how users expect the product to work or what value they hope it can provide for them and continue to plan the enhancements to the product.
For the next four to six weeks, the team works feverishly to develop the key features for this product, with a heavy focus on things that provide the most business value or reduce the risk to the product’s success. They know they are shipping some less-than-ideal code and user experiences (i.e., technical debt, more on that later), but they also know that if the product doesn’t get continuation funding in a few weeks, none will matter. As they approach the end of the first quarter, they begin to work together as a team to prepare the continuation pitch, which will show the results of their work, what they have learned so far, and where they will go next if given additional funding.
Each week throughout the project’s life, the team gathers to discuss the results of A/B testing for various key features, the overall strategy, and the deliverables that have shipped since the last chat. It’s an informal meeting with other Incubator team leaders and senior Innovation leadership. It works as a way to challenge assumptions and help the team move faster or with more clarity and direction. The team meets with their executive sponsor monthly to review progress, get their guidance, and ask for additional help.
The day of the continuation pitch arrives, and the team watches with bated breath as the founder shows the executive sponsor and a broader funding committee a snapshot of what the team has accomplished and where it plans to go next. This time they have a bit more time, and everyone has more context on the product and progress, so the focus is on direction and execution. All signs point to a strong start for this new product. So after the founder and team step out of the room, the executive team has a quick discussion that makes it clear they want to continue the product experimentation in this area and increase the investment. Of course, they could have chosen another three months of funding, but the project is promising, and giving them more time to run could be what it needs. This time instead of only three months, the team will have six months before the next continuation pitch, and rather than just doubling the budget, they’ll get a triple budget. They now have room to bring additional engineers or other necessary roles onto the team and have a larger general budget. The next six months look a lot like the first quarter. Weekly check-ins with the broader Incubator team. Monthly executive check-ins. Experimentation and growth. Rinse and repeat.
Now the team has come to a fork in the road; they can continue to receive additional funding rounds, 12 months, maybe others even longer, and eventually reach a point where the project is so large and successful that the best thing for it is to exit the Incubator all together, or they can reach a point where the executive team no longer wishes to invest additional time/money into this project in which case it will shutdown. Either way, the team will work to produce several presentations and other documentation on the learnings from the product and share them with a variety of stakeholders around the company. Those final presentations will also be archived on a wiki page or other internal documentation hub allowing everyone in the company to see what the team tried and learned.
All of this can play out over ten weeks, or it can take years to reach a point where the product is ready to exit the Incubator. This system of metered funding provides the framework for evaluating products regularly to compare the opportunity cost of continuing with the various other ideas the company could be pursuing. It also acts as a governor to prevent wild overspending on any new ideas to make sure that they compare apples to apples with other experiments the company has tested previously. It prevents a product from looking successful because it’s getting pumped with so much extra funding compared to other products and rewards the frugal successes. The first thing you’ll need to build this is a team who understands how to Scale Innovation.
I’m blaming myself for this layoff. Let me tell you why by telling you a story.
In February 2020, I signed up for StitchFix’s Style Pass (one year of unlimited “fixes,” e.g., boxes of clothes to buy or return.) That was just a bit more than a month before Indeed went fully remote for the COVID-19 pandemic. I might have been the only person to get more and more dressy throughout the first year of the pandemic.
Here’s the thing. Last month I signed up for the Style Pass again. I needed some new jeans and a few replacement shirts. I had no idea that a StitchFix subscription could trigger another significant shift in my life, let alone for many others who had no idea it was coming. I’m sorry y’all.
Now, obviously, my purchase of Style Pass didn’t cause the layoff. Still, I tell this story to remind us that our brains will take the easiest path to explain a situation. It’s not healthy to only ruminate on what you did that caused you to be included in the layoff. So let’s look back and learn, look forward at what’s to come, make the time to laugh a little, and make a plan for our next step.
At Indeed, we often talked about the flywheel effect. Maybe you’re thinking of the Job Seeker flywheel, the Performance Management flywheel, or some other flywheel within the business. The flywheel effect is one of my biggest takeaways from Indeed. Looking for ways to create flywheels/feedback loops/virtuous cycles to get to where we want to go. (4 min read)
The same concept applies to your job search right now. Doing the next right thing, even if it’s small but moves the ball forward, builds momentum. Set a routine. Take a call. Practice interviews with peers. Take interviews with a company to get back out there. Whatever it is, a little momentum will help you through this tough time. Even rejections help move you forward. They tell you a place where the door is closed and help you refine your process of explaining the value you bring.
Looking forward
OK, it’s been over a week since we were laid off. Hopefully, you’ve taken some time to reflect on what you learned and what you want to do next. This week, even without a full-time job, I still found myself very busy. Coffee with old friends and former coworkers. Lunch with potential teams I could interview to join. It all added up to a lot of time on the road and away from my desk. This article on managing your time was a good reminder to pay attention to where my time is going. (8 min read)
In terms of things to get rolling this week, it was time to do a number of boring procedural things too. Investigating and filing for unemployment. Looking for replacement insurance to compare against the COBRA coverage. Making sure I got all the last bits of data (payroll stubs, performance data, legal documents, etc.) from Indeed.
Today’s Tip
Last week I mentioned how important using your network was. This week I’ll share a really tactical tip on using LinkedIn introductions. When you introduce yourself via LinkedIn (or when someone else introduces you), you can remove individuals from that conversation, much like moving someone to BCC when using email.
Clicking the … at the top of the conversation gives you the option to leave or remove people from the conversation reducing it to just the people who will be conversing post-introduction.
Fun Stuff
You made it this far. Here are a few fun cracks at the layoff market and one cat gif to cleanse the timeline until next week.
Final Words
If I can help with your search, please contact me. Please give me feedback on what you like or don’t care for in this newsletter, and I’ll adjust. For full transparency, I have no affiliation with any of the tools, companies, or resources I share. These are just my impressions, not tainted by any outside influences. https://onlynewmistakes.com/
I announced in November of 2021 (with an update in December as well) that I was writing a book about our Incubator and the Scaling Innovation process. After approximately a year of mostly hiatus, I picked back up editing and re-reading that first draft. It’s not perfect. There are several other books out there about similar things. I have about a million other reasons to just delete it…but…it’s written, and now that my time at Indeed has come to an end, sharing a bit of our story feels like a useful ending. So, here’s the prologue to the book. I’ll try to release a new chapter approximately every week or two going forward. I’d love any and all feedback – LinkedIn, the contact form, Twitter (I’m paying less attention to this of late until the hubbub settles down, or Mastodon.
Prologue
Like any process, this one isn’t perfect, and it isn’t static. However, our strategy for scaling innovation proved successful on several occasions. Over five years, more than four dozen products have been tested using this approach. Many did not work out, but a few survived and thrived, making a significant impact.
Our team comprised start-up veterans from Product and Engineering, leaders, boot camp graduates, and classically trained Computer Scientists. Before we started the Incubator, the team had honed several vital skills, such as rapidly delivering business value and measuring product success. They learned that shipping a product required acquiring users quickly to demonstrate the value created was something users truly wanted. Adopting the Scaling Innovation approach allowed the team to iterate swiftly on the innovation processes and the platform that powered them.
The team behind this success wasn’t special or unique. What set them apart was their deep-seated desire to improve the business every single day. They were relentlessly focused on helping more people find jobs. We couldn’t have achieved this without their diverse thoughts, opinions, and experiences.
Scaling Innovation is about the process we developed, discovered, and borrowed from various sources, along with the parts that made it work for us. It’s not a static process; it is still evolving today, more than five years later. However, it has been successful, as you’ll see. In this book, we will discuss the following:
The importance of the Scaling Innovation process
An executive-level introduction and a fictional example project
Strategies and techniques to help Engineering and Product teams
Meta-level guidance on running a Scaling Innovation program
Case studies and anti-patterns for Innovation teams
We hope this book inspires you and your team to overcome challenges in innovation, persevere when your resources seem exhausted, and ultimately grow your business in unexpected and remarkable ways.
Today starts my first full week of “funemployment” after nearly seven years at Indeed.com due to their recent layoff. I’m starting a weekly newsletter (hat tip to Brendan Sterne for his amazing newsletter when he was at Indeed) for a while to document progress, share tips, and keep my mind a bit busier while I find the right next role. I’m no expert on this space, just sharing my notes in the hope that they help someone out there searching. If I can help your search in any way, please reach out to me. I’ll probably vary the format of this newsletter for the first few weeks, so give me feedback on what you like or don’t care for and I’ll adjust. For full transparency, I have no affiliation with any of the tools, companies, or resources I’ll be sharing. These are just my impressions not tainted by any outside influences.
Looking Back
I’ve talked with a number of people who were very hurt by the layoff and I completely understand where they’re coming from. Personally, I’m mostly just feeling disappointed. I’ve definitely had moments where I’m deeply sad that my time in the Incubator is over, and been very upset about the stories of folks who are far more negatively impacted by the layoff timing (those with children on the way in particular.)
The best advice I can give and have seen repeated elsewhere is to spend some time reflecting. I couldn’t sleep the other night and took out my Remarkable (that’s another post for another time, but I highly recommend them for those who are curious) and jotted down a number of things I loved about my role, things I felt could have been better, what I wanted to do next, and people I should reconnect with. Unloading those things from my brain helped a ton and I was able to crash. Well, that and a healthy dose of melatonin. ;)
Forbes had a pretty straightforward article on coping with a layoff that I’d recommend. There are some good tips for getting yourself into a good place, and then taking on the immediate tasks of looking at your finances and healthcare to make sure you’ve got a good stable place to start. (4 min read)
Looking Forward
I’m fortunate to have several opportunities opening up, but I know that’s not the case for everyone. This read by Morgan Luce was a super short one, but very dense with tools and based on their search after their layoff. (2 min read)
This week my goal is to set up a system for tracking my next steps and to start filling it in with various opportunities that have already presented themselves. I’m planning to use Notion. I’ve only ever had a chance to dabble with it and wanted to learn more about it. Additionally, I’ll start looking through my network to see who’s hiring engineering leaders (more on that later.)
Additionally, I’m still trying to live the mission of “I help people get jobs.” I have time, resources, and a network, and I’ll be using them to help my fellow former Indeedians find their next good role. Reach out to me if I can help. My network is deepest here in Austin, but I do have connections across the globe as well.
Today’s Tip
Nothing revolutionary here: use your network. I dug into LinkedIn in earnest this morning and was able to pretty quickly find a number of roles in my network for former Indeedians. Mastering the quite powerful search functionality in LinkedIn is a great skill. I was able to filter to particular roles/titles, in my network, in Austin within just a few clicks and see exactly how I’m connected to those opportunities. (1 min video)
Several people in my network have already reached out to me and I’m looking at a number of opportunities in a number of different industries. It may not be my next “forever” job, but in this challenging market, I’m thankful that there are some great companies looking to pick up the amazing talent that’s being laid off from big tech. I know that’s one of my favorite parts of the job and I look forward to being back in those trenches soon.
Fun Stuff
You made it this far. Here are a few fun cracks at the layoff market and one cat gif to cleanse the timeline until next week.
I announced that I was writing (or trying to write) a book in November about our experience running the Indeed Incubator over the last 4+ years. (For the uninitiated, the Incubator is our new product innovation group at Indeed. Think of it as an internal venture capital program.) I wanted to give a quick update on that experience. I didn’t end up writing every single day. In fact most days I capped out just a bit over the needed 1,667 words. I missed the 50,000-word target but I did get about half that down on paper (screen?).
Where’s the book, bro?
It’s not in a place where it can be shared yet, sorry. However, having this much down has given me the confidence to share with others close to me about my intention to finish this project. I’ve even had several people volunteer to read the pre-release book when it’s ready. I haven’t even started figuring out whether I’ll self-publish or look for a traditional publisher to help get this out there. I still have quite a bit more work to do to get this ready for publication anyways. Even if I never make a dime off this project, the act of capturing many of our learnings in one place has been incredible. I fully expect this will be a very valuable resource for our team members. It will really help them understand exactly what it is that we do at Indeed.
A little Christmas present – tips from my November writing excursion
Rather than making this a boring update blog post with no value for you, I also wanted to give you a few (recently learned) tips in case you’ve ever thought about writing. I’m by no means an expert, so take these with a grain of salt.
Planning is invaluable. My preparation in October was just jotting down various notes and topics I might want to capture into a book. Having that made writing in November just a matter of fleshing things out and arranging them in a sensible order.
Setting aside time was key. I tried to write in the evenings after my kids were in bed before my own bedtime or before spending quality time with my wife. This worked so-so. There are a lot of distractions in the evenings. Unfortunately no matter how much I tried I could not rally my brain to write in the mornings. Find a time that works, and be semi-consistent.
A quality tool matters. It took me a bit of time to learn how Scrivener works. However, after a quick tutorial and picking a reasonable template, I was able to use it quite effectively.
Just write – edit later. I think this tip came from my high-school language arts class. Unfortnately for me in this situation that was the last time I took a class specifically on writing. The core is simple. Don’t worry a ton about sentence structure or grammar. Just get the thoughts down. I ended up accidentally writing one whole chapter in more of a memoir format instead of the typical business book approach, so that will have to be edited, but the good news is that the chapter is captured.
New Goal!
I’m looking forward to sharing this with the world. For now, I’ve got to get a bit more written before it would make sense. My new goal is to get the shitty-first draft complete by the end of January. We’ll see how that goes, 2022 is looking to be another year of great change! Happy New Year to you all!
Performance management is one of those topics that everyone loves to hate on, but I’ve found that if done right it can produce real value for your team (and everyone will still hate on it.) The key to the most successful performance management process I’ve seen involves the use of flywheels (positive feedback loops, virtuous cycles, etc.) The crux of any performance management system is the evaluation of both the “what” and the “how.”
The Impact Flywheel
The “what” summarizes the work that was completed in the review cycle. It should include a measure of the impact that work had on the company, team, or product. First, this starts as a simple summary of the work completed, but the focus should be on finding the most important items. You can allow the smaller items to fall away. Second, enumerating how beneficial the work was is a difficult, but very important part. There’s no need to list every single accomplishment in the performance review. Finally, grouping the accomplishments into key areas that align with your career rubrics is a crucial element. For instance, leadership, collaboration, or technical mastery. This creates the first flywheel of performance management, a focus on impact.
By focusing on how the work completed made the company better and rewarding individuals you reinforce a culture of company improvement. Improvements can be making the company faster, more valuable, more profitable, larger, whatever is valuable to your team. Every time you reward someone for making the company better you encourage the team to look for more ways to do it again. As an example: say an engineer on the team created a new feature now used by 90% of new customers. We should congratulate them for that work by noting it in their performance review and reward them appropriately.
The Growth Flywheel
Similarly, the “how” of performance management is also a critical component. “How” looks at the behaviors demonstrated by the individual in accomplishing the work. However, you still only need to hit the highlights. Don’t document every single behavior that was demonstrated in the performance review period. Highlighting those behaviors demonstrating next-level performance will keep the focus on the most impactful work. Note: measuring these is considerably more tricky as the impact from this work is often subjective. Capturing the clearest demonstrations of behaviors your company values will create the second flywheel.
This flywheel of performance management creates a positive feedback loop of individual growth. Individual growth that is rewarded (say with a compensation increase, a promotion, or why not both) encourages even more next-level growth. For example, you notice a more junior team member is starting to show leadership across the team. You should encourage this by recognizing and rewarding that behavior. This encourages them to take on more leadership in the future.
The Partnership Flywheel
The final flywheel is less about the process of documenting the performance. It’s about how the individual and their manager partner in making sure the performance review is representative of their work. I’ve found that doing performance reviews in a collaborative (the manager and the individual working together) and progressive (writing down the accomplishments and behaviors throughout the review period) manner makes the work required at the end of each cycle considerably less onerous. It also drives good conversations about performance and growth opportunities throughout the review cycle. By creating a partnership between managers and individuals in this way you can create an organization that values performance growth.
This is the third flywheel of performance management. Individuals see growth and are rewarded for it. Managers help individuals grow and are rewarded for it. The company, product, or team improves and morale improves. And the cycle repeats as the company and individuals grow together.
I’ve wanted for a few years now to stop and write a book about the amazing innovation team we’ve built over the last five or so years, but the pace of life with the kids and the hectic nature of growing 10+ startups simultaneously have always gotten in the way. This month is no better, and yet, thanks to the Nanowrimo challenge I’m three days into writing a book on Scaling Innovation (title to be determined, but that’s not a bad working title for a book, I think.)
Honestly, I have no idea if this book will ever see the light of day, but the very act of revisiting the early days of creating the Incubator team, hiring, staffing, planning, and with the help of hindsight reverse engineering the work we’ve done has already been an insightful exercise. I’m not ready to share anything more just yet but did want to take a few minutes to procrastinate and put a bit more social pressure out there for myself to accomplish the goal of writing a book. Nanowrimo is mostly about writing novels, but I figure a business book is more my speed. I’ve told several close friends and a good number of my team members that this book is in flight, but this is a bigger stage than any of the rest of that combined.
I did a fair amount of pre-thinking and some organizing of my thoughts for this book for the last month or two in anticipation of Nanowrimo, and then really just started writing on November 1. It’s not any easier to find the time, but thankfully given the five years of lived experience, and the long-winded nature of family members that I’ve clearly inherited, it’s not been too hard to have the words flow. I’m behind on my goal due to missing a day already, but I’m hopeful that between weekends and some extra days off here and there I’ll be able to make up for the missed days and get caught up.
If you’d be interested in reading a book on how to create successful innovation teams and the process we created/adapted/stole that as launched 10+ new ideas into the ecosystem (several of which are multi-million dollar opportunities) drop me a line via the about page, or on Twitter. I’m not doing this for the dozens and dozens of dollars, I truly have enjoyed this experience and look forward to sharing it with you all.