Lessons on Building a Great Engineering Team (and Why Rockstar Sales Teams Aren’t All That Different)

With Adam Aarons (SVP of worldwide sales) and Hector Aguilar (VP of engineering) joining the Okta team, I thought I’d reflect on what makes a great engineering team — and how that philosophy also applies to building a rockstar sales team. I’ll get into sales next week, but first here are some thoughts on what makes a high performing engineering team tick that I’ve picked up along the way. There are a few key parts of the puzzle, but none are more important than talent.

Talent

“These are my new shoes. They're good shoes. They won't make you rich like me, they won't make you rebound like me, they definitely won't make you handsome like me. They'll only make you have shoes like me. That's it.” -- Charles Barkley

Like Sir Charles said, it’s all about talent. Without talent, you’re not Charles Barkley – you’re simply wearing his shoes. A great engineering team is built on talent, and talent is found through effective recruiting. You have to know what you’re looking for, set up an interview team that can accurately assess if a candidate has “it” and – just as importantly – move quickly.

Hiring managers need to know what they want in a candidate, and they must be empowered enough to pull the trigger when they find candidates they like. The hiring decision should not have to be unanimous. Everyone on the interview team should have their say and should be heard, but ultimately it is the hiring manager’s decision. Throughout my career, some of my best hires were not unanimously supported in the interview process.

Vying for top candidates is always competitive. The company that moves fastest often wins.

Management

"My main job was developing talent. I was a gardener providing water and other nourishment to our top people. Of course, I had to pull out some weeds, too." -- Jack Welch

Talent’s massively important, but so is management of that talent. Ultimately, happy employees are those who feel challenged, noticed and believe they are truly making a difference. They want a chance to learn and grow.

Here are a few quick things to consider when thinking about effective management:

When it comes to assigning people to products and projects, I've seen one end of the spectrum where people are treated as completely fungible. They are moved from product to product, release after release, according to priority. At the other end of the spectrum, people are assigned to products permanently and rarely move. I believe the permanent model is more effective. People build expertise and a strong sense of ownership for their area, leading to higher motivation and better output.

I’ve also found that a dual track approach, one for management-minded folks and one for technical contributors, works well. This approach allows both top management and top technical talent to grow and receive fair compensation for their contributions. (Of course, both tracks must be equal; the top of the technical track should earn the same and have the same influence in the organization as the top of the management track.) Both tracks are essential, especially in high tech where the company’s success or failure rests on its ability to innovate.

Another important component of effective management is feedback. Frankly, a once-a-year employee review is just too infrequent to be effective. Managers tend to overemphasize the last two or three months worth of work and ignore the 10 months prior. Strong performers will value this feedback and be motivated by the discussion about what it will take for them to advance. Any poor performers will also benefit from frank, frequent feedback.

Roadmap

"We don't have much in the way of a business strategy. Like no business plan, which I say to torment all my friends who are VCs or MBAs. That's always entertaining. The deal is, it's a mixture of luck and persistence." – Craig Newmark

Know where your product and technology are headed — and how you’re going to get there. It’s not some grandiose “strategy” or “boil-the-ocean” architectural vision – just a high level list of what you need to accomplish in your product and underlying technology. Write it down and share it with the company. A 12-month horizon is reasonable. It won’t be perfect and will change often, but the value of the discussion this creates is invaluable. This helps spread the understanding of internal infrastructure work that isn’t apparent as a product feature. When the inevitable trade off between product features and infrastructure work arises, the business and product teams will have a better understanding of what is required to “keep the lights on.”

Execute

"An idea isn't worth that much. It's the execution of the idea that has value." -- Joel Spolsky

Execute (or Always Be Closing, for those in sales). Hire your dream team, motivate them, know where you’re headed and then make stuff happen. The most important principles of execution are: iteration, bottom-up empowerment and open communication. Master these, and execution will follow.

Iteration is dividing software development into intervals. The intervals should be long enough to complete a reasonable feature or component. At the end of each iteration, the team should have complete, working and tested software for the feature or component they chose to develop. The end of an iteration allows everyone to see that the product is progressing, including all the underlying work required (testing, performance work, etc.).

Openly communicate the results of an iteration. The more people know about what is going on, the better.

Follow the following simple guidelines when deciding on iteration length. Longer than a month is too long. Less than a week is too short. Actual mileage may very depending on the product and market.

Bottom-up empowerment comes from deferring to the individuals on the team and trusting them to come up with a solid plan for each iteration. It’s critical that the team sign up for the work, as opposed to management telling them what to complete. This personal commitment to get the work done is strongly motivating. People work harder when they freely choose to commit to something vs. being assigned a task.

Sound architecture

"With good architecture, debugging is a breeze because bugs will be where they should be." -- David May

Software architecture is how your code is organized and factored, how the modules fit together and interact. Just like you need 12-month roadmap for product areas and infrastructure, you need a 12-month roadmap for the software architecture.

Since software architecture inherently crosses all engineering groups, the team that owns and manages it shouldn't be a specific team on the organizational chart, but rather a virtual team made up of members from all groups in the engineering organization.

This team has three main responsibilities. First, they must define the software architecture roadmap, which consists of a list of important modules to build, and a list of the “technical debt” — or code that needs to be refactored or reimplemented. Writing down this roadmap forces the team to think about what needs to be done and holds them accountable to making progress. It also is a powerful signal to the entire team that the organization recognizes the technical debt they see every day and is willing to do something about it.

The second responsibility is to define technical standards. These may be coding, design or technology standards.

Finally, the team should provide technical design review and guidance for all significant development work. The architecture team is made up of the top people with the most experience and insight. They need to help make sure all projects are done in an architecturally sound way. They need to help drive the particularly large projects that will cross several different product teams.

Test. Test. Test.

"A good threat is worth a thousand tests." -- Boris Beizer

It’s critically important to invest in automated testing. Good automated testing allows an engineering organization to move fast while still producing a high quality product. Poor automation slows you down and reduces quality. Challenging your team to write automated tests while they develop produces better designs because the team members think through all possible usage scenarios in advance. It is impossible to have short, high quality iterations without good automated testing.

Performance analysis

"There exists no ‘improve performance’ check box." -- Anonymous

Designing and implementing high performance and scalable systems is the responsibility of every engineer and team. Teams need to have the environments and tools to test code at scale and analyze the results. It’s best to form a dedicated team to this function because of the specialized skills and knowledge around performance and load testing. Members of this team should be experts at how to generate load and identify real issues among the inevitable noise in the results.

There may be resistance to this approach. The fear is that if you make a "performance team," you send a message that nobody else needs to worry about performance. There may be some validity to this fear, but engineers know performance is important and won’t focus on it less if there’s a dedicated team overseeing all quality analysis.

… and there you have it, the essential elements of a highly performing engineering team. As I mentioned earlier in the post, I’ve come to realize that the best sales teams have more in common with great engineering teams than one might think. I’ll post more on that next week.