This blog has moved. Go to SoftwareDevelopmentToday.com for the latest posts.

Tuesday, January 21, 2014

Hire generalists to help your specialists shine!


Imagine you are developing a highly-specialized embedded software product. Like a radio tower for the GSM/UMTS network, or a high-frequency trading back-end for a large New York trading firm. Why would you want to have generalists in that team? After all, these are niche-niche-niche products. Maybe a few thousand people work on these projects in the world. No need, right? Wrong! Here's why.

Forget common-sense

The comment above is designed to sound counter-intuitive. The reason for that is that most of this post is counter-intuitive. I'll argue that one of the basic premises behind software project management are purely and simply wrong. This one specifically, is ultra-wrong: specialists in a software project (even a niche one) should be the majority of the team. The "favor specialists" heuristic says things like: "don't hire a Ruby programmer to a Java project", "hire only people who've done financial systems to that high-frequency trading platform", etc. You get the picture.

What is the reason for this "favor specialists" heuristic? Why did it arise? The most obvious reason is that we want to hire people that "know what they are doing", and in our functional definition of software projects that means: "people who have done that one thing before". And who could argue with that? Right?

What if we looked at projects like systems, complex systems that incorporate technical and social aspects that are very hard to control or manage? In this case we would be compelled to question the "favor specialists" heuristics, because we would look at a project as much more than a technical endeavor. We would look at projects as being social and technical endeavors.

Social is complex

Social systems have many more dynamics in place than "what is the best technical solution? How do we select from competing technical solutions? What skills should we hire for?"
Social systems change rapidly (whether you like it or not), and they require a different set of assumptions about what is the best project team composition and organization. For example - the point of this post - it requires us to question the ratio of generalists to specialists.
In the last post I talked about Emergence. I explained that system behavior is affected by many unpredictable dynamics and that simple rules favor adaptable behavior in projects. I also said that a long list of complicated rules will remove adaptability from the project team. The heuristic I described in that post is: "complex rules emerge stupid behavior."

Emergence is favored by and favors generalists

I believe all projects are social complex systems. Yes, even two people projects (those, probably even more than larger projects. Think of the rule set on a 2 people project!). These social complex systems perform better when there are only a few and simple rules. They benefit from constant change (see here how to do that so that it does not kill you). Social complex systems are environments where generalists excel! Here's why:

  • generalists are more likely to think laterally (similar problems in other domains), and therefore come up with innovative solutions that provide business advantages;
  • generalists are more likely to establish communication links to other teams and organizations (because they are connected to more interest groups - which is what makes them generalists), and therefore improve the overall communication in the project team;
  • and there are many more, let me know which you have found in your experience by leaving a comment.

Improve performance by adding generalists to your project

I propose that we start designing our projects based on a different heuristic: "favor generalists". This means that we will try to seed all teams with generalists, people who know their trade but are not invested in only one particular technical solution or process.

For Developers this means that all developers should be encouraged to learn several programming languages, work in different problems during their employment, and that we don't hire people just because they've solved the same problem in the past.

For Testers this means that we hire people that can do manual and automated testing (maybe more on than the other, but both), that know different technologies, that understand social aspects (users) and technical aspects of software development (e.g. math).

For Product Managers this means that we hire people that have worked in other industries, other types of products or even in non-software only products.

If you believe, like I do, that software projects are social complex systems, then you must not favor specialists. Hire and groom specialists but seed all teams with generalists, sit back and enjoy the higher performance.

Picture credit: John Hammink, follow him on twitter.

Labels: , , , , , , , ,

at 08:30
RSS link

Bookmark and Share

1 Comments:

  • I am going to answer your tweet by commenting on your post, as there is no way I can fit this into 140 characters…

    Your article ‘Hire generalists to help your specialists shine' offered validation!

    Somewhere in one of your other posts (The simple recipe for disciplined organizations) you said: 'Agile does not fit their view of the world. A question that makes non-Agilists feel insecure and reject Agile completely or mostly.’
    Truth is also that it can be difficult for an Agilist to place him or herself in a position in which he or she can be of help and be appreciated by the world.
    There is an opportunity lying dormant for both Agilists and non- Agilists.
    How do we go about unlocking it?

    For over 10 years I saw successful high performing ensembles playing avantgarde graphic scores of contemporary music. Few rules, a purpose and a structured but flexible guide, and ensembles became naturally self-organizing (without conductor) and high performing.

    I saw the same thing happen when the same musicians (generalists) put on the hat of project/product manager to realize crossfunctional avantgarde music productions. Few rules, clear purpose and a structured but flexible guide, and team members became naturally self-organizing and high performing.

    Agile feels natural to me, it runs through my system. Now that I have become a ScrumMaster and have more than 10+ years of experience in an Agile environment I am looking forward to putting that experience into use in non-music environments.

    I see myself as a creative agilist that can provide solutions learned in a certain domain to other domains, but what I see as a unique selling point is seen by the world as a weakness. I am puzzled. I naturally enjoy translating what I see in one domain to different ones and enjoy interacting socially with different types of networks.
    I see where I can be of help, but I keep hearing things like ‘you have never done banking software’. ?!? Who cares?!?

    To name another example (outside of Agile), I have 5+ years as board member. I recently attempted to join an organization that places experienced board members on boards of large companies. During my interview I kept hearing ‘you don’t have relevant experience’.
    Pardon? I have social/political skills learned in multidisciplinary boards, can read budgets and have experience in both the active role of influencing a conversation and the passive one of chairing it, but my interviewer kept saying ‘you don’t have relevant experience’. ‘Relevant’ meant, it turned out, experience in the exact same domain. 'If the company is in retail, you can be a board member only if you have experience in retail’, she said.

    The world, to refer to your article, doesn’t think ‘laterally’, but ‘literally’.

    So yes, your article offers validation. I have seen what you describe succeed!

    generalists are more likely to think laterally (similar problems in other domains), and therefore come up with innovative solutions that provide business advantages
    generalists are more likely to establish communication links to other teams and organizations (because they are connected to more interest groups - which is what makes them generalists), and therefore improve the overall communication in the project team;
    complex, adaptive behavior emerges from the rules, and the action of the individuals. The rules are real (there is a benefit in following them), and the resulting behavior is complex and adaptable but also, very very disciplined (because there is a benefit to that discipline, you follow it or you die of hunger).
    emergence can not be explained by reducing our model of the system to simply modeling of the agents' independent behaviors. Emergence is a result of all the parts interacting in the system.

    As I mentioned at the beginning of this comment, there is an opportunity lying dormant for both Agilists and non- Agilists.
    How do we go about unlocking it?

    By Anonymous Sonsoles, at January 21, 2014 11:46 AM  

Post a Comment

Links to this post:

Create a Link

<< Home


 
(c) All rights reserved