91–100 of 148 posts
I was in an interview and asked this, and the interviewer got annoyed and wouldn't give me an answer. It sounds like this sort of experience may be more common than I thought.
> A good manager is more like a transparent umbrella. They protect the team from unnecessary stress and pressure, but don’t hide reality from them. I'm absolutely going to steal this metaphor going forward. Being a "transparent umbrella" does require knowing the personalities of your reports, some people do get distracted when they think higher-up decisions or unhappiness are going to affect their team. Most people,…
Honestly, I’m not sure. If I know what was going on transparently I am stressed. As an ordinary employee, I don’t need to know everything and therefore don’t need to worry about it.
If you get stressed about that, imagine finding yourself redundant by close of business today, and job hunting from tomorrow.
Earlier quoted context omitted.
> 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…
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 t…
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.
> A good manager is more like a transparent umbrella. They protect the team from unnecessary stress and pressure, but don’t hide reality from them. I'm absolutely going to steal this metaphor going forward. Being a "transparent umbrella" does require knowing the personalities of your reports, some people do get distracted when they think higher-up decisions or unhappiness are going to affect their team. Most people,…
There is the expectation that the manager knows who will be distracted. This is a basic part of knowing your people. I know which of my colleagues is going to get distracted without having the level of communication that my manager has. On one extreme, they just forward information knowing a report can work with it. One the other, the manager has to translate and communicate every element.
Ideally, the manager is already working on a way to ensure their report can handle transparency because that means they can work autonomously. You can't have individual contributors lead, if they are going to run into issues as soon as they discover what is going on overhead. They may not understand it yet, but they should have coping and mitigation strategies.
Engineers can be the worst group you could deal with when it comes to overhead conversations when they expect things to be orderly. Your organization is failing when everything has to go through managers and people can't operate independently.
Earlier quoted context omitted.
> 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…
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 na…
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 like the umbrella callout especially, that one took me a few years to really internalize. "Protection" isn't as beneficial as "good stress" is. You don't just protect muscles, you use them in a responsible manner to get stronger. I've started trying to ensure my team gets a lot of "good stress" (so projects that grow careers, develop expertise, etc), while getting some concentrated down time after to rest, reflect and grow (often it manifests as time to fix bugs and just not be the star of the show).
>I wondered, “Who is this feature even for? Who will use it?” No one on my team knew. I think there's another key here - Don't assume someone else knows something. If you don't know why something is done some way, find out who does and make sure they do. I've been in so many situations where the organization gets complex - person A is loaned over here or person B is working on project X because team Y needed feature…
When I was in the Marines, we had a rule of thumb that every Marine needed to know their own mission and the mission of units two or three echelons above them. So individual Marines needed to know their mission, their platoon's mission and their company's mission. Company commanders needed to know their mission, their battalion's mission and the division's mission. More specifics for echelons closer to you. This is c…
The other thing I've seen incredibly less of in software than in uniform is a bias for action at all levels. Combined with understanding the mission, a mentality that "in the absence of being told what to do, I will act." Better to ask forgiveness than permission, etc. etc. So many people in the private sector just wait for the boss to push them around like chess pieces, and I can't understand how they're OK living like that.
Earlier quoted context omitted.
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 t…
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 financi…
Earlier quoted context omitted.
I think the biggest thing I've found myself teaching my younger colleagues is basically the internals of the systems or in what ways some of the things they've written might fail. I haven't written any production C++ in about 2-3 years and honestly lost track of all the language updates since c++14. But when I explained how the code they write gets translated to assembly and runs on the machines, that's what i felt d…
Are you at a company that tends to hire from non-traditional backgrounds? The topics you mention -- the underlying "how it works" of the tech we use to build things day to day -- should be, and in my experience are, the areas where juniors have the clearest understanding relative to more senior engineers, since they just finished 4+ years learning about it five days a week in detail.
> Everyone needs to care about the Product This isn't the first time I hear this, but I always have a bit of trouble with this one. It's one thing to take a step back and think about the actual product and how it'll be used, but I think it's presumptuous to think that software engineers know what makes a product good or not. We don't say "Everyone needs to care about software architecture, even Product", so I'm not s…
We absolutely should say that. I was an engineer for 13 years and have now been in Product for 8 years. I work on a highly technical Product team, and it is absolutely an expectation for myself, my peers, and my reports that we should ensure we fully understand our Product, including its software architecture, and have an opinion about it. Engineering ultimately decides the "How", but they cannot do that effectively if Product cannot articulate an opinion about the architecture guided by an understanding of things like expected scale, potential future integration decisions, and other cross-organizational expectations that may not yet be codified. In general, Product should have an educated opinion on anything that is a one-way door, and so should Engineering. It should not be a unilateral decision, and if either party is unable to form an informed opinion, that's an organizational miss.