HomeIndustry Commentary

Specialists, generally speaking

Like Tweet Pin it Share Share Email

Generalists, according to the old joke, know nothing about everything, as opposed to specialists, who know everything about nothing.

Their managers know nothing about anything, which is why they hire consultants like me — people who know everything about everything.

Or at least know how to create that impression.

Smaller companies rely, for the most part, on generalists. Their receptionists figure out InDesign and use it to create brochures. IT doesn’t just code their websites — IT also organizes them and writes a lot of their copy, too.

Meanwhile, Fred in Accounting closes the books, sends out the invoices, pays the bills, and manages cash flow too.

And the owner variously serves as the top sales rep, lead product designer, head of customer service, and janitor, depending on what most needs doing and who called in sick that day.

Smaller companies have been populated by generalists since the days when the closest thing there was to a specialist was someone who was particularly good at chipping flint arrowheads, trading them for some mastodon steaks.

Bigger companies have relied on specialization at least since the dawn of the industrial revolution, when the invention of the factory resulted in jobs limited to a single task performed over and over again.

Employees’ sense of alienation and dehumanization, customers’ sense of being trapped in a bureaucracy, and management’s nostalgia for the days when business was fun … these accoutrements of excessive specialization are, I’m sure, just as old.

Why exactly do we do this to ourselves, when we all hate it so much?

One answer, I think, is being trapped in the mental habit of mass production.

Start with the difference between processes and practices. Processes are recipes: Follow the steps exactly and good results must follow. While practices also involve a series of steps, following them exactly leads to failure. Practitioners must apply their knowledge, experience and judgment in executing each step.

Great art is a practice. Turn it into a process and the result is a paint-by-numbers system. Being the carnelian specialist is unrewarding; the result is a parody of art.

Those who practice a craft take pride in the uniqueness of each item they produce. Their customers value uniqueness and are willing to pay more to get it.

Large manufacturing companies take pride in the opposite of uniqueness. They deliver enormous numbers of products as nearly identical as possible, built out of identical, interchangeable parts.

Assembled, of course, by fully fungible employees.

This industrial system works well at supporting the twin goals of throughput (high volume) and quality (adherence to specifications).

But business theorists extrapolated, applying the mass production model of increased specialization, organized sequencing, and interchangeability to business practices as well.

Which is how IT ended up practicing waterfall methodologies, convinced that if we just managed to become good enough at them, they’d suddenly start producing useful results.

No such luck.

In IT we’ve finally figured out that waterfall’s problems aren’t the result of a failure to perfect the process — they’re intrinsic to our having misapplied the mass-production model. Its specialization of roles adds overhead, impairs communication, delays delivery (it increases cycle time), and limits flexibility and richness of function (it reduces excellence).

We call the alternative “Agile.” It relies on generalists, who:

  • Talk directly to business managers and end-users to figure out what they need, instead of working through an intermediary.
  • Show business managers and end-users progress on a regular basis — often every day, instead of talking to them once during “requirements gathering” — making frequent design adjustments as a result.
  • Write code, too.

When it comes to developing software, we’ve found that a collection of generalists, each of whom is competent in the whole craft, outperforms a team of specialists who segment responsibilities into a structured workflow.

The time has come for us to evangelize our discovery. Because elsewhere in the enterprise are managers who have been trying manfully (and sometimes womanfully) to force the square peg of factory-style organization into the round hole of the fast, creative, non-repetitive outcomes they’re responsible for.

Most managers, in fact, because very little of the work in a modern corporation looks like mass production unless your gaze is cockeyed.

When the work is more practice-like than process-like, mass production’s large number of hand-offs from one specialist to the next leads to results everyone hates — customers and managers just as much as employees.

I have an easy solution.

Let’s stop doing this.

Comments (14)

  • Thanks Bob –
    Specialists, Generally Speaking –
    Totally Agree.

    Sounds like you have been reading John Seddon talking about the failure of command and control management. He has a similar philosophy when it comes to public service.

    You can get a flavor of his thinking from this website video: http://www.infoq.com/presentations/rethinking-lean-service. (or search youtube)

    His books have perhaps a bit too much of his British politics, but… Hey its government he’s talking about.

    His advice – Customers are the secret to understanding value. Do what they value as fast as you can. All else is waste. Eliminate waste.

    Good Demand is what the customers want.
    Failure Demand is all the effort you put into fixing your bad service. He documents Failure Demand is 20% to 80% of companies output.

    He sites several kinds of waste:
    Writing Specifications
    Inspections – does it match spec?
    Preparing for Inspections
    Specification is wrong
    Demoralized staff

    So True.

    Best Regards,
    Dave

    • Without commenting directly about something I haven’t read, two points:

      1. I couldn’t agree more that customers define value. In fact, I made this point in the very first Survival Guide I wrote for InfoWorld (https://issurvivor.com/?p=39) and haven’t changed my view at all since that time.

      2. Except for government, which doesn’t have customers. It’s too bad so many citizens consider themselves to be government’s customers, when we are, in fact, its owners. The closest business correspondents to the relationship between citizens and government are mutual insurance companies and cooperatives, in which members are both owners and customers.

  • I am reminded of the old saw:

    You cannot have a baby in one month by getting nine women pregnant.

    I think that many attempts to improve processes fail to recognize the inalienable order of some things.

  • The challenge with relying on generalists is that they must be truly multi-functional and capable of learning new things. Not all generalists are. A team of insufficiently skilled (at the “I know how to learn what I need to know” level) or unmotivated generalists will not create the same kind of results that a team of go-getters will.

    The interesting phenomenon this wide variation leads to is that a team of generalists can produce results way below OR way above the results produced by a waterfall-style team of specialists.

    I’ve seen this time and time again. A dozen people trying to figure out how to even start can get beaten to the finish line by even the most glacial assembly line of specialists. Conversely a team of sharp generalists intent on a goal can leave the assembly line in the dust.

    Many big companies prize the minimization of risk even if it comes at a cost. Hence, heavy follow-or-else processes, thick procedures and rules manuals, and formalized workflows with all of the delays you’d expect any time a sequence of 8 people are “critical path” on a task are still prevalent. They provide an illusion of safety (did I hear someone say Six Sigma?) by often enabling managers to avoid consequences by saying of a poor result, “We followed the steps that the steering committee agreed on to the letter,” and citing some external factor outside their control as an unpredictable variable.

  • Another vote in favour, but (there’s always a “but”) where are we to find all these generalists? In small organisations it may well be the case that receptionists write the brochures. Do they do it as well as a dedicated person who does nothing but write brochures for a living? Probably not. If the message of the brochure is “Use Bob’s Plumbers – we’re cheap and local and we do a great job”, then near enough is good enough. If it’s purpose is to sell a new model of car that has cost $1bn to develop, not so much.
    How many developers do you know who are even semi-competent at coding C++ AND JavaScript AND Sql AND are comfortable getting requirements by talking directly to business managers? Specialisation (in larger organisations) will be with us for a while yet – we’d better learn to deal with it!
    One way to deal with it is to make sure that the specialists don’t all sit in separate silos that only talk to each other at CIO level. To do this effectively you need generalist managers who can do (or at least understand how to do) all these activities and are competent man-managers and know how to manage a budget too. They’re not easy to find, but at least you only need a few percent of your team to meet these criteria rather than 100%.

  • As always, a great column. I am fortunate to work in a group that values practice over process. But, our corporate IT folks are just the opposite (for all the reasons listed in the article). They have a high turnover rate. Ours is essentially zero. Which place is more fun to work?

  • Spot on and well said Bob.

    Replying to some other comments. You find these generalists by hiring solid business people who can implement technology. You get away from resume scanning and hiring exact technical skills.

    Offshoring and short term consulting engagements (guns for hire) do not work with a team of generalists. You are in the business of developing long-term talent that cares about your business. You are also developing talent that can manage their own work without layers to management.

    I think of my staff as business professionals that just happen to be able to write programs. The majority of development time is spent learning about what needs solving and how to do it. Coding turns out to be rather trivial.

  • AMEN!!! to this proposal.

  • Well put Bob.

    In my experience a team of good generalists is much more valuable than a team of great specialists. Generalists truly understand the business processes they are modeling. They know that the business is nuanced, not just black and white. They even know which requirements are likely to change. Because they know this they create better software.

    Remember playing the “telephone” game when we were kids? That’s what many specialists have to deal with when reading specs written by someone else. It’s no wonder they often get things wrong.

    With that said, I’m not ready to give up on specifications. I like specs because they force generalists to think through the entire process and make sure they create an elegant, cohesive solution.

  • One thing most managers don’t realize is that “Programming Languages” are a lot like keys in music. Someone who can play/write beautiful music in the Key-of-C, only has to “learn” the tonality of another key to be successful there.

    Other than the rare prodigy, it takes years of practice to become skilled on one instrument (read industry or department). Once one instrument is mastered, gaining mastery of additional instruments is essentially an exercise in muscle memory.

    An experienced generalist has the skills necessary to design and implement systems that touch many segments of their world. The specialists (one-trick-pony) can impress their masters, but usually miss the boat in other areas.

    Case in point: My bank just implemented a “new” web-access system. I would bet money that the development team had an average age under 30 – and are all “Web Specialists” in the “Banking Industry” – – because the customer-side reports and downloads are useless and/or non-functional.

    “Experience” is that quality of life that lets us recognize our mistakes early, and correct them before they go public. “Specialization” is a form of blinders – and often leads to tunnel vision.

  • Hi Bob,

    Great article!

    My thoughts were a bit too long to be easily expressed in a comment, so I’ve posted them in an article on my blog: Effectively using generalists.

  • I once worked with a fellow manager who had decades of experience in electronics manufacturing. He expressed dismay that it would take my software team more than a month to produce the web app our company needed.

    “I’ve wondered for years why the production of software can’t be like the production of hardware?” he said. “Even my most sophisticated product can be put together in under two days. Production is like the push of a button.”

    I explained to him that the analogy was wrong. Software development is not equivalent to hardware production, which is an easy process; but rather to hardware R&D, which is a practice, and a difficult and unpredictable one at that.

    So what would be the software equivalent of hardware’s “production”? Making copies of the finished product, which can easily be achieved with the push of a button, and in under one second, if you’ve got the right processes in place.

    He got it.

  • Yes I agree 100%.

    Unfortunately there are many managers that are more interested in keeping ‘control’ of their department than in the product it produces.
    A bunch of narrow specialists are less likely to challenge the manager’s authority than a generalist

  • I have proudly been a generalist all my IT life.
    That worked very well for all but one of my former employers – that one had difficulty grasping the concept of a developer that actually talked to and worked with the users. (turned out to be a relatively short stay).

    Glad being a generalist is now becoming fashionable as well!

Comments are closed.