Tag Archives: Career

Transition Reflections

Posted on by
Monarch chrysalis (Danaus plexippus) in its “neutral” phase.

Over the past year, I have had several clients going through periods of transition. Some have been co-founders who realized that it was time for a more experienced leader to take their business to the next level. Some were just ready for something new. Others have shifted their roles from leader to individual contributor and in one recent case, a CEO-founder sold their company and is now transitioning to a leader within a very large organization. In each of these cases, these were not overnight changes, but rather they were thoughtful shifts that each managed with intention. By transitioning with intention, we are more likely to come out on the other side with more clarity, less stress and with a higher likelihood of success – in whatever way each individual defines success.

The book Transitions, by William and Susan Bridges, outlines the three stages of transition – The Ending, The Neutral Zone and The New Beginning – and encourages the reader to pause and understand each of these phases during their own transitions. This is something most of us do not do with intention – whether it’s ending a relationship, changing a job or transitioning from a household of kids to an empty nest. When it comes to our employment, we have our last day at an old job on a Friday and start our new job on Monday; perhaps taking a week or two in between to decompress. Most people do not have the luxury of long breaks between jobs or extended periods of time to think about their transition before they step into the next thing. Additionally, as Bridges points out, we often don’t see when we are in a neutral zone – that time when we have officially “let go” of who we were before things ended, before we fully embrace the new beginning. Think of it as that time between how you associate yourself with “we”. When you stop saying “at my last company, we…” but you have yet to associate yourself with the “we” of your new role and still refer to your new team as “you”. E.g., “How do you do things here?” It is in this neutral zone where we are truly able to start our transition to a new beginning.

With this neutral zone in mind, I encourage my clients to take a moment – even if it’s just an afternoon – to consider the impact of a transition and what lies ahead. This is usually in the form of journaling where they write their responses to the prompts below and then we discuss them together. Whether or not you have a coach with whom to process your answers to these prompts, you should find journaling your responses to be a useful exercise. You might also consider asking a friend or partner to be your listening guide as you talk them through; be sure to encourage them just to listen and be curious about insights vs. helping you try to solve things.

The prompts below are very career-centric, geared towards startup founders. However, one can easily apply this guide to any type of transition.

Document Your Feels

There is lots of research proving that writing what’s going on in our brains is an important way to process and organize our thoughts. Whether you keep a journal or are just taking a moment in transition to write your thoughts, consider the following:

Highlights & Lowlights

  • What are 1-2 highlights from your experience? This could be a memory of your first big product launch, closing a hard funding round or even just that night that all hell broke loose and you fixed a hairy bug at 2am. What made these experiences great? What do you remember about how you felt – physically and emotionally – about these events? How did they motivate you going forward?
  • What are 1-2 lowlights from your experience? It could be that one time you really thought the company was dead or when one of your best employees quit because they just couldn’t adapt to the frenetic startup life. What made these experiences awful? What do you remember about how you felt – physically and emotionally – about these events? How did they motivate you going forward?

Learning

  • What have you learned as…a leader, partner, employee, peer, innovator, business-person? Most leaders wear many hats and it’s important to use these different lenses to fully embrace all the learnings that came from your journey.
  • What specific skills have you developed or mastered? Consider all functions within an organization – financial, sales, product, hiring, etc. These are typically your marketable skills and are often very transferable for the next gig.
  • What are you more aware of about yourself that you may not have known at the start of this journey? For example, you may have thought you were not technical, but after having to build your company’s first app because you couldn’t afford to hire a developer, you now know you are more technical than you thought you were at the start!

Evolution

  • How have you evolved? Consider phases in your journey – by role or “eras”. For example, perhaps who you were as a strategic leader was very different when you were bootstrapped vs. once you raised your A-round and had a board of directors. Or, perhaps you have shifted in the way you approach the work day as you went from being single to being married with children. 
  • Who have you become? Think about your key characteristics, your behavioral patterns and attitudes. How is the current “you” different from who you were when you first started this journey? Do you feel differently about things (family, relationships, career) or have changed your reaction to certain situations (more/less triggered, sensitive, focused, caring)?

The Future

  • What new tools do you wish to ADD to your toolbox? For example, a product-oriented CEO may wish to learn more about creating a sales playbook or experience venture from an investor’s perspective vs. as the fundraiser. What tools are missing from your toolbox?
  • What existing tools in your toolbox do you wish to HONE? For example, a founder may have led a small team and might want to know what it’s like to lead a larger team at scale. Or perhaps you were great at building a social media campaign, but want to learn more about the broader elements of marketing and brand functions.
  • What do you wish to leave behind? Consider elements of your role that you didn’t enjoy and that you don’t want to do again (e.g., finance or maybe even management!). Similarly, consider behavioral characteristics that no longer serve you. Were you a micromanager who spent too much time in the weeds? Did you spend too much time on product and not enough time on the rest of your business? Think about what drove you to develop these behaviors, why they did or didn’t serve you in your role and how they will or won’t serve you going forward. 
    • NOTE: The act of physically releasing things can be very healing. Start by writing a few sentences or drawing pictures on a piece of paper and (safely) burn it or fold it into a paper airplane and toss it from a city window or into the sea. Instead of writing, you could also use natural objects to represent things (e.g., an acorn to represent your tough outer shell or a dried leaf to represent being fragile in certain situations). State your intentions – out loud or in your mind – as you let these things go. What will be different once you let them go?
  • What do you wish to teach others? Whether your transition is related to a great exit or awesome promotion or because you feel you failed in some way – your business imploded or you were fired – you have lots to teach others! My father called any learning, even if we failed, “money in the bank”. Take time to reflect on what you learned (above) and how you might be able to mentor others to grow or avoid pitfalls. Not only will this help others following your path, but this will also help you further process your transition.

When journaling the above, I encourage writing full sentences and fully expressing your thoughts around each. Don’t worry about being legible – you may never go back to read them – it is the act of writing that is key here. As you write, look for themes or patterns – do these further inform your transition? Do you see new patterns and/or growth opportunities?

Other Opportunities To Reflect And Reach Closure

If your transition involves others such as cofounders or partners, consider conducting a group reflection process in addition to your individual process. This can be a great way to recognize how the sum is greater than its parts. While each team member played a role in your efforts, it is almost always how the team worked together that led to where you are now. Schedule a couple hours to be together – ideally, face to face and out of the office/home – and share the following with each other:

  • Highlights & Lowlights of the work you did together. Consider specific wins you had as a team and what made that work together special. Name one or two times that the team was not at its best. How did these moments affect the trajectory of your business/relationship?
  • What are you most proud of as a team? Are there events or elements of your business that could not have happened without the team coming together?
  • Key learnings for each individual. Have each person speak to one or two key learnings. It is OK to “+1” someone else’s key learning, but that should not supplant one’s own learnings. Try to acknowledge each of your team members as they cite a learning. “You crushed that big deal. I learned a lot from watching you navigate such a tricky negotiation.” OR “Firing that great engineer who was a bad teammate was so hard. I really admired the way you handled that situation.”
  • State what you wish for each other to encourage their path forward. For example, wishing them a great new partnership or a challenging new role.
  • Finally, commit to each other. This may be very tactical like committing to getting together once a quarter for beers or a family gathering. Or, it could be committing to supporting each other in their journeys going forward (networking, job reference, a place to crash when they are in town, etc.…).

These prompts work best when they are spontaneous vs. prepared in advance, so I recommend sharing the prompts when you come together. This certainly depends on the type of relationship you have with your partners, but if you are the CEO with co-founders all going through a transition, I recommend you do the above with a facilitator OR at the very least encourage your partners to speak first so as not to bias their reflections. Further, if you and/or your partners have significant others, do not lose sight that they too are going through this transition. A partner who’s significant other is all of a sudden more available than they were when they were running a company, or who is feeling insecure because their partner just lost their job, needs to reflect as much as you do. Make the space for this and include them in any group processes that will serve these important adjunct members of your group.

The New Beginning

You may know exactly what your New Beginning is – e.g., your company was acquired and now you’re in a new role at the acquiring company – you’ve got a new business idea or you have no idea what’s next. When you are unsure about what’s next, it can be easier to think about what you don’t want in your next role vs. what the perfect next role might be. Here are a few prompts to consider for the next thing:

  • What types of roles do you know you definitely don’t want? This could be a level of responsibility (e.g., a founding CEO may know they never want to be a CEO again) or within a function of an organization. (e.g., an engineer who became a product leader may prefer to go back to coding).
  • What industries are off the table for you? Maybe you spent the last decade in e-commerce and you’d like to try an adjacent area like MarTech or retail?
  • What type of people do you prefer to not work with? E.g., extroverts or introverts, micromanagers, jerks, etc.
  • What stage of business disinterests you? E.g., does the thought of inheriting a team vs. starting a team from scratch sound miserable? Or perhaps you never want to have to fundraise again.
  • What would you have to see in your future role to signal potential? Often, when in transition, we overcorrect for the things we didn’t enjoy in our last role. You may cut yourself off from something you might enjoy based on fear from your past experience. Consider what characteristics are important to you in a new role that may allow you to step into discomfort in an effort to grow and learn.

Whichever route you take, if you have less urgency to get employed ASAP, take as much time (if not more) to consider what’s next as you do with your reflections about what was. I suggest a ninety day period – yes, I know, that may be an unaffordable luxury – where you take at least 30 days to reflect, 30 days to consider your new beginning and then 30 days to gear up for the next thing. Even if you are working through the next thing during this period, try to recognize that you are still in transition and journal new insights as they arise.

Transitions are not always easy and we often don’t give ourselves the time to fully process our endings before we jump into the next thing. Take the time if you can and I am almost certain you will find it helpful. Have you tried other techniques to help you process a transition? Please share in the comments!

On Hiring: Beyond the Interview

Posted on by

There are no books you can read or blog posts you can scan that will guarantee that you make the right hire 100% of the time. From bad chemistry to misunderstandings about role expectations, even the strongest candidate may not work out. Also, despite best efforts, early stage companies or new teams inside scaling business often don’t know what they need until they have someone in a particular role. You might realize “oops, this person is great, but their skills are not what we need!”. It happens at every company. Hiring is HARD.

While you can’t prevent occasional mis-hires, you can try to minimize the possibility by including a project or testing phase in your hiring process. This is the stage beyond the standard interview questions and reference checks that gives you a sense of who this person really is, their skills and how they will approach their role. The goal of these tests is to allow the candidate to demonstrate what they are capable of and what it might be like to work with them once they are on board. These tests are critical and will either help you dodge a mis-hire or give you a higher degree of confidence that this is “the one”. I recommend that these tests are performed when you have 1-2 finalists and just before you are ready to do reference checks and make an offer. This can be an especially helpful step if you are down to two finalists you really like.

With this in mind, below are some tips on how to do these tests. For each of these tests, it’s about how the candidate approaches the test and the problem vs. getting correct answers. Build alignment with your team on what “good looks like” for each test and plan to debrief once the assignment is complete and/or presented. Examples of what good might look like are included below.

“The First 90 Days” Test

This is a good general test for any new hire, especially an executive, but also for a people manager or technical leader. Have the candidate explain what their first 90 days on the job will look like. Either leave it wide open or offer a few prompts like “Who will you spend time with?” or “How will you get to know the business?” or “What accomplishments do you hope to make by the end of the first 90-days?”. Avoid being overly prescriptive or leading questions like “Name all the team members you’ll want to get to know” or “Will you spend time with marketing and sales?”. An experienced candidate should have a good sense of how they would spend their first 90 days based on the research they’ve done on your company and insights they’ve gained from interviews with the team.

What good might look like: 

  • Thoughtful about talking with the right stakeholders and when – align with your team on who they’d expect to see on the candidate’s list and when they’d expect to meet with this new hire within the first 90 days
  • Organized and realistic about what can be accomplished in 90 days – align with your team on what you’d expect
  • Asks good questions to get a feel for the assignment – shows they are comfortable with getting clarity on situations (not arrogant)
  • Articulates assumptions made (if any) – often a requirement of leadership roles and demonstrates strong communication skills
  • Cites examples from conversations they’ve had with team members/research they’ve done on the company, market, etc. – demonstrates they listened, interested and have taken the time to understand the opportunity

Engineering and Design Tests

While there are some nifty tools out there that can test coding skills for engineers, I am a strong advocate for testing the human side of these skills. Those who design and/or build your product should be able to demonstrate their work beyond coding or portfolio samples. The best tests here are brief scenarios that demonstrate not just depth of syntax knowledge or design best practices, but also how they will work on a problem with your team. These types of tests can be done as “homework” although it’s nice if it can be done in-person as part of an onsite/video interview. Present a scenario and ask the candidate how they will approach it. You could give them some alone time to think it through and then ask them to talk you (or a domain expert) through it. Ask them to cite how they thought about it and explain the direction they took and why. Prepare to have another approach or idea for the scenario when they walk through their work. This can help gauge how the candidate handles feedback and if they are willing to collaborate on ideas.

Try not to give an assignment that takes more than 1-2 hours to do unless you pay them for the work. I know a company who always pays for the time taken to do the test and if the candidate declines payment, they make a donation to their charity of the candidate’s choice for their time. (So cool!)

What good might look like: 

  • Asks good questions to get a feel for the assignment
  • Articulates assumptions made (if any)
  • Able to explain their work and creative approach; approach aligns with how your team operates and/or offers new ideas that will expand the possibilities for your team/product
  • Comfortable receiving feedback; bonus points if they’re willing to riff on the idea and take it to a better place.

Scenario Tests For Functional Teams (Marketing, Sales, Product, etc.)

Functional leaders are often asked to present a past project they did as a way to demonstrate their work. While this lends insight into the candidate’s past work, I prefer scenario tests. While the former does tell you an experience they had and what worked or not, it will not expose their work on something new. Further, a walkthrough of a former project may not give you insight into what they (vs. other team members) actually did to achieve success. In those cases, I listen for “we did this…” which begs the question “what part of that did YOU do?”. Here are some quick examples of scenario tests for a few functional areas:

Product: Our CTO just came back from a “listening tour” with some of our customers and wants to explore a new set of features to expand our product offerings. These offerings are not on the product roadmap. What steps would you take to understand these new features and how would you approach the prioritization process?

Marketing: We’re about to launch a new product for our customers. It is the first new product we’ve launched in a year. What steps would you take to plan for this product launch and how will you measure its success?

Sales Leader: We are building a product to attract new customers in a new vertical. What information do you need to prepare your team to sell this new product and how will you set sales goals for the team?

You could imagine similar scenarios for finance, customer support or other functional roles. Remember, they still don’t know how your business functions day to day and this isn’t whether they have a perfect plan, but more about how they approach the problem. For functional roles that will require strong communication and presentation skills, have them present their assignments as they would if they were doing it for your team, board or customers, depending on the scenario. For presentations, the ideal flow is interviews, assignment for finalists, and then a presentation to all those who interviewed the candidate. Other key stakeholders could sit in on the presentation, but to mitigate overwhelming the candidate, I suggest only those who interview them do Q&A after the presentation. Q&A should probe what’s being tested (what good looks like) and not to have candidates try to get correct answers.

What good might look like: 

  • Demonstrates research they’ve done to prepare the assignment
    • Including people on your team they may ask to speak with to prepare their preparation
  • Presentation skills – both oral and written. Focus more on content and less on pretty graphics on presentation decks unless that’s an important element of the role
  • Articulates assumptions made (if any).
  • Scenario solution is thoughtful, logical and realistic – align with your team in advance on what this would look like
  • Bonus points if they add insights that the team can learn from (e.g., I once had a VP Marketing candidate tell us what was broken with our SEO and how to improve it as part of his presentation of a hypothetical scenario. It was brilliant!)

With all of the interviews and testing, you still may not get it right every time. Again, hiring is HARD. For some roles, a “try before you buy” is often the best way to go for both the candidate and the company. Not every candidate can opt out of benefits or other things they need from a full time job to do a trial, but if it’s possible or they can do it outside of work, go for it. Pick a project that’s reasonable to do in 30-45 days and agree on what good will look like before they get started. Pay them an hourly rate and set the candidate up for success so they can hit the ground running (e.g., security access to your code repo, slack, etc,) and continue to test the soft skills as they go. if applicable, tell the candidate in advance that if they are hired, equity vesting will start when they started their project vs their actual start date. It’s a nice incentive for them to take the project seriously and know you are invested in their success. 

Finally, if you’re hiring a role for the first time and no one on your team has experience with that role – no one knows what good looks like – ask an advisor, investor or friend with experience to be part of the interview process. They should not only be able to interview the candidate, but also help you formulate the tests!

Do you have other tests or projects you like to use as part of the hiring process? Please share in the comments!

Paving The Way For Less Experienced Hires At Early Startups

Posted on by
Photo Credit From: https://hfaplanning.com/

So many of the early stage companies I work with are struggling to hire talent. Despite the pandemic, they have raised capital and are looking to hire everything from engineering and UX to marketing, sales and support. You’d think with the pandemic there’d be a lot of people looking for work, but in startup land (tech or not), it’s definitely a candidate’s market…unless you are considered too inexperienced for a role. I especially see this for candidates in underrepresented talent groups where there are less opportunities to develop strong networks. Further, less experienced candidates coming from first jobs at a big company where they hoped to gain mentoring and experience before going to a startup can be boxed out before they even get their careers of the ground. These candidates are often viewed as unable to work in a more scrappy, smaller scale organization.

The most common reason for not hiring less experienced talent in a very early stage company (say, less than 20 people) is lack of time to manage and mentor these team members. I get it. If you are a startup leader, you want an A+ team of people who are self-starters and have seen the movie before. While also more expensive, experienced hires should know how things work and in theory should hit the ground running. That said, even experienced hires rarely work effectively and that independently on day one. Further, I don’t know a single startup that has hired an all senior team and never had to let someone go (or they quit) within their first 90 days. This can be because of a mismatch in expectations, lack of alignment or often it’s because the more senior team members had become accustomed to managing more than doing in their prior roles; they were potentially “startup curious” and couldn’t scale down and/or they had lost their player-coach edge.

It is rare that any startup gets their first twenty hires right. Iteration, learning what you need in your team and evolution as your product changes and company grows is a likely cause for lots of refactoring of teams in the first few years. Therefore, hiring a few less experienced folks could net the same result as one senior hire – some will work out, and some will not. Yes, letting someone go or having them quit and starting over is a total time suck, but that’s part of the game and most companies get better and better in finding and keeping great talent over time. From my personal experience working for several startups early on, each of which had insane growth, I found having a mix of seasoned and less experienced team members can be a super power. Less experienced team members were hungry and eager to learn and the senior team members enjoyed mentoring and handing off the more menial tasks so they could focus on meatier and often more strategic work. It was a win-win and many of those junior team members have had incredible careers after we gave them their first shot.

For the Manager

Here are a few things to consider for those anxious about hiring less experienced talent:

  • Pipeline: In this candidates’ market, hiring managers need to treat recruiting like a sales exercise. Fill the funnel! Overly prescriptive job descriptions will limit applicants (especially women) – this includes being too specific about the number of years of experience required which may not translate well for someone who’s been coding since middle school, but has only been in the workforce for 1-2 years. Get the resumes in, then decide how you want to weed out less relevant candidates.
  • Pre-Interview Screening: Don’t judge a resume by it’s timeline! As noted above, many inexperienced candidates – especially engineers – have been doing relevant work well before they went to college or may be understating their contributions in their current roles. They may lack the confidence to promote their work, but that doesn’t mean they can’t get the work done. Consider having a screening question about how long the candidate has been doing relevant work that may not appear on their LinkedIn/resume.
  • Interview: Size the questions and/or the coding exercise with the experience. Determine if the candidate can learn quickly, whether they ask good questions and whether they can deliver on time. Early on in their careers, these are the key skills that will assure they will thrive vs. showing you their perfect coding capabilities in an interview or through a take-home exercise.
  • Potential for hire: If all that is keeping you from hiring a less experienced candidate who shows tons of potential is having the time or talent to mentor these candidates, look beyond yourself and your more experienced team. Have advisors who can sign up to serve as mentors for inexperienced folks. This can range from doing code reviews before check-ins to helping an inexperienced salesperson practice their pitch. These mentors do not have to have full context on your business or the details of the work; if they are seasoned, they know what to look for and should be able to offer objective guidance (and you should offer them some equity and have them sign an NDA, obvi!).
  • On the job: Yay! You are ready to hire a less experienced team member. Set the right expectations and scale the work. As with any hire, they won’t be up to speed on day one. Their 30-60-90 day onboarding process may look different than a more senior hire though. Start small and work up to more challenging tasks. As my favorite leadership coach Brené Brown says in her amazing book Dare To Lead “Paint what ‘done’ looks like.” The most common reason for failure between employees and their leaders in any job – regardless of experience – is misalignment about what the endpoint should look like. Always define and communicate measurable, clear, goals.

NOTE: If you will hire for a role within the next six months, but are not actively filling it, and a current candidate shows promise for that future role, hire them! You don’t want to kick yourself in a few months that you didn’t hire that candidate when you had the chance. This of course assumes you have the budget to do so.

For The Less Experienced Candidate

For folks dealing with the catch-22 of needing experience, but not getting job interviews or offers because you lack enough experience, here are some things to consider:

  • Highlight Transferable Skills: Look deeply at your resume and try to tease out skills you have gained in past roles that are applicable to the job you wish to land. Were you a camp counselor while in college? You likely have strong leadership skills, can multitask and work well in teams. Worked as a waitperson in college? You have sales and customer service experience! Were you on the robotics team or helped friends build their first websites in high school? You started building your technical skills earlier than you think! This also works for job shifters – pull out the buzzwords that highlight your transferable skills. Be explicit under each role such as “Product Management Skills:…” or “Sales Skills:…”.
  • Get Help: Find someone in your network to help you further tease out your experience in your resume and help you practice your interviewing skills. Tap into former bosses, advisors and college professors. If they can’t help directly, they may know someone who can! Practice both technical skills and general communication skills. Both are important.
  • Continuous Ed: Continue to develop your skills outside of school or your day job. Take coding classes online (there are tons) or participate in one of a gazillion webinars designed for core skills like sales, growth marketing and design. A silver lining of the pandemic is that there are now so many great online resources! If you complete these courses, list them on your resume; this shows initiative, willingness to learn and the ability to multitask if you did this work outside of your day job or school.
  • Never Assume: Finally, never assume that just because a company doesn’t have a job posting commensurate with your experience that should not apply. This could be a stretch opportunity or the chance to get a warm introduction to the hiring manager for a future opportunity. Taking steps like this is a first sign that you are ambitious and creative and many people will hire talent despite a position lining up perfectly or even being open. As noted for hiring managers above, good people are hard to come by! I have personally hired many talented people without a perfect fit or a role open at the time because someone showed promise or I knew I’d need them within the next six months.

If all else fails…

Still not sure you can bring someone less experienced on board or can’t get a young startup to take a chance on you? Get creative and offer a “try before you buy” option. Even if part time, it can be great for both the company and the candidate to do a small project together – for pay. The manager can get a sense of a candidate’s work and the candidate can get a sense of what it’s like to work at the company. 

Tips on this concept:

  • Agree on a project that is no more than 2-3 weeks worth of work for a junior team member and with a clear deliverable.
  • Use the time working on the project to meet other members of the team. Schedule a quick meet and greet on Zoom or join team meetings to get a deeper sense of the company culture.
  • If the trial goes well and an offer is made, the equity vesting/cliff start date should be from the start date of the trial project. 
  • Be careful about competitive situations. If a current employer has a clause in their employment agreement that says any relevant work done outside of business belongs to them, don’t do a trial role like this for a related business (sounds obvious, but I have seen this happen too many times!).

I am truly hopeful that more young companies will take chances on less experienced hires. This is where magic can happen for all involved and I can’t tell you how amazing it is to see some of my most junior hires “back in the day” now in senior leadership roles or starting companies of their own. Hopefully, they are now paying it forward!

How have you figured out ways to hire less experienced people or find a role as a less experienced hire yourself? Please share in the comments. You can also read more about my thoughts on hiring here.

Are You Being Strategic About Hiring?

Posted on by

If I had a nickel for every time I get an email or text asking if I know any full stack developers for hire, I could cover the cost of my next trip to SF. I’m also struck by the number of founders who say they’re raising more money simply because they need more engineers to code, yet they do not have a good hiring strategy.

For decades, there have been books and articles about building engineering teams. The infamous book The Mythical Man Month, by Fred Brooks should be on every software engineer and tech startup leader’s reading list (It should also be re-titled either “The Mythical Person Month” OR “Nine women can’t make a baby in one month”…just sayin’). There are also many blog posts explaining why full stack engineers are unicorns. Yet, when I did my latest poll on twitter on top hiring priorities this is the response:

screen-shot-2019-06-02-at-1.20.42-pm.png

Sure, it’s fine to look for a generalist [or augmenting your team with an outsourced dev shop] to get basic stuff done, but being more strategic about your hiring process, is what could be the difference between a great product in the market vs. something basic that is slow to ship. Below are some tips on how to be more strategic about hiring:

  • Product prioritization leads to hiring prioritization: If you’re doing proper product prioritization via discovery – talking with customers and understanding what you need to get to product market fit or grow adoption – then these priorities set the hiring agenda. For example, if you’re realizing that your on-boarding process is too complicated, then hiring a User Experience (UX) person may serve you far better than someone who can code a fresh UI. If performance issues are causing churn, then hire a performance engineer; someone who knows how to diagnose and fix performance issues. Just like you are building a product to solve for the job to be done, hire the engineer for the development job to be done. 
  • Understand the roles: Do you understand the difference between a front end developer vs. designer vs. UX expert? (if you don’t, read this) Are you fluent enough in your architecture to know what type of engineer should be building which elements of your product? Many early stage companies are started by engineers who know exactly what they’re doing, but many are biased in the areas of which they are most familiar, even if that is the suboptimal choice for their current products. I’ve seen products built with .NET simply because the seasoned engineer-founder knows that platform best, without considering whether it is the best platform for their product and/or whether they’ll be able to hire engineers who are skilled in .NET (or want to learn it) to build it at scale. I’ve also seen many startups default to the language of choice for the full stack engineer they found to build their first prototype and then let that language dictate future work as their product gets market fit and scales. This rarely works out, unless that first engineer is a ringer, and most of the time the reality of having to refactor your entire codebase or port to a new language hangs over the product team…forever. 
  • Long term need vs. short term fix: Another common mistake is hiring a full time expert in an area that only needs occasional work. E.g., Performance engineering. Certainly, if you’re building a complex, distributed, application that has heavy computation or many API calls, then a performance engineer is a critical full time hire. However, it may behoove you to find a good contract engineer who specializes in performance tuning as needed; at least until you’re operating at scale. Same thing for a designer – unless you’re at scale and adding new features/products at a steady clip, then a contract designer may be prudent while you iterate on your MVP. You may pay a little more per hour for these contractors, but that far outweighs over hiring and paying a full time salary early on. 
  • Time Delay + J-curve: Just because you have cash in hand to hire, doesn’t mean you will find and hire the right people right away AND each time you add a new person to the team, there will likely be a j-curve impact on productivity.
    Screen Shot 2019-06-03 at 1.47.59 PM.png
    Therefore, when you prioritize hiring, factor in how long* some roles will take to fill (e.g., we don’t need a designer for a few months, but it could take three months just to find the right person) and be thoughtful about the cadence of adding new people to any team. Adding a bunch of new engineers at once is not going to accelerate development over night. Each time a new person comes on board, it’s disruptive to team’s flow – and this is not just about training them. It disrupts the whole     dynamic of the team. If you’re doing a lot of hiring over a discrete period of time, set the right expectations (with yourself, your company and your investors) that a ramp in hiring will likely slow things down until new teams settle into new norms. If the ramp is constant, by the way, your teams will never settle into a groove leading to employee dissatisfaction, high turnover, product delays, etc.

    *This delay should also be considered in the budget exercise for these roles. Don’t front-load salary expenses for open jobs that may take weeks or months to fill. 
  • Humans are not robots: Hiring is hard, and even when you get really good at it, at the end of the day these hires are human beings that have their own unique needs, past-job baggage and career aspirations. Their added productivity, how they diversify and/or add to your culture is only part of the consideration. Having a strategy to prioritize manager, team time and money for their human needs (benefits, HR support, a strong on-boarding experience, ongoing training and mentorship, etc.) is just as important as having a strategy to prioritize these hires! 
  • Apply the 80-20 rule: A great product leader will tell you that if you invest 80% of effort to understand the problem, it should result in 20% effort to build the right solution. The same applies to hiring. If you take 80% of your effort to develop a great hiring strategy and program, it should lead to 20% of the effort to bring great people on board and retain them for the long term. 

There’s a severe opportunity cost that comes with bringing on the wrong people and/or at the wrong time and not having the right people programs in place. Even if you are a tiny early stage company, having to let someone go, or having them quit, and finding a replacement not only stresses out the manager and team, but there is a productivity hit to all while you go through the process. Even though it may feel like you’re moving slowly through the process of building a team, a strategic approach will pay off.

You can read more about my thoughts on hiring for startups here. Please share other ideas on this topic in the comments!

Go Big, Or Go…Startup

big Fish Little Fish

Image source unknown

A common career advice question I get all the time is what the tradeoffs are between going to a startup vs. going to a big company. There are many things to consider and lots of “it depends” when it comes to where you are in your career, where you live etc., but when it comes to the general aspects of a startup vs. mature company, most of the situations don’t vary that much. I’ve done both, several times, so here’s a perspective on the tradeoffs based on my own experiences.

Startup vs. Mature Company

Screen Shot 2018-10-15 at 10.54.03 AM

(c) 2018 Julia B Austin

Putting aside for a moment industry and how you feel about the products the company is building (both of which are very important!), most of the differences between a startup vs. a mature company are pretty obvious. In a mature company, you will likely have more role models to learn from and stronger teams to collaborate with, a clear direction and a mature board. The role you consider may have a narrow scope, but could offer deeper learning and of course great benefits, compensation, etc.. You’ll also get exposure to what good (or bad) looks like at scale and possibly a nice brand for your resume.

Startups can offer a chance to do “all the things” which can be either a blessing or a curse depending on your interests. You may miss out on having peers to collaborate with, have to look outside of your company for mentors and role models or have limited budget to get stuff done, but you may get high value equity in exchange for lower than market-level pay. If you want to dig more into deciding which startup to join, I suggest Jeff Bussgang’s book Entering Startupland which goes deep on the different roles at startups and how to get your foot in the door.

Leadership

One thing often overlooked when considering a new job is the leadership of the company. Serial entrepreneurs will have a very different approach than someone who has limited real-world experience and mature company executive teams can be world class or “legacy” leaders who can’t move with the times. There are many tradeoffs when factoring in leadership into the decision process of startup vs. a mature company.

Screen Shot 2018-10-15 at 10.55.10 AM

(c) 2018 Julia B Austin

Startup founded by serial entrepreneurs: This can often be the best case scenario if you want to learn from those who have “seen the movie before”. They likely had no issue raising money and were selective on who their investors were and who sits on their board. They will know how to get the flywheel moving incited by past mistakes OR failures.

“When I started my fifth company I knew exactly how I wanted to build the team. So, on day one I hired a head of recruiting to get things off to a strong start. I also knew market adoption would be critical to fundraising so focused on growth very early on – before we even had a product!” – David Cancel, CEO & Co-Founder Drift

Serial entrepreneurs may also try to overcorrect in areas where they failed the first time, such as over analyzing or delaying decisions, being too conservative on cash flow or focusing too much on scalability too early in the product development process. If you’re interviewing with a serial entrepreneur, it’s always good to ask what lessons they learned in their last startup and how they’re bringing those lessons into their new venture.

“I joined Drift in part because I wanted to learn from the experience of the co-founders. They’ve seen it before so they anticipate issues, they know when (and how) to hire experts to level up the team, and they know what’s “normal” for a hypergrowth company. It’s the best of both worlds: you get the rollercoaster startup experience with some of the more measured leadership and strategic characteristics of a bigger company.” – Maggie Crowley, Product Manager Drift

Industry veterans doing their first startup: Founders coming from mature companies with no startup experience can have big company confidence, be great at hiring and leading teams, but lack scrappiness to get a Minimum Viable Product (MVP) out the door and work towards product market fit.

“At our first startup after a series of roles at large enterprise software companies, we tried to force a big company perspective on how we did employee feedback and reviews. We were too structured with this initially and quickly cut back to a more loose feedback and review process with our team.” Izzy Azeri & Dan Belcher, Co-Founders Mabl

They may also be too used to having teams of people and systems in place to cover the more mundane duties of running a company and don’t want to get their hands dirty. On the flip side, they often know how to implement those processes and know the people to hire to run them so once the flywheel is moving and cash is in-hand, they can get momentum quickly.

“Earlier in my career, I hired a small team within a large corporation that was scrappy and had entrepreneurial mentality. At my startup, I quickly realized the benefit of once having a corporation behind me when things weren’t working out. The impact of a bad decision or process was much greater with no safety net.” – Karen Young, CEO & Founder Oui Shave

Startup with limited leadership experience: Working with a skilled group of founders leading teams for the first time can be tons of fun. If you bring some experience to the table, it can be very gratifying to not only work from the ground up, but also work alongside these founders as they grow. However, it can be frustrating if you find yourself figuring out things on your own because there’s no one in the company to mentor you. These situations can be very rewarding if you’re patient and you can always get outside mentors and advisors if they’re not available at this type of startup.

“When we started, we got a lot of advice like: stay focused, don’t expand too quickly, be careful that experienced hires match your culture.  All good advice, but we discovered there’s no real substitute for learning the hard way. The lesson just doesn’t sink in until you feel the pain of doing it wrong.” Wombi Rose, CEO & Co-Founder LovePop

Mature company with inexperienced leadership: If they made it this far, they are either wicked smart, lucky or both! More likely they also have surrounded themselves with strong, experienced leaders, investors and/or board members. You can learn a lot from joining a company like this, but they are very, very rare! When companies scale too fast, they can also suffer from having people in roles that have outgrown their experience. Read more about the impact of Hypergrowth situations written by my friend at Reboot, Khalid Halim, for First Round.

Mature companies with experienced leadership: These organizations have all the standard things you’d expect. Probably more politics and process than you’d ever find at a startup, but the benefit of exposure to great role models and best practices can be invaluable. Sometimes, these bigger companies can also expose you to the “dark side” of leadership and processes which are also great learnings on what not to do in your next job or company you may start yourself.

Which comes first in your journey?

For those doing early career path planning and knowing they want to do both a startup and a mature company at some point, there’s always the question of which should come first. Hiring managers at early stage companies can get “spooked” when they see someone with too much time (5+ years) at mature companies; questioning whether the candidate will be able to transition to startup life. Not that it’s impossible, but it’s something to consider. For these candidates, I suggest highlighting any scrappy “ground zero” work they may have done at their companies to demonstrate they can handle ambiguity and take risks. I am also a huge (and very biased) fan of people who’ve joined companies early and scaled with them. They have learned a TON from those experiences and can often start scrappy, but know how to operate at scale. Win-win.

Conversely, someone with a lot of startup experience may have a hard time adjusting to mature company. A hiring manager at a mature company may question whether a candidate with only startup experience can handle a slower pace or won’t know how to navigate a complex organizational structure that requires political and communication savvy. You may have to sacrifice title and maybe some salary to get a foot into larger institutions who may view your past role, which may have been very senior at a startup, to being pretty junior if those around you have decades more experience. However, I always find those with startup experience can be invaluable to a team that needs to be shaken up, take more risks or explore new ground. Often, those who sacrifice title and pay when they joined, make it up fast as they move up the chain in a larger organization.

There’s no right or wrong place to start. A lot depends on how you define your skills and how willing and patient you are in either case to adjust. Much can depend on who hires you and their management philosophy. I’ve seen some people bounce between both types of situations over and over, some that just can’t handle startup life, and others who have startups in their DNA and should just stick with that world 🙂

“At a startup, every job matters and you can see almost daily that you are creating something that wasn’t there before. You have the ability to learn quickly and have a fast feedback loop to let you know how you’re doing. It’s very different working at an established company vs a startup, but you can learn a lot at both – you’ll just learn very different things.” – Rebecca Liebman, CEO & Co-Founder LearnLux

Questions To Ask

Regardless of whether you are a seasoned veteran or fresh out of school, as you ponder whether you want to join a startup or a mature company here are some final things to consider:

  • What tools do you want to add to your toolbox? Will the role allow you to hone skills you already have or add new ones?
  • Who do you want to learn from, and how do you want to learn? You can learn from experienced colleagues and mentors, but having bad role models can also teach you a lot about what not to do. Similarly, if you are an experienced hire coming into a company started by inexperienced founders, you may want to learn by mentoring or teaching these young leaders. Taking the skills you’ve developed over your career and applying them to a new situation in itself can be a very enlightening experience.
  • Who do you want to work with? How important is the size and culture of the team you’ll work with? Remember, you’ll probably spend more waking hours of the day with these people than anyone else in your life – regardless of the size and nature of the company you join.
  • What do you value? At the end of the day, love what you do and decide what role will allow you to maintain the integrity of who you are and who you aspire to be!

Do you have other tips on how to decide whether to join a startup vs. a mature company? Please share in the comments!

So You Want to Be A Product Manager

Posted on by

Because I teach a course on Product Management at Harvard Business School, I am routinely asked “what is the role of a Product Manager?”. The role of a Product Manager (PM) is often referred to as the “CEO of the Product”. I disagree because, as Martin Eriksson points out, “Product managers simply don’t have any direct authority over most of the things needed to make their products successful – from user and data research through design and development to marketing, sales, and support”. PMs are not the CEO of product and their roles vary widely depending on a number of factors. So what should you consider if you’re thinking of pursuing a PM role?

As an aspiring PM, there are three primary considerations when evaluating the role: Core Competencies, Emotional Intelligence (EQ) and Company Fit. The best PMs I have worked with have mastered the core competencies, have a high EQ and work for the right company for them. Beyond shipping new features on a regular cadence and keeping the peace between engineering and the des

ign team, the best PMs create products with strong user adoption that have exponential revenue growth and perhaps even disrupt an industry.

Screen Shot 2017-10-31 at 1.44.18 PM

Do you have what it takes to be the best PM?

Core Competencies
There are core competencies that every PM must have – many of which can start in the classroom – but most are developed with experience and good role models/mentoring. Some examples of these competencies include:

  • Conducting customer interviews and user testing
  • Running design sprints
  • Feature prioritization and roadmap planning
  • The art of resource allocation (it is not a science!)
  • Performing market assessments
  • Translating business-to-technical requirements, and vice versa
  • Pricing and revenue modeling
  • Defining and tracking success metrics

These core competencies are the baseline for any PM and the best PMs hone these skills over years of defining, shipping and iterating on products. These PMs excel at reflecting on where each of these competencies contributed to the success or failure of their products and continuously adjust their approach based on customer feedback.

Emotional Intelligence (EQ)
A good PM may know the Do’s and Don’ts of a customer interview, but the best PM has the ability to empathize with customers in that interview, are tuned into their body language and emotions and can astutely suss out the true pain-points that their product/feature will address. A PM with a high EQ has strong relationships within their organization and they have a keen sense of how to navigate both internal and external hurdles to ship a great product. Here’s a deeper look at how the four EQ key traits, as defined by Daniel Goleman, relate to the PM role:

  • Relationship Management: Probably one of the most important characteristics of a great PM is their relationship management skills. By forming authentic and trustworthy connections with both internal and external stakeholders, the best PMs inspire people and help them reach their full potential. Relationship management is also vital in successful negotiation, resolving conflicts and working with others toward a shared goal which is especially challenging when a PM is tasked with balancing the needs of customers, resource constrained engineering teams and the company’s revenue goals.

    Authentic and trusting relationships within an organization can lead to more support if additional funding is needed for a product or to sway an engineer to include a quick bug fix in the next sprint. Outside an organization, these skills could encourage existing customers to beta test a new feature for early feedback or convince a target customer to try the MVP of a product still in stealth mode. These relationship skills can also be what makes the difference between having irate customers because of a bug introduced into the product and those who say “no worries, we know you’ll fix this!”. 
  • Self-awareness: PMs must be self-aware to remain objective and avoid projecting their own preferences onto users of their products. If a PM is in love with a feature because it addresses their own pain points (PMs are often super users of the products for which they are responsible), they may cause a user to say they love it too just to please the PM (“False positive feature validation”). If not self aware, a PM may push to prioritize a feature they conceived even when all the customer interviews and evidence is stacked against it. This lack of self awareness could derail more important priorities and/or damage the PM’s relationship with engineers who may lose confidence in their PM when the feature isn’t readily adopted by users. 
  • Self-management: Being a PM can be incredibly stressful! The CEO wants one thing, the engineering team another, and customers have their own opinions about feature priorities. Managing tight deadlines, revenue targets, market demands, prioritization conflicts and resource constraints all at once is not for the faint of heart. If a PM cannot maintain their emotions and keep it cool under pressure, they can quickly lose the confidence of all their constituents. The best PMs know how to push hard on the right priorities, with urgency, but without conveying a sense of panic or stress. These PMs also know when to take a breath and step away if needed, regroup, and go back into the game to get sh*t done (GSD). 
  • Social Awareness: According to Goleman, the competencies associated with being socially aware are Empathy, Organizational Awareness, and Service. PMs must understand customers emotions and concerns about their product as much as they understand the concerns of the sales team on how to sell that product (or support team to support it, or engineering to build it). PMs have to have a deep understanding of how the organization operates and build social capital to influence the success of their product – from obtaining budget and staffing to securing a top engineer to work on their product. Finally, social awareness ensures the best PMs service their customers with a product that addresses their jobs to be done which is ultimately what drives product market fit.

Read more about what Paul Jackson has to say about EQ and PMs here – including a sub-link of an interview with Sam Lessin, former VP of Product Management at Facebook, who says he has ‘never successfully trained empathy.’ (or as Lady Gaga would say “you were born this way”…or not!)

Company Fit
So if the best PMs have well developed core competencies and a high EQ, does that mean that they are then destined for success no matter where they work? Going deeper, it is taking these skills and personality traits and applying them to the right company – amid a broad array of opportunities – that will ultimately guarantee success.

I have yet to see a standard job description for a Product Manager because each role is ultimately defined by the size, type of product, stage, industry and even culture of the company. Assuming the core competencies and high EQ as the minimum requirements, the next step is to unpack who’s hiring and what they are truly looking for:

  • Technical Skill – The type of product, who uses it and/or the type of company (e.g. Google who requires PMs pass a technical skills test regardless of what product they’ll work on) will determine how technical a PM needs to be. If the company is building a SaaS CRM, there may be more requirements for experience with go-to-market and customer lifecycles than how the product itself is built. If it’s a data science product with machine learning algorithms and APIs, the role may require a lot more technical depth to not only understand how to build the product but also how to talk, credibly, with the customers who will use it. That said, having a basic technical understanding of what is “under the hood” and mastery of the tools that PMs use is definitely important for the role, anywhere. Colin Lernell has more to say about these necessary skills here.

    If you are an aspiring PM concerned you lack the basic tech skills for the role, you might consider taking online courses such as the renowned Introduction to Computer Science (CS50) course offered by Harvard University or one of the many intro and advanced technology courses offered by The Flatiron School. 
  • Company philosophy about PM – Every company has a different philosophy about the product development process and where PMs fit into that process. Below are the three most common types with pros and cons:

    • PM Drives Engineering: A “throw it over the wall” approach where PMs gather requirements, write the quintessential PRD (Product Requirements Document) and hand it off to Engineering to spec out the technical requirements. Contemporary organizations may do this process in a more agile and collaborative way, but the expectation is that PMs know best about what customers need and engineering is there to serve.
      • Pro: Engineering can focus on coding without a lot of distraction; tends to work well for Waterfall development shops with long lifecycles.
      • Con: Engineers lose sight of the big picture and do not develop empathy for customers which can lead to a poor user experience; often there are unhealthy tensions when tech-debt and “plumbing” work needs to be prioritized against customer requirements. 
    • Engineering Drives Product: More technically oriented product companies (e.g., cloud, big data, networking…) tend to be engineering driven where engineers are advancing the science in their domain and PMs validate solutions or create front end access points (UIs, APIs) to tap into this new technology. There can be a collaborative relationship and feedback loop between customers, PM and engineering, but typically, PMs are serving engineering in these companies.
      • Pro: Breakthrough technology can offer customers things they didn’t even know they needed (VMotion at VMware was a great example of this. An engineer thought it would be cool to do, a PM figured out how to monetize it and it became THE billion dollar game changer for the company).
      • Cons: Engineers chase the shiny new thing, over-architect the solution or iterate forever (seeking perfection) before getting customer feedback; PM input on priorities are ignored, which is sometimes the most basic needs of customers to encourage adoption and increase stickiness of the product.

        Screen Shot 2017-10-31 at 10.52.40 AM
    • The PM<>Engineering Partnership: There is a strong yin-yang between PM and Engineering where there is joint discovery, decision-making and shared accountability. Engineers join PMs in customer interviews and PMs are insprint meetings to help unblock tasks or bring clarity to  requirements, but the two roles respect the line where one starts and the other stops. PMs understand what’s being coded, but don’t tell engineers how to code and engineers have empathy for customers’ needs, but leave the prioritization to the PMs.
      • Pros: Streamlined prioritization process that values tech-debt/plumbing projects; better design processes leading to a more positive user experience; higher performing teams with improved product velocity, quality and typically, happier customers.
      • Con: Breakthrough innovation may not get light/investment; time-to-market may seem to lag (but I’d argue what’s released is far better aligned with customer needs with a far more scalable product).

I’m clearly biased (as is Fred Wilson) on the third type of philosophy about PM as I’ve experienced all three and found the yin-yang to be most effective, but it’s not to say the others are notably bad and, again, it really depends on what type of product, stage, etc,. Regardless, when considering a PM role, the philosophy of PM at the company could be the deciding factor on fit for the role.

  • Stage of company – The role of the PM at a startup is far likely to be responsible for “all the things” vs. a mature company where their role will be more distinctly defined. Eriksson, Banfield and Walkingshaw’s book Product Leadership has a section that has a lot more detail on this topic).

    • Startup: Beyond discovery, definition and shipping, they may also be responsible for pricing, marketing, support and potentially even sales of the product. These PMs thrive in a scrappy environment and are comfortable with ambiguity and frequent changes to direction as the company works towards product market fit and learns to operate at scale.
      • Pros: Likely to be more involved with company strategy, exposure to senior leadership/board, able to take more risks/make a bigger impact; more influence/authority over company resources.
      • Cons: Little-to-no mentorship or role models or best practice within the company (may have to seek externally); may not have requisite experience for some of the “things” (comfortable winging it); tight budgets. 
    • Mature Company: The PM may have a more narrow scope (deep vs. broad), have co-workers who handle pricing, go to market strategies, etc.. and likely part of a larger team of Product Managers.
      • Pros: More likely to have mentoring/role models and development standards/best practice; close association with an engineering team can develop strong relationships over time (great for long term impact/career growth); if product has market fit, there is an established customer base and performance baseline to work from vs. guessing until you get it right.
      • Cons: Less exposure to company strategy; just one of many voices of the customer; can get “lost” in the system; more politics; tight budgets. 
  • Founder/CTO/CEO relationship with PM – Especially in earlier stage companies, it’s important to know how involved the Founder/CEO/CTO is in the product process. If they are deeply involved, the PM role may play more of a support role to flesh out their ideas or validate concepts with customers vs. conceiving and driving ideas of their own. This can be great fun for some PMs who enjoy partnering with founders/c-levels and collaborate on the product evolution, but for some PMs it can be very frustrating if they prefer to take more ownership of product direction. It can also be challenging if the more technical founders/c-levels prefer working directly with engineers. This can leave PMs out of the loop or undermined (even if unintentional) causing not just personal frustrations but delays if they have to play catch up and/or continuously recalibrate. When considering a PM role that may work closely with the founding leadership team, be sure to find out their expectations of the PM function and decide whether this is the right fit with your interests.

There are of course many other factors to consider for any role such as the type of product you are building (B2B, B2C, industry, etc.), the humans with whom you’ll work and the overall company culture (diverse, inclusive, flexible work hours, remote culture, etc.), and of course compensation and benefits. There are also a million articles on hiring product managers to get perspective on what the hiring managers are looking for – I especially recommend my friend Ken Norton’s piece How to Hire a Product Manager. However, if you are striving to be the best Product Manager, consider all of the above before signing on to your next gig. Developing core competencies will be an ongoing activity throughout your career and leveraging a high EQ will ensure a more positive experience, but where you work, how they work and who you work with/for will ultimately determine your long term success.

Have additional pointers on succeeding in the PM role? Please share in the comments!