It’s Time to Reset the IT Talent Model

Foster an engineering culture of small teams of high-performance engineers to maximize productivity.

Reading Time: 14 min 

Topics

Buy
Like what you're reading?
Join our community
Member
Free

5 Free Articles per month, $6.95/article thereafter. Free newsletter.

Subscribe
$89 $44/Year

Unlimited digital content, quaterly magazine, free newsletter, entire archive.

Sign me up

How do you identify which talent in your technology teams create the most value for your business?

This question plagues IT leaders and gets at the heart of a conundrum many organizations face today in their quest to transform digitally. All CIOs know they have star engineers on their teams who are more motivated, creative, and productive than their peers. But what sets them apart from solid but middling performers? Most organizations have no reliable way of pinpointing these crucial differences in performance. As a result, leaders struggle to retain stars, reward them fairly, and hire others of equal caliber.

But things don’t have to be that way. A few companies have started to adopt a new model for evaluating talent — one that helps them build the advanced tech capabilities they need in a digital age without inflating costs. In some of these companies we’ve studied, IT leadership has been able to reduce technology costs by as much as 30% while maintaining or improving productivity.

The best companies reshape their IT organizations around small cadres of top-performing engineers to create highly motivated, self-managing, agile teams. The secret lies in first learning how to spot your top talent and then working out how to keep them — namely, by valuing performance over cost, celebrating craftsmanship in coding, and building a culture that nurtures engineering talent.

Establishing a Model to Identify Top Performers

Over the past decade or so, many organizations have pursued an offshoring and outsourcing model to meet their technology needs. That made sense at a time when IT was less complex and large companies could reduce their IT spend by contracting out most of this work to external organizations overseas.

But today, companies are different. Across industries, technology has evolved from a support function to a source of competitive differentiation. At the same time, advances in the way code can be modularized and reused have streamlined the process of creating software. With these recent trends, the balance of advantage has swung back from outsourcing to developing in-house talent.

A few leading companies have recognized this shift and changed course, but many others still struggle with the old model. Their IT departments tend to be well stocked with managers and coordinators but severely lacking in people who can actually write code. In our work with organizations such as global banks and large oil and gas companies, we’ve seen coordinators accounting for as much as 70% of an IT team, and coders just 30%. We think that at a minimum, this ratio should be flipped the other way around.

Creating an IT model fit for the digital age starts with valuing excellence in coding. Unfortunately, traditional methods for evaluating programming competence have failed. Counting lines of code, for example, doesn’t work, because three well-crafted lines from an expert can accomplish more than dozens of lines of sloppy code from a novice. Other assessment approaches measured delivery times, but speed doesn’t equal quality.

However, a few leading companies are pioneering a more reliable approach that bases evaluations on observable behaviors. (See “Assessing Performance in Modern IT Teams.”)

To see how this maturity model plays out in practice, let’s look at six members of a hypothetical IT team in a midsize technology company. David has been with the company for a year, having joined immediately after earning his degree in computer science from an undergraduate program. He thought he knew what programming was all about from coursework, but working as a front-end developer on the mobile app team has taught him the difference between writing a line of code and bringing it to production. David’s observable behavior indicates that he is a novice.

David’s colleague Nadya has been with the company for three years. Nadya works independently, making it clear at the beginning of a sprint that she understands which user stories are expected from her and then delivering them. Unlike David, Nadya doesn’t need constant oversight, but she knows to ask colleagues for help if things get more complex than she can manage. From time to time she attends training classes to further her knowledge of engineering disciplines, and she regularly accesses online tutorials. Nadya is classified as an advanced beginner.

Two other members of the team, Steph and Raj, are regarded — and remunerated — as competent engineers. Steph spent the first part of her career writing code at a fintech company, and Raj was hired after completing a master’s degree in software engineering. Both Steph and Raj head small project teams working on agile sprints and structure team members’ work, coordinate with other teams when necessary, and act as mentors for novices and advanced beginners. They still take part in training but at an advanced level.

Mimi operates at the level of proficient engineer. She actively shares her extraordinary knowledge of functional programming languages by leading training sessions. She is the go-to person in the organization for queries on multiple programming languages, and if applications behave unexpectedly at runtime, it’s Mimi who gets called on to look at the code and find the root cause. She attends leading industry conferences each year and looks forward to the opportunity to network with and learn new skills from other elite professionals in her field.

Jorge was headhunted by the company eight years ago after completing his doctoral thesis on enterprisewide security modeling and analysis, which was subsequently published. He rose rapidly through the maturity framework and is regarded as an expert engineer not only within the company but in the industry as well. The CIO provides Jorge with fresh challenges, high-potential colleagues to guide, and external forums for showcasing his expertise.

Assessing Productivity as a Function of IT Maturity

Once a company has a model in place for assessing the maturity of its engineers, it can start to measure productivity gaps. Researchers at one leading organization found that a single expert is as productive as eight novices.1 In our own experience, we’ve observed productivity multiples as high as 10.

Across industries, companies that we’ve worked with have found that hiring highly skilled engineers can deliver incalculable benefits. Take the example of a bank struggling with a common engineering challenge: As a large enterprise with thousands of servers, how does it allow an individual engineer access to a specific system to execute an approved command? The bank can easily end up juggling so many entitlements, it needs labyrinthine protocols and processes and large teams of people just to manage them all.

We worked with a group of engineers who took a novel approach to this problem. What if they could do away with user access altogether? The engineers pushed so hard to automate deployment processes that they were able to compile code and deploy the resulting application on a fresh server within a few minutes of a fault occurring. This speed allowed them to revoke all user access across all servers. If a system failed, the engineers simply replaced it with a new one. Such a radical step enabled the bank to shift its quality and security controls from user access to the software development phase, where effective peer review and other measures were already hardwired into standard operating procedures.

In recognition of the disproportionate impact of the best engineers, smart companies don’t track the usual metric — cost per full-time employee — when planning their IT strategies and recruiting new hires. Instead, they monitor cost per novice equivalent, calculated by dividing the cost of each team member by his or her productivity.

Developing an Engineer-First Capability

Our work with companies seeking to improve the quality of their tech talent has identified three critical steps: building your organization around the best engineers, unburdening your top people, and creating a culture that nurtures engineering talent.

1. Build your organization around the best engineers you can attract. Better IT performance starts with hiring the best engineers who can create the most value for your company. Counterintuitive though it may seem, finding these people and being prepared to pay more for them is the most cost-effective approach to maximizing IT productivity. To see how, let’s compare three different archetypes adopted by IT organizations. (See “Understanding IT Engineering Productivity: 3 Team Archetypes.”)

Many companies adopt a pyramid-shaped model, like the one illustrated on the left side of the figure, by recruiting mostly novice engineers and supplementing them with numerous advanced beginners, with fewer proficient engineers and experts. With this approach, companies set out to save money by hiring the least expensive talent, but they end up paying a large productivity penalty because the average member of the IT team is only a fraction more productive than an advanced beginner.

In contrast, a world-class tech leader with a reputation as a great place to work will be able to adopt a talent-heavy model (as seen in the middle column of the same figure) by recruiting only experts and proficient engineers to meet its IT needs. Although these top-tier engineers command higher pay, each of them will be as productive as eight novices. That means the IT team needs only 30% of the engineers in the pyramid model to achieve the same productivity output.

Some tech leaders, such as Google, follow a different model and recruit large numbers of graduates straight from college, but that doesn’t mean they have a lot of novices. On the contrary, because they recruit only the best talent available, their new hires start showing the observable behavior of proficient and expert engineers in months rather than years.

Outside the Silicon Valley giants, though, few companies have the reputation and resources to recruit only talent of this caliber. These other organizations need to be realistic about the talent pools available to them in their particular markets and localities. One feasible and sustainable strategy we’ve seen involves focusing on strengthening the cadre of competent engineers, as illustrated by the third team archetype: the diamond model.

In this model, half of the IT workforce is made up of competent engineers, with 20% of them proficient and 10% expert. At lower maturity levels, only 7.5% are novices and 12.5% advanced beginners. The organization in the diamond model has an average productivity level of 4.73 novice equivalents and needs only half as many engineers as the pyramid model to achieve the same output.

2. Unburden your top people. Companies that source most of their IT capabilities offshore or hire legions of inexperienced graduates to reduce costs create a massive burden for their best engineers. The demands of checking and correcting the work of novices and navigating bureaucratic hurdles imposed by managers — such as progress reviews, status updates, requisitions, and the like — leave top engineers little time for what they do best: writing code and problem-solving. As a result, the IT department ends up too large and too costly, yet with poor output.

A story told by the former talent officer at Netflix, Patty McCord, neatly illustrates how this syndrome plays out.2 She went to see one of the company’s best engineers, burdened with a heavy workload after the three staff members he managed were laid off. When she said she hoped to hire help for him soon, she was taken aback by his reply: “There’s no rush — I’m happier now.” Having spent much of his time overseeing his colleagues’ output and fixing their mistakes, he explained, “I’ve learned that I’d rather work by myself than with subpar performers.” McCord concluded that the best thing a company can do for its employees is to hire only “A” players to work alongside them.

For better productivity, better products, and lower costs, set your engineers free so they can work their craft. One bank we worked with had an IT team comprising mainly managers and coordinators; in fact, only 15% of team members could actually write code. After a determined effort to build its engineering capability, the bank boosted the team’s share of coders to 80%.

3. Create a culture that nurtures engineering talent. To attract top engineers and provide them with an environment in which they can do their best work, organizations need to change their culture and rethink the value proposition they offer employees. Companies looking to engage with this issue can take the following first steps:

  • Use great engineers to recruit great engineers. Recruitment is as much about talent finding the right organization as organizations finding the right talent. Top engineers want to work in an inspiring environment with like-minded people who share their commitment to craftsmanship and set high standards. To show potential new hires that your company is the best place to be, get your top performers to talk about their work not only with peers at conferences but also with job applicants during recruitment.
  • Recruit for careers, not roles. To find employees who not only do great work but also stay for years, top companies recruit with an eye toward how new hires will grow over the course of their careers, not just how well they fit today’s vacancies. These companies carve out career paths that enable top engineers to get promoted while continuing to write software so they don’t have to switch to a management role to earn more money and recognition.
  • Recognize that mindsets matter too. Engineers who routinely collaborate with colleagues from multiple functions — and often with customers as well — need a different mindset from engineers who work within smaller IT silos. Instead of moving step by step toward a predetermined goal, these collaborative engineers need to be able to feel their way to solving complex problems. Relevant qualities such as openness to change, skill at handling ambiguity, and readiness to see others’ points of view can be probed through discussions of cases and scenarios in interviews. To ensure that these soft skills are given full weight and that team members’ technical capabilities are complemented with a breadth of outlook, organizations should pursue inclusive hiring policies that foster diversity in IT teams. In talent development, meanwhile, the use of observable behaviors in evaluations helps create a level playing field in which a team member’s gender, race, age, and background have no bearing on his or her progression through the company.
  • Define and reward great performance. Top tech companies set clear and consistent criteria for the skills and behaviors needed to reach the next level of salary and recognition. Not only does this motivate top performers, but it enables average or weaker performers to assess their situation and take steps to improve or find a different path. For mature engineers, for example, great performance entails sharing their knowledge, teaching at in-house IT academies, and mentoring junior colleagues. It also involves maintaining an external profile as a leader in the field by speaking at conferences, writing articles, lecturing at universities, contributing to open-source technologies, and so on — all of which, in turn, helps attract other top talent to the organization.
  • Review performance comprehensively and regularly. Having a well-specified tool for assessing professional maturity allows companies to reward craftsmanship with promotion. In some organizations we know, engineers rank themselves on the scale from novice to expert twice a year. At the same time, their colleagues and managers make similar judgments based on their observations of the individuals’ everyday behavior. The results are amalgamated into one-page summaries that leaders then use to assess each employee’s role within the organization.

Companies have been trying to improve IT productivity for decades, with mostly disappointing results. Although building an engineering culture takes time, the secret to achieving success lies in treating IT engineering as the craft it is and understanding what quality looks like. That means paying for top talent, surrounding great engineers with equally accomplished peers, and creating a culture that rewards excellence.

Topics

References

1. This finding was first reported by researchers studying engineers and computer scientists at AT&T’s Bell Labs. See R. Kelley and J. Caplan, “How Bell Labs Creates Star Performers,” Harvard Business Review 71, no. 4 (July-August 1993): 128-139.

2. P. McCord, “How Netflix Reinvented HR,” Harvard Business Review 92, no. 1, (January-February 2014): 70-76.

i. This classification is based on the Dreyfus model for acquiring, applying, and transferring skills. See S.E. Dreyfus and H.L. Dreyfus, “A Five-Stage Model of the Mental Activities Involved in Directed Skill Acquisition,” University of California, Berkeley Operations Research Center, 1980.

Reprint #:

61329

More Like This

Add a comment

You must to post a comment.

First time here? Sign up for a free account: Comment on articles and get access to many more articles.