Uncharted Waters

Feb 15 2016   5:13PM GMT

Generalists or Specialists? Why not both!

Matt Heusser Matt Heusser Profile: Matt Heusser


Model T Ford Assembly LineThe history of late 19th to middle 20th-century business is one of consolidation; companies bought other companies to expand. Paul Graham called the new emergent companies Duplo companies because they dominate an industry and act as building blocks for the economy.  A hundred years before the outsourcing fad, National Biscuit, American Steel, Standard Oil, and AT&T did everything themselves.

The extreme end of this was Henry Ford’s Rouge River Plant, which was designed to literally take iron ore in at one end and send assembled automobiles out of the other. Built between 1917 and 1928, the factory employed over 100,000 workers at its peak, and it seemed like the future.

Today, a great deal of design and manufacturing happens in a long supply chain, whose products the car companies ultimately assemble and sell. The reason car companies operate this way is that they think it works better. Each company in the supply chain focuses on what they know best. The have to; if the suppliers can’t compete, they’ll either be replaced or go out of business.

Now let’s talk about technology projects and specializing roles.

The Big Tradeoff

Matthew Stewart, the Philosophy Ph.D. turned management consultant, claims that there are only two kinds of management advice – one group wants to reduce running a company to a spreadsheet, while the other makes the argument “these are people!”

Similarly, there tend to be two kinds of advice for running an IT organization – Either specialize or have everyone a member of the technical staff. The first argument is that “it works better”; each person focuses on what they know best. The second argument, of course, is that “it works better”, eliminating handoffs, delays and waiting.

In our lean software delivery course, we run a simulation that models an organization with a lot of hand-offs, using a sample company that has balanced capacity (a tough enough feat) in the long-term, but high variation. We use a six-sided die to predict performance, which means that specialists average 3.5 widgets a day, but on any day, could produce anything from one to six pieces of finished work. It’s a simple simulation, but the math is clear – because of the variation, bottlenecks will emerge. The more workstations (handoffs) you have, the more bottlenecks you get, and performance goes down. It’s an imperfect simulation in a lot of ways, and doesn’t account for things like multitasking, delays, or the cost of rework, but the point is clear – score one for the generalists.

If the math is clear, why is everyone trying to hire a ninja rock star purple squirrel full stack developer/administrator, yet no one seems to be able to find them?

Rock Star Ninja

Source: Actual Indeed.com job posting, today.

Too Many Disciplines

Consider the front and back-end, graphic design, database administration, and web server administration, continuous integration/builds, plus testing and customer service – that’s eight disciplines. Perhaps, for the right ninja rock star, we might let a little poor customer service slide.   Even with only seven, try splitting your professional development hours among all seven roles, and you’ll find you can’t keep up … or at least, can’t have a meaningful life outside of work.

Yet there are a few companies (Pillar, LeanDog, and AtomicObject come to mind) that seem to routinely take true apprentices and transform them into extremely strong technical generalists, and do it quickly – on the order of two to four years from technical newbie to recognized “name” coach, assuming the person wants to be a public coach. How do they do it?

The Not So Secret

Most companies assume a person has 100% of what they need to solve a problem. For the specialist, they might be close – they might have 90%. The generalist won’t; they might only have 70%. The difference is pairing. Two people, even two generalists, are more likely to have the skills needed for the task, and more likely to be able to figure it out. Working together, they learn from each other directly. No brown-bag. No code review. Instead, “watch this.”

What I see today is that companies want the benefits of pairing, the ability to take a general problem in an uncertain domain and just go solve it, without handoffs or delays. And they don’t want to make the investment to make that possible. The end result is the search for the purple squirrel.

First, recognize that right now, today, if you can’t pair, you won’t be able to find or keep a purple squirrel programmer – purple squirrels don’t exist. Instead, I’d suggest seeking a middle ground – trying to job share a little more, taking a look a the value stream and reducing, or eliminating, handoffs where you can.

“But Matt!” you say “We can’t pair, our bosses won’t let us!” or “Please explain why this works so well – not just the effects, but the logic.” Perhaps you want to know how to find the middle ground or “How can we get 80% of that benefit for 20% of the effort?”

Don’t worry friend. There’s plenty more to come.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: