Category Archives: Engineering

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.

The Fundamentals of Roadmapping

Posted on by

We are in an era of Objectives & Key Results (OKRs) and Key Performance Indicators (KPIs); tools companies use to track and measure their progress and ensure they are on track to reach strategic goals. In scaling startups, CEOs and co-founders have mixed feelings about delegating tasks they once owned to new layers of management. Some tasks, like perhaps managing the books to a new head of finance, they are eager to let go of, and some, like product decisions, can cause a lot of angst. In these times of transition, it’s not uncommon to implement OKRs/KPIs as a way to get comfortable with handing off these responsibilities. As management layers are added, there is a natural fear of no longer being close to the detail, of wondering whether a team can execute as well without a founder/top leader engaged in the day-to-day. I often hear CEOs/Founders of scaling companies ask how they will know if things are working if they are no longer in the weeds. These leaders want to trust their team and worry about micromanaging, but they also want accountability and the ability to track progress. 

Measuring performance and holding leaders accountable is indeed important, but what’s often missing is the holistic view of where the company is going and an organization-wide understanding of how it will reach its goals. Before setting those metrics, leaders must be clear about the True North for the business – the compass of your company’s identity and growth direction – and set a near-term vision with a roadmap to get there.

The 30K Foot View

Anyone that asks what your company’s 3-5 year roadmap looks like is clueless about how businesses – at any stage – really work. With constant innovation, new market entrants and potential black swans like a global pandemic, the best a leader can do is set a 12-18 month strategic plan that is directionally aligned with the company’s true north. That plan should be broken down by quarter with the assumption that the degree of confidence in achieving goals within each quarter will decline over time. You cannot predict the future, but you can build within a set of assumptions. Assumptions should be articulated for each goal as a means to establish confidence levels.  

Here’s a framework for thinking about the high level view of your company’s roadmap:

roadmapframework

High-level Roadmap Framework (c) Julia Austin 2020

The true north (or mission) statement should be at the highest level, a guiding principle of the impact your company is committed to making for the long term. When I was CTO at DigitalOcean, we coined the true north statement “To Empower Developers To Build Great Software”. This gave us focus on our target persona (developers) and latitude to evolve as needed to achieve that mission. While we were (and they still are) a cloud company, this statement said no matter how we evolved, markets change, etc. we would remain focused on what’s needed for developers to build great software. Google’s statement is “to organize the world’s information and make it universally accessible and useful.” Again, the focus is on the impact – the world’s information being accessible – not how the company delivers on that mission.

The 12-18 month vision statement should be a clear focus on near-term impacts. This may be to achieve a certain level of market adoption or to have a core set of offerings viewed as table stakes for the target audience. It could be the launch of a new product or service or a major financial metric like reaching Free Cash Flow.

Quarterly OKRs/KPIs should be brief (no more than 2-3 major goals), achievable, but with some amount of stretch. In other words, if you were using the traffic light rating system (red, yellow, green) not all of them will be “green” per quarter. More info here. Beware of over-adjusting OKRs every quarter – while they will definitely evolve, especially if the process is new to an organization, there can be a temptation to focus on changing the objectives vs. adjusting KPIs or accepting that the goals simply can’t be met for other reasons (poor leadership, systemic issues, market changes) which should be addressed outside of the rating process.

Expect each team across the organization to cascade their operational roadmaps from these strategic foci. Operational roadmaps should identify key initiatives and milestones. Some milestones may be a sum of parts (as in the Engineering roadmap below) and some may be more linear and timeline driven as the Operations and GTM roadmaps show below. Of course, each initiative can be broken down even further per team (see next section); that’s up to each team to decide how to manage from there. However this high level format is the right level of detail for broader communication across the organization and perhaps with your board or even your customers.

strategic_roadmap

Strategic Roadmap Example (c) Julia Austin 2020

The Process

I encourage a six-quarter rolling approach whereby each quarter the leadership team:

  • rates and reflects on last quarter’s results;
  • reviews upcoming quarterly goals;
  • adjusts assumptions and factors in any new information (market shifts, product/revenue changes, etc.) for the next 6th quarter;
  • communicates the updated company plan across the organization; and 
  • has each team create a tactical roadmap that lines up with the quarterly goals.

Below are representations of tactical roadmaps I’ve seen used in two very different organizations. In the first example, the product team and key stakeholders (sales, support and finance leads) review current priorities and drag and drop efforts according to their complexity and priority relative to company goals. They use a product like Mural to collaborate electronically (both when in-person and remotely). In the second example, a simple spreadsheet is used, projects are t-shirt sized using standard scrum methods, and there are links to each project’s details (in apps like Jira or Trello) for more information about relevant epics and user stories. PMs meet with engineering leaders each month to review and adjust as needed. In all cases, the details of each major initiative includes tie-backs to OKRs/KPIs. If they can’t be tied back, and measured, they should not be on the roadmap!

matrix_roadmap

Example One

 

spreadsheet_roadmap

Example Two

Considerations For Very Early Stage Companies – Pre-Product Market Fit

  • If your company is very early stage, expect to pivot the vision and the roadmap a lot as you learn and grow. Create guiding principles for when and how you would adjust a True North and/or Vision Statement. What factors must be true? What assumptions are you making about the market and/or target persona that may prove wrong or different than what was expected? Will you lean into these new findings and shift the direction of the business or keep testing those assumptions in different ways to learn more? Even the earliest staged companies should have a true north as they get started.
  • Avoid peanut buttering! One of my favorite terms, this suggests spreading many things across a broad surface vs. being focused on a few key initiatives. It is scary – especially for early stage companies – to commit to only 1-2 things when it’s so unclear whether either/both will be a success and there are so many other things to try. However, by spreading limited resources across too many things, it’s more likely nothing of substance will get done, or things will move too slowly OR each thing will be done with poor quality while possibly burning out your team. Pick those 1-2 focus areas and set time-boxed milestones that will drive next steps or a change in direction. For example, “we must reach 20-30% conversion rate with the current MVP over the next two quarters or shift to the other product idea.” Commit to these milestones and agree how close you’d need to be to reaching that goal to keep moving forward vs. cutting bait and moving on.

Considerations For Companies With Product Market Fit

  • Appoint a roadmap owner who can oversee the process across the organization. This is typically a senior product manager/head of product or Chief of Staff who is empowered to drive decisions and prioritize based on the 12-18 month vision. This role may be supported by a program/project manager who maintains the details in whichever tool or platform you use (e.g., updates the spreadsheet, inputs changes into Trello, etc.)
  • Be mindful of how much time your team is spending on roadmapping and the measurement process. If it’s taking more than a few hours per quarter to discuss, update and communicate the roadmap and OKRs, it’s costing your company far too much time and money. This process supports productivity, it doesn’t become the work itself! If it’s taking up too much time, it’s likely the goals and measures are far too detailed and/or there are too many people involved in the process.
  • Establish Rules of Engagement (ROE) for times when an opportunity or challenge may disrupt the roadmap. For example, what size/nature of a new customer opportunity would disrupt the roadmap? Can it only be for initiatives that were already on the roadmap, but further out? Will the sales team have points they can “spend” per quarter to reprioritize something? What about a major bug/performance issue? How bad would they have to be to disrupt the current plan? Once the ROE are set, these too should be managed by the roadmap owner. If the ROE are not adhered to, they’re useless, so only have a few and keep them simple. E.g., unless a new customer could grow revenue by x% and what they need is already on the roadmap, we won’t do it. OR if a bug is creating more than x% churn or denying service to a critical mass of customers, it’ll be fixed in accordance with the roadmap.
  • Prioritize the backlog and tech debt as part of the process. These are just as important as new features and the longer they are put off, the harder they will be to schedule and get done. Set aside anywhere from 3-10% of resource allocation dedicated to these efforts. It largely depends on how severe issues are, whether upcoming roadmap initiatives have dependencies on these issues and/or how long they have been festering. It can be useful to “age up” backlog/debt items to raise their priority.
  • A few finer points on this topic:
    • If a new request or critical issue bumps something else, always communicate the tradeoff(s) made and the positive or negative impact they will have on OKRs/KPIs.
    • Developers hate roadmap thrash! So try not to disrupt it too often.
    • Remember, for projects already underway, a reprioritization is not a 1:1 swap – there will be a J-curve in productivity each time a team has to stop something, start something new, and return to the old project later. 

Conclusion

There is no one best way to do the roadmapping process. How you lead, the type of product you build, organizational structure and culture all come into play to determine what will work best for your company. Having a roadmap process will improve the prioritization process and create alignment among teams, will provide transparency across the organization and should give leaders (including your board) the right level of visibility to ensure the work is getting done. Don’t create a process just for the sake of process or implement OKRs just because someone told you that’s what you’re supposed to do. Be thoughtful and implement whatever process works best for your company.

Do you have other suggestions on how to run a great roadmapping process? Please share in the comments!

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!

The War For (Diverse) Teams At Early Stage Companies…and Beyond

Note: Diversity is a term used 30+ times in this piece and refers to all types of diversity, beyond just gender.

In 2004, there was a post-bubble burst resurgence of well funded startups and VMware, like many other companies in the Silicon Valley, was struggling to compete for talent against Google, Yahoo and others in their space. The hot conversation in the weekly e-staff meeting in Palo Alto was about maintaining the bar and hiring the very best talent they could find. This was well before diversity and inclusion was trending as a hiring pain point. There was a war on talent.

To combat this war, the leadership team at VMware got creative. There was an urgency to bring on talent and just competing on compensation and equity wasn’t enough when that talent pool itself was sparse. So, leveraging ties to several of the team members’ east coast roots, they tried an experiment and opened an office in Cambridge, MA.

As the Site Director hired to build out that office at the start of 2005, I was charged with bringing on at least a dozen engineers by the end of the year. I had strict guidance on who to hire first;  the first six hires had to be at least a Staff level engineer, which at that time was like a Principal at most other companies. Even though we were desperate to bring on more talent, the leadership team insisted we still keep the bar high. There were no compromises – hire the best, no matter what.

By the end of 2005, we ended up hiring over 20 seasoned engineers and were well poised to scale that location with more junior talent and expand into other regions across the globe. It was a hard push to win the war, but we won it and many would say that getting scrappy, maintaining the bar and taking risks outside of Palo Alto to hire great talent was one of the key factors that led to VMware becoming the multi-billion dollar success story it is today.

Getting Scrappy And Taking Risks To Create Diverse Teams

Flash forward to 2017, and the talent war is still on, but it’s not just about hiring top talent, it’s about hiring for diversity. There’s plenty of science to prove that diverse teams are what separate average companies from the big success stories. Once there’s diversity in teams, you attract more candidates from underrepresented groups. But there is a catch-22 when companies and teams with no diversity can’t hire candidates from underrepresented groups, in part, because they have no diversity in their current teams!

I was at an event recently where I sat in a breakout session about diversity and inclusion where most of the fifteen or so participants were white, male, CEO-Founders of very early stage companies. These leaders were complaining that despite best efforts, they were not able to find/hire qualified, candidates from underrepresented groups for their open positions. Investors were on their back to meet deadlines and reach revenue goals and the push for building diverse teams was not a high enough priority to push back. They had to hire the best talent they could find, and get coding!

But what if that talent didn’t exist? What if it was 2004 and there were no engineers to hire, never mind engineers from underrepresented groups? How do companies, like VMware did back then, combat this war vs. becoming complacent? What can companies do today to be creative, continue to scale, and develop a diverse team? What if CEOs, their leadership team and their boards held the line on diversity metrics, no matter what?

Starting From The Top

A company that is committed to diversity must demonstrate that commitment from the top, down. CEOs set the tone for the organization’s culture by demonstrating a commitment to diversity and inclusion. They don’t just say they care about the problem and acknowledge the importance of solving it, but they force it to happen. VMware’s founding CEO, Diane Greene, was adamant that we hire only the best talent from day one, and CEOs today need to do the same when it comes to hiring diverse talent.

One of the most compelling reasons for any strong candidate to join a company is knowing there’s diversity at the senior most levels. Having Diane at the helm played a huge role in my decision to join VMware. She was a role model and inspiration to everyone at the company as she balanced the complex demands of scaling our business with her family and other commitments outside of work. We were not only inspired to follow her drive and passion for the business, but the company naturally attracted other strong, candidates because of her leadership.

Whether you are an early stage company, mature business or even just a growing team within a maturing business, committing to diversity at the top is critical. Here are some suggestions on how to do that:

  • The founding team: Diversity does not just have to exist between your co-founding team, it should be among your first hires, your advisors, customers and/or friends of the company. The more diverse the team, the more likely you will be to attract new team members from under represented groups. Introduce prospects to these company “community” members to begin to demonstrate your commitment to this metric at the start. For example, I frequently join interview panels for early stage companies I advise to ensure not just a great hire, but to add diversity to the panel itself.
  • Set and hold the diversity bar for leadership hires: Don’t say “it would be really great to fill the next senior role with a diverse candidate”, rather make it mandatory to create a diverse organization. “We will not hire another manager, director, VP, etc. unless they bring diversity into our team.” Get scrappy and go hard to build these teams (see below). Stop looking for just culture fit and homogenous pattern matching and seek those different than you – they are sure to be additive to your organization beyond just their skills and experiences. Yes, it may take longer to find that person, but hold out for it – it’s worth it!

Note to VCs & Board Members

It is great to see so many VCs and board members stepping up to foster diversity in their portfolios. They are committing to invest in more women founded companies, hosting “diversity events”, making the Decency Pledge and some are creating special funds for diverse entrepreneurs. I believe many VCs are sincerely interested in this effort and not just creating PR tactics to position firms to appear supportive. While those efforts are important to further the cause (don’t stop doing them!), I challenge them to set the bar higher; implementing hard accountability metrics for diversity in their firms and in their portfolio companies. To not be complacent in the reality that it’s “hard to find qualified  candidates from underrepresented groups”, but rather force change to happen. Here are a few suggestions:

  • Mandate that your partnership be a diverse team. Studies continue to come out on how diversity in investment teams have stronger exit outcomes. Get scrappy and find ways to build diverse teams for your firms. The more diverse your team, the more likely your firm, will attract a more diverse group of entrepreneurs into your deal flow. And don’t stop at one – keep forging ahead and strive for a more balanced group of partners; a token diversity hire isn’t enough. Also, each partner from an underrepresented group on your team allows for more diversity on your portfolio companies’ boards. While there’s great debate on whether there’s a direct correlation with diversity on boards and company performance, it is a sure thing that diverse boards add new perspective and new ideas to help the organization succeed.
  • Refuse to fund a non-diverse team (!). Yes, you may have to get your LPs to sign off on this, but many LPs are now pressuring the funds they’re in to push harder on the diversity front. So, take the lead, be proactive and tell them you’re holding the bar. Even if it means an initial slow down on deal flow and longer lead times to exit. The data proves that those investments are far likely to pay off in a bigger way than the non-diverse team investments you’re making today.
  • Set your portfolio teams up for success and help find candidates from underrepresented groups for your investments. Extend runway with a bridge loan or other means until the company has had at least six months to try to shore up their team. Make this a priority of your firm. This too is likely to improve deal flow if you offer this type of support to entrepreneurs as many entrepreneurs are not even coming to you because they don’t have the requisite co-founder, never mind a co-founder/founding team that is diverse.
  • Cover the cost to augment teams during the recruiting process. Not only encourage your portfolio companies to bring in consultants/contractors from underrepresented groups as part of their core team until they demonstrate diversity in their teams, but pay for it! Invest in your teams beyond the equity round.
  • Note to Founders: Depending on urgency to raise capital, you might consider refusing to take money from funds that don’t walk the talk – will your board be diverse? Would non-diverse investment group allow you to fill their board seat with an alternate who brings diversity into the board? The more senior candidates you are courting to join your company will examine board composition carefully – especially if your investors play an active role in the day-to-day of your company (It happens more than we think!). How hard are you willing to work to get a diverse board? Also consider creating a seat for an independent board member from day one to be used if needed to round out your team.

Beyond The Leadership Team And Investors

How are you set up to source for and hire diverse teams? Are you looking in all the right places? In 2015, I wrote a whole primer on hiring for startups (much of which is also applicable for later stage companies), but here are some specific tips on getting creative on hiring for diverse teams:

  • Diversity in your interview panel: Most hiring managers these days know it’s ideal to have a diverse interview panel to help sell a candidate on the role and company, but if your team lacks diversity, consider augmenting the interview team with diverse “community” members – either from other teams in your company or by inviting board members, advisors, friends of the company, etc. to participate. More good info on the hiring process for diversity here.
  • Join, sponsor or network with diversity orgs: There are countless non-profit organizations that cater to diversity hiring causes. For example, joining the National Center for Women in Technology’s Entrepreneurial Alliance which is designed for both startups and incubators/accelerators, provides access to job forums, invitations to their events and connections with over 600 other membership companies. Blackengineer.com has a jobs board, as does lgbtconnect.com. There are loooong lists of other organizations you can tap into to support diversity hiring efforts here, here and here.
  • Bring on Diverse Contractors: To me this is a win-win. You can start getting some work done and having diversity in the office can allay concerns when members of underrepresented groups come in to interview. I’ve heard countless stories of a candidate going for an interview and saying “the whole office was dudes or all white” …you get the visual. I’ve also heard many stories of contractors who fall in love with the company they’re working with (and vice versa) and join full time! (and as noted above, maybe you can get your investors to pay for it!).
  • Never miss the opportunity of a passive candidate: So many companies fail to build diverse teams because they wait for applicants vs. seeking out great people. Troll LinkedIn, go to meetups related to your company’s area, hire sourcers to look for great candidates who may not even know they might want a change until they get a call from your company! Don’t wait for these candidates to come to you.

The First Diverse Hire

Once you reach success and start to hire diverse team members, remember, for many of them, they may be the first one – whether it’s at your company as a whole or perhaps just in one team. There can be an ominous feeling when one thinks they’ve been courted or hired as the token diverse candidate/employee. What will you do to ensure that they are set up for success?

  • Acknowledge the problem from the start. The first time you diversify your team, especially for a small company, the individual will know they are bringing diversity to the table. Speaking from experience, it’s fine to call it out, as long as it’s clear that this is not THE reason they are in consideration. Needing a strong technical leader, or someone who has specific domain expertise is the priority, diversity is simply a value add to the team/company…but don’t dwell on it.
  • Consider how you operate today and whether there are any conscious or unconscious biases towards the current homogeneity of your company/team. Are there activities that happen at work or after hours such as fantasy leagues, spa trips or perhaps even non-family friendly activities that keep the first diverse hire from feeling comfortable or the outlier? Does your office decor offend or intimidate? Carefully examine how your company culture, rituals and environment is setup to be as friendly as possible.
  • You’re not done – the first hire that creates diversity in your team should not check a box and then you move on. Keep at it and for God’s sake please do not make that hire the ambassador for all future diversity activities! It is still the hiring manager/leadership team’s responsibility to keep the momentum.
  • Finally, focus on retaining those great hires.

Make diversity a priority. Hold yourself, your team, your investors and your board accountable. Set standards, get scrappy and change things for the better.

This is a war on for diverse teams. Treat it that way.

Reply in the comments if you have other creative suggestions on how to win the war on creating diverse teams.

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!

The CTO to VP Engineering Fork

Posted on by

bfa_code-fork_simple-black_512x512

[This blog was first posted in 2016, updated in 2018 and in 2020]

There comes a time in every scaling tech start-up’s life when an engineering team begins to show signs of needing help. The symptoms can include lost velocity in releasing new products/features, attrition or morale issues, fragile code or lack of innovation. I frequently hear CEOs and founders say “we need a new CTO” or “should we hire a VP of Engineering?”. But what does that really mean? A title is one thing, but the skills necessary to cure the symptoms is a whole other challenge.

Most tech startups have someone serving as CTO — whether it is one of the co-founders or a first senior hire. The role of the CTO is not straightforward and as a company scales, it’s unreasonable for that role to be the end-all-be-all. In the early days of a startup, the CTO is often the chief cook and bottle washer for all things technical. She is coding, serving as the de facto IT person and project manager as well as meeting customers alongside the CEO and helping with hiring decisions. She is expected to be deeply technical and often a domain expert. Firing on all of these cylinders may meet your company’s needs in the short-term, but quite often, there reaches a point where your CTO is no longer being excellent at what they came to your company to do.

In my experience, there tends to be two types of CTOs that evolve as a company grows:

The Evangelist — The shameless promoter of your product, this CTO is out on the road meeting prospects, existing customers and partners and marketing your product. At the same time, they are gathering valuable insight into your product, its pain-points and understanding how it compares to the competition. They are mindful of industry trends and the ecosystem of which your product belongs. They are the ultimate voice of the customer and are keenly aware of the product priorities. They set the vision for the “.next” of your product and the long-term roadmap. They may have once been a coder and understand the basics of your technology architecture. They can go head-to-head with other technology leaders in your space and represent your company at technology conferences. They also tend to be a recruiting magnet for engineering talent.

This CTO works hand-in-hand with the CEO and sales and marketing leads to set the strategy for the company — from market direction to the operations and scale of the business. They are financially savvy and comfortable presenting to and working with your Board of Directors.

The Expert — Often a domain expert or technical guru, this CTO is heads down with your engineering team ensuring your products are built to perform at scale. They may code, sit in code reviews, and mentor junior engineers. They are either designing your underlying architecture or at the very least leading that conversation and signing off on proposed plans. Also talent magnets, they attract senior engineers who wish to learn from this CTO’s experience. They may be key contributors to the open source community, prolific in filing patents, publishing technical papers and speaking at technical and academic conferences. While they enjoy meeting customers and value the insight from those meetings, they prefer more intimate meetings with technical members of customer teams and whiteboard sessions to brainstorm solutions vs. “selling” your products.

This CTO works closely with the sales and support team and often leaves the company strategy and growth discussions to the CEO and other leaders of the organization. They have an opinion on where the company should go, and they’re not afraid to share that, but they leave the details up to “management”.

In both cases above, it’s rare when one of these types of CTOs is also a master at execution. This is when it is important to have a VP of Engineering (VPE). While a VPE can often be someone who can serve as a voice of the customer, be a technical expert and/or represent the company in technical forums, the VPE’s focus is on GSD. Key characteristics of a VP of Engineering that can often differ from a CTO are:

  • Process oriented — highly organized around priorities, velocity, quality and meeting deadlines. They have strong project management and communication skills.
  • Great at hiring — pattern matching skills for not just technical expertise, but for people who are collaborative and mission-driven. Knows how to ID the prima donna engineer from the eager-to-learn engineer and when to say “no” even with a great looking resume. Being additive to the team is paramount to success.
  • Great at growing their team — this isn’t just about about going from 10 to 40 or 100+ engineers. This is about career development. They’ve got a track record for bringing junior engineers into an organization and developing them into technology leaders and domain experts. Their former engineers have followed them from company to company because they are great to work with. They know how to have fun, but also how to appropriately push a team towards meeting a deadline with urgency and not burn them out.
  • Challenges the status-quo — they won’t just keep building what the co-founders started, but will question both the what and the how. They understand the impact that technical debt can have on the long term scalability of your products. They also know how to tune processes without slowing the company with process. They are motivated to deliver products and features that customers not only need, but love. They partner well with their PM colleagues and both respect and appreciate the inputs from outside engineering (sales, support, the CTO…).
  • Not afraid to get their hands dirty — they lead/attend code reviews, can code if there is an emergency, enjoy tinkering with competitors’ products to understand advantages/challenges of your own products, and appreciate the fine art of squashing bugs. They come in early and stay late when there’s a deadline — even if it’s just to make sure engineers are getting food and coffee.
  • Strategic thinker — while a VP of Engineering may not be at the the table deciding the long term strategy of the company, they are part of the discussion. They understand tradeoffs of time-to-market vs. quality and value the need to get a MVP out the door to garner customer feedback early on. They may push for a product, feature or carving out time to catch up on tech-debt, but also respect the larger vision of the roadmap and know when to let go of something that isn’t a priority — in fact, the really good VPE’s kill things sooner than a CTO or CEO may like for the sake of velocity and GSD.

When you’ve decided it’s time to fork that technology leadership role and have both a CTO and a VPE, look for someone eager to create a partnership who prefers to lean into GSD and growing teams and who values the technology leadership, vision and evangelism of your CTO. That person may be a strong leader within your engineering organization or you’ll have to recruit for the position. If recruiting from outside of your company, be leery of career CTOs who seek a role as VPE at your company — they may say they’re willing to be in charge of GSD, but could struggle to partner with your CTO. Look for examples of their past engineering leadership roles as managers or tech leads. Have their former employees followed them to different companies? Also look for measurable achievements like improved velocity rates, quality improvements or hiring/team development metrics. Those are telltale signs that you’ve got a solid VPE candidate.

Sometimes it takes a lot of soul searching for a founding CTO to realize they’re not serving the company well around VPE-types of activities. I’ve seen plenty of CTOs worried that with a VPE on board, they’re not sure what’s next for them at the company. I’ve also seen CTOs excel when partnered with a great VPE where they can set the vision and execution strategy in tandem. Similarly, I have seen companies bring in a great CTO when their current head of engineering is just not ready for or interested in that role (internal or external facing). It can be a great mentoring opportunity for the head of engineering and/or allows them to keep focusing on GSD.

One more thing to consider (added in 2020): Whether they more closely associate with the Evangelist or the Expert, CTOs can also be great leaders of VPs (Engineering, Product, Design, etc.). They can “glue” these teams together to ensure that the vision and execution of products move well together. These CTOs can also serve as bridges to other teams — fostering healthy working relationships with support, sales, marketing, etc.. However, not every CTO is (or wants to be) a great people/team leader, even at a higher and more strategic level. In these situations, VPs may be better served by reporting to CEO or COO. When the organization is designed this way, the CTO would typically report directly to the CEO and could still have a team of individual contributors (architects, scientists, mini-CTOs) report to them if the need/desire arises.

Have you struggled with the CTO to VPE fork? Share your experience in the comments!