Comment by fleabitdev
11 hours ago
> Influencing without authority
> Getting work prioritized
> Developing 1YP+ plans for their areas
I was a little surprised by your list. Aren't these normally the responsibilities of a team lead or a manager? If I were hired as a senior engineer, I'd expect to be involved in group decisions about cross-cutting technical concerns (architecture, choosing languages and frameworks, the code review process), but changing my team's priorities would fall well outside the job description.
If somebody has the power to tell me what to prioritise, it feels topsy-turvy for them to ask me to tell them what they should tell me to prioritise. At that point, why have a leader at all?
I work at a large software company, senior engineers here are essentially technical leads for a team or a subsystem. They are my equals when it comes to level, often getting paid a lot more than me for high performers.
I'm here to help the team make decisions, but I delegate as much of the opinion having to my senior engineers. To have an opinion they need a bunch of inputs, sometimes getting those inputs isn't as natural as the technical inputs, that's where I come in.
Senior engineers are still involved in cross cutting technical concerns but for any work that is bounded by our team I'd be working with them scope out the work as requirements or use cases we give to mid level or early career engineers on the team to disambiguate with the senior engineer as a consult/negotiate.
Just a misunderstanding, then - thanks for taking the time to clear it up, I appreciate it.
Strange that your company calls its tech leads "senior engineers", when every other company is going through title inflation! Hiring for those roles must be a pain.
I've never worked at a company that had a "tech lead" role as part of official HR levels. Junior engineers (couple levels) -> Senior Engineers (couple levels) -> Principle/Staff (couple levels) -> some form of really rare role of Distinguished.
Senior Engineers should definitely do what I think earlier comment thought of as "tech lead". Should be able to run juniors, solve cross-cutting needs, etc....
Team lead manages the overall direction of the team (and is possibly the expert on some portions), but for an individual subsystem a senior engineer might be the expert.
For work coming from outside the team, it’s sort of upto your management chain and team lead to prioritise. But for internally driven work (tech debt reduction, reliability/efficiency improvements etc) often the senior engineer has a better idea of the priorities for their area of expertise.
Prioritisation between the two is often a bit more collaborative and as a senior engineer you have to justify why thing X is super critical (not just propose that thing X needs to be done).
I view the goal of managers + lead as more balancing the various things the team could be doing (especially externally) and the goal of a senior engineer is to be an input to the process for a specific system they know most about.
I agree, but I think that input is limited to unopinionated information about the technical impact or user-facing impact of each task.
I don't think it can be said that senior engineers persuade their leaders to take one position or the other, because you can't really argue against a political or financial decision using technical or altruistic arguments, especially when you have no access to the political or financial context in which these decisions are made. In those conversations, "we need to do this for the good of the business" is an unbeatable move.
I guess this is also a matter of organisational policy and how much power individual teams/organisational units have.
I would imagine mature organisations without serious short/medium term existential risk due to product features may build some push back mechanisms to defend against the inherent cost of maintaining existing business (ie prioritising tech debt to avoid outages etc).
In general, it is a probably a mix of the two - even if there is a mandate from up high, things are typically arranged so that it can only occupy X% of a team’s capacity in normal operation etc, with at least some amount “protected” for things the team thinks are important. Of course, this is not the case everywhere and a specific demand might require “all hands on deck”, but to me that seems like a short-sighted decision without an extremely good reason.
In my 30 years in industry -- "we need to do this for the good of the business" has come up maybe a dozen times, tops. Things are generally much more open to debate with different perspectives, including things like feasibility. Every blue moon you'll get "GDPR is here... this MUST be done". But for 99% of the work there's a reasonable argument for a range of work to get prioritized.
1 reply →
Architecture, choosing languages and frameworks, the code review process are all aspects where "influence without authority" comes into play. What if you want to introduce a new lint rule or CI process that might impact other teams?
Having technical influence across other teams of peers is exceptionally important for senior developers.
In a large company there aren’t enough teams to lead for everyone who wants to get more money (promoted) so management invents these meaningless (for a regular senior) hoops to jump so they can track kpis and can’t be accused of favoritism. Something like that =)