Hacker News new | comments | ask | show | jobs | submit login

In my experience it’s rare for orgs to hire for principal/staff/architect roles. What I’ve seen instead is people getting hired on as senior engineers and get promoted up from there after they’ve settled into the org.

I was hired into a company as a staff engineer, and I probably won’t consider it again. The existing engineers resented me for it, though it was super clear that the product was suffering because the existing engineers had serious skill gaps in critical areas. Meanwhile, to other managers & directors, I was just some new engineer they didn’t know, a political unknown quantity.

I hit the ground running and earned a lot of technical respect from my teammates, but nobody cares at all about my perspective on architecture, scoping, technology investment, tech debt, etc. They had decided merely by the manner in which I joined to give no credibility to my ideas.

The next time I will require the role to be some type of director or IC/distinguished engineer hybrid that is operating with an authority level above that.

> The next time I will require the role to be some type of director or IC/distinguished engineer hybrid that is operating with an authority level above that.

I've seen this go roughly. A director who brings in a lot of new technical views, challenging the perspectives and opinions held by the team, might not have an easier time than a staff engineer. The director was largely right, but dealt not just with technical resistance but with more political fallout of having disgruntled employees reporting to them.

Forcing change isn't easy. It can pay well, when upper management knows someone needs to take on that role, and doesn't have anyone already doing it, but authority alone won't solve your problems. Especially if your management doesn't want to be seen as the bad guy themselves.

Authority certainly helps. It's not everything but without authority you almost have no chance.

There's kinds of authority. "personal authority" can easily work better than "org chart" authority since it usually has respect and trust attached - which no mere org chart can grant.

Admittedly some org charts do grant "respect" - the same sort you give a rattlesnake.

There is the saying “always speak softly but carry a big stick”. It’s good to build up personal author but in the end it’s good to have the final say. Hopefully with buyin from everybody else.

The difference is usually in terms of negotiating details about the budget & resources you’ll have when you join, your own much larger severance package or equity package with acceleration provisions, etc.

Based on the degree of resources they put into you at a director level, the option is disallowed for other people to fail to work constructively to onboard your new ideas / approaches.

Definitely still may not work out, but it’s a different ballgame than a high level engineering hire, which (however foolish) many companies will still view like they are sweetening some pot just with the title and don’t have any plans to honor the agreed nature of the role.

If it is going roughly that's on the director. Soft skills come into play when trying to make changes. IMO, "forcing" change means there are already leadership skill gaps with the director.

I ... earned a lot of technical respect from my teammates, but nobody cares at all about my perspective on architecture, scoping, technology investment, tech debt, etc.

How does that work? All the things you talk about are folded into my concept of "technical respect".

In fact they are not at all related. The engineers on my team bought into the ideas I was bringing as I rolled out implementations that proved the value.

Management however was less interested in increased value and more interested in entrenching their existing status and authority levels even if it meant torpedoing obvious and proved-out value-additive / cost effective engineering projects.

Ah, so it wasn't that nobody cared about your perspective. It's that managers didn't care about your perspective.

A gem I've picked up from my experience in different kinds of tech companies: Never work anywhere where managers are the ultimate decision makers. At engineer-driven companies, managers are enablers.

That really is a good heuristic. Managers at these companies should be asking, “what do we need to be doing?” and “what do you need to get it done?” If instead they are dictating what to do or only telling you what you can’t have, that is big trouble.

so I think this kind of managers is the “shit” :)

This probably had more to do with the org and the role than the title. Management probably recognized the gaps and shortcomings of the team, but never had buy-in from the team that these are problems and more senior people can help with them.

I think a director should only kind of "put value" to tech debt, making the mid-term and long term choices and assessing the risks. How to do the actual tech debt emission and how to deal with it when it hurts is more of a staff engineer thing.

If you think that as a director you'll have "power" to make actual week to week or month to month architectural or technical decisions you are thinking more of micro-managed projects and not of serious mid-sized or bigger engineering organizations.

I mean the general prioritization of tech debt as a continually worthwhile time investment / required basic hygienic activity necessary for product health.

As a staff engineer, I provided inarguable evidence that tech debt had been ignored to the point of extreme risk of product failure and revenue loss, along with well-scoped and iterative approaches to pay down the tech debt with ideas and creative effort from the existing tech leads and experienced engineers.

It was just squashed for political reasons. In this case, product management happens to be the part of the hierarchy with all of the “the buck stops here authority” and since tech debt did not contribute to visibly obvious progress on vanity features and cosmetic product changes (that had not been rigorously derived from product feedback, expertise or needs), then tech debt was disallowed from entering any quarterly goals, etc.

Director or certain “org wide” IC roles could plausibly have authority to stop that.

Sorry if I have the impression this was about micromanaging weekly tech debt stuff... definitely not.

I have been in a similar situation as contractor. I would only do it again if I was in a position where I could ultimately call the shots. Usually that means being some kind of manager.

I mean I'd consider myself somewhat experienced with the tech I have. But practically speaking, if you have a company with a somewhat established technology stack - or 2 or 3, commonly called legacy of some degree.

How would you have a thoroughly constructive opinion on moving the tech stack away from legacy and towards a more productive situation, without understanding the needs, situations and interactions of a company? And this takes time to learn.

In fact, even just learning the needs, goals, capabilities of different teams in an org just takes time to learn. Sometimes the path forward is to tell everyone to just do it. But no one talked with each other and thus, this never emerged.

This. This really is the value add and it's unique to every company, so it just takes time to learn.

And at some places the "senior" engineer IS the principal/staff/architect.

Company size seems to (rightly) play a role in how many levels there are in the career track. Part of the mentality that the business needs to take off before titles are concerned. However, this would most likely apply to <20 person engineering team. If the engineering team is bigger than that, I'd question why the org structure is flat.

Flat orgs at their finest.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact