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.
Congratulations to the Indian space agency and all of India for successfully landing on the moon! (Sorry, I’m generally a quiet space nerd, but this was cool and relevant.) After years of planning, hundreds (if not thousands) of people involved, and millions of dollars (quite possibly, literally a shoestring budget for NASA), India’s Space Research Organisation (ISRO) successfully touched down a lander and rover on the lunar surface—fantastic teamwork, planning, collaboration, and achievement.
Of course, none of us was planning our layoffs, but that doesn’t mean we cannot continue to be planful about our job search. I mentioned in week #1 that using a tracker (like Notion) would be helpful, and it has proven to be very useful in keeping track of companies I’ve applied to, follow-ups, things to research, and much more. I’ve also mentioned planning for your next role in week #12.
Today, I want to talk about planning for something entirely new. (Unfortunately, it’s not a job yet.) I’m partnering with an executive coach to co-create a curriculum for managers moving towards directors, VP, and eventually CTO roles. Cataloging leading teams into distinct lessons, reading materials, discussions, models, and homework has been gratifying. Seeing the years of hard-fought lessons and (more often) mistakes I struggled through has crystalized for me the vision and action plan as I embark on my next role. Even if you’re not planning to offer a course in your career field shortly, writing down how you executed and led has the powerful effect of forcing you to explain your thoughts. Give it a shot!
Planning Numbers
79% of profits have outpaced expectations this cycle…but that is based on lowered guidance leading to a 5.2% decrease in earnings per share against spring last year, a signal that more layoffs may be coming. source
2,400 Jobs were cut at Farmers Insurance, or about 11% of its workforce, joining Binance, T-Mobile, Robinhood, and Ford, showing that the tech layoffs may be the tip of the spear still. source
84% -> 50% drop in 6+ hour in-office workdays compared to before the pandemic. Return to office…but for how long? source
Plan to layoff the work
This coming weekend is Labor Day Weekend in the US. Get out and enjoy that last gasp of Summer. If you’re in Texas, don’t worry too much; we still have “second summer” to look forward to. I know it’s hard, but planning some downtime away from the job search is crucial to mental health. Refreshing your inbox, scanning LinkedIn for the 50th time today, revising your resume for the 90th time (does “resume_final_v2_done_edited.pdf” look familiar to anyone?), and similar activities aren’t going to be the way you get a job. They’re how you give yourself extra stress you don’t need. Plan a break. Step away. Read a book. Do something for yourself. Whatever you do, enjoy the long weekend.
Strategic Planning
As I’m writing the curriculum for this new course, strategic planning was a key topic. I broke it down into four areas where strategy is most important as you move from manager to CTO.
Strategic hiring – evaluating the teams’ skills, the business needs, the projected growth, the seniority of the group, and more to create a holistic plan for what roles are needed and in what order.
Product Strategy – connecting the company mission and vision with a long-term picture of how the product(s) will evolve and meet customer needs more and more.
Strategic Architecture – balancing organizational design with technical design to be able to deliver impactful software in record time.
Strategic Growth – growing the culture of the team and company from your current incarnation into the company you need to be years down the line.
I’m sure you will think of other vital areas to consider. I thought of several more to consider while writing today, but nailing these gives you a significant leg up over many other teams in my experience.
Alternate: A woman holding a frying pan in the store practices tossing food in the pan to see how it feels. A second woman behind her holds the pan and swings it as if swatting a fly out of the air.
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 total transparency, I have no affiliation with any of the tools, companies, or resources I share. These are my impressions, not colored by any outside influences.
We briefly discussed the kickoff process in Chapter 1, but much more goes into a successful kickoff. The kickoff is a chance to energize the entire cross-functional team about the product they’re about to build, excited about the customers they’re serving, and fixed on the same clear direction for the new development. Of course, it won’t start that way. It’ll be messy at first—lots of competing ideas and opinions. No data. No product. No clear MVP. But a little structure will bring order from this chaos, and you’ll have a great time.
The first thing that goes into a great kickoff is a lot of preparation. We have had both User Experience and Product lead the kickoffs, but ultimately, we landed on User Experience as our best fit. The key is you need great facilitators, people who are passionate about the problem space and want to hear all the voices in the room. Allowing the Product Manager or Founder to play the visionary without having to watch the clock and remember to give everyone a chance to grab some lunch helps maintain everyone’s sanity. Additionally, having the User Experience team member be the first to think through the problem space allows them to begin to crisp up the personas and maybe even bring some real-world user experience into the discussion.
Second, you’ll want all cross-functional partners there for the kickoff. This is an excellent chance for everyone to meet and get to know one another, so including at least one social event (if your budget allows) for the team to grab dinner or go to happy hour will kickstart the team formation process. The other benefit of bringing the cross-functional team together is getting all the voices into the room. Nearly everyone is starting from scratch on this idea, and (generally) no idea is terrible, so hearing more diverse ideas can help flesh out the problem space, the customer persona, or the solution.
We’ve successfully used two different kickoff strategies over the last few years. The first strategy we employed was having the team fill in a Lean Canvas (we modified it a bit, removing a few of the unnecessary boxes for teams in our group) over three days. Day one focused on the customer and the problem space, intending to state the customer’s pain points, needs, and desires at the end of the day. Day two was all about potential solutions and brainstorming ways to solve the customer’s pains. Finally, on day three, the team would explore the competitive differentiators and establish team goals.
This approach to the Kickoff had its merits. It was short and to the point. Very much focused on customer-centricity. It brought the team back to the principles for the product’s existence and who it should serve. But it had its downsides, too. It wasn’t as structured as Design Sprints. It didn’t incorporate any actual user data into the process. Worst of all, there wasn’t any documentation other than what we had written on how to do this process.
When our User Experience team learned about Design Sprints, they were very excited to test whether they would be helpful as a replacement for our custom kickoff routine. Sure enough, using (a somewhat modified) Design Sprints approach gave us the best of both worlds – a structure for running a successful kickoff that included public documentation/validation (vis a vis Jake Knapp’s book – “Sprint”) and a clearly understood process for exploring a new idea quickly and effectively. I won’t cover the whole process here, but suffice it to say it starts with the goals in mind, works through several potential solutions, and ends by getting real users to talk about your possible product and give you feedback, which is invaluable.
The kickoff results in a well-defined minimum viable product (MVP) that, while a bit embarrassing or risky, will very quickly allow your team to start learning. Let’s talk a bit more about what makes a good MVP.
Selecting the MVP
The Minimum Viable Product (MVP) is well defined in books like “The Lean Startup,” “Nail It, Then Scale It,” and ”Inspired,” so we won’t take the time to redefine it here. The core of how you approach the MVP for Disruptive Innovation teams is about three things:
1. Creating business value.
2. Reducing risk.
3. Learning.
Creating business value and reducing risk are covered extensively elsewhere and are core to the Agile software development methodology. They take some getting used to if you’re coming from another style of development (like Waterfall or other approaches), but with practice, they can be applied in most (if not all) situations.
Designing your MVP for learning is a new concept for many, so we’ll spend some time unpacking that. The crux of your MVP is testing the market to determine whether there’s enough value to warrant additional investment into this product area. That means if a feature or enhancement is not moving (or likely to move) a key metric by double-digit percentage points, you can defer it (or better yet, delete it. You can always think of it again when there’s more time.) We want to see that we have passionate users who are adopting the product, so if our sales funnel isn’t showing a solid conversion, we invest heavily in fixing that funnel and the messaging.
Reid Hoffman’s stance that if you aren’t embarrassed by your initial launch, you’ve launched too late is also correct. Please don’t wait for perfection (or anything close to it.) There’s so much to learn in a new business area that every day without a product in the market is a day of learning that is lost forever.
Getting started in Engineering will require some upfront investment. You’ll need a technology stack that is primed for experimentation. This stack will be the focal point of each of your product ideas. Consistency is a blessing here because solving a problem once means all other teams can gain from that wisdom, and the process of launching gets simpler for every subsequent product. An additional benefit from a consistent stack is that the engineers working on Product A can lend a hand or give a high-quality code review to engineers working on Product B or when Product B shuts down. The engineers can also easily and quickly join in on Product A because it’s very similar.
We’re intentionally mixing programming language and technology stack choices for this book to simplify the discussion. In reality, all of these decisions about language, database, scaffolding framework, front-end libraries, etc., are muddled together into one overarching design, and you’ll have to make some compromises here and there to accommodate integrations, brand requirements, or other teams. There are a few key characteristics that you’ll want to consider when choosing a technology stack.
Easy to write (and read)
The ability to quickly and easily express business solutions in code is a crucial characteristic of most high-level programming languages, but some are more verbose than others. We’re not looking for the most terse language here, nor the one that’s the most declarative. You’re looking for a happy medium where the language is sufficiently easy to write, but, to be honest, the more important part is how easy it is to write readable code. This distinction is interesting since any language can be used to write illegible software (sorry, but PERL, anyone?). Still, the goal for Disruptive Innovation teams isn’t to write the most glorious code either. It’s a happy medium where the code is easy to express, and simultaneously, the code is also easy to understand for the next person (or yourself a few months down the road). Performance (meaning the speed of running applications) of that language is a helpful consideration. However, you’ll probably be good to go if it performs well enough to get you through the first million users. Anything beyond that is an ability to scale that you don’t need right now; worse is wasted effort.
Easy to hire
Before you adopt a programming language, you’ll want to do a quick search to see how easy it is to find talented engineers within your budget in whatever location you want to hire. It’s never easy, of course, and engineers aren’t cheap, but choosing a language and well-liked stack can make a big difference in how quickly you can scale up your team when you’re ready to add more investments.
The best gauge we’ve seen for this is to use a company like Indeed.com to see how many jobs there are in your area for the programming languages you’re considering. It will give you a relative measure of how hard it will be to hire in your chosen language at a given time. For example, when writing this, in the Austin area, just over 4,100 jobs mentioned Java, more than 4,800 jobs mentioned Python, around 3,000 jobs mentioned Javascript, and only 11 said Haskell. Of course, it’s not perfectly scientific, but it gives you a rough guide and indicates that trying to staff your team with local Haskell developers will be a significant challenge. This language distribution does vary pretty widely by market as well. For example, we regularly found Python developers easy to hire in Austin and struggled to employ them in Seattle and Tokyo.
Easy to support
The stack you choose should have a healthy online community and, ideally, a community within your company as well (although, depending on the size of your investment in Incubation activities, your team may be able to meet this need independently.) You’ll want a community that is growing and investing in new open-source libraries to help make programming on this stack even easier. Additionally, as you’ll hopefully eventually need to scale up some of your products built on this stack, it’s helpful to have many online resources that help you follow behind someone who’s done it before.
Easy to deploy
Finally, you’ll want to quickly and regularly deploy to keep new features flowing into production, so the stack you select should be able to be deployed to production quickly (e.g., minutes.) Never underestimate how much delays in build and deployment can sap a team’s energy when they’re trying to fix a user bug or when a simple change takes ten times longer to deploy than to write. Investing in a quality continuous integration and deployment pipeline and enough capacity to make it efficient will pay back that investment with significant interest.
Our recommendation (don’t @ me)
For all of our projects, the core language we selected was Python. It’s a language that many people can easily read and write. While it has some eccentricities (especially when doing things the “Pythonic” way), you can ignore those and write straightforward code. One of the other great benefits of Python is that it forces the consistent indentation of code, thus helping make the code a little bit easier to read.
On top of Python, we selected an application scaffolding framework called Django. Django has several advantages, but the biggest ones for us were that it allowed the simple modular design to extend the core application flow easily, it has a project archetype that strongly suggests where each bit of code should be stored, and it has a lot of built-in functionality (class-based views, the Django Admin, the objection relational mapping (ORM), etc.) that make simple applications extremely easy to create.
For the front end, when we weren’t integrating with another team, we often used simple server-side rendered HTML through the default Django templating engine. More and more often, though, we found that we were integrating with other projects and platforms, and we used React since it was the front-end library of choice for the rest of the company. We intentionally held off from adding React for our front-end user experiences until we had a strong case that the product needed React, often opting instead to use JQuery until we had reached a point where the readability of the JavaScript started to fall apart.
For visuals, we kept the design library simple. While there was a component library we could utilize, it was focused on React components, and as I explained earlier, that wasn’t a framework we were always using. Instead, we were able to customize the Bootstrap UI library to closely match the design system the company was using and keep our teams moving quickly with easily laid out pages and on-brand designs.
We stayed with the tried and true MySQL for the backend database as it integrated nicely with Django and was easily deployed for us. Leveraging the Django ORM meant that we were regularly updating models and changing the database schema, so having an accessible, fast, and flexible database to do all of this work was vital.
We reused the company’s existing infrastructure for everything else – continuous integration/deployment, virtual instances, message queueing, monitoring, etc.
Integrations: You ain’t gonna need ’em until you do.
For your early-stage products, you’ll want to choose your integrations carefully. Of course, the intent is to leverage your core product or other parts of your company to springboard this new product into an even stronger position, but every integration comes with costs. You have to keep that integration up to date. You have to operate the way the system you are integrating with expects. No integration does things exactly the way you want. And so on.
One of the fundamental principles we leveraged to ensure that our teams could continue moving quickly as they iterated on the business model and product was to “maintain optionality.” It’s probably much easier to say, “Stay flexible.” Every time you make a design choice that closes doors, you have taken the risk that the door you closed must be re-opened.
But it’s not about being too flexible! We’re not looking to design the most flexible, generic system that could do anything for anyone at any time. The team would be lost in the jungle of analysis paralysis, trying to keep all doors open. There’s a sweet spot. Let’s look at an example.
One of our teams was building a job seeker and employer chat product. We knew job seekers had questions for employers and firmly believed that if an employer responded to a job seeker, the job seeker would be much more likely to apply for a job. Simple enough. The design of this application struck a good balance on flexibility by focusing on the core of what was needed in this experiment: an application that allowed a job seeker to communicate with an employer and vice versa. No preconceived notions of having to apply for a job first or that the communication always started with one side or the other.
The team could have integrated with many systems to test introducing chat to job seekers/employers. However, some of those systems had previously conceived notions around when a conversation was taking place, who was initiating the conversation, or the medium the discussion would be conducted on (email, SMS, etc.) By not integrating with these systems early on, the team was free to explore various places where conversations could be helpful, opportunities for either side to start the conversation, and different transport mechanisms for the messages. Once they had done several tests and found an area that seemed promising, they were able to do a deeper integration to run a more thorough examination of whether the chat functionality was beneficial, whether it detracted from any other essential metrics, and what would happen if an entire job market had chat functionality enabled by default for every job.
Other times, you won’t be able to avoid the integration, so let’s talk about experimentation frameworks next because they’re the key to keeping integrations speedy.
Experimentation Frameworks
We could have said A/B testing frameworks, but the truth is that experimentation is so much more than just the ability to run and verify A/B tests in your product efficiently. Yes, you’ll want a robust platform for doing A/B testing (ours was built in-house and is available as free open-source software: https://opensource.indeedeng.io/proctor/.) There’s plenty of guidance on good A/B testing platforms and implementations and several high-quality vendors that can provide you with this functionality. (That’s a pretty good idea if your company doesn’t already have a team managing the A/B testing platform, but I digress.)
Beyond the A/B testing framework, you’ll want a feature flagging platform. Some A/B testing platforms can do this as well, and that’s probably fine, but there are some benefits to an easily managed feature flagging platform. For example, the simplicity of enabling/disabling as opposed to changing allocations, the ability to coordinate changes in feature flags with other releases/deployable applications, etc. As long as you can quickly and easily turn a feature on and off wholesale, the framework you are using will be sufficient.
Finally, you’ll want an experimentation framework embedded into your core product(s) to make it easier for your Disruptive Innovation teams to explore new ideas/integrations quickly. This can start simply as a way to load arbitrary javascript into any page and have it execute (a company-sanctioned cross-site scripting attack, if you will.) This would need to come with some pretty significant guardrails around how it will be used (or not used), who will use it, how much, and who will turn it off if it misbehaves. All of these questions are true no matter how mature your experimentation framework becomes, and some of them will even more into the experimentation framework and its codebase.
A more complex integration would involve a plugin framework, ideally serverless, that allows your Disruptive Innovation teams to write simple browser (or backend) plugins for your core product. These plugins should be able to target a particular page or a part of the page and replace or add functionality. React, and Webpack Module Federation does a pretty good job laying out the fundamentals for this integration. Each Disruptive Innovation team can construct plugins to promote their product to various existing users on your platform. They can enhance the core product to show additional data or bring additional information to the users’ attention. Or they can create new experiences in the sign-up flow to allow users to configure your experimental products.
The more flexible this plugin system is, the more pages they can adjust, and how much they can change them, the more your Disruptive Innovation teams can experiment quickly. However, there’s a nice second-order benefit to this sort of platform. Your core product teams will also be able to run additional experiments safely and efficiently using this same plugin framework.
I mentioned before some guardrails you’ll want to place around these experiments. Let’s talk briefly about three critical limits you’ll want in place early on. If you’re doing server-side rendered plugins, you’ll need guardrails around how long that rendering can take to keep page load times low. For browser-based plugins, you’ll want some protections around modifying the page, document object model, and overall plugin size.
Goals/OKRs
Setting goals for a brand-new product can sometimes be daunting. You’re not even sure what the market looks like, you haven’t written a line of production code yet, and you’re being asked what the product can accomplish. The key is to choose something meaningful and challenging and not get stuck on whether or not that goal is achieved. The goal is valuable if it inspires and pushes the team to iterate quickly. Too much, and you’ll be demotivated with an impossible dream. Too little, and you’re either sandbagging (don’t allow it,) or you’ll just be revisiting the goal in a few weeks because you’ve achieved it, and it’s still not meaningful.
Objectives and Key Results (OKRs) provide a good framework for structuring goals within the team, but in our experience, the typical roll-up and roll-down of OKRs doesn’t work as well for disparate Innovation teams. Having meaningful objectives (cap it at three) and just a few measurable key results within each objective will give the team a feeling of accomplishment as they move closer to meeting the goals and help with prioritization as you decide what to work on throughout the first quarter.
Lastly, goals should be created collectively by the whole team. The earliest-stage products will probably primarily focus on learning about the market size and delivering value for your customers. Still, as the team progresses into later stages, you’ll add additional goals around scale, quality, and other engineering-specific objectives to balance the investment between new product growth and maintainability.
Your product team will have three main types of check-ins each funding cycle. The weekly check-ins will provide tactical updates on the delivery of the MVP and other experiments. The monthly executive check-in will be a chance to course correct for any tests that are going astray, as well as a chance to get guidance and executive “air cover” if you need it. The last check-in will be at the end of the current funding cycle and will be a chance to catalog the successes/misses, capture and share learnings, and share plans for the future of the product. Let’s go a bit deeper on each type.
Weekly Check-ins
Weekly check-ins should be attended by much, if not all, of the team and will likely only be about 15 minutes long (maybe more for later funding rounds). There’s value in grouping a few related or similar stage Disruptive Innovation teams into one weekly check-in meeting as there are often common learnings between teams, and teams can learn from each other.
These check-ins should be attended by the Product Manager/Founder and other team leaders, but the main read-out about the product should be delivered by the Product Manager or Founder. They should have enough context on everything happening within the team to give a high-level summary of progress and next steps. Of course, they won’t be able to answer every question in full detail, but having only one person present the product each week will ensure they stay abreast of the work and keep the meeting moving smoothly. If the Product Manager/Founder cannot attend, another leader could step in occasionally to drive the discussion as needed.
These weekly check-ins should be optional for the rest of the team, but for those who either cannot or choose not to attend, they should have a chance to review the materials shared and ask questions, often at a quick weekly team meeting, but standup can work for this just as well. Beyond the team, you’ll also want several senior leaders from around your Disruptive Innovation organization present to give feedback on the product, typically Product Directors, UX, and Engineering leadership. However, others also bring unique insights if they are available.
There’s a balance to strike here in having leadership in the room to give constructive feedback to the team and not having too many people in the room such that discussion is stifled. We’ve generally found that between four and six teams work best, and that also works well because it caps the meeting length between one and one and a half hours, which is probably about as long as anyone can sustain attention anyway. You may want to experiment with processes that have everyone pre-read the material before the meeting or dedicate the first few minutes of each team’s time to pre-reading. Still, either way, a little chance for individuals to read before the discussion/presentation begins is very useful.
Monthly Executive Check-ins
The monthly executive check-in is a bit more formal. You’ll want to prepare an actual presentation for this, and it should cover the major features/experiments delivered since the last check-in, the learnings about market sizing, current in-flight experiments, and the things planned next. It would be best if you planned to spend a significant portion of this time answering questions, but thankfully, you’ll be scheduling these for about 30 minutes per team. Once again, the whole team should be included (at least optionally) at this meeting to listen in and hear how the executive thinks about your product. Furthermore, you’ll want much of the senior leadership from your Innovation program there to listen to the feedback and begin planning for scaling up or shutting down based on that feedback. These check-ins are a great time to capture incremental learnings you can share with others in the organization, so saving the presentation decks and recordings in an ordered fashion will be a helpful asset.
Continuation PItch Check-ins
The continuation pitch process will be the most formal of all the check-ins but the least frequent. You’ll need to give a quick executive-level overview of the product and progress to date, showing the data and learnings you’ve acquired. Like the monthly check-ins, you’ll present to the executive sponsor but may be joined by other executives, including the overall Innovation program sponsor. This will replace the last monthly check-in of the funding cycle.
For the core of the meeting, you’ll want the attendance to look just like the monthly check-in: the team, senior Innovation leaders, etc. However, there’s a second part to this meeting where you may want/need to reduce the room to only Innovation leadership and executives, and that’s where the discussion around whether or not the product should receive continuation funding takes place. Sometimes, the debate on whether or not to continue is less about the product or market and more about the execution of the team, and it can be a rather sensitive discussion. If possible, it’s nice to have the funding discussion with the Product Manager/Founder still in the room so that they can understand the nuances of the decision.
If the project is selected to continue, the team should be informed of the decision and their new funding cycle (budget, timeline, etc.). If, however, the decision is made to shut this product down, there’s more to think about and do.
Shutting down
Shutting down a product can be one of the hardest things to do. It would be best if you normalized this as early as possible and celebrate the team’s accomplishments. There is a lot to think about when shutting down a product, and you’ll want a significant amount of Program support to make this a repeatable and efficient process.
Notifying users
One of the first things you’ll need to do is notify existing users that this product is shutting down. That messaging will vary from product to product. Sometimes, you may be required to keep the product around for a while to allow customers access to data, tax information, etc., but the product development (and almost all maintenance) should stop now. Banners within the product and emails are the most common way to notify users that the product is sunsetting, and often, 30 days’ notice is more than enough, but your process may vary a bit.
Cleaning up the application and data
You must do a few things once you have the all-clear to shut down. The most important part is to get the product wholly and cleanly shut down so that there is no maintenance burden left behind from this product. Any lingering portions of a product can quickly become a drag on the team when they need to apply security patches, answer support questions, etc. Here’s a non-exhaustive list of things to do when shutting down:
Redirect the domain from your product to another appropriate place on your company’s website.
Shut down any running instances of the application and remove all data according to your data retention policies.
Archive the project repository (keeping the code around in read-only mode so you can reuse snippets in later products if needed.)
Remove any integrations/experiments you built into other core products.
Capturing Learnings
This will be done throughout the shutdown process and is one of the most critical parts. The Product Manager/Founder should produce a learning presentation and share it with the Innovation program as a whole, but it also should be recorded for posterity. We make these learning presentations available to the entire company as they can (and often do) inspire additional product ideas being pitched to the Incubator in future sessions.
The Engineering team may also choose to produce some documentation from their learnings, and that may be useful. We have historically coached teams to try to codify some of their knowledge into libraries and services that make the next project faster, simpler, less maintenance, etc.
For those in California dealing with a tropical storm or others affected by wildfires right now, my heart goes out to you. I’m praying for your safety.
Indian Independence Day was mid-week last week, and I hope everyone who celebrates had a great day. While my wife and I are not from India, our daughter is, so we had a small celebration and a bit of cultural study with the kids about how India gained its independence. It’s filled with mixed emotions. The independence from colonial rule was exciting, but you cannot discuss their freedom without noting the partitioning (separating India and Pakistan.) I’m no expert on this topic, so I’ll leave the political, social, and religious discussions to others, but it points to the challenging emotions that come with independence.
I’ve noted previously that layoffs come with highs and lows; last week was one of those emotional weeks. I’m narrowing in on a potential offer (maybe even more than one), so the vibe has shifted. It’s easy to start getting optimistic about what work could look like in a few weeks and having a new team, but it is also too easy to slip into a funk about what could happen if the offer or offers are not extended. And behind the scenes, you must continue looking for new opportunities to keep the pipeline flowing, keeping you from ever living in the moment. Thankfully, this weekend was filled with quality time and several good friends making it incredibly recharging. Let’s go week #22, I’m ready for you!
Independent Numbers
3.6% – the near record low unemployment rate, a signal that the demand for workers is still strong and that a soft landing instead of a recession may be possible. source
500/5000 Connecticut and company-wide jobs lost at CVS, posing whether bio/pharma is now seeing some of the same pushback Tech did last year. Source
6.6% -> 4.3% Projection headline inflation in 2023 and 2024 by the OECD (Organisation for Economic Co-operation and Development) source
Encouraging Independence
As employees grow in their careers, moving through the stages of career growth (3 min read), the goal is to move to more and more independence. Independently writing software, solving problems, leading teams, influencing others, and casting vision. This structure is a helpful way of breaking up roles and responsibilities, even if it does not precisely map to a career ladder.
As a job seeker, I have become independent in finding roles to apply to. I have apprenticed under a few experts on resume writing and LinkedIn profile curation. I have practiced my interviewing skills (having been on the other side of the table hundreds of times.) I’m actively curating my network and meeting with leaders who can help me (and whom I can help as well.) But, I need to actively develop my career objective and search more for hiring companies, so I’ll lean into those in the coming weeks. Here’s a model that nicely breaks down the Job Seeker’s Stages of a Job Search if you’d like a guide to the process (2 min read).
Independent Encouragement
A few weeks ago, I mentioned writing down ten things you’re good at and reviewing that list each morning. I’ve been practicing this for several weeks, which has been encouraging. I emailed them to myself, and each morning when I check my email I re-read them and snooze them to the next morning. Here’s my list in case it helps inspire anyone else:
1. I built a culture of rapid innovation.
2. I hire well.
3. I lead the team with compassion.
4. I am an excellent partner to product teams.
5. I am a leader in the organization.
6. I help people grow in their careers.
7. I am flexible.
8. I am capable of leading small and large engineering teams.
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 total transparency, I have no affiliation with any of the tools, companies, or resources I share. These are my impressions, not colored by any outside influences.
Quick note: I am officially and actively searching for a job now. I wanted to start with that so that if anyone reading this is looking for a senior engineering leader or knows someone who is. Please forward my LinkedIn profile or contact me and make a referral. Thank you all in advance.
As an engineer, I never cared for the art of selling. I appreciated what salespeople did for the company, but it was never my interest or forte. Now, as a job seeker, I see how much salesmanship is necessary to prepare for my next role. I must actively sell myself in every job application, cover letter, resume, interview, and more.
I have been contacted by several resume professionals and digital marketing agencies offering to help improve my resume, freshen my LinkedIn profile, and hold mock interviews for additional practice. I took a free session with one agency last week and obtained several good insights, but the biggest takeaway was that it was time to think of myself as a salesman for my product (myself). Building a brand, creating a presence, engaging with my community, and doing regular outreach to prospects. While sales techniques alone aren’t going to get me my next job, it’s a skill I can hone and one that will undoubtedly lead to better prospects.
These July numbers from ADP confirm what I’ve been experiencing (smaller employers are hiring, larger employers less so.)
Encouraging Sales
“When you undervalue what you do, the world will undervalue who you are.” –Oprah Winfrey
I’m sure most of the feedback in this article on selling yourself in interviews (19m read time) includes things you’ve seen before, so I’ll summarize for those who have time to skim. But there’s depth to each of these sections, and I got insights from several, so I suggest reading any passages you can improve on most.
Research the company and interviewer(s)
Practice explaining your unique selling points.
Master your elevator pitch.
Present your skills and accomplishments well.
Demonstrate your soft skills during the interview.
Remember positive body language.
Ask insightful questions.
Close the interview with a plan.
Send a thank you note.
Selling is Social
LinkedIn has a model called the Social Selling Index (SSI) that users can use to see how their LinkedIn profile compares to others on the platform. Their index considers things like how much of a personal brand you’ve created, how you’re contributing to discussions, that you’re connected to the right people, and that you’re building relationships (amongst other proprietary things, I’m sure.) It seems that anyone can get their SSI for free.
The tool targets those using LinkedIn to support their Sales roles, but since my job right now is to sell myself, investing the time to improve this score seemed like a tangible way to get more traction with employers. I’m starting by adding more personal details to my LinkedIn profile page, taking my role descriptions through Grammarly to help clean up any silly issues, and adding a Projects section to my page to list the accomplishments I’ve been a part of over the last few years.
While I’m at it, I’m also refreshing my resume. I hadn’t updated my resume when I searched for jobs in the last decade, so it was overdue. I created a quick one-page resumé for this job search, but it hasn’t been received exceptionally well (given the employer response rate I discussed last week). I’m giving it some additional attention (and a second page so that I can more deeply explain the impact of the work I’ve done. Hopefully, that will help improve my response rate in the future as well.
Selling Fun
For those with a few weeks left before school starts:
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 total transparency, I have no affiliation with any of the tools, companies, or resources I share. These are my impressions, not colored by any outside influences.
You can tell that summer vacation is over: hiring managers are back in town and conversations are moving much faster of late. I’ve increased the amount of work I’m putting into job searching, networking, and interviewing to get things rolling again. I was still actively searching throughout July, but things were moving much slower then. In my spare time, I’ve also been working to create a more rigorous schedule at home.
I check my LinkedIn alerts, email, and other places for any updates daily. I schedule networking coffee, lunch, and beers with former coworkers and others in the industry each week to stay abreast of how things are going and who’s hiring. I’m working on a side project to sharpen my technical skills.
On the personal side, I’m exercising each morning (even in this Texas heat, the mornings are at least manageable.) I’m reading “No Rules, Rules” to understand Netflix’s culture a bit deeper than just the old Netflix Culture Deck. I’m also enjoying some CrunchLab kits with my kids as they turn their brains on before school starts next week. The days are busy, but we’re making the most of each of them.
Hard Numbers
17 people were laid off from Y Combinator (and an additional seven from Sequoia Capital), in a rare move for VC firms. (source explaining why this is particularly interesting)
10x more people quit after a layoff than after other forms of attrition. Source
7,400 Zoom employees are returning to the office. #irony source
Encouragement for Hard Work
“I do not know anyone who has got to the top without hard work. That is the recipe. It will not always get you to the top, but should get you pretty near.” — Margaret Thatcher, former Prime Minister
I strive for minimalism in many aspects of my life (reducing, reusing, recycling, but also owning less stuff,) and this article on a minimalist’s perspective on work was encouraging. The reminders that work not only provides us with meaning and produces valuable goods and services but that it’s a good example to our kids and is a forcing function for personal growth were encouraging. (3 min read)
Hard Work Comes Intrinsically
In a handful of interviews recently, I’ve had the chance to explain my perspective on motivating teams to do their best work. For me, the first thing to get right on motivation is driving intrinsic value. Intrinsic motivation refers to doing an activity for its inherent enjoyment rather than for some separable outcome (source). At Indeed, we regularly pointed to the mission, “We Help People Get Jobs,” to motivate individuals and teams. As I interview at various companies, I’m trying on their missions to understand whether I can be excited about that work and outcomes, and secondly, to see if it’s something I can excite others around.
Beyond just force-feeding that mission to everyone on the team every day, week, all-hands, Q&A, whatever, the mission must be lived out in the outcomes. Sharing stories of people getting jobs, new products that helped whole new markets of job seekers find roles, and successful teams with customer-centricity helped motivate everyone on the team. I’ve seen many ex-Indeedians land great new jobs, and I’m so excited for them. It’s a reminder that there are jobs and hiring is happening. It’s an encouragement to me that we’re each going to find the next right position (hopefully soon.)
Beyond the intrinsic motivation of the company mission and the anecdotal evidence to support that mission, I have said for years that “you aren’t truly managing someone until you know what non-monetary reward you would give them for a job well done.” Put another way, you should know people so profoundly that you can think of a gift you’d give them as a bonus. Not a cash bonus, pay bump, or gift card. What motivates them? Maybe it’s cycling, coffee, or time with their kids. Perhaps the best reward for them is that new board game they’ve been waiting for (wink, wink, nudge, nudge.) Knowing this allows you to align the company and team goals with their motivations and to get the best work out of everyone on the team.
So, whether corporate, anecdotal, or personal motivation, focusing on intrinsic motivation is always the first step in my playbook.
Is Hard Work Paying Off?
I can’t say for sure, but I did have a final round interview last week. That is progress. Beyond that company, I had several other first-round discussions. Hopefully, some of those will continue forward this week as well.
I was looking at my stats and have applied to or seriously considered (at least) 54 positions in the last 20 or so weeks. Of those:
18 – Positions I explored but decided not to apply to.
29 – Companies ghosted/auto-rejected me.
3 – Organizations rejected after an initial screen (e.g., I only spoke with the recruiter.)
3 – Companies gave me only first-round interviews (at least one interview beyond the recruiter).
1 – Company invited me to second-round interviews (callback with a larger panel of interviewers.)
0 – offers.
4 – Companies currently in various rounds of exploration (two in the final round and two early interviews.)
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 total 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.
Note: This week’s newsletter is a departure from the format of the previous 18 weeks. I’m playing with the structure and content to see what resonates. Let me know what you think.
There have been a lot of firsts with this layoff. My first layoff. My first time spending 18+ weeks searching for a job. My first weekly newsletter. As we roll into August, I want to try something else new. The feedback I’ve been getting from readers of this newsletter, on the whole, seems to indicate two things: 1) People appreciate my honesty, the reality of my position, and updates on my work to find a new role, and 2) People have been encouraged by the upbeat attitude and the helpful reminders and links. Those aren’t going anywhere.
All of that is good, but it was getting hard to avoid drifting into mostly meaningless self-help content, and as much as I enjoy that from time to time, just getting a dose of it in my email every week doesn’t seem like something I’d sign up for. Since the last 13 years of my professional career have been in leading teams and organizations, I wanted to mix some of that content in too. I am going back to publishing chapters of my book on running innovation teams. So, here goes everything. I hope you like it. Either way, let me know.
Refreshing Numbers
8,231 additional people were laid off in July, according to Layoffs.fyi, continuing the downward trend since January.
Over 50 tech unicorns were founded during the 2007-2009 recession. Source
28% of Americans have been laid off in the last two years (notably not including the COVID layoffs of 2020). Source
Encouragement – A Refreshment For Your Soul
While vacation was a great time with family, it was also exhausting. We walked five to eight miles daily on top of lots of standing around looking at things and figuring out where to go next. Keeping all four kids satisfactorily fed, rested, hydrated, and safe took a huge physical (and emotional) toll on me. I was ready to get home and get “back to work,” even if that work was job searching.
I’ll confess: I didn’t read this article. I skimmed it (skim time ~1 min, read time ~9 min), but it had what I was looking for: reminders of some good ways to practice “self-care.” Now that I’m back, I’m scheduled for a massage, and I went for a long walk this morning (both for the exercise and the time away,) and I’m about to pick up a novel for the first time in I don’t remember how long. It’s time to get my batteries fully charged; expecting that I’ll be starting a new role this Fall, and I want to start with high energy.
Please take some time this week to do something for yourself.
Refreshing Teams
I’ve heard many rumors about the post-layoff reorgs (at Indeed and elsewhere), and I’ve been through a few big reorgs in my career, and the biggest thing I’ve learned from them is that reorgs hurt. They hurt a lot. Morale can plummet. Productivity can be destroyed. Even profits and revenue can be negatively impacted by reorgs.
Of course, experienced managers would only take on a reorg knowing that it will tank their next three, six, or twelve months of metrics because they sincerely believe that the other side of the reorg will more than pay for that investment. But the truth is that I’ve never seen a team stop to measure the loss and gains from reorgs. Not that it’s easy to measure, of course. And even if you did measure it, how do you use those measurements? How do you compare intangibles like morale and happiness with tangibles like retention, revenue, and user experience?
I’m sure there are times when a complete reorg is necessary, just as I’m sure there are times when a whole system rewrite is needed too. But, having much more firsthand experience with system rewrites, I believe in incremental rewrites whenever possible, and I have seen how incremental reorgs (or micro-reorgs if you’ll allow it) avoid much of the “big bang” reorg pain.
Here’s the micro-reorg process in three simple (albeit not particularly easy) steps:
Create a shared understanding of what is valuable across the team (especially leadership.)
Regularly assess which projects are producing positive ROI vs. those that are not.
Adjust staffing levels to maximize organizational ROI as often as possible.
Micro-reorging several times per year by moving a few percent of the team to better projects/products opens up the possibility to extract more value from key projects and right-size projects that are overstaffed and gives new opportunities to team members as they move to new teams. You have to set expectations upfront of course, and make sure not to move anyone around so often that it negatively affects their career growth.
We ran a program like this with 40-80 engineers over 6 years, and while it wasn’t perfect, we avoided full team reorgs the entire time (assuming you don’t count COVID’s impact in early 2020, which I don’t.)
Career Refresh
At the moment, I’m in the early stages with one sizeable multi-national company and various stages of interviews with three or so startups in Austin. I’m torn between looking for a company the size of Indeed again or jumping back into the wild west that is “startup land.” So, I’m toying with both sizes and looking to see what connects. My passion aligns more with the startup side, but I worry about the financial impact of putting everything in one startup basket again.
Additionally, I’m hitting the networking circuit again hard now that I’m back in Austin. So, if we haven’t caught up in a while, let’s chat and reconnect.
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 total 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.
This week is effectively the last week of Summer break for our family. School is still a few weeks away (although that is just around the corner in mid-August). However, the sports tryouts and workouts begin next week, so as a family, we’re gearing up for those. Summer has flown by, and with it ending so soon (okay, we’re in Texas, and the Summer feelings will hang on until October), I’m contemplating how every ending creates a new beginning. Over the last few months of interviewing and networking, enabled by the layoff in March, I’ve been able to meet a lot of people, spend quality time with friends, coworkers, and family, and generally start a lot of new things that I hadn’t had the time to do when working full-time. Something new is just on the horizon, and it’s just a matter of finding it.
With employment ending so abruptly, it left most of us in shock. There was a lot of activity to establish new insurance, start the job search, and develop new routines. Now that we’ve been out of Indeed for several months and the severance is running out, many have to reevaluate those decisions again. Several of these tips in this HBR article are things I’ve said before (focus on self-care, use your network and others). Still, the tip to regularly review positive reminders of the value I bring is one I’m putting into practice starting today (5 min read).
Looking Forward – Ending Means Beginning
All this thought about endings has me thinking more and more about what my first day, week, and month at my new job will contain. I’m still in the early interview stages with the companies I am interviewing with, so it may be a bit premature, but I want to be prepared. Many articles on the Internet about your first day, week, month, and beyond mainly include the same things. This article on inhersight.com had some practical tips on implementing conventional wisdom and a few unique thoughts (7 min read).
Today’s Tip
As job seekers, we don’t have many opportunities to provide feedback (to companies, recruiters, or hiring managers.) Record what parts of the process worked well and which could be improved. That way, if you get the role, you can work to enhance the company recruiting process.
While we’re on the topic of feedback, if you’re still reading this deep into the newsletter, I’d love some feedback on what you like in these newsletters and what you wish it would include or would change. Drop me a line.
Fun Stuff
Career limiting moves.
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 total 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.
I’ve been battling the rejection blues this week. I was in the second round with a company and felt like things were going well, but got the feedback that I wasn’t a fit and wouldn’t be continuing and it’s got me down. I’m not really back to square one on the search, but definitely a few steps backward. I can see now how I didn’t put my best foot forward in the final interview and how that feedback reflects that, and it’s very disappointing, but a very good lesson for my next set of interviews. I’m thankful for the chance I got to get deeper into the interview process and practice some additional skills I hadn’t practiced in quite some time.
I’ve often heard that companies don’t want to give feedback to candidates in the rejection letter because it opens the door for debates, or worse lawsuits over why they were rejected. Now on the receiving end of those rejections I can completely understand both how hard it can be to get that feedback, and also how valuable it can be. This article on Hubspot gives some advice that I’ll be trying to follow going forward when it comes to rejecting candidates. (3 min read)
Looking Forward – Healing From Rejection
This article on BetterUp (7 min read) covers not just the phases of rejection but also has some meaningful tips on bouncing back from that rejection. In particular, the concept of growing from the experience completely hit home.
Today’s Tip – Bouncing Back From Rejection
Take care of yourself by being around those who bring you the most joy. We’ve had the pleasure recently of spending quality time with family and friends and it has been a big lift in my spirits to share about my job search troubles and the new opportunities that are coming up soon.
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 total 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.
As we start month four since the Indeed layoff (for those laid off by other companies, your timeline likely varies), we’ve reached a pivotal moment where the severance package provided will begin to run out. On the face of it, this sounds like only bad news, and for those who are still job searching, there is minimal upside. But there are a few positive signals. First, you should be eligible by the end of this month for those who haven’t been able to get unemployment up to this point. While that won’t replace previous full-employment income, it certainly helps. Secondly, if it feels like the layoffs have slowed, the data backs that up. Comparing Q1 to Q2’s layoffs, there were over 70% fewer people laid off in Q2 than in Q1. That’s significant progress, although, unfortunately, there were still another 45,000+ people laid off in Q2, so we still have a ways to go to get back to complete hiring. All in all, there are enough positive signals of a slow-down and a turnaround coming to gain confidence and bolster our faith that the jobs will come back.
Returning from our family vacation in Europe, I’ve had the chance to tour several churches, cathedrals, and temples, which has me thinking about that faith. Much of my faith is rooted in my experience in the tech industry’s history for the last 20-plus years. I started my career in the final throws of the dot-com bust, weathered the housing bubble burst while at a startup in 2010-2012, and now I’m experiencing the tech downturn of 2022-2023. I’ve seen various technology pendulums (thick client vs. thin client, server-side or client-side, Java or anything else) swing between their various endpoints and back again. I still have faith that software is a great place to be. There is still so much opportunity to bring software to many spaces, so many new markets to be created by software startups, and so much more. I expect this downturn to spawn many new ideas, products, and markets that will be exciting to watch over the next three to five years.
Looking Back – Faith in the mission, leadership, or the company?
While at Indeed, I had faith in the mission (we help people get jobs), the products (moving closer to the hire), and the leadership team. When the layoff happened, most of that trust was shattered, not just for me. Over 2200 people were directly impacted by the layoff. Beyond that, everyone at Indeed and their families were affected, putting the number of impacted people beyond ten thousand or more. While I’m no longer at Indeed and can’t do much to help restore the trust, this article on Forbes has several good suggestions for building that faith back. (4 min read) This is excellent advice for repairing a relationship after damage, and it almost all works proactively, too, so I’m putting this in my back pocket as I look at new leadership positions.
Looking Forward – Faith that you’ll find love again
Most people work long, hard hours at jobs they hate that enable them to buy things they don’t need to impress people they don’t like. — Nigel Marsh
The tangible suggestions on improving your love of your work were practical and approachable. I can even see myself applying some of them to unemployment.
Today’s Tip
It’s time for a layoff playlist. I haven’t made one yet, although many are already out there: Apple Music, Spotify, or create your own (here’s a starter list.) Having good music to listen to during the day while you’re job searching or just relaxing can make all the difference between high and low-stress days.
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 total 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.
We’re wrapping up the family vacation just after the 4th of July, so this is still a bit shorter newsletter than usual. Happy birthday America. I hope everyone in the US had a grand celebration. We got to enjoy just a few fireworks from London, which was fun and a bit ironic all rolled into one.
Thinking back on all my years of sending exploding rockets into the sky, I’m reflecting on the patience of lighting a fuse and waiting for the payoff. Now and then, you’d light a fuse and see it seem to die out. You’d spend the next few seconds (what felt far longer) wondering whether it would rekindle and launch. Now nearly four months into the layoff, patience is wearing a bit thin at times, and I’ve put energy into several duds along the way. Patience tells me this will eventually lead to a better outcome, but I’ve got to trust that the right opportunity is out there for each of us.
Looking Back – Patient Expectation
One of the more unique things about Indeed’s engineering culture revolved around releasing software. Many places I’ve worked focused relentlessly on the date software was slated to ship. Of course, this makes sense because that’s the first chance to derive value from your investment in planning, designing, implementing, and verifying the software. It’s completely reasonable and good business sense to focus on that point, but the date is the wrong measure of success. It’s not as obvious, but the measurement you need to focus on is the time to first value.
At Indeed, much of the software we released was released in A/B tests, so it would often launch with no traffic or only a tiny portion of users. This is an essential point in the life of the software, but it doesn’t tell us the software is a success, so it’s not the ultimate goal. We had to be patient and wait until we saw the value climb as the test was enabled. When we finally reached a point of being confident the software was successful, or occasionally, that it wasn’t working as hoped, we had finally delivered value and could celebrate by either rolling it out to everyone or removing the software for another test. This required patience as teams built software, and the date fluctuated, but it was a much healthier pattern than many other teams I’ve worked on because it kept the focus on the core outcome.
Looking Forward – Patiently Searching
I’ll be honest, the last time I interviewed (in 2016), companies still expected you to give up a whole day for onsite interviews (6+ hours, in my experience.) It was grueling, but at least the decision typically came a few days after that. My experience this year indicates that many companies now spread those interviews out over days and weeks. I’m impatiently awaiting the following interview in this second round of interviews with a company. If given the chance, I would have happily packed both of these interviews (and more) into one day. The upside for this is that it’s probably a lot easier to squeeze an interview into a busy workday without tipping off your boss or team that you’re out for an interview, but for those of us with nothing but time, it feels painfully slow.
Today’s Tip – Patiently Returning
I passed on the opportunity to interview further with a few companies early in my search because I wanted to be more excited about the possibilities for various reasons. Now that we’re reaching month four, I’m revisiting a few. I see they’re still open, and I’ve had more time to reflect on exactly what I want to do and explore whether they could be right. So, if you haven’t revisited some of your previous searches, companies, or roles, that’s my suggestion for this week.
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 total 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.
