There Are No Individual Contributors
Why labeling people as Individual Contributors is bad for us
Like all professions software developers have their own terminology. Meanings change and jargon falls in and out of fashion. When you’re preoccupied it’s easy to lose track. One day everything makes sense, but the next your colleagues are leveraging synergy in a forward-facing, market-driven proposition that drives change and enhances stakeholder value. The recent BA advert parodies this very well.
One such term is Individual Contributors, or IC for short. Over the last few years I’ve heard it more and more. The meaning hovers somewhere between ‘people who deliver features’ and ‘people who don’t manage other people’. Sometimes there’s a dash of ‘people who do real work’ 😉.
Developers happily, even pridefully, refer to themselves as IC’s (and also as ‘builders’), whilst managers use it in reference to their staff (also known as ‘reports’). But personally I think the term IC is misleading, archaic, and harmful. Read on if you want to know why…
Real Individual Contributors
Let me give you two, very personal, examples of Individual Contributors:
- My grandfather was a cobbler, who repaired shoes. He toiled in his own workshop, mostly with hand tools. He was certainly an individual contributor. Give him a damaged pair of shoes and you would get them back fixed within a week.
- My father was a pharmacist, in the old sense of the term. As a child I watched him make potions and lotions and count tablets into hand labelled bottles using special sorting sieves. An individual contributor once again.
Hopefully two things strike you about these examples:
- It’s all a matter of degree. My grandfather could have made shoes from scratch, but in my lifetime he never did. Similarly my dad never manufactured his own pills or diagnosed an illness.
- These roles don’t really exist in the modern world. Cobblers are pretty thin on the ground these days, and the job of a pharmacist has been greatly simplified (saving lives in the process).
Individual Contributors in the Software Industry
There is a close metaphor between the above and the role of a software developer. Back in the 90s a lot of developers were the coding equivalent of my grandfather. They worked in C and C++, on applications they had helped design, using only a few basic libraries. They could be considered Individual Contributors.
After all the overwhelming majority of the codebase was written within the team, including all the build and deployment scripts. There were still plenty of folks who practised their craft down to the bedrock. They could program in assembly, read raw postscript, patch platform specific bugs in linkers and compilers etc…
Fast forward to today and these people no longer exist. Innovations such as Frameworks, Cloud Computing, Serverless, Low-Code, and CI/CD Pipelines have rendered them archaic. Which is a good thing! We all benefit from the evolution of the profession, increasing levels of abstraction and the standardisation of infrastructure. But the modern developer sits at the centre of a vast interconnected web of tools and libraries. It would be silly to pretend otherwise.
The most important trends in software engineering over the past decade act against the notion of Individual Contributors:
- Product Design and Management are now vitally important. Customers are overwhelmed with choice but impoverished when it comes to time. So usability matters more than ever before. Developers can’t just implement the algorithmn and a slap a few extra screens on the front end.
- Users now expect to be able to safely use our software all the time, from anywhere in the world, on any device, without worrying about security concerns. So QA, and non-functional testing in particular, is no longer an optional afterthought to be performed late in the day.
- Developers now work in tiny feedback loops and tight iterations. Features are submitted daily and included in the main build via CI/CD pipelines. The days of single developers sitting on a VCS branch for weeks, playing with a proposed implementation, are long gone.
- The majority of us work remotely as part of global teams. Often our colleagues core hours barely overlap with our own. The notion of a predictable 9–5 day seems as archaic as waking up in a Bourneville cottage to the sound of a factory whistle.
Individual Contributors Versus Independant Contributors
If you’ve read this far you’re probably thinking I’ve fallen into a common misconception. Confusing Independant Contributors with Individual Contributors. The definition of an IC from the Internet (which tells no lies) is as follows:
An employee responsible for performing specific tasks or functions within an organization without the authority to manage other employees. In other words, they are individual contributors who work independently and are accountable for their work.
So, although independence is part of the definition, it’s more about accountability for your own work and a lack of mangerial responsibilities.
But here’s what I didn’t tell you above about my forefathers:
- My grandfather ran his own shoe shop. He managed multiple staff, purchased stock from distributors, managed lines of credit with customers, and did all his own accounting.
- Similarly my dad managed his pharmacy, as part of a chain. He also managed staff, supervised renovations and added new lines of business. Such as selling cameras and (unfortunately) homeopathy.
Likewise, in today’s IT industry, I don’t know of any company where senior developers don’t have some level of authority over junior ones. Just the reverse — in previous roles I’ve seen senior management go out of their way to reassure staff that a technical job title does not preclude a leadership role.
Of course this authority is benevolent — it comes in the form of feedback, guidance, and mentoring. But soft power is still real power. Moreover, thanks to the Agile revolution, senior developers are now talking directly to clients, making architectural choices, and in general are more empowered than they have ever been.
Why The Term Sucks
OK, so maybe the term isn’t great. But is it deserving of hate? To see why think about flipping it. What does it mean not to be an Individual Contributor?
The definition above would imply a non-IC is someone who lacks independence, is not accountable for their work, and exists only to manage others. Which brings to mind the sort of command and control, 1970’s era middle manager who was relentlelesssly parodied in the comedy of the day. CJ in Reggie Perrin is a classic example.
I admit I can see the appeal of distinguishing between:
- Folks who mostly spend their time on tasks that produce outputs which are relatively independant and encapsulated.
- Folks who mostly spend their time enabling and supporting the folks above.
After all my own career has been an incremental transition from one camp to the other, over the course of three decades. But I don’t think this distinction should be used to cleft our profession in twain.
The modern world of IT is supposed to be about enabling change at the speed of the Internet. Working in cross-functional fusion teams to ideate and generate innovate ideas that excite customers. There was a time when a developer could be a law onto themselves and build away in splendid isolation. But that time has passed.
It’s no longer about automating business processes, or porting existing applications onto new platforms (Web, Mobile, Cloud etc…). It’s about genuine originality and creativity. Reinforcing a duality that is corrosive to that effort doesn’t seem to be a good idea.
Or am I wrong?
