Building a High Performance Team
Kenneth Ledeen
Peter Jaffe
Like winning sports teams, great software development teams combine top talent, leadership, culture, and process (the development equivalent of a strategy and game plan). They require close cooperation and teamwork. They are the result of a process of continual improvement and refinement, and, like champion teams, embody the ability to respond dynamically to changing circumstances.
This White Paper addresses what it takes to build such a team, looking at the three main components: People, Process, and Leadership/Culture.
People
First, some general characteristics. They are listed here because they have important implications for finding, landing, and retaining the right people.
Great developers:
● like to work with other great
developers. If someone wants to be the smartest person
in the room, you probably don’t want them on your team.
● tend to be generalists, not specialists. They can work at every level of the application, from the database to the user interface.
● are often technology neutral. They bring a deep conceptual understanding to problems, and recognize that, for the most part, details like which programming language they are going to use, are just details, not the stuff that really matters
● are, without exception, passionate
about software They read about it in their spare time. They are fascinated by new ideas and concepts in software architecture and design. Software is a consuming interest, not a job. They do it for fun.
● experience the development process
itself as a meditative activity. They become engrossed by the work, losing track of time. They get “in the zone.” When deep in development they don’t hear others around them.
● are probably not looking for a job.
For another excellent reference see Michael Lant’s blog at http://michaellant.com/, and, in particular, his article on building high performance teams. (Lant)
The Chicken and Egg Dilemma
It’s very hard to hire your first “great developer.” Great developers like to work with others just like them. That’s why it was so easy for Microsoft in their heyday, or Google and Facebook today to hire the best talent. Money is only one motivator. A really top notch developer doesn’t want to be working in a group of average developers.
For startups, this isn’t a problem. The slate is clean, and often one of the founders is a superstar to begin with: Bill Gates, Mark Zuckerberg, Larry Page are the obvious
examples, but there are hundreds of lesser, but equally as impressive ones among companies that had great development teams but didn’t succeed for other reasons.
What is a larger, established company to do? There are lots of choices, but three stand out as the most effective:
1. Create an elite group within the organization, and treat it accordingly. This may have political and organizational consequences. If you want to have a Delta Force, you will need to be prepared to deal with them and support them.
2. Decide that you are going to upgrade the entire development organization. This is far more problematic than creating an elite team for several reasons. First, as we will discuss later, not everything the organization does should be done by the HPT. Lots of activities are better done by the regular team. Next, by definition, only 10% of developers are in the top 10%. If you have a large group, it may be impossible to turn the whole group over.
3. Outsource the functions that would benefit the most from a High Performance Team.
This is another “make versus buy” decision. It may well be far more cost effective to partner with a organization that can bring in a group, particularly if they are capable of integrating with the internal organization to raise the overall level of excellence.
If you decide to build a team, then, one way or another, you will need to solve the chicken and egg dilemma. You will need to attract the core, the critical mass of top talent. That process will likely involve:
● Involving senior management in the recruiting process. Their role is not to screen candidates, but rather to convince them that this is the place to be. Money isn’t the only motivator for top technical talent. Recognition and a sense of the importance of the role to the organization are both key factors.
● Extraordinary compensation – I’m not talking about 20% above the median, but rather an amount that will get the candidate’s attention. If you think the salary
should be $150,000, you may need to consider paying $250,000.
● In small, private companies, equity can be an incentive. In larger ones, it’s not an option. You might consider, as an alternative, some form of incentive
compensation.
● Other forms of enticement – and some creative thinking.
● Personal referral sources. Your chances of landing the person you want are much greater if they are referred to you by someone both you and they trust.
Solving the chicken and egg problem is critical, and not only because top developers like to work with other top developers. It is also critical because it takes one to know one. You need really talented developers to interview the rest of the members of the team you will be hiring.
Which brings us to:
Recruiting and More
It’s hard to build a High Performance Team. It takes vastly more time and effort, more thought and planning, than most people recognize. You can’t do it quickly, and you can’t do it all at once. It is iterative. It involves finding good people and culling bad ones. There are some useful guidelines, though, to help with the process.
Principle #1 – DO NOT COMPROMISE. You can’t build a great team if you hire someone who isn’t good enough just because you haven’t found someone better, or because you committed to have the team ready by some particular date, or, even worse, because you are afraid that “the req will go away.” There are no exceptions to this rule. Remember, an average person is not actually better than no one at all. They are often net negative. They sap energy.
Which leads to...
Corollary #1 – CULL QUICKLY. If you have any doubt whatsoever about a developer’s ability or performance, don’t hesitate to remove them from the team. In nearly 50 years of working in and managing software teams, we can’t recall a single instance where someone was terminated too soon. And we can recount dozens of stories of situations where managers decided to give someone “one more chance” or perhaps “look for tasks better suited to their skills.” In most cases removing someone from the team means removing them from the organization, but not always. Not every team needs to be an HPT.
Corollary #2 - “A players hire A players. B players hire C players.” Few people want to acknowledge this one, but it is nearly universally true. It often breeds mediocrity in large organizations where managers value loyalty above competence, or seek to have people below them whom they do not see as a threat. By contrast, Bill Gates, Steve Jobs, Scott McNeely, Larry Ellison never hesitated to hire the very best.
Principle #2 – Super Stars are, by definition, extra-ordinary. They are often square pegs in round holes, the kind of people whom HR might screen out early because they don’t quite fit some predefined requirements or characteristics.
Michael Lant describes common job search criteria (Lant):
● Does the person have a degree
● Number of years of work experience
● Number of years experience with a particular tool or language
● Has the candidate built something like this before
● Does everyone on the team give the person the “thumbs up” when they interview the candidate
The principle behind all of these is to avoid homogeneity. Large organizations tend to seek out employees who fit the mold, who reflect the corporate culture. An extreme case was IBM in the 1980’s. It was known as the company where everyone wore dark suits, white shirts, and red ties. Similarity is the adversary of excellence.
Consider Lant’s criteria in this light. Plenty of great developers don’t have college degrees, or perhaps have degrees in fields that are completely unrelated to computer science and software development. Years of work experience really means very little. Someone with 10 years of experience might not have been exposed to nearly as much innovative software as someone with two or three. Great developers, as we noted earlier, are largely technology-neutral, often capable of picking up a new tool or language in a very short period of time. The marginal savings on that learning curve is overwhelmed by their core ability. And so it goes.
A few years ago, a good friend of mine who is a professor of Computer Science was cleaning out his closet and found a printout of a program written by a sophomore student of his about 30 years earlier. It was a remarkably complex and sophisticated program. It was a language interpreter that was running on top of a simulator for a computer than wasn’t yet available. The young student had written the simulator and compiler using one of the university’s computers in a programming language that he hadn’t seen until he had arrived there a year before. Just for fun, my professor friend wrote to his former student and posed a detailed technical question about this piece of software. He received a thorough and thoughtful reply. The programmer, Bill Gates, recalled exactly how he had solved the particular problem. His solution was elegant and effective. He had no years of experience, and no college degree. No previous work with
the particular language and tools, and no domain knowledge. He clearly, though, was a superstar, and it was obvious from the work he was doing at the time. Most HR departments and nearly all recruiters would have screened him out of any applicant pool.
Clarification #1 - People with extraordinary talents and abilities can, sometimes, have difficult personalities as well. While eccentricity is fine, be obnoxious isn’t. The goal is to build a high performance team, and that isn’t not possible if some of the members are too difficult.
Principle #3 – use every personal source you can find.
Principle #4 – You need great programmers to interview great programmers. And they need to devote some serious time and thought to the process.
There are some things, however, that are critical to discern in an interview.
● Does the candidate have a deep understanding of software principles? It’s easy to ask specific language questions, and test for details. It’s MUCH harder to discern if someone can think abstractly, if they understand how to generalize problems, if they really grasp, for example, object oriented programming fundamentals, as contrasted with knowing specifics about a particular language or tool.
● Do they get the “big picture?” Great programmers want to get the entire problem in their head so that they can work through the implications, the interrelations, the challenges and opportunities. Average programmers are perfectly content to work on one aspect or another of a system, to follow established design patterns, or copy existing code without questions why or how it works.
● Can they communicate effectively, both in writing and orally? Communication both within the team and externally is critical to project success.
● Do they like to mentor others? If they don’t like to give advice, then they probably also don’t like to take it.
● Do they work hard? No one will ever say they don’t, so you’ll have to find more ingenious ways to ask the questions.
● Do they need to be the smartest person in the room? This may seem like a strange hiring criterion. One of the dilemmas that we often face in hiring for an HPT is that many of the most desirable candidates were often the smartest / fastest / most talented / most respected developer in most, if not all of their prior positions. Since the key to the overall success of the “team” is its ability to work together, to maximize the effectiveness of their collective skills, prima donnas are not welcome.
Process
Players are only one part of the team. The second critical component is process. Without it, the efforts of the team are uncoordinated, energy is dissipated, and results are at best unpredictable, and at worst, far below optimum. Effective processes are required for every aspect of the
development life cycle including (but not limited to...):
● requirements gathering,
● project estimation,
● framework design,
● object persistence (often a form of Object / Relational Mapping),
● error handling, logging, reporting,
● source control,
● automated unit testing,
● continuous integration,
● requirements management,
● issue tracking, management, and resolution,
● project management.
Each of these is of critical importance. No amount of development skill can compensate for poorly defined or poorly managed requirements. Failure to build a solid framework will undermine productivity as the team expands. Similarly, a failure to build comprehensive unit tests and to include them in a continuous build and integration environment will impede the code refactoring that is essential to refining the application in the later stages of development.
While it is good to have formal tools and processes associated with each of these components, it is even more important for the leaders of the team to have a deep understanding of the what, why, and how so that the team can adapt to different approaches in different environments, without compromising the core principles. For example, it doesn’t matter which issue tracking system is used as long the critical data elements can be captured, and the issue life cycle is supported.
The success or failure of a project is largely determined by the requirements gathering and estimation activities. If the team doesn’t have a clear understanding of what is desired it is highly unlikely that they will deliver on time and on budget. Similarly, if management doesn’t have a realistic understanding of the time and effort required, then failure is inevitable because of the disconnect be expectation and reality.
It is important for management to understand that many of these steps require extra effort in the early stages of the project, but pay substantial rewards as the project evolves, which leads directly to the discussion of leadership.
Leadership / Culture
The third critical component for a high performance team is leadership, and it secondary attribute - culture. The two go hand in hand. It is not possible to have an effective development culture without leadership that supports it.
Leadership in this context combines both technical guidance as well as the more generalized and amorphous characteristics that are required to mold a set of talented individuals into a focused, productive, and “winning” team.
Leadership is what differentiates a winning team from an all-star team. It is what brings the collective effort together and enables everyone individually to perform at a higher level than their personal norm.
Leadership ultimately defines the team dominant culture, and the culture has a tremendous impact on performance.
The key cultural elements are:
● Collegial - everyone is willing to help their colleagues. We can’t overemphasize this one point. Software development involves a continual process of overcoming obtacles, or running up against challenges and finding solutions. It is nearly always the case that two minds are better than one. A collegial, supportive culture means that people don’t get stuck. When they do, they reach out, and the net forward progress is dramatically better.
● Respectful - everyone understands that their colleagues are solid contributors, with differing skills.
● Self critical - we encourage peer review of code, and seek people who bring a very high personal standard of quality.
● Communicative - this one is somewhat contrary to the normal image of programmers working in solitude, hunched over a keyboard, staring a a bunch screens, noise cancelling headphones screening out all distractions. The culture should encourage frequent casual conversation.
