Building the right digital team

An emerging skill for executives in the “software is eating the world” era is knowing how to build and manage teams. Like most things in digital, there are no universal solutions. If there was one, best, way to do things, everybody would be doing it and we would no longer be competing on digital readiness. If there was a known solution, companies like Hertz wouldn’t be paying/losing $32 million to consultants on presumably straightforward projects.

Companies that aren’t digital at their core, or whose growth years preceded the various internet booms, have real challenges in building their digital teams:

• staff it in-house or source it?
• freelance talent or services firm/vendor?
• which vendor?
• off-shore, near-shore, on-shore?
• what skills am I actually hiring – development, back-end, front-end, systems, integration, updating, building from scratch?

It’s hard enough to build a simple in-house team or pick a single firm to do the work for you. Most companies, however, have to do a little bit of everything: leverage/build an internal team, get some outside firms to help, plan for temporary individual help. All the while, they have to make choices about platforms, environments, development tracking tools, and processes for writing and deploying coded designs.

A new study, based on suggests that “Hero” teams are likely the most efficient and reliable teams. For the purposes of their study, a “‘hero’ project is one where 80% or more of the contributions come from 20% of developers.” A hero is defined as those that “participate in 80% of the discussions prior to the commits”. That’s worth emphasizing, they aren’t writing 80% of the lines of code, but they are shaping the work behind the code (think mentors, code reviews, architecture, style guides, managerial direction about the approach to the work).

This dovetails with a quote from the minor gospels of Steve Jobs:

“I noticed that the dynamic range between what an average person could accomplish and what the best person could accomplish was 50 or 100 to 1. Given that, you’re well advised to go after the cream of the cream … A small team of A+ players can run circles around a giant team of B and C players.”

The study goes deeper, though, and points to measurable ways in which ‘hero teams’ pay off:

1. Fewer bugs per team
2. Faster times to identifying the source of the bugs
3. Faster times to solving the bugs

These bullets dovetail nicely with yet another Pareto-driven rule of thumb: software teams spend 20% of their time writing the original code and 80% of their time making it work right.

Disclaimer: the findings are specific to 1,100 open source projects. It’s unclear whether this slightly strengthens or slightly weakens the insights for enterprise software work. But I do think unpacking the dynamics uncovered in this study, highlight problems in the enterprise software world. Please continue.

Despite having a history in the literature, the hero moniker is unfortunate (borderline clickbait-y). Heroism is dangerous language to give managers. It connotes extraordinary efforts from people with ungodly talent, while suggest that all managers simply need to motivate (yell at) teams or fire mortals and hire heroes. (Seriously, in this age of tl;dr headline-only reading, you just know that someone is going to a meeting and talking about hero strategies.) What hero teams really describes are small teams of highly skilled and highly experienced programmers.

Skill and experience are part of the hero team and both must be accounted for in a successful enterprise team. I’ve worked with young geniuses (high skill, no experience) whose intellectual charisma has led teams to unfounded optimism about delivery, only to discover that the genius/hero hasn’t had enough cycles to anticipate problems or time sucks that an experienced programmer would catch. I’ve also worked small teams of less- or differently-skilled programmers who are working heroic hours, but are doing too many things for the first time. Their estimates are always optimistic (and subject to unrealistic change from demanding managers who say “c’mon, can’t you go faster?”). Too many of their tasks are first-time efforts resulting in long hours, delays, bugs, and cut and paste code from stackoverflow.

So, I’ll say it again, the best results come from small teams of seasoned and skilled developers.

The problem for many companies is that they can’t always control the size of the teams, and they can’t always control or correctly assess the skills of the individuals on the team.

On the size front, many enterprises are structurally committed to large and complicated teams, made up of a mix of the following:

• corporate IT – the owners of the infrastructure, enterprise licenses, and security policies and practices. None of them likely does actual development work, but they configure environments, write or provide integration components, and often control deployment pipelines and protocols.
• internal development teams – most large corporations have multiple groups who are developing code, who have primary responsibilities for their group and secondary ones to support others. Often, these teams will spend most of their years maintaining and doing minor tweaks to the product and the underlying code. They are maintenance and update developers who rarely develop new code, innovate or engage in contemporary practices. Every couple of quarters or years, they will be pressed into service to develop things from scratch or engage in serious re-engineering of the work. These tasks may not be things in which they are skilled or experienced, but budgetary pressures, along with fears of being asked “shoulnd’t you be able to do that? Isn’t it all just writing code?” may push people to dangerously over-reach.
• enterprise providers’ ecosystems – if the firm has an enterprise license, they more than likely have a vendor, recommended by the software maker (and sometimes a pitch partner when buying the license), who specializes in that work. A worry here, though, is that “specializing” often means optimizing – making the work as routine, low-skilled, and low-cost as possible. Because of profit-sharing, the non-transferable skills of working in a platform, and the normal pursuit of margins, these teams are always good at routine problem-solving, but are quickly outside of their skill and experience range when they work with a larger team on bigger projects.
• freelance developers and designers – in the age of open-source enterprise deployments and when people learn their trade on low-cost open-source tools, this is a tragically under-utilized talent pool, but managing individual developers on a gig basis requires a particular set of skills on the client side. Nonetheless, enterprise project leaders increasingly need to work with freelance designers and developers to find the expertise they need within their budget.

This complex mix of talent makes it hard to create ‘hero teams’, but there are still valuable lessons to learn from the insights in the study. In general, diversity of sources of talent, unlike say diversity in sources of income, creates, rather than reduces, risk. Part of the underlying success of hero teams is that there are fewer people who can be responsible for defects/bugs that arise, and fewer dependencies in solving them. In addition to the sheer number of developers you have to navigate in an enterprise team, you also have intermediaries (project managers, account leads, bosses) and wildly differing incentives (eg, “you’re only paying me $5,000 out of your $1 million project, I can’t get to this until . . . “).

This is a problem that’s hard to solve once you have your team, but it’s one that can be avoided when the team is being put together. Too often, there is a false economy created by procurement and finance who, rightfully but harmfully, are only able to look at the dollars. Externally, chunking out the work to the cheapest firms looks more attractive than going with a single firm who is more expensive overall. Internally, pushing the people you’re already paying too far outside of your comfort zone looks good on the spreadsheet, but plays poorly when you incur the costs of delay or, worse, paying someone on the outside to find and fix your problems.

There aren’t easy answers, though many people have rules of thumb to guide them. Part of the point of the study is to debunk a long-standing rule of thumb that broad teams minimize risk by avoiding bottlenecks and reducing critical points of failure. Building teams a skill that needs to be learned and a place where solutions have to be crafted with thought and input from multiple perspectives. Strict adherence to a favored management book or a single driving KPIs will most likely get you the wrong team.

As noted above, this study has been cited as a rejection of old ideas in favor of new ones. I’ve certainly written this post that could be perceived that way. But that’s the wrong message. The study should highlight a couple key ideas that should be factored into how you build your team the next time whether you are able to build a true hero team or not:

1. Senior, more expensive, talent is often worth it. You pay a higher amount up front, but you increase your chances of launching on time and on budget. Problems that do emerge are easier to identify and fix. The work product, in this case code, is generally cleaner, easier to read, and therefore easier for your internal team and future members to work with.
2. Size matters – spreading out a project across cheaper resources can, contrary to the literature, introduce more risk through increased points of failure in the code, communication, and integration. Every step you take past a small group of people in a room working at a common task allows for more problems (and conflicting incentives) to come into play.

“Hero teams” is a useful idea if you take away the real defining characteristics of them: the team is small, and its members are highly skilled, and have deep experience. And if they love their craft (ie, if they have integrity), they’ll be easier to manage.