4 ms·

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

by Denzel 7y ago

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.

SpicyLemonZest 7y ago
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.
- Denzel 7y ago
  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?
  - SpicyLemonZest 7y ago
    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.
- playing_colours 7y ago
  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.
ptero 7y ago
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.
- Denzel 7y ago
  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.
jorblumesea 7y ago
> 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.

by Denzel 7y ago

SpicyLemonZest 7y ago

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.

Denzel 7y ago
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?
- SpicyLemonZest 7y ago
  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.
playing_colours 7y ago
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.

ptero 7y ago

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.

Denzel 7y ago
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.

jorblumesea 7y ago

> 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.