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

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

bfa_code-fork_simple-black_512x512There 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”.

The VP of Engineering

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 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. Team fit is paramount to success.
  • Great at growing their team — this isn’t about going from 10 to 40 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 overkilling the company with process. They are motivated to deliver products and features that customers not only need, but love.
  • 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 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 fate 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 or feature, 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. Someone who prefers to lean into GSD and growing teams and who values the technology leadership, vision and evangelism of your CTO. 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 easily step on your CTOs toes. Look for examples of past engineering leadership roles as managers or tech leads. 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. Fortunately, I am lucky to have such a VPE on board here @DigitalOcean — as well as two awesome Engineering Directors with whom we partner to drive our technology roadmap.

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