Are You Being Strategic About Hiring?

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 Three P’s: Lenses to Assess Your Startup’s Performance

I took a bit of a sabbatical this summer and now, refreshed and with a few new topics brewing, it’s time to get back to writing!

LunettesA recurring theme I’ve encountered this summer is which lenses you should apply when evaluating the performance of your growing organization. As an advisor and executive coach to early stage companies, I’m finding more often I am preaching the concept of the “Three P’s: People, Processes and Programs”. Looking at your company or department through each of these lenses and asking yourself how you’re doing in each area can be very telling. It helps you understand where you may need to improve to continue to scale and reach success.

Lens #1 – People

The best leaders of any organization know that their people are what makes or breaks the success of their company. This isn’t just about performance and productivity metrics of each member or as a team, this is about people being in the right roles, having the right training, career path and great peers, bosses and teams to work with. When you ask yourself “are my employees happy?”, consider if you are doing everything you can to ensure greatness. This is well beyond great pay and company perks or weekly beer bashes. Most people want to feel challenged in their roles, but also supported and set up for success. They want equally smart (or often smarter) people to work with and they want to see you get rid of people who don’t work as hard as they do or who are jerks.

Great employees want to work towards growth either as an individual contributor or as a leader. They want to know that they will be rewarded for making solid contributions and for being team players. Growth should not always come from taking on more responsibility or more people to manage. Growth can also come from broadening their knowledge through exposure to new things such as customer visits, interactions with your board, or maybe going to a conference or speaking on a panel with other domain experts. When an employee is not growing or rising to a new challenge, ask yourself if this is a limitation of the individual, or is the system limiting them? Do they need mentorship from someone who’s been in their shoes before to guide them to the next level? Are you micromanaging, thus not giving them a chance to step up and show what they can do?

Happy employees also feel like they have visibility into the vision and direction of the company. They don’t need to know every detail of a product roadmap or the revenue strategy, but they want to understand where the company is headed and how leaders of the organization are measuring success. As a leader of an organization, do you have weekly or monthly all-hands and/or quarterly reviews that include vision and strategy? Do you routinely communicate through company email or on-line forums (e.g., Slack) on big company news like closing a big deal or a great new hire and include why these are important? The more understanding each employee has about the big picture, the more they can calibrate their actions and contribute towards success.

This first lens – evaluating if you are setting up an environment for happy, growing and informed employees – is probably the most important thing you can do to set your company up for long term success.

Lens #2 – Processes

As much as any startup loves being small, nimble and usually pretty organizationally flat, the reality is that implementing processes can be useful. I’m not talking about three ring binders full of protocols and standards. I’m just saying that having a general process for key parts of the business is important. There was probably a time (or maybe your company is there now) where everyone sat around one table and could just talk through how to get something done. Then, all of a sudden, one table becomes a few desks, maybe a few remote employees and a field sales person or two and what used to be a simple chat becomes harder to navigate.

ProcessConsider what processes are in place today that grew organically vs. with intention. If the organic processes work, that’s cool, but keep an eye on them because over time they may not scale. For those set up with intention – e.g., a hiring process or maybe your weekly sprints – reevaluate them on a regular basis. Are they repeatable and do they scale with more people in the company or more bugs to fix? Resist the temptation to keep a process because “that’s how we’ve always done it” or because “our Founder set it up, so how can we kill it?”. Companies that evolve have processes that evolve and what once worked then, may not work now.

Think about how decisions are made, information is disseminated and loops are closed for critical processes first. The most common areas where processes comes more and more into play tend to be product roadmap and execution plans, hiring strategies and go to market strategies. Here are some suggestions for each:

Product Roadmaps

  • Consider monthly, three-months-out roadmap reviews to prioritize new products, major features and release plans. Do not lose sight of the fact that this is not just which designers or engineers are building what, but also how you’ll market and support these products and features.
  • You may have weekly reviews to ensure you’re tracking to the meta-plan and make adjustments if needed. Have some sort of process in place to deal with surprises like a critical bug that bumps a feature or a customer opportunity that may change the priority of a future feature. Set criteria that justifies this type of change so you don’t have to analyze each one on the fly. For a critical bug to bump a priority feature, it might be something like “must impact >50% of our customers or degrade performance more than “20%”. For a customer opportunity it could be “must be a deal worth >$(?) revenue or a customer that will provide undeniable street cred for >50% of our current prospects”.
  • If/when the roadmap changes, have a process for letting people know. Don’t just update Trello and assume everyone will see it – have some sort of change management message that goes out via email/slack that tells the team what and why.
  • It also doesn’t hurt to have a process to track changes to the roadmap so you can see the impact on your initial plan over time. This will contribute to better planning going forward.

Hiring

  • I highly recommend a quarterly hiring plan – not just how many new heads, but actual roles you intend to fill. Given today’s climate where hiring is SO hard, it could take 2-3 months to get that right candidate. So have a process in place to assess where you are with hiring and what new roles you need to ramp on filling.
  • Get in the habit of a regular job description (JD) writing process. Don’t always wait for a role to open up. If people are in the role now, have them write their own job descriptions. This not only helps when it comes to review or promotion time, but you then have these JDs on file if/when needed. I’ve seen major delays with filling a pipeline with good candidates or terribly inefficient candidate interviews simply because no JD exists.
  • Have a hiring process in place that starts with the JD and ends with the on-boarding of this new hire. I’ll write a future post on this with more details, but the short story is that it should include how you’ll post and market the opening, handle phone screens, on-site interviews, making an offer, negotiating terms and how you’ll get that new hire on board and productive as fast as possible.

Go to Market

  • It’s one thing to have a product roadmap that outlines what you’ll build, but it’s another to say how you’ll get those things out there. With every product roadmap, there should be a parallel process for laying out how and when new products/features are publicized, priced (if applicable) and sold.
  • Have a process for content updates such as your website, marketing materials, and demos.
  • What process will you have for telling the world about your new stuff? Do you have a regular list of press or industry bloggers who write about your company or trends in your market? When should they hear about your new product/feature and what’s your plan to share what they write through social media or other channels?  How do your current customers and/or prospects hear about the latest new thing? These are not afterthoughts once the engineering is done, they are just as important processes to get in place as your code check-ins and testing procedures (which you have already, right?).

Looking through the lens of processes and seeing what you have and don’t have in place should tell you whether your company will be able to scale or is heading for a train wreck. Don’t be afraid to pause when you see a gap where a light process could relieve a bottle neck or better prepare your team for future scaling challenges.

Lens #3 – Programs

The Program lens is not used as often as it should. Granted, as a former Program Manager in a past life, I’m a little biased. However, what I often see missing in growing organizations is someone looking across the organization, programmatically, to ensure all the pieces are coming together including people, schedules and money.

A great example of this is the processes I mentioned above around new products or major feature releases. These are often multi-pronged activities involving engineering, sales, support, marketing and maybe finance and operations. You may have program_managerheads of each of these groups, but who is overseeing how they all work towards a common goal or launch date? For many small companies, that’s the CEO or CPO, but (oh by the way), these same people are running your company or out in the field selling or closing your next round of funding.

In the early stage, you may consider rotating the role of Program Manager between different leaders in your organization. Keep in mind, though, not everyone has the knack for project plans and cross-company communication. Make sure you pick the right people to be in this role.  As your organization grows, consider hiring an actual Program Manager. A Program Manager is often one of the unsung heroes of a company because they are in the background instead of on the front lines. They quietly prod and check things off lists. They communicate what’s happening and where there are possible gotchas. Program Managers beat the drum so everyone is marching in the right direction and at the right pace. They are masters in GSD (Getting Sh-t Done) with no task too small or ask too big.

So, don’t just look through the process lens, but also ask yourself what programs are cutting across more than one part of your company and who is orchestrating them. You’d be amazed how productive and efficient your startup will be when programs are well managed.

In Summary….

Startups, when they’re working, develop very quickly – often without enough attention given to people, processes and programs. It’s one thing for an Advisor or Investor to tell you what your company or department is lacking or how you could be doing better, but in the end, you need to ask yourself how YOU think it’s going. Applying these three lenses should help bring things into focus [pun intended].

Have you been using any of these lenses to assess performance or have different lenses that you’ve found effective?  Please share in the comments below!