Hacker News Reader

Comment by SpicyLemonZest | Hacker News Reader

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.

View on HN

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.

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.

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.

Reply on news.ycombinator.com