6 ms·

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

by ptero 7y ago

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.

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.

by ptero 7y ago

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.