How we’re building a world-class engineering team to create cutting-edge products

Table of contents

• What great engineering teams do

• How to build and scale a world-class engineering team

• Part 1: maximizing your mass

• Part 2: maximizing velocity

• Hiring the right people

What great engineering teams do

Agile engineering teams understand how their work fits into the larger company strategy. They make data-driven decisions, ruthlessly prioritizing their work (and reprioritizing when necessary) based on what will deliver the greatest return for the company.

Their focus is laser-sharp, and they consistently communicate the business case for each project so the rest of the company understands why those priorities matter.

What does a VP of Engineering do

A VP of Engineering offers leadership and support to the engineering team and helps maximize their growth, impact, contribution to the business, and overall happiness.

What this actually looks like on a daily basis for me at Hotjar:

• Working on attracting, retaining, and growing top talent

• Aligning tech strategy with the overall company strategy

• Organizational design and capacity planning

• Collecting and sharing context so the rest of the company understands the business case behind every project

How to build and scale a world-class engineering team

Before joining Hotjar, I was managing a team of about 160 people as their VP of Engineering and Product. In my experience, the key to the success of a team and a company as a whole is one: building momentum. In many cases, when a team seems to lack urgency, the root cause is not laziness or apathy—it’s an absence of momentum.

The importance of building momentum—and how to do it

When a team experiences a win, it sparks motivation, which produces additional wins. Winning has a snowball effect, where the more you win, the more you keep winning.

Amazon's ‘growth flywheel’ demonstrates this snowball effect. When an online reseller like Amazon gets quality sellers, they’re better able to serve customers. When customers are happy, they buy more products, which attracts more quality sellers. As the business grows, sellers compete by providing lower-priced products, which further improves the customer experience. Growth breeds growth, momentum breeds momentum:

Of course, the opposite is true as well. When you’re facing the headwinds of negative momentum, it can pull your team into a downward spiral. That’s why leaders have to keep spirits high and seek out wins whenever possible—to guard against negative momentum and profit from a positive one.

So how do you build momentum? In physics, Momentum is defined as Velocity multiplied by Mass, so if you want to optimize for momentum, you have to increase velocity. In software engineering, the best way to boost momentum is to achieve quick (high-velocity) wins in areas that have the greatest impact (mass).

THE IDEA OF USING THE PHYSICS FORMULA TO ALSO DESCRIBE TEAM MOMENTUM COMES FROM RICHARD LENNOX

Part 1: maximizing your mass

Maximizing mass is all about impact—on your products, your customers, and your bottom line. As such, you must ruthlessly prioritize (and frequently re-prioritize) your projects to ensure you’re achieving the greatest return on your efforts.

What does that mean? To be successful, engineering teams (as well as product development teams, technology teams, etc.: the logic always applies) must:

• Make data-driven decisions, where they value analytical rigor over hunches, ego, and personal opinion

• Develop a business case for every initiative they work on, regularly communicating the rationale behind each project

• Maintain focus and resist the temptation to do too many things at the same time

• Be agile and adaptable, responding quickly to changing market conditions

Talent (like time) is a limited resource, so it must be directed in a way that maximizes results. This entails laser-sharp focus, with everyone striving daily to optimize impact.

If you want a world-class engineering team, you cannot compromise on that.

Part 2: maximizing velocity

For an engineering team at a startup, responding quickly and efficiently to market demands is one of your most powerful assets. When you’re going up against established competitors with enormous budgets, flexibility is one of your main your competitive advantages. This principle is illustrated by three pillars:

1. High-velocity decision making

The ‘high-velocity decision-making’ approach (as championed by Amazon CEO Jeff Bezos in one of his annual letters to shareholders) helps decision-makers do what the term literally implies: make impactful decisions, fast. When done right, this model helps build momentum and drive success.

Here are its four basic principles:

Principle #1: most decisions can be made (and reversed) quickly

Some decisions are highly consequential and irreversible. These ‘one-way doors’ represent decisions you have to get right the first time, so they shouldn't be taken lightly.

Most decisions, however, are ‘two-way doors’ that can be reversed with very little effort, which makes them excellent candidates for high-velocity decision making. They have light-weight processes associated with them, and you can measure success or failure quickly. Then you can reverse the decision if it doesn’t produce results, so there’s no harm in making decisions quickly when you reach a two-way door.

Principle #2: don’t confuse buy-in with decision-making by committee

Decision-making by committee is costly and ineffective. Instead of having the 75 people in the company make the decision by consensus, teams need to trust that a group of people has the best interest of the company in mind.

Of course, you should do what you need to do to get the buy-in from other people on the team and gather feedback from different departments; in the end, you need to empower teams to make the final decision on their own when it comes to reversible decisions.

Principle #3: make decisions with 70% of the information you need

It’s tempting to wait for near-certainty, but it’s also costly. If you wait until you’re 90% certain before taking action, then you’re moving too slowly for the high-velocity model. Instead, learn to make decisions with 70% of the data you wish you had.

Principle #4: become good at course correction

When you adopt this model, you have to be good at quickly recognizing and correcting bad decisions. If you’re good at course correction, then being wrong will be less expensive than being slow.

2. Shipping fast and learning quickly

Shipping fast and learning quickly is the second necessary pillar for improving velocity and boosting momentum. As Marty Cagan discusses extensively in his book Inspired, there are two inconvenient truths about products:

1. Roughly half of the initiatives you launch will not have the impact you’re expecting them to have on the business. In fact, good teams plan for 75% of their ideas not working.

2. Ideas that actually work will typically require multiple iterations until they get the business impact you expect. As such, those quick, efficient iterations are, in many cases, more important than the absolute quality of any single iteration.

Here’s a way to visualize this principle at work:

The peaks in this graph represent successes, and the dips represent failures. You’ll notice that the red curve (a high-velocity team) has four times as many peaks as the blue curve (a low-velocity team).

The red team also has four times as many failures—but that’s a good thing because that’s four times as many learning opportunities. In other words: the red team has more opportunities to validate their assumptions within the same time frame, which gives them a huge competitive edge over the slow, laborious blue team.

Note: of course, we have to be careful not to confuse high-velocity decision making with compromising quality for speed. There’s a difference between discovery work and delivery work, and it’s important to know when to optimize for quality and when to optimize for speed.

3. Improving the efficiency of execution

Improving execution efficiency is the third pillar of the high-velocity decision-making model. Standardizing the following procedures will improve efficiency:

• Quick flagging and removal of blockers

• Smart Minimum Viable Products (MVPs): 80% of the value comes from 20% of the effort, so focus on the features that offer the highest return

• Optimizing the use of group time (meetings culture, means of communication, push/pull updates) and using other means of collaboration when they’re more efficient

• Improving the software delivery process: technology, infrastructure, and tooling

• Encouraging a ‘disagree and commit’ attitude. In other words, no final decision should be reached because somebody has been exhausted into submission; a better way forward is to disagree and commit, so the team can move forward and quickly escalate if it’s needed.

Hiring the right people

This should be obvious, but in order to build momentum and accomplish everything I’ve laid out above, you have got to hire the right people. The best processes in the world won’t work unless you have a team that is open to giving them a try.

So, what should you look for when hiring software engineers? Here are five traits I look for in everyone who joins the Hotjar team:

• Open-minded team players: someone might be a brilliant engineer, but if they’re too rigid to explore a new way of doing things, they may end up being our weakest link and slowing the team down

• Skills that exceed ours: we all have our strengths and weaknesses, and a good team is composed of people whose knowledge and intellect complement one another

• Strong communication skills: sometimes we underestimate the value of solid communication skills when it comes to engineers. We don’t have to be the next William Shakespeare, but if we can’t communicate our ideas to others within (and outside) our department, it will definitely create barriers to success.

• Low ego with high self-esteem: this may seem contradictory until you dig a little deeper. Think about the most confident people you’ve worked with—more often than not, they’re willing to admit when they are wrong because their self-worth doesn’t depend on being right all the time.

• Ruthless prioritization and pragmatism: pragmatic problem-solvers understand and embrace the fact that software is never done nor perfect, and can deliver clean code & architecture while staying focused on solving business problems and delivering value.

A final note: share your knowledge and join our team

If you have experience building a world-class engineering team or are part of one, I’d like to hear more about the qualities you select for, your management philosophy, and what successes you achieved as a result.

In the meantime, let me remind you that we’re constantly on the lookout for great talent at Hotjar. We’re on a mission to build the leading platform for user feedback & behavior analytics, and we’re hiring for positions across the product and engineering teams. Join us!