Hacker News Reader

Comment by ptero | Hacker News Reader

If one wants more responsibility, one has to move to leadership. This is true in almost every company and work type, not just in software development.

There is a flip side to this, as some (many? most?) excellent ICs either become poor managers, or hate the job of dealing with humans, or (frequently) both. This is well known and many companies actually want and support top ICs who want to stay ICs with significant freedom to choose projects, generous (time, travel and $$) conference budgets and other perks.

Thus at least some ICs do not go anywhere after they peak (hopefully plateau), which can be a good place to be. But sooner or later they will likely be working under one of their team members whom they did not think much about (who may just be better with people than with technology). This is not a reason to lose any sleep; just something to keep in mind. My 2c.

View on HN

Responsibility vs. accountability. If one wants more accountability, then you must move to management. Responsibility can and should scale with IC levels.

What’s the difference? Think about when a project fails. “Bad things” happen for the person accountable, whereas the person responsible can move on to the next project. The buck stops at the accountable individual not the responsible one.

In practice, every project has a manager that’s accountable and a lead that’s responsible. As ICs move up the ladder, they’re able to lead larger and larger projects and offer expertise and guidance across multiple projects. Think: providing feedback, from hard-fought past experience, on a design doc that’ll save a team 3 months worth of effort; architecture review, etc. Essentially ensuring and instilling engineering excellence across the organization.

One thing to note, moving up into a senior engineering role may mean you’ll be coding or designing less. And that’s to be expected. Senior engineers understand that coding/designing is one portion of a larger picture that includes communication, eliciting buyin, documentation, architecture, software quality attributes, and many more responsibilities.

In theory, this provides equal management and IC tracks that are fulfilling to all. In practice, very few companies work this way, but there are some out there. And when you find them, you won’t want to leave because it’s such a pleasant experience.

I'm sure it's a pleasant experience for the high level IC, but from the rest of the organization's perspective it you're describing architecture astronauts.

* They descend on random design docs to demand changes, based on vague pattern matching to a problem they faced 5 years ago.

* They don't have to do any of the work to implement those changes, of course. My team has to, and we have to defer to their opinion that changes are needed.

* If the changes they demand end up being really dumb, and hurt or kill my project, they can't be held accountable. Not even when it's a recurring pattern, since every corporate metric will show that the project team are the ones who messed up.

Maybe our disagreement is less severe than I'm thinking, since I also wouldn't agree the IC model at e.g. Google works like you're describing. But separating accountability and responsibility is in my experience an unmitigated disaster.

You describe a bad implementation of top level IC. They same way, it can be someone from the top management who has no clue about individual teams, makes dump decisions that hurt your team.

Top ICs work together with ICs that represent their teams, so that they can make informed decisions. They are up to date with technologies (this must be an obligatory requirement), code regularly, so they are much better then managers to make efficient company wide technical decisions, own the architecture of the whole system or large parts, organise and overlook large and expensive engineering initiatives, drive prototypes and research projects. They must me accountable for being up to date, understanding the consequences of their decisions, getting feedback from managers and engineers - not turn into “astronauts” in some years.

I think ICs should go in parallel with engineering management in the reporting chain: the top IC reports to CTO, next level reports to directors, etc. This ensures that IC’s scope of responsibilities is expanding and they have better visibility and power.

> I think ICs should go in parallel with engineering management in the reporting chain: the top IC reports to CTO, next level reports to directors, etc. This ensures that IC’s scope of responsibilities is expanding and they have better visibility and power.

That’s how it works at IBM. I’m the “responsible” party and technical leader for a couple of teams working on related projects. I report to a program director who reports to a VP. My peers are line managers and other senior tech leaders. Part of what’s great about the team that I’m in is that we ha e clear talent pipelines that show how you can matriculate upward in design, engineering, or management, and that a “band 10” of engineering is equivalent in scope, comp, influence, and autonomy to his or her manager equivalent or design equivalent. That extends into the executive ranks as well though it’s more common to find people who hold dual roles of VP and Fellow or Director and Distinguished Engineer or Distinguished Designer.

Exactly, it is similar to my position at some previous company: as a tech lead I reported to a Director of Engineering who also managed a few engineering managers. The top IC tech guy - “Chief Architect” reported to CTO.

You didn’t contradict anything I wrote.

This anti-pattern is alive and well throughout the industry. I'm automatically suspicious of any department that dubs itself as "architecture" because the motivations are usually broken in that success looks like forcing outside engineering teams to adopt a pattern conceived in abstraction.

My experience says that ICs are best embedded in the team to deliver working code with patterns that are conceived from exposure to the real problem being solved.

I agree, architecture departments are anti-patterns, but very soon, IC cannot grow in the value they can bring to a company by being scoped within a team and shipping code - as IC you scale by: writing some code that benefits many teams, by mentoring, helping with planning and executing challenging work, prototyping, organizing and overlooking large engineering initiatives: CI/CD, ops, migrations on a large scale, and more and more.

Yeah, you are right. Where I've seen it work is when an embedded IC is given free reign to spend time helping other teams organically. The real root cause for architecture in abstraction is a management issue where some VP is kingdom building by collecting engineers to be disconnected oversight architects to other engineering groups.

I feel like one of the worst things that can be done to engineers is disconnecting them from the problems being solved.

> embedded IC is given free reign to spend time helping other teams organically

Then, by definition, they wouldn’t be an “embedded” engineer, no? In fact, what you’ve described is not at odds with what I’ve described.

I’m afraid you constructed a strawman to argue against that doesn’t occur in my comment at all.

I’d like to hear more on your thoughts about Google’s IC track and implementation, especially if you’ve worked there. Care to provide a compare and contrast?

At some companies I'm familiar with, the highest level ICs have nearly unlimited freedom to "move on to the next project" as you put it. Some slot themselves into purely advisory roles, so they can dedicate their time to accountability-free control without ever having to risk assuming responsibility. Others constantly flip through greenfield development projects, leaving maintenance teams behind like mouse droppings once the projects are too mature for their tastes.

At Google, high level ICs seemed accountable by most standards. They couldn't just abandon projects when they became boring, they got in trouble when their projects didn't work well, and the weird committees (which admittedly did exist) generally felt like guideposts more than obstacles.

I have no beef with your definitions, those are nice and consistent, but in practical terms I have trouble imagining anyone who, by your definition, wants more accountability. This seems to be asking for a harness and a whip.

On moving up the ladder while staying an individual contributor -- IME as one becomes the tech lead of larger and larger projects, the "tech" part shrinks and "lead" grows and the setup has a constant forcing function into a "manager in all but a name" setup. One might resist, but this is frequently a pretty hard push.

People that want to control P&L necessarily want accountability. I’m not sure why it’s difficult to imagine someone who’d want that? Every founder of a company, by definition, is seeking and taking accountability.

Your second point is spot on. A natural tension arises as ICs move up the ladder, and if one values being an IC, then one must maintain their boundaries.

> Responsibility vs. accountability. If one wants more accountability, then you must move to management.

Depends on the org and company, to be completely honest. Sometimes, management and leadership have little true accountability and that ends up falling on ICs. Projects fail and senior ICs are blamed instead of management because they were "responsible for the implementation". Accountability without responsibility or vice versa often ends up in failure.

Reply on news.ycombinator.com