Why I Love Being an Individual Contributor

AI, flat teams, and why high-autonomy IC work feels more powerful than ever.

7 min read

I love being an individual contributor.

I have managed people before, and I do understand why people like it. But personally, the work I enjoy the most is when I can sit close to a problem, understand it firsthand, build the system that fixes it, and then watch the output show up in the business.

That used to be harder.

For a long time, IC work came with a lot of waiting. Waiting for design. Waiting for engineering. Waiting for sales to send data. Waiting for someone in the middle layer to translate the problem for you. You could still be great at your job, but your output was shaped by how much context you were given and how many people had to unblock you.

AI has changed that in a very real way.

AI makes average skill useful

One of the biggest things AI has leveled up is being average at things.

Earlier, you were usually good at one function. Maybe you were good at product. Maybe engineering. Maybe marketing. Everything else depended on someone else being available.

Now you suddenly have access to a baseline version of many skills. You can write copy, design a quick flow, build a script, clean data, analyze a CSV, prototype an internal tool, or automate an operational process. You may not be world-class at all of those things, but you do not need to be. You just need to be good enough to move the work forward.

Hand-drawn comparison of pre-AI and post-AI skill baselines showing how AI raises the floor across product, engineering, design, and marketing

That is a huge unlock for individual contributors.

The unique advantage is still your own taste, judgment, and domain understanding. AI does not replace that. But it fills in enough of the surrounding skill stack that you can stop being blocked by every dependency around you.

If you are a product person, you can code enough to prototype. If you are a marketer, you can design and automate parts of your campaigns. If you are a growth person, you can run experiments without waiting for someone to build every tiny piece for you.

You become more complete as an operator.

The old problem was information loss

The other thing that used to frustrate me was how information moved inside larger teams.

In a hundred-person org, information often flows from the top, then to a middle layer, then to managers, then finally to the people doing the work. Every handoff changes the shape of the problem.

There is loss of information. There is noise added into it. And most importantly, your exposure to the real problem is shaped by the person you report to.

The same thing happens in reverse. If you are leading a project and someone reports to you, they often get a version of the problem that has already been filtered through how you frame it.

That is not always bad. It is just how hierarchy works. But it creates distance between the person doing the work and the actual problem the company needs solved.

Smaller teams change that.

I currently work in a 14-member organization, and it is mostly flat. There is maybe a single layer in between for strategic focus, but there are not long approval chains or complicated reporting structures.

Because of that, I get access to the problem directly. I can look at it from first principles, build my own understanding, propose a solution, and then collaborate to refine it.

That is a very different kind of IC role.

Autonomy compounds with AI

The magic happens when you combine those two things: direct access to problems and AI-expanded skill sets.

If you understand the real business problem and you also have the tools to build across functions, you can move very fast. You do not need to wait for ten different people to do ten different small things. You can take the first version from idea to execution yourself.

This is the part I enjoy the most.

An idea can become a script, a workflow, a campaign, a dashboard, or a shipped experiment in a matter of hours. The feedback cycle becomes incredibly short. You try something, see what happens, change it, and keep going.

That does not mean collaboration disappears. It just means collaboration becomes more useful because you are not waiting on people for every tiny dependency. You bring something real to the table, and then the team can improve it.

A recent example from my work

Over the past few weeks, I have been running cold email campaigns that directly impact revenue.

There is a lot of operational work behind that. We manage hundreds of mailboxes. They need to be warmed up. Campaigns need to be created. Lists need to be validated. Copy needs to be written and A/B tested. Mailboxes need to be added or removed from campaigns depending on deliverability. Some mailboxes start going to spam and need to be rotated out.

None of this is fun work. But it matters.

Previously, scaling this kind of process would have needed a lot of manual ops or a bunch of engineering asks. Now I can automate large parts of it with scripts and APIs.

I can validate email lists. I can set up campaigns. I can pull campaign data from the cold email infrastructure, clean it with Python or Pandas, feed it into an LLM for analysis, export it as a CSV, and push the output into Google Sheets.

Once I have run a few campaigns manually and understood the process, scaling it becomes much easier. The system can be broken into smaller repeatable pieces, and those pieces can be automated.

This is where AI feels like leverage. Not because it does everything, but because it helps me build the machinery around the work much faster.

Ownership feels different now

This kind of IC work feels different from the old version of IC work.

Earlier, being an individual contributor could sometimes feel like pure execution. Someone else defined the problem, someone else decided the strategy, and you were expected to complete your piece of the puzzle.

Now, in the right kind of organization, an IC can own the whole thing from inception to outcome.

You can understand the problem, define the system, build the first version, measure the result, and keep improving it. You are not just doing tasks. You are owning a business outcome.

Hand-drawn idea to outcome loop showing an individual contributor owning the full loop from problem to system, experiment, data, iteration, and outcome

That is the fun part.

I hate being blocked by other people. A few years ago, that happened all the time. Today, it happens a lot less. If I have context, access, and the right tools, I can usually get something moving.

This only works in the right culture

This is not automatic.

AI alone does not create high-impact ICs. The company culture has to support it.

There cannot be gatekeeping of information. ICs need first-person access to the problems the organization is facing. They need enough autonomy to make decisions. They need access to the tools and systems required to actually do the work.

Without that, AI just makes people slightly faster at doing assigned tasks.

With that, AI lets people operate at a much higher level.

The thing I have had to learn along the way is to look at problems as systems. Not just “what task needs to be done?”, but “what system needs to exist so this problem keeps getting solved?”

Sometimes the solution is one script. Sometimes it is a set of workflows. Sometimes it is a dashboard, a campaign engine, an internal tool, or a process that connects multiple systems together.

That is the kind of work I enjoy now.

Being an individual contributor today does not have to mean being lower in the hierarchy. It can mean being closer to the problem, closer to the execution, and closer to the outcome.

And honestly, that is where I like being.

Meme about specialists wasting energy on LLMs while generalists use them as leverage