Generalist or Specialist — welcome to the PaintDrip Model
Before starting to fulfill the promise made in my last article about how to scale engineering teams in a healthy way and explain in more details how to work the team's maturity and the quality metric I wanted to follow up with Felipe Teixeira's suggestion and get into an old — and very important — topic about a more generalist or specialist career path for devs.
People that know me for some time know that I'm a person that likes balance—I always joke that although I respect all religions and despite not being very religious myself, it I was, I would be buddhist- for its quest to balance and the use of the middle way and reason.
Extremes — where people get lost so often — are good to illustrate. However, in real life I have always looked for more balanced models that bring results that last longer.
What I will try to show in this article is a method that I believe is way more efficient for you to grow as a professional: generating more results for your team, your company and, as a consequence, making you more valuable as the professional for the future.
To get there we will talk about the advantages and disadvantages of being a generalist or a specialist, how — and when — we can combine both and the impact that a more balanced model has in the company's culture.
It's important to notice though, that in order to focus I keep the discussion related to software development. Although, I believe the discussion between being a generalist X specialist is way more open and can be applied to any area. A very interesting book about that is Range — Why Generalists Triumph in a Specialized World that was just recommended by — no one less than — Bill Gates as one of the best books he read this year.
Bill Gates — the programmer who created the software industry — says in his post about the book: “My own career fits the generalist model pretty well”
I want to apologize in taking so long to publish this article. When I read Bill's post, I had to stop and read the book. It's truly one of the most interesting books I read recently. I identify with the generalist model myself.
Along my journey I have always felt that many different experiences are a differential and a catalyst to learning and creativity. The book has a lot of stories and studies explaining eloquently the author's point of view. Definitely worth reading.
Getting back to software development: one thing that always surprised me is how since the inception of their careers many developers — and in my experience not just in Brazil, I have seen happening in Europe and Asia as well — have the ambition to become hyper specialists in a specific discipline of software engineering.
We have a plethora of frontend specialists, mobile specialists, backend specialists, database specialists, and the list goes on. Even specialists in "sub-disciplines": iOS specialists, android, angular, Postgres, Java specialists, etc. Don't get me wrong, I believe that having good knowledge about a good range of useful tools to do our craft is essential. However, in my opinion, being a "hyper-specialist" in a few tools is not a good career choice because that is simply the opposite of what we need in order to build software nowadays.
The hyper-specialist myth — the one responsible for a specific part of the software development process—comes from the software factory metaphor where each group of professionals is responsible for a pre-defined step in the process: a group does the specification, another design, another frontend, another backend, another tests everything and, at last 🙏, the last group deploys everything in production.
Nowadays, I believe it is already very clear to a good number of technology companies that this metaphor is not a good one for software development products. However, I believe it is important to be conscious of the reasons. Unfortunately, I do not believe every dev has this conscience yet.
In my experience, to develop complex software products like the ones we have in the current days we need two things: team work and creativity.
It's not feasible that each of the specialist teams , the more specialists they are — deliver a "factory-ready part" that is perfect — so the next specialist teams in the production line continues the work, going in that fashion until the last team in line deploys software to production so it is available to the user.
The factory mindset applied to software development causes several problems regarding teams formation. Two, in special, derive from a "purely specialist mindset":
- handoffs — as each specialist group is responsible for a part of the process and does not have a holistic view — more often than not — we have incomplete specs, layout and interfaces having to go back and forth in the "software production line". I've seen cases where this process took the team's lead time to months: what certainly influences the team's health.
- silos — in a factory organization with specialists team the tendency is that one team does not have empathy to others. Teams do not have tangible shared common goals, thus they end up not creating the necessary empathy fot other "specialist areas" problems. One of the aspects I observe when I am exposed to software engineering teams is how the several groups interact. A good test to see how team organization influences in that is what I call "the lunch test". In a team with specialist teams — in general: frontends have lunch with frontends, backends have lunch with backends, QAs have lunch with QAs, and so forth. In my experience, this dynamic — together with the lack of knowledge of other team's work — creates "psychological fences", communication problems arise, and the quality of the software ends up being low.
Those two problems alone should be enough reason to avoid a purely specialist culture — handoffs and silos can kill group work and productivity in a software team in the long run.
Software creation is a collaborative, iterative and creative process where multifuncional teams are essential and have to take every and each feature to production as a group.
As we have seen above, a purely specialist mindset is a burden for collaboration and iteration within the teams. What about creativity?
As it is very well explained at the first chapter of Range — yes: the book recommended by Bill Gates again, I loved it — in a activity where the problem does not have already a mapped solutions — in order words, there is no known fixed rules — abstract thinking is crucial to develop possible solutions. In Range, David Epstein shows that abstract thinking is one of the great differentiators we have as a species and what enables us to innovate in the most diverse situations.
In software development it is no different.
Of course that a lot of algorithms and frameworks are already created, and we do not have to re-invent the wheel all the time. Certainly, we have to go deep and specialize sometimes, searching for the adequate tools to apply in every day problems.
Nevertheless, innovating is a process that requires our ability to engage in abstract thinking and apply tools we already know in new situations — and, a generalist view is essential for that.
Now, we have the famous question:
But how do I differentiate myself as a professional? What should I specialize in?
First we have to take a look at the T-shape model.
It 's a model that exists for some time now, since the nineties. However, it has become more popular lately.
I've been working with this model in my teams for years, not always easy to adopt, because it is somehow, contrary to the software factory metaphor and it focus on the hyper specialist — which is still in the unconscious of many devs.
The first reference I had from this model came from Valve's onboarding booklet — a company that is world-renowned and responsible for classics such as half life and steam — the famous gaming publishing network.
The image above — taken from valve's booklet — shows in a playful way the character “heavy” with his skills illustrated following the T-Shape model.
The idea here is to have a group of skills and broad knowledge — the upper part of the T — that allows us to develop our empathy and abstract thinking so we can enable more collaborative and creative teams.
At the same time, we specialize in a specific are — or areas — so we can go deeper and provide this specific knowledge to the team — that is the body of the T
This model — in my opinion — is a quantum leap in relation to the purely specialist model. But, implementing it over the years, I realized that many people started to fall again in the hyper-specialist approach. It was as if — with time — “heavy” as evolving as the image below:
And, of course if we develop a culture with the pattern above we will — over time — end up at the hyper specialist model and get into trouble.
When I was at OLX Brazil, we were facing a similar cultural challenge as the one above and searching for a solution that would help us to create a more T-shaped culture — Guilheme Cirne found the “PaintDrip Person” analogy, created by Kent Beck, the father of XP and TDD.
The image above is literarily the slide I used in one of our all hands in 2018, explaining the model to the team
In this model, Kent makes a series of observations about the characteristics developed by a good dev and shows that she is always exploring and developing her interests over time.
He explains this person's career evolution over time as it was a paint drip in a wall — as illustrated in the slide above. In this analogy each dripping drop of paint is a project where the dev had to go deeper in a technology. The depth she develops — or that the paint drips — depends on the team's or project's needs. Following that fashion, the dev goes along her career, exploring new paths and specializing — if and when needed in order to learn and help her team.
I confess that I find this analogy not only precise but artistically beautiful.
[ poetic pause 😀 ]
What we have learned implementing this model was that it's not enough to have great role models such as: Kent Beck, Steve Wozniak or Bill Gates — zooming in at Microsoft — they still hire people with the profile he describes in his review about Range.
We also need to have a conscious decision to favor a exploration culture
It is necessary to create explicit incentives to the team. One example is to embed the paintdrip profile in your career plan and have leadership supporting it and walking the talk.
Now, I'm already entering the topic that I should cover in a new team formation article promised here. Let's leave the explanation on how to insert this model into the culture to our next conversation.
While you wait for the next article I hope this model — and a bit of the explanation from where the hyper-specialist profile came — has helped you.
Now you have to fill the bucket with a lot of paint and point the paintbrush because there is certainly a lot of exploration and things to learn in your career.
