[HN Gopher] Things I've learned in my 10 years as an engineering...
___________________________________________________________________
Things I've learned in my 10 years as an engineering manager
Author : jampa
Score : 543 points
Date : 2026-01-21 18:11 UTC (5 days ago)
(HTM) web link (www.jampa.dev)
(TXT) w3m dump (www.jampa.dev)
| bravetraveler wrote:
| Whoa an EM that talks to clients? A rare treat. I just got a
| browbeating because I _(an IC)_ didn 't jump at the chance to do
| more _(that)_ for ~free~ growth. Ahem.
|
| Mind you, we have piles of both kinds of PMs: product, project.
| Best I can tell, they play video games between calls/status
| updates. Forgot the blur on more than one occasion. Clownshow,
| myself included.
| andreidbr wrote:
| I wholeheartedly agree with point 7 Your goal is for your team to
| thrive without you.
|
| I spent a lot of time also playing a Scrum Master role in
| addition to my regular duties. So much so that some managers
| asked me to pursue this full time. I always explained that my
| goal is to be there just as a point of contact and that the team
| should be able to manage itself.
|
| Sadly, I see so many managers, scrum masters, or even regular
| engineers consider this as a dumb approach to make yourself
| replaceable. If you don't hoard knowledge then you'll be laid off
| when the company's numbers look bad.
| soulofmischief wrote:
| I've always told my engineers that their job is to get me fired
| for redundancy.
| pjbster wrote:
| I always say that a job without an end date is a lifestyle.
| OhMeadhbh wrote:
| I'm stealing that one.
| DevKit wrote:
| Agreed, I was fortunate enough to learn this lesson early in my
| management career when I was passed over for a promotion I felt
| I deserved for someone who's team was able to operate without
| them. Looking back, I know this is why he got the role rather
| than me, my team couldn't live without me whereas his could and
| therefore he could take on the expanded role.
| jofzar wrote:
| Damn, this person looks like a good manager.
|
| These are all things I have seen in my good managers over the
| years when I had them.
| andros wrote:
| Yes, he has a lot of accumulated experience!
| OhMeadhbh wrote:
| If only all experienced managers could have developed the
| same amount of understanding.
| lloydatkinson wrote:
| I've had one good manager and I concur. As valuable as gold.
| andros wrote:
| I completely agree with point 9
| pplonski86 wrote:
| Maybe point 9, trust but verify, should be extended to AI
| coworkers as well. I would love to have tools to verify AI code
| by quantity.
| jrflowers wrote:
| Whatever human that is in charge of the chat bots is your
| coworker. That person that is responsible for the output of
| the bots is the one that you would trust but verify with.
| junon wrote:
| This is clearly a good EM. Agreed with pretty much everything,
| being on the engineering side. Stuff that seems trivial and
| obvious but that a lot of EMs miss.
| satisfice wrote:
| Why do people espouse goals like "not to be needed?" I never
| understood that. It sounds like LinkedIn virtue signaling. It's a
| capitalist talking point along the lines of "I seek to be good
| and inexpensive capital for my corporate masters."
|
| My goal is to help my team succeed in such a way as to keep my
| job or else get a better one. Being "not needed" hardly serves
| that goal.
|
| Look around you. We are in a world that is turning away from
| middle managers. Don't play into their hands.
| mulmboy wrote:
| Because it's a good heuristic for a functional and resilient
| team. People don't usually means it literally, more like "if I
| disappeared it should be pretty painless for the team to
| continue along for a month or so and to find and onboard a
| replacement".
| Keirmot wrote:
| The way I read it is not to be needed for normal functionality
| of the team, not to "not be needed" at all. Akin to a ship's
| captain - for the most part a ship works without a captain just
| fine, but that doesn't make the captain's job redundant, it's
| just he's needed for specific occasions, otherwise, he's just
| making sure the crew works as a well oiled machine.
| Rainbooow wrote:
| I think the points made at mostly for a front-line manager
| though, not so much for a middle manager.
| skirge wrote:
| cause it means: I lead them so good that I do nothing and still
| get my salary.
| mcapodici wrote:
| the coder's equivalent is not get paged (or bug reports). the
| system run's itself with no dramas, so I get to work on
| improving it.
| satisfice wrote:
| I think you don't understand what a manager does. As a
| manager, I'm not standing there telling people what to do all
| day. Instead I am creating the conditions for the team to
| succeed. This is an active and every day service.
| ebiester wrote:
| "Don't be needed" isn't "don't be valuable." The EM should not
| be a bottleneck. The EM should be able to take a vacation
| without being paged. (So should anybody on the team!)
|
| My teams would slow down without me because I can due process
| tasks more efficiently, but nothing demands me to be in the
| loop.
| ghaff wrote:
| Someone I know used to be pretty senior at a major SV
| company. Over dinner one night, he told me that the CEO would
| take vacations with instructions to the effect of "handle it"
| if something comes up. (Assume it wasn't absolute but that
| was the basic gist.) Apparently, a new PR head came in and
| was like "I can't work under that condition" and quickly
| left.
| onion2k wrote:
| The goal should be to have teams who _want_ you to be
| supporting them, not _need_ you to be supporting them. Getting
| teams to the point where they don 't need you isn't actually
| that hard. They might be only performing at 50% effectiveness,
| but that's fine if the work is getting done. You should build a
| relationship with the teams so they want you to support them to
| get to 90% or even more.
|
| If your teams fail to function without your help then you're
| clearly not supporting them well enough, and you can't take a
| vacation or go off sick _or be promoted_. That is not optimal
| for anyone.
| dasil003 wrote:
| You're taking it too literally, it's not saying don't be
| useful, it's saying don't make yourself a bottleneck. It's a
| very common failure mode for new engineers turned manager,
| leading to a frustrated team that feels micro-managed and the
| perception from leadership that you don't have your shit
| together and can't adequately handle the scope you've been
| given.
| satisfice wrote:
| Your interpretation does not fit the text. You are talking
| about someone who is micromanaging. But he's not saying
| "don't micromanage" in that section.
| mtippett wrote:
| A really good book on this is "Turn the ship around".
|
| Your role is to improve your staff to be better in their jobs.
| Ignoring the Manager/Engineer caste system, there is a lot
| general leadership in both roles.
|
| You want your staff to be able to integrate and find
| information that allows them to make decisions, you don't lose
| accountability or responsibilty.
|
| There is a big difference between
|
| - "I've looked at the details, and I think we should do X, what
| do you think?"
|
| and
|
| - "What should we do about this?"
|
| In the former, you can add extra context, and help your report
| understand details that may have been hidden or unknown to
| them. In the latter you are allowing your report to shift all
| the burden to you.
| satisfice wrote:
| I appreciate that book and that context, but that's not
| making yourself unnecessary. In this interview
| (https://www.youtube.com/watch?v=b9rGATwZRr0) Rear Admiral
| Mike "Nasty" Manazir talks a lot about empowerment, but also
| about how the commander of an aircraft carrier never gets a
| lot of sleep.
| matt_s wrote:
| Its more about being a servant leader and not a bottleneck than
| literally being "not needed". Its a mindset of wanting your
| team to be able to operate without having to check with you
| (the EM) on every little thing. I've also heard it called
| having IC's be a "manager of one" where they can independently
| work on things, get work finished, etc. without needing
| constant nagging.
|
| A good manager I had once had the approach of setting
| guidelines and "just getting out of the way" and I try to
| follow that, it works well for most people.
| satisfice wrote:
| I like being a servant leader. In no way does that mean I can
| go on holiday and people won't miss me. They will miss my
| services. If people don't miss me, then they must HATE me as
| a manager.
| rglynn wrote:
| I think of it this way:
|
| Is your goal for the software you write to need constant
| intervention, or would you say you'd aim for it to run smoothly
| with few bugs?
|
| The team is akin to a piece of software architecture, only much
| more complex and comprised (partially) of humans.
|
| You want someone to build that team and then have the team up
| and running, delivering value. When it breaks, or you want it
| to do new/different things, you need someone to step in to fix
| it or change it.
| satisfice wrote:
| The fallacy there is that I am not merely "building a team,"
| I am managing. Managing is a live, interactive skill that
| involves certain services. A perfect team still needs
| management to help create the environment in which that team
| can effectively operate.
|
| I saw a wonderful interview with a former commander of an
| aircraft carrier.
| (https://www.youtube.com/watch?v=b9rGATwZRr0) Rear Admiral
| Mike "Nasty" Manazir speaks of his main job as being clearing
| away obstacles that no one underneath him could clear. That's
| a service that no "self-managing team" can do for itself. A
| good manager also serves as a focus for the strategy, and
| deals with conflicts that would otherwise become impasses.
| vasco wrote:
| > People above you have limited time to focus on your specific
| issues. You can't info dump on them. If they take a misguided
| action based on what you tell them, it will be your fault
|
| This bit is useful to everyone, and many people never learn it
| and get jaded about work itself! They paint themselves into a
| dilbert strip without realizing. And then of course there's also
| bad bosses, but any work advice is like relationship advice, it
| really depends on the specific people involved.
| 20260126032624 wrote:
| 11. What works in one country doesn't necessarily work in
| another.
| palata wrote:
| > That's why lying or withholding information that affects them
| causes irreversible damage. They might not leave immediately, but
| they will resent you. [...] I have a friend who still resents a
| manager for a lie told three years ago.
|
| Oh yeah. To be fair, it's not only the case for managers. If a
| colleague lies to me, they lose my trust. But I have never had
| that... why would a colleague lie to my face or withhold
| information? That's a thing bad managers do.
|
| When a manager lies to me (or withhold information), it's never
| one time only; it's the way they work. And when they work like
| this, they are not in my team. They play against me, so I play
| against them.
| snarf21 wrote:
| There is an old saying that rings true here: "People don't quit
| jobs, they quit bosses."
| vachina wrote:
| All these properties of a good manager will come naturally with
| humility.
|
| Because being humble makes you more receptive.
| CBLT wrote:
| I've had great experiences being managed twice by very humble
| engineers who've made the transition to EM. Both were sacked
| within the year by their boss because they didn't play the
| corporate politics game.
| Schlagbohrer wrote:
| It's so disheartening to learn that one works for a manager
| who doesn't care about having the most skilled team, or best
| product, but rather someone who has selected for "Who will
| kiss up to me no matter what? Who will never tell me anything
| I don't want to hear?"
| Traster wrote:
| >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 Z. So frequently you'll find out that core
| assumptions have been made because everyone involved was only
| half-involved and either kind of assumed someone else was taking
| care of it, or (more frequently) knows the assumption is wrong
| but is choosing not to say so for political reasons.
| Schlagbohrer wrote:
| I sympathize with keeping one's mouth shut for political
| reasons. Having a boss who angrily shouts at anyone who dared
| use their own brain and offer an idea, I learned to keep my
| mouth firmly shut even if i saw countless problems coming down
| the road.
| arendtio wrote:
| It is one thing to do that while you have that boss, but
| something completely different to keep acting that way even
| when you have a different boss. The more people you have on a
| team who keep their mouths shut, the less effective it will
| be.
| Traster wrote:
| It's totally understandable, but it would have been good to
| have been given a heads up - I'm totally new at the company
| (new to the industry), assume _one_ of these people knows
| what they 're doing. In the end I got a new boss and
| convinced him to take a different approach once the first
| approach failed, but I would not have blamed my new boss for
| just binning the entire project and getting rid of me.
| OhMeadhbh wrote:
| 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 complicated by the fact that Marines deploy as MEUs,
| MEBs and MEFs [1] which aren't "pure" echelons, but it's a rule
| of thumb and guiding principle more than a hard and fast
| requirement.
|
| I've ALWAYS been annoyed by engineering organizations that
| don't think developers at the leaf nodes of the org chart need
| to know what's going on. Devs may not do anything with the
| info, but letting people in on what's happening seems to send
| the message that "management thinks you're important enough to
| hear what we're working on" and every now and again, individual
| devs need to make decisions that depend on these more abstract
| / higher-level goals.
|
| 1.
| https://en.wikipedia.org/wiki/Marine_air%E2%80%93ground_task...
| anarticle wrote:
| My dad is a retired Marine and I learned several things from
| the NCO system and Marines in general: good leaders
| (EM/Sergeant) will generally never ask you something they
| cannot also do (implies they are your peer, even if they are
| not), and Marine Corps manuals are able to take anyone who
| can read and make them operate technical things. Their
| manuals are written in a very direct stepwise way to get
| people up to speed in doing whatever task they are assigned
| which I learned early on is just plain good documentation.
|
| Servant leadership works really well when you have high
| agency individuals, and can grow high agency individuals. I
| have definitely been on the other side of that with control
| freak machiavellian / nearly adversarial leaders as well.
| bloomingeek wrote:
| <Servant leadership works really well when you have high
| agency individuals, and can grow high agency individuals. I
| have definitely been on the other side of that with control
| freak Machiavellian / nearly adversarial leaders as well.>
|
| This. Every time I've lead people, IF they were already or
| were able to become high agency, we were efficient and
| capable. Control freak managers were usually guilty of what
| they obsessed over before they became managers. Good
| workers always leave bad managers in time, which always
| hurts the company.
| psunavy03 wrote:
| As a former Naval Flight Officer, it's somewhat ironic how
| the private sector is more "sir, yes sir" command and control
| than the military ever was, and they're the ones who
| stereotype servicemembers for being drones who can only
| follow orders.
|
| 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.
| ryandrake wrote:
| > 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.
|
| I think a lot times, office workers will be reprimanded for
| taking action if they don't realize their chain of command
| are not supportive. Have this happen a couple of times, and
| you will quickly move into this mode of "I'm not going to
| do anything I'm not told to do." I can recall more than one
| former company where taking the initiative to perform some
| action independently was _very_ risky to your career there.
| fogzen wrote:
| Because every time I've done something of my own
| initiative, one of three things happens:
|
| 1/ I'm punished or reprimanded for doing something that my
| time wasn't explicitly scheduled for. This comes from
| managers.
|
| 2/ Nobody cares and I'm now further behind on the things I
| committed to.
|
| 3/ People care, are happy I took the initiative, but I'm
| not materially rewarded in any way. At worst, I'm given
| more work.
|
| In all cases I am no better off. I just don't do it
| anymore. Employers don't want employee autonomy, so they
| don't get employee autonomy. Employers only want to give
| paychecks not profits, so they get employees who only want
| paychecks.
| OhMeadhbh wrote:
| When my boss (non prior service) at Amazon found out I was
| prior service he said "I want to run my group like a
| military unit." Without thinking I blurted out "what? you
| want to spend 80% of your budget on training?"
| Schlagbohrer wrote:
| Good advice in the last point about interviews. "While you're
| scheduling the seventh round, good hires are already accepting a
| job elsewhere." I gave up on a job I was lukewarm about when,
| after flying me there for an all day site visit and hours and
| hours of technical interviews, they then wanted me to do 3 days
| of video calls with various groups around the company! People i
| could have simply met for 15 minutes in person when I was there.
| In all the time this took I accepted a much better job closer to
| home.
| OhMeadhbh wrote:
| > "Most engineers prefer feeling appreciated over having a ping-
| pong table."
|
| Truer words have never been spoken. Note the OP put the word
| "Most" in there. Sure... there are a few ping-pong fanatics, but
| not as many as there are humans who like an emotionally
| fulfilling work environment.
|
| A related sentence I've uttered is "Most engineers prefer more
| control over their daily tasks than cash bonuses." But again, the
| word "Most" is doing a lot of heavy lifting here. My experience
| is no more than 25% of devs will trade cash for micro-management.
| YMMV.
| tmarice wrote:
| This kind of EM-focused articles often mention "coaching" and
| "career growth" -- I always wonder what does this concretely
| mean. Are they all managing teams of juniors straight out of
| college?
|
| What can a career EM, or even an engineer-to-EM convert who has
| been out of the coding game for more than a few years, teach a
| non-junior engineer on their team?
|
| I understand we can talk and exchange our concrete life
| experiences, same as I would talk to and listen to any other
| person, but the word "coaching" implies one party is superior to
| the other in one very concrete area.
| __alexs wrote:
| I am not an EM (anymore) but I see a lot of more junior
| engineers struggle with ambiguity and complex decision making
| in general.
|
| It is not uncommon to end up in situations where there are not
| clear right answers and developing the techniques as an
| individual, and as a technical contributor to navigate these
| well is tricky.
|
| I don't think this is an EM specific function at all though and
| is just something more experienced people should be doing for
| their team. I think the EM definitely has a role in making sure
| people identify that they could benefit from that kind of help
| and make sure they find it, but doing the actual coaching is
| optional.
| GabriDaFirenze wrote:
| Coaching doesn't imply superiority. Most coaching can be done
| with little to no context and the goal is to guide the other
| person in finding the right answer on their own. I think you
| might be confusing coaching with mentoring.
|
| As an example, I attended a coaching training session and when
| we broke out in groups I played the coach role. The other
| individual brought up a concrete issue they were having and I
| was able to unblock them and I never met that person before. I
| was their guide even though I had no context (but I have
| experience mentoring and coaching).
|
| I've been a manager for years and there's a lot outside of raw
| technical ability that a good coach and mentor can keep you
| honest on. Rarely will you find someone who's reached full
| potential or who doesn't want to improve at all (maybe
| surprisingly based on your comment but I have found seniors to
| be the most eager to grow)
| tl wrote:
| Most of the job is noticing friction and clearing paths --
| which requires context and trust more than technical
| superiority.
|
| In practice: Start a note for each engineer you manage. Fred
| Brooks called this a "career file". Start by writing down
| things that frustrate them enough to complain about publicly.
| Add hurdles that come up in their one-on-one. Identify problems
| you can solve, problems you understand but cannot solve right
| now and problems you do not understand.
|
| Then put on your PM hat; sort by priority and execute.
| djb_hackernews wrote:
| I am an EM that manages several senior engineers currently. I
| find it super common for senior engineers to get promoted
| mostly on technical merit, we end up thinking the rest "can be
| coached". Or it's coaching to the next level. Here are some
| areas I coach them on:
|
| - influencing without authority. Managing up. Leadership.
|
| - getting work prioritized
|
| - providing useful performance feedback (promos etc)
|
| - coaching and giving feedback to early career engineers
|
| - communicating ideas effectively
|
| - developing 1YP+ plans for their areas.
|
| - idk, there are a lot, senior engineers are rarely "complete"
| parthdesai wrote:
| I'm sorry, but if a senior engineer needs coaching on getting
| work prioritized, they are not a senior engineer.
| johngunderman wrote:
| I interpret this comment as talking about prioritization
| across a broader org. A senior engineer should be able to
| prioritize inside of their team and adjacent teams. But
| there is a reason why there are levels of engineer beyond
| senior - beyond just increased technical judgement, there
| is increased influence in orgs spanning hundreds or even
| thousands of engineers.
|
| There is always opportunity for growth in this dimension.
| For example even the CEO has to build the right skills to
| convince the board of their priorities.
| ecshafer wrote:
| I worked with someone who had 30 years of experience, and
| would routinely go down rabbit holes of minimal value that
| they thought were valuable. Days spending on local
| environment setup and configuration scripts, for multiple
| platforms, when it only took a few commands to start
| everything up in a few seconds. Or making custom patterns
| to "improve maintainability" of the code base, that were
| brittle, overly abstract, and confusing.
| parthdesai wrote:
| Well in my opinion, they really aren't a senior engineer
| then. 30 years of experience doesn't automatically mean
| you're a senior engineer IMO.
|
| To me, you can trust a senior engineer to get the project
| done properly without any oversight
| fleabitdev wrote:
| > 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?
| ratorx wrote:
| 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.
| fleabitdev wrote:
| 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.
| kenjackson wrote:
| 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.
| fleabitdev wrote:
| When working as a senior engineer, I've never been given
| enough business context to confidently say, for example,
| "this stakeholder isn't important enough to justify such
| a tight deadline". Doesn't that leave the business side
| of things as a mysterious black box? You can't do much
| more than report "meeting that deadline would create
| ruinous amounts of technical debt", and then pray that
| your leader has kept some alternatives open.
| ratorx wrote:
| 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.
| djb_hackernews wrote:
| 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.
| fleabitdev wrote:
| 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.
| taude wrote:
| 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....
| dilyevsky wrote:
| 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 =)
| madeofpalk wrote:
| 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.
| 0kl wrote:
| In my experience, I have used coaches that don't have more
| technical skill than me, but are able to provide insight,
| questions, and provoke me to think through my problems in ways
| I might not have otherwise.
|
| I break things down into coaching vs training vs mentorship.
|
| Training is when you need to learn a very specific skill from
| someone that knows more than you. A great example is learning
| how to drive - it requires training from someone who knows more
| than you.
|
| Mentorship is when you need to grow more holistically and are
| learning from someone that is significantly more advanced in
| your chosen area of study than you. Usually this involves not
| just technical training, but also a mindset that you wish to
| learn. Examples of this are apprenticeships or when you seek
| out a mentor that you think has done well and wish to learn
| from.
|
| Coaching is when someone may not have more technical skill than
| you, but is still able to help you improve by probing,
| prompting, reflecting, or observing. A great example are sport
| coaches, who are not necessarily more skilled than many of the
| players they coach.
|
| These are loose and blurry definitions, but I hope it helps
| frame another perspective on coaching.
| idiotsecant wrote:
| Dude, soft skills. 80% of any job, software development
| especially, is messy human problems. Engineers more than anyone
| can generally benefit from improving these skills.
| saidinesh5 wrote:
| 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
| demystified the large codebases to my younger colleagues.
|
| Same with many other topics - the event loops behind the
| JavaScript async/await, memory mapped io behind every
| read/write calls their operating system syscalls, basic data
| structures/algorithmic complexity behind their DB queries,
| scenegraphs and graphics APIs behind user interfaces etc...
| especially when pair programming.
|
| I don't think I'm superior to them in any of these areas. I
| feel I'm fairly slower than them when writing code in any of
| these things. I definitely haven't kept up with all the changes
| in web frameworks or CLI tools or vim plugins. But sharing the
| behind the scenes knowledge helps them write better code is
| what i felt.
| addaon wrote:
| 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.
| saidinesh5 wrote:
| Good point.. A lot of those colleagues were indeed either
| fresh out of college (math, computer science, mechanism
| etc...) or graduated in things like electrical engineering
| etc.. and worked in software roles for 3-5 years..
| tv26101617 wrote:
| Top tier sports people still have coaches. Some even have
| multiple coaches. Musicians have managers.
|
| Unlike coaches for kids/ novices these folks aren't necessarily
| better at the craft.
|
| Yet, they (ideally )have a outside perspective that would
| improve an individual in their craft.
| throwaway173738 wrote:
| Coaching in my role is mostly about seeing the person up for
| promotion and helping them focus on the right stuff for the
| teams success. Even great senior engineers sometimes lose focus
| or miss the sentence in s career ladder that doesn't mesh with
| what they want to be doing.
|
| I've got a senior IC who is always hesitant to reach out to
| non-engineers, so to coach him I'm constantly asking him to
| reach out directly. It will improve his impact if he does so.
| devdp430 wrote:
| The mindset shift from IC to EM is very complex. And the newly
| appointed managers don't always know how to not be a programmer
| when in that role. It sometimes bleeds into the reports' work
| and damages than helping.
|
| I guess the "coaching" is to understand that mindset shift.
| dasil003 wrote:
| How does a football coach do their job if they can't run or
| throw or block as well as the players?
| nitwit005 wrote:
| Their job in professional leagues isn't to provide some sort
| of educational instruction, it's closer to being a
| strategist.
| parthdesai wrote:
| Not an EM, but definitely think a strong technical EM can
| provide valuable feedback when it comes to system design and
| data modelling.
| jampa wrote:
| There are already some great responses, but I want to add that
| one effective way to coach senior employees is to give them
| responsibilities one level above their current role and then
| provide feedback.
|
| For engineers aiming to move into management or staff
| engineering, you can assign them a project at the level they
| aspire to reach and give feedback once they complete it. For
| example, for an engineer aiming to be an EM, I expect them to
| lead not only meetings but also all communications related to
| this project, while I act as their director. Afterwards, I
| provide feedback.
|
| It doesn't have to be that extensive right away. You can start
| small, like asking them to lead a roadmap meeting, and then
| increase responsibilities as they improve. Essentially, create
| a safe environment for them to grow.
| doctaj wrote:
| Here are a couple more things: - holding people accountable to
| their own goals - like getting a certification or learning
| about a particular, new topic. This benefits the company by
| having more highly trained people, and the individual benefits
| from higher success rates or more depth of learning
| accomplished. - setting expectations for promotions. Often,
| it's a squishy guessing game about when a promo will come, but
| if you're able, you can set the bar and hold the person to that
| to set them up for success. - one tangible example of coaching
| is just noticing bad behaviors -- like, being late to meetings,
| lazy code, missing deadlines... and letting the person know
| you've noticed it, understand what's going on, and hold them
| accountable to stopping the bad behavior.
| super_mario wrote:
| Coaching does not imply superiority. I doubt any sports coach
| could substitute any player in a competitive game, yet they can
| coach them to become better version of themselves.
|
| What engineers usually struggle with as they grow into more
| senior roles is the transition from being primarily a
| technologist to being a leader. This is such a huge shift for a
| lot of engineers and requires soft skills and communication
| style adjustments. The more senior you are the more your focus
| shifts from coding to listening, networking, influencing,
| selling the technical vision, building trust relationships,
| understanding what other engineers need and want, to mentoring,
| to raising the quality of the team around you through influence
| to motivating others as well. Being able to influence the
| product direction, being able to express in business terms why
| something has to be done or should be a higher priority etc.
| Also, understanding the organization and becoming
| organizationally savvy is important.
|
| All of these skills take time and practice to achieve, and good
| managers can guide their people through the journey.
| singleshot_ wrote:
| > the word "coaching" implies one party is superior to the
| other in one very concrete area.
|
| The opposite seems obvious to me. After all, your manager isn't
| writing the code. He's not your boss because he's a better
| coder than you are, but because he's a better boss.
|
| (If this does not fit your experience, I'd recommend quitting
| your job as soon as practicable).
| crjohns648 wrote:
| > 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, however, really appreciate the
| transparency. It helps them feel more in control when they know
| what is happening around them, and when things do change they can
| tie it back to something that was said previously.
| fidansin wrote:
| Kinda like; You got to do, what you got to do.
| ghaff wrote:
| The basic question is how much context do you actually want
| if you can't really affect it and it's therefore more of a
| distraction than useful input. Some is almost certainly
| useful but it probably varies by individual and situation.
| gambutin wrote:
| 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.
| _blk wrote:
| As a leader, it's important to provide not just the meat but
| also the veggies. What people end up eating is up to them,
| but serve the full course! If as a ME, I start deciding who
| needs to know what, information will be perceived as
| incomplete because people _always_ talk and engineer are
| often smart enough to read between the lines. So the
| transparent umbrella is a great analogy. Communicate bad news
| as fast and coherently as possible - group meeting with open
| questions works well for me but be ready to address the
| potential fears: "In my current assessment, that's not going
| to be a problem, I'll let you know if that changes." and of
| course "Thanks for asking, I didn't consider that and I don't
| know yet. I'll clarify" is a valid answer, if you do indeed
| clarify.
|
| If you're genuinely stressed with that, talk to your lead
| about it and they'll find a way to filter a little more while
| not giving you the feeling of being left out.
| DrBazza wrote:
| Knowing more about your company and how well your employer is
| doing allows you to plan your exit strategy.
|
| If you get stressed about that, imagine finding yourself
| redundant by close of business today, and job hunting from
| tomorrow.
| jamesfinlayson wrote:
| Very much this - often the signs are there but I'd always
| be grateful for a heads-up.
| gambutin wrote:
| I humbly disagree.
|
| I want to be aware of enough to be productive, yes, but not
| so much that I get bogged down in the minutiae of corporate
| politics and can't focus on my daily work.
| madeofpalk wrote:
| You're right, probably not everything! It's a managers job to
| understand what you don't need to know or worry about. But I
| find it very useful to understand _why_ something is
| happening, or what else is happening out there that might
| have an impact on us and we should worry about.
| Scubabear68 wrote:
| > They protect the team from unnecessary stress and pressure,
| but don't hide reality from them.
|
| I was going to highlight this as well, but it is also one of
| the trickiest parts of the equation, because by definition this
| inevitably involves a lot of politics and social implications.
|
| What I have learned over the years: let the overall direction,
| and also the overall competitive pressures, filter down through
| your umbrella. But shield them from the details and your
| specific efforts here, unless it is relevant.
|
| Maybe even more important, though - recognize inflection points
| in your company and your group. How you manage during routine
| times and during stressful times may well be very different. If
| they're not, then you have a serious problem.
| ghaff wrote:
| I agree with that. It's useful for (most) people to
| understand the overall environment the company is operating
| in. Probably less every top-down decision the company is
| making.
| randoglando wrote:
| That's true for a junior engineer, but the more senior
| engineers should be given a view into the organization's
| priorities and business challenges.
| gramie wrote:
| I recall hearing that Google had a term similar to this:
|
| A "shit umbrella" was a manager who protected the development
| team from all the politics, blame, and mismanagement coming
| from above.
|
| A "shit funnel" was a manager who directed all the shit coming
| down, directly onto the team.
| mikestew wrote:
| Not that it originated with me, but I was using that metaphor
| long before Google showed up.
| BerislavLopac wrote:
| Yeah, I've been using "shit umbrella" for a long time. But
| the "transparent shit umbrella" is an even more powerful,
| albeit more disturbing, metaphor.
| tharkun__ wrote:
| I wouldn't say more disturbing, really. But more
| "enlightening".
|
| A shit umbrella is great to have if the alternative is a
| shit funnel. But how are you gonna appreciate the shit
| umbrella if it's pitch black, blocks everything at all
| times?
|
| You're not gonna appreciate it. In fact, you might think
| some of the things your manager does are the "bad things",
| when in fact, it's just the umbrella bowing under all the
| shitload.
|
| If the umbrella is (somewhat) transparent, you, as the
| manager, gain some legitimacy through transparency. You're
| no longer the manager that "sits around on his ass all day
| doing nothing". You're actually doing something for the
| team and they can "see" it, even though it doesn't affect
| them.
| evilduck wrote:
| You forgot "shit spewer". One who creates the shit that
| someone else has to then deal with (usually organizational
| peers or the team beneath them).
| _whiteCaps_ wrote:
| I've always called those folks seagulls - fly in, shit on
| everything, and take off again without having to deal with
| the consequences.
| zerkten wrote:
| >> 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.
|
| 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.
| Shalomboy wrote:
| My favorite manager told me a similar analogy before I left,
| but with a caveat; a good manager has to provide cover for the
| team, but it's up to the team to hold the manager up - just
| like an umbrella.
| jamesfinlayson wrote:
| > require knowing the personalities of your reports
|
| I think this an underrated quality.
| v_CodeSentinal wrote:
| The point about 'no such thing as a free lunch with processes' is
| something I wish more junior EMs understood.
|
| I've seen so many teams treat process as a pure 'fix', ignoring
| that it's always a trade-off: you are explicitly trading velocity
| for consistency. Sometimes that trade is worth it (e.g.,
| payments), but often for internal tools, you're just paying a tax
| for consistency you don't actually need.
| talkingtab wrote:
| Enough already. The way to determine what kind of manager a
| person is, is to listen for the context they use. For an extreme
| hypothetical example, if you hear a manager talk about locking
| their team in their cells every night, you will know something
| about their context.
|
| If the manager says "They look to you for leadership and
| clarity", you know something.
|
| It they quote Jeff Bezo, that provides more definition.
|
| The lesson to learn from this article is not the words, but the
| context. What is the context you find in this article? How does
| this person talk about other people? What assumptions are
| inherent in this article? If you find this normal, what does this
| say about your assumptions?
|
| What I have learned from my years of being an engineering manager
| is that the corporate model of software development is fubar.
| PlatoIsADisease wrote:
| > How does this person talk about other people?
|
| I find myself referring to my contractors as: Workers.
|
| What does that mean about me?
|
| I can't call them employees. I read the communist stuff a while
| ago and decided I didn't want to be exploited, so I thought
| this was just the proper terminology.
|
| But people on the internet loath being called a worker and have
| called me out on this.
|
| Meanwhile I yoyo between to nice and too hard... I think I'm
| naturally too nice to the point of failure. I seem to only be
| 'too hard' for a few months before I go back.
|
| Thank god my industry is high demand, I think even with bad
| management we will survive. (I got a masters in Engineering
| Management + read 10 books, but management/supervision
| orthodoxy is diverse and contradictory.)
| videogreg93 wrote:
| > 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 sure why
| we think the flip side of that is true.
| 1980phipsi wrote:
| At the end of the day, the goal is to make a product that
| people find useful. How that ends up happening is almost
| completely irrelevant to the people actually using the product.
| SkyPuncher wrote:
| If you consider product as a proxy for customer, I think it
| gets a bit easier to understand. Customers don't care about
| architecture (unless you have a technical product where they do
| actually need to know architecture). They don't care about many
| of the details. They just want their problem solved.
|
| For software engineers, our goal isn't to necessarily know what
| makes good product or not - but we do need to make sure that
| what we're building solves an actual customer problem or need.
| tristor wrote:
| > We don't say "Everyone needs to care about software
| architecture, even Product"
|
| 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.
| hnthrow0287345 wrote:
| >The most common reason companies fail is creating products that
| don't deliver value to users, causing them not to pay.
|
| >"Oh, but I have a PM for that," you might say. But having a PM
| is not enough.
|
| It should be, that's literally their job. Developers and EMs
| shouldn't be doing that part for them.
|
| In the same way developers need to know how to ifs and loops,
| Product Managers need to find out which features to build and
| user pains to fix.
|
| _Maybe_ , _just maybe_ , we need to stop raising the bar for
| interviewing developers and start raising the bar for the other
| people working with developers, instead of getting developers to
| compensate for shortfalls.
| AndrewKemendo wrote:
| There's a reason you never see posts like: "My jump from BD to
| software engineer"
|
| I've never met a sales person as broadly capable as your
| average engineer.
|
| The curse of competence is organizational as well
| ghaff wrote:
| Because your average engineer is _so_ good at creating
| customer relationships and generating revenue.
|
| Customer relationships are certainly more important in some
| categories than others but sales is certainly key in a lot of
| B2B organizations.
| AndrewKemendo wrote:
| I guarantee I'll be more successful with a group of
| engineers doing sales than I would a group of sales people
| trying to do engineering
| ghaff wrote:
| Both would generally be crap in isolation. (Assuming non-
| overlapping skill sets such as solution/system
| engineers.)
| derwildemomo wrote:
| I was wondering about that for a while now - it feels in my
| last few jobs as an EM, the major part of my work (or rather
| the most influential one?) was managing, coaching and guiding
| product. The realization was actually quite simple for me:
| while hiring in engineering is defined by an sometimes absurd
| number of interviews, code challenges and so on, product is a
| case study and you're good: and that doesn't seem to be doing
| the trick.
| gedy wrote:
| This is one of the reasons I think the "replace developers with
| ai" doesn't really fly in reality, as devs/engineers are
| typically the smartest people in any company I've worked for in
| a few decades. I don't see how the other folks could pull the
| weight via prompting.
| Aurornis wrote:
| I think dividing responsibilities across so many different
| managers has become too much of an anti-pattern for small and
| medium sized companies.
|
| The least productive tech companies I worked for in the past
| decade had a nearly 1:1 ratio of engineers to different manager
| types. Our teams of 3-4 engineers had to work with our
| engineering manager, a product manager, a project manager, and
| a program manager at minimum. If you did UI work you would work
| with another UI/UX manager.
|
| The minimum timespan to get anything done was measured in
| quarters. You could expect to have to spend more time
| scheduling meetings and following up with all your different
| managers by a factor of 10X or more than time spent doing
| anything related to code.
|
| Contrast this with another employer I had who was very clear
| about the fact that we were not a big tech company and we were
| not going to structure our teams like one. We kept team units
| small and made them work together as a unit, not a disparate
| collection of managers that had to be appeased. We shipped a
| lot and we shipped fast.
|
| We need to stop trying to use complicated and divided
| management structures everywhere. Companies with small teams
| and clearly unified management structures will always perform
| better than the management styles where responsibilities are
| divided across 5 different people and even basic work requires
| coordinating all of them through meetings
| SkyPuncher wrote:
| This is a good article. In fact one of my favorites now (will be
| sending it to my peers).
|
| There's a point buried in it that I increasingly come to believe
| is missed in nearly every single management book and management
| advice I've read. It's almost there in point 1, but under "don't
| have a PM".
|
| None of these points matter if you're not creating value for your
| company. That is the job of a manager - get your team to create
| value.
|
| I've been increasingly disgruntled with most management advice
| because it overlooks this key point.
|
| I felt like one of the biggest steps back I took in my career was
| when one of my companies had our management attend training that
| taught these skills and then the company emphasized these skills
| repeatedly. Suddenly my career stagnated. I had managed before, I
| had led before, I had delivered results before. But my growth
| came grinding to a halt. I was following all of these tips and
| tricks while overlooking the implicit thing - deliver value.
|
| In many, the same ways, I've become wary of any company beliefs,
| values, or guidelines that aren't clearly working towards making
| the company money. They're really just distractions for the
| underlying goal.
| joshcsimmons wrote:
| Correct on all points! Very well put - you sound like an
| excellent manager.
|
| As always the difficulty is in getting people outside your team
| to realize that the 60% cheerleading bit is crucial, many will
| see this as a waste of time that doesn't create "business value",
| as if the only business value was measured in lines of code.
| bradley13 wrote:
| "Delegate everything" - delegation is hugely important. But not
| everything, obviously, as a team lead your responsibility as
| "transparent umbrella" cannot be delegated.
|
| It also sounds like he is talking mostly about external projects.
| For internal projects, you really do serve as a shield. One
| project, I spent my first months teaching the internal customers
| that they _were not allowed_ to talk to my people. They had
| become accustomed to telling individual developers "I want
| feature X", which cause total chaos.
|
| I stood between the customers and my developers - at the
| beginning, sometimes literally blocking the office door - and
| said: my team, my job, you talk to me.
| rendaw wrote:
| > Never ask the interviewer what they expect from a manager. Some
| managers assume their experience is industry standard and might
| find that question odd.
|
| 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.
| gorpomon wrote:
| This is all really good stuff, and thankfully I feel like I have
| been practicing a fair bit of this already (so, I could be biased
| here!).
|
| 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).
| highfrequency wrote:
| > you need to stay off the critical path. As soon as you start
| handling essential tickets, you'll block your team when
| managerial work pulls you away.
|
| Very well put
| Insanity wrote:
| Similar to the article, I always think of it as my job to make
| sure the team has the mechanisms in place to continually deliver
| high quality software, even without me.
|
| I once had a senior engineer blatantly say: "that means you're
| just being lazy, your team should be dependent on you".
|
| Scary to think that engineer was a manager earlier in his career.
| mtippett wrote:
| Lots of good advice there. I did pause on the "Be risk adverse".
| My take is
|
| - Be Risk Aware - know them, quantify them, manage by mitigating
| or having contingencies
|
| - Don't be Risk Averse - Averse means being avoidant of risks or
| disinclined, it's safer, but it means risks aren't taken.
|
| - Don't be Risk Paranoid - Protecting against unseen risks wastes
| time and efforts.
| dakiol wrote:
| As an IC that's been in the industry for over a decade, I don't
| see myself jumping into the management track. I just can't. I see
| my calendar and I see few meetings, and typically I have the
| power to move some of them (because some of them are arranged by
| me). I see my manager's calendar and it's constantly packed with
| meetings he probably cannot move. Worse than that, I see for
| instance he has one meeting at 10, then another at 12, then
| another at 3 and then another at 5. Like, you cannot escape that
| hell. I start my work at 10, work solid 4-5 hours or so and then
| close the laptop. I cannot sacrifice that kind of freedom
| willio58 wrote:
| As someone who did get on the management track a couple of
| years ago myself, I think it's great you have that perspective.
| I miss being able to turn on some tunes, code for a few hours,
| and call it good for the day. At the same time, I have always
| naturally fell into leadership positions I think mainly because
| I like helping people make better decisions. As an IC, I
| despised broken processes, bad decisions from product, and
| overall poor management. As an engineering manager, I have some
| amount of control over these things and I hope those I manage,
| as well as our users, have benefited from me being in this
| role.
|
| A few examples of things I heavily influenced:
|
| - reduction in investment of time, effort, and cost going to
| offshore engineering. We've reduced bugs and effort from our
| engineers in coordinating between disparate time zones.
|
| - advocacy of a design system shared between design and dev
| teams. We now have one.
|
| - reduction in the amount of meetings our devs are expected to
| attend weekly, increasing time they can spend building
|
| - heavily advocating to reduce number of clicks for our users
| to get where they need to be, benefit UX greatly
|
| - better defined incident management process
|
| It's not perfect though, the amount of control I have is still
| limited, and I am in meetings basically all day sometimes.
|
| While I will say that would have sounded like hell to me a
| couple of years ago as an IC, I have been able to sway the
| direction of the company meaningfully in ways that feel
| ultimately more impactful than what I could have done jamming
| on some code in the same amount of time. The cost of doing so
| is a little more stress, but hey I get to do so from the
| comfort of my home and I'm allowed a good amount of schedule
| flexibility outside of some specific meetings each day. It's
| definitely not for everyone though!
| kaydub wrote:
| And most the meetings end up with the same people in them where
| we're just repeating the same shit to an additional 1-2 people
| per each meeting
| throwaway8177 wrote:
| This is a great list!
|
| The biggest lesson for me was that your job as a manager is to be
| the soft power representing the authority of the investors.
| Everything else you hear about management is people rationalizing
| their role and figuring out how to tow the line. That's why it's
| so hard and stressful.
|
| The hardest lesson comes when you're ordered to fire someone from
| your team. HR has decided to implement a performance rubric and
| wants to maintain the company's position in the hiring market
| place as a competitive place to work. You must fire the poorest
| performing member of your team. Who do you pick?
|
| That's the essence of management. Who do you reward, who do you
| punish, how do you show that you're towing the line?
|
| Most folks, myself included, are promoted into an EM role. No
| training. No certifications. If you're lucky you get a few
| training videos from HR if the company you work for is big enough
| to have an HR department. As an EM you are now in charge of the
| careers of the people who work under you.
|
| This is why you get such a high variation in the quality of EMs.
| Some people are a nightmare to work with. If they get a bad
| impression of you there's nothing you can do. You're cooked when
| it comes time for that manager to let someone go. There are no
| objective metrics. They have to pick someone and they will find
| the reasons.
|
| I left management because I couldn't handle it. Too stressful.
| nitwit005 wrote:
| > Everyone needs to care about the Product
|
| > A few times in my career as a developer, I wondered, "Who is
| this feature even for? Who will use it?" No one on my team knew.
| We were doing it because we were told to. Morale was low. We felt
| we were working on things that didn't matter - and we were.
| Eventually, our team disbanded, and engineers scattered across
| other projects.
|
| There's no way they had no idea what it was for. They thought the
| idea was dumb, and they wanted off a sinking ship.
| Buttons840 wrote:
| I struggled as a team lead, a manager of sorts.
|
| I was expected to do some programming, and so the "failures" of
| the team (which were often just normal human limitation) I would
| deal with by personally doing all the work myself.
|
| Has anyone else experienced this?
___________________________________________________________________
(page generated 2026-01-27 10:01 UTC)