[HN Gopher] Mistakes as a new manager
___________________________________________________________________
Mistakes as a new manager
Author : Sharpie4679
Score : 282 points
Date : 2024-12-06 16:56 UTC (1 days ago)
(HTM) web link (terriblesoftware.org)
(TXT) w3m dump (terriblesoftware.org)
| eastbound wrote:
| List is toi short. I'd add: Posture.
|
| Everyone wants to be the benevolent manager, especially if there
| is enough money for everyone, and especially in these times where
| collaboration and positive management are touted. But you have to
| keep a carrot and a leash on the employees.
|
| My first employees got a 33% raise the first year things were
| good. Long story short: None of them are here anymore and we're
| still scrambling to recover from the mess they've created by
| being lazy.
|
| Now people struggle to get a few percent salary increase. It eats
| me to my core, but I want them to get my product out.
| chasd00 wrote:
| heh i will say being a parent helps with being a manager. You
| really understand the carrot/stick balance as a parent.
| dowager_dan99 wrote:
| true! I'm not really kidding when I "joke" that being a
| father of three has helped shape my management style. The
| value systems and overall approach are really similar :)
| Joel_Mckay wrote:
| I have to admit I initially hired a few Papered Posers, and it
| was a mistake to pay them 2.4x higher than market rate to
| ensure the project would reach conclusion on schedule.
|
| The lessons we learned:
|
| 1. "Manage or be managed...": your first lesson is people will
| try to manipulate those in positions of authority regardless of
| competency. i.e. the idea of "goodwill" being the true core
| product can escape the irrationally ambitious/sycophantic.
|
| 2. No amount of money can make someone care about company
| projects. The worker may be interested in the project, or is
| simply there for the wrong reasons. Remember you want to keep
| employees content, but a "kingdom of kings" is unsustainable.
|
| 3. People can postpone something until tomorrow indefinitely.
| Thus, pay very close attention to projected deliverable times.
|
| 4. Fire someone for being unproductive according to a defined
| workmanship-standard as soon as possible. It will notify the
| rest of staff you are not there to play games, and stupid
| behavior will have consequences. Mostly effective with Jr staff
| using ChatGPT to try and BS the world like any other con.
|
| 5. Delegation? Just initially run trial contracts with
| potential staff first for each project deliverable. Failure to
| deliver on time means they don't get another dime, or a second
| chance to be unaccountable for their behavior.
|
| 6. Entrenched incompetence: organizations have their own
| emergent structure, and it will usually drift back to the same
| dysfunctional patterns/designs.
|
| 7. Redacted
|
| 8. try to leave things slightly better than when you arrived.
|
| 9. Managers usually can never be a normal employee again.
| People subconsciously fear they cannot control authority, and
| will prefer to hire someone easier to "handle".
|
| Best regards, =3
| KerrAvon wrote:
| You may wish to talk to someone to evaluate whether the
| company you work for might be completely dysfunctional-- none
| of that list sounds like it's coming from a healthy place.
|
| > 9. Managers usually can never be a normal employee again.
| People subconsciously fear they cannot control authority, and
| will prefer to hire someone easier to "handle".
|
| This is usually not the case at a FAANG, for whatever it's
| worth. Multiple people I know have voluntarily moved back to
| IC from management positions. It's not that unusual for
| senior devs to try managing and figure out that they don't
| like it (whether or not they're good at it) and then move
| back into being a highly regarded IC.
| Joel_Mckay wrote:
| My personal experience with titles has always been
| complicated.
|
| By the time a corporation has reached FAANG scale, they
| become boring and ultimately immutable out of necessity. I
| find it sad many folks dream of joining that drudgery,
| inventing nothing, and gambling on asinine business plans.
| =3
| osigurdson wrote:
| >> Failure to deliver on time means they don't get another
| dime
|
| "On time" can be achieved by over estimating. As a
| hypothetical, dev A estimates that a project will take a year
| and completes it in 6 months. Dev B estimates 1 month for the
| same project and completes it in 3.
|
| Companies that focus too much on things being "on time"
| ultimately get the "nothing is worth doing" corporate
| culture.
| Joel_Mckay wrote:
| Actually, sometimes it means hiring rank amateurs, and
| training them to reliably complete tasks like a real
| business. Understanding the time constraint would be lower
| for Jr, and thus the equivalent pay scale will be less
| lucrative... but it is up to individuals to decide their
| own work ethics.
|
| Using PERT deliverable/vertices redundancies is often
| necessary for projects no one has seen before:
|
| https://en.wikipedia.org/wiki/Program_evaluation_and_review
| _...
|
| Note, the simple system uses probabilistic time estimates
| of key deliverables, considers redundancy, and explicitly
| mitigates teams that introduce liabilities.
|
| If it put people on the moon, than I figured it was good
| enough for most of my ridiculous projects. Have a great day
| =3
|
| Rule #17: "Always listen to the person that signs your
| paycheck. Everyone has an opinion, but some opinions are
| more profitable than others"
| osigurdson wrote:
| I think the PERT chart is pretty accurate. The issue is
| typically predicting what all of the nodes on graph will
| be ends up being a waste of time. Instead, there are
| really just two points: current state and desired state.
| It is better to spend time clearly articulating the
| desired state so that everyone really understands it.
| Then incentivize people to get there as quickly as
| possible.
| Joel_Mckay wrote:
| I think our perspectives differ slightly, as I really
| don't care to micromanage adults that know better.
| Notably, the fixed cost of development is far less of a
| concern than long-term deployment, support, and
| maintenance costs.
|
| Probably a ROWE would be a similar modern equivalent...
|
| Have a nice day, =3
| Bjartr wrote:
| How were things good if there was a mess?
| otteromkram wrote:
| > "Where's my dopamine?"
|
| I'm not in management, but couldn't OP become a working manager?
| Might depend on the size of their team and demands of the new
| role, but I've worked with managers who wear their IC hat on
| occasion and thought it was a positive value-add for the group as
| a whole.
| 98codes wrote:
| Every manager I've ever had that couldn't let go of their IC
| hat also had a pile of manager hat work that wasn't ever
| getting done.
| justsomeshmuck wrote:
| What sort of manager work was ignored?
| icedchai wrote:
| For small teams (like, 5 people max) that may make sense. It
| really depends on the organization. With some orgs, you're
| going to meetings all day and there's no time to focus.
| dowager_dan99 wrote:
| for these IC/leaders a big mistake is taking on critical path
| work, then blocking everyone else.
| sumedh wrote:
| > With some orgs, you're going to meetings all day and
| there's no time to focus.
|
| Let's be honest here, some of those meetings could have been
| done over chat conversation.
| icedchai wrote:
| Absolutely! But who is going to really admit this?
| dowager_dan99 wrote:
| For team leads, yes - to some degree. It is really hard to get
| the balance right, and even harder to step out of one of those
| worlds as your responsibilities grow.
| starky wrote:
| This is generally a bad idea. I never know when I'm going to
| get pulled into something that will take my attention away from
| the task. The only times I really do that anymore is if the
| task is not time critical or if it is something that I know I
| could be picked up by others in any state without any issue.
| TripleChecker wrote:
| Delegation was one I struggled with a lot in the early days. Even
| as the CEO, I was reluctant to give up my customer service
| responsibilities of manning the inboxes. Eventually, I understand
| that even if someone handled it only 80-90% as well, that would
| be much better for the company than having me do it.
| chasd00 wrote:
| Delegation is so hard, i struggle constantly and I'm
| technically a "Sr. Manager". When the project is up against
| deadline pressure, it's so tempting to do something yourself
| that only takes you a day vs delegating to someone else and
| they spin on it for 3 and screw it up at the end anyway.
| Inevitably you become the bottleneck when a wave of escalations
| or other management tasks come down the pipe but there's a pile
| of actual work you decided to take on yourself half done too.
| dowager_dan99 wrote:
| I moved up to Director this year, and explicitly called out
| that if I needed to give up any more direct interaction with
| ICs and "contact time" with the real builders I had probably
| topped out. I've mitigated this a lot with an awesome team of
| leads and managers, and a (hopefully good kind of) lazy, non-
| prescriptive management style.
| roenxi wrote:
| > vs delegating to someone else and they spin on it for 3 and
| screw it up at the end anyway.
|
| If that is happening more than twice in a 6 month period you
| need to do a post-mortem on your management style, something
| is wrong. Spinning on a task is already a bad sign pointing
| at a problem that can be solved at the management level.
| xandrius wrote:
| Sounds like there are some fundamental process/team issues
| going on. If a team cannot be trusted to deliver, superman
| always coming in to save the day shouldn't be the solution.
| nineteen999 wrote:
| "Mistakes I made as a new manager which you won't necessarily
| make because all humans are different"
| Ferret7446 wrote:
| Everyone is different, yes, but people are >99% similar. We all
| go through the same developmental stages, perhaps at different
| times, and we exhibit millions of the same psychological
| biases.
| anotheracc88 wrote:
| The mistakes are common. Almost tropes.
|
| It would be like golf swing or skiing mistakes. Every
| instructor knows em.
| localghost3000 wrote:
| This misses the single biggest mistake every new manager makes:
| avoiding hard conversations with your reports. If you start
| managing folks you were recently in the trenches with this can be
| VERY hard. These are your comrades after all! You want them to
| like you. It's all very natural. Sadly it is the single biggest
| cause for dissatisfaction I've seen on a given team. Being
| unwilling to give honest, direct feedback results in
| underperforming teams and unhappy reports. It's counterintuitive
| but very important to get right as a manager. The big "AHA!!"
| moment for me was when I realized you need to speak to behaviors
| and outcomes not character. So instead of "you're sloppy" you say
| something like "I've noticed quality issues in your code recently
| that's resulted in some rollbacks. Can we talk about how we can
| address that?". Involving them in the solution and explaining why
| it matters. It makes all the difference and folks ironically
| respect and like you more for it.
| steerpike wrote:
| 100% agree with this. I would say that the other highly likely
| mistake new managers make is trying to code their way out of
| problems. It makes sense, right? Previously when you're an IC
| and a project ran into issues you could just "code harder" and
| get through it, but that's rarely the right solution when
| you're a manager and will likely exacerbate the problem itself
| if you disappear into the trenches trying to code your way
| through a critical path. Your role is no longer primarily
| solving coding problems it's solving people problems.
| anotheracc88 wrote:
| Indeed. Purposefully stay off the critical path! Do coding
| that helps you keep up with what people are talking about.
| Not coding that is urgent!
| ad_hockey wrote:
| I made that mistake as a new manager by picking up a small
| but important task in an area I knew well. I thought it
| would help unblock the team, but I didn't realise I was
| about to go into three days of back to back meetings. After
| the third stand-up in a row of reporting zero progress I
| sheepishly reassigned the ticket to someone else, and
| didn't make that mistake again.
|
| Refactors, doc fixes, low priority bug fixes, and tech debt
| are all fair game for managers to pick up. I do think it's
| important to keep your hand in.
| osigurdson wrote:
| If you are not going to add anything technically, you should
| probably have 20+ reports.
| diatone wrote:
| It depends!
| bobsomers wrote:
| Completely agree. This is excellent advice.
| roenxi wrote:
| I got the impression that when he says "couple of years" he's
| talking about the low-end of the word couple. The other thing
| in the article that jumps out is the conclusion where he says
| that a team that is shipping and happy is enough to be crushing
| it.
|
| That isn't really enough in my experience. There are 3
| questions - is the team happy? Are they shipping? Is what they
| are shipping valuable? - and I've seen a lot of new managers
| are so overwhelmed that they forget about number 3 and a fair
| chunk of people end up unemployed because sooner or later the
| bean counters figure out that the team isn't actually
| productive.
|
| This article, overall, doesn't identify achieving excellent
| outcomes as something he got wrong at first. I suspect either
| he is a natural manager or it is a mistake that is still being
| made. Probably the latter based on the other mistakes
| identified. The journey I've seen usually goes from lost ->
| controlling external perceptions of success -> oh I need to
| actually succeed and it isn't what I thought.
| choppaface wrote:
| > Is what they are shipping valuable?
|
| That's indeed critical, but most Director-level managers and
| below have very little control of how well the business model
| serves the OKRs. Yes the OKRs need to be achieved and help
| make the business work, but e.g. if the business model's
| margins are just too tepid or if the VC's expected revenue
| growth (exponential?) will never actually realize, then there
| is really zero _material_ value to the shipped product. Hence
| the focus on a happy team that's shipping, because at least
| that provides some _technological_ value. And build a network
| you can bring to your next gig--- because _that's_ what gets
| you the next job.
|
| There are rare cases where a team might discover a new
| business model or impress a whale customer, and then the
| business model fundamentally changes.
|
| Yes there is risk the "bean counters" or CFO / COO office
| will want to cut the cord (especially now tech hiring is in a
| recession). But tech moves fast; those bean counters will
| likely end up owning shares of a zombie in the next 5-7
| years. And their game is to cash out, not build a future.
|
| And if the business model actually works, then keep at those
| OKRs and everybody should win. Good business models are where
| stupid can succeed; the team has the right levers.
| brailsafe wrote:
| I agree with the sentiment and importance of addressing these
| things, or dealing with conflicts in-general, but I disagree
| with the tone somewhat and disagree with the notion that you're
| not in the trenches with them, but it depends on what trenches
| means to whoever it's relevant to. I feel like many new
| managers know they'll need to deal with this, but never
| developed their abilities prior to being a manager, and don't
| realize that just because the conversation happens, doesn't
| mean it produces _valuable_ outcomes, breeds respect, or means
| anyone will like the way you approached it, or even that you
| were as vulnerable or honest as you thought you were.
|
| Every manager I've had that used your example quote--almost
| verbatim--went on to be incredibly passive-aggressive, because
| they're trying too hard not to actually create conflict, they
| want to be liked more than they care about the result, they
| don't have that much innate confidence, or like the author of
| the article suggested, they want to see the results they would
| have produced when they were an IC, and haven't yet learned how
| to guide autonomy and relinquish a certain amount of control.
| These are perhaps the traits that led them to keeping their IC
| job all those years.
|
| These people would turn 1-on-1s into 45 mins of beating around
| the bush, trying to get me to reveal myself as having
| insufficiently met the unspoken criteria they've been having
| internal anxiety attacks about, and _maybe_ in the last few
| minutes when there 's no room left for pushback they'd conjure
| the answer they wanted to hear and set that as the benchmark.
|
| This failure on their part predictibly bled into other
| interactions and created toxicity and resentment, they couldn't
| yield control, and they couldn't have a real discussion that
| involved more than themselves manifesting as their overbearing
| mother waiting for their kid to implicate themselves for some
| petty wrongdoing. They couldn't clearly communicate priorities,
| or timelines, or requirements, and were starting in their new
| job with a skill issue of their own. They hadn't adapted to the
| role or developed a good personality for it, and apparently
| lacked an ability to reflect on their behavior or communication
| style.
|
| I don't mean to extrapolate too far from this or in-turn attack
| you in any way, it's just a small quote, but in the past it's
| been telling.
|
| "Can we talk about code quality issues" doesn't just avoid a
| character trait, which I agree should should never be the
| target, it leans into vague, soft, meek, intentionally indirect
| language that just creates undue anxiety and establishes an
| ambiguous context for whatever the problem might be, and was a
| dishonest pretext for for downstream attribution of fault,
| since they couldn't accept the possibility that the problem
| might be upstream (which it wasn't always, but if it had been,
| they weren't going to address it then). In these situations,
| sometimes I was struggling with purely my own productivity,
| having a bad couple weeks, but otherwise it was some other
| issue they weren't willing or able to genuinely help me with.
|
| Do your best to be humble, learn to delegate and _try_ to trust
| people, avoid thinking about character traits but don 't avoid
| direct (and clear) language, and accept that your perception
| might be inaccurate. Get as far away as necessary from the
| dreaded "just checking in" or "is there anything _we_ can do to
| improve ( _your problem_ )" as possible. What if their code is
| suffering because of noise in the office or someone's depressed
| because they're having relationship issues? What if it's
| because you keep coming over to their desk unannounced and
| asking diverting their attention?
|
| If you can do that, you're on a good track.
|
| Edit: it's worth noting that the underlying assumption in all
| of my comment is that people and their reasons and issues are
| often different, and likewise how they respond to this language
| may be different, and as such many might actually love the
| quoted phrases because they aren't imposing, and a good manager
| will do their best to communicate with people in a way that
| accepts that a variety of ways to address conflict is the right
| move, and sometimes less imposing language is viable.
| localghost3000 wrote:
| You're basically validating my original point if I am reading
| your comment correctly. You absolutely cannot avoid conflict
| but there is a right and a wrong way to go about it. Simple,
| direct feedback that speaks to behaviors not character is
| very important.
|
| To your point about being in the trenches I think maybe
| you're extrapolating too much from that. Any manager who is
| any good is of course right there alongside their team in
| said trenches.
| crowcroft wrote:
| I have found that company culture has the biggest impact on
| junior managers. It sets the expectation for them the most
| because they don't have any actual ability yet.
|
| Overly empathetic companies end up with terrible junior
| managers because they can't have any real direct conversations.
| Tough and demanding companies I have seen fair much better
| because no one can hide from tough conversations for too long.
| hackable_sand wrote:
| That's not what empathy means.
| crowcroft wrote:
| I'm meaning in the sense of 'ruinous empathy'
|
| https://www.radicalcandor.com/faq/what-is-ruinous-empathy/
| hackable_sand wrote:
| Thank you for the link. I like saying "confront with
| compassion" for the upside of empathetic honesty.
| hackable_sand wrote:
| These are the marks of a passive-aggressive and adversarial
| manager who would sell their team out from under them.
| localghost3000 wrote:
| This is literally the opposite of passive aggressive. That's
| my entire point!! You have to be direct with people so the
| know where they stand. That applies to what they're doing
| well on also.
|
| As for the "sell out" statement... I have no idea how you got
| that out of what I said. Sounds like maybe you had some bad
| managers?
| hackable_sand wrote:
| That camaraderie should have been built up in the trenches.
| They must trust you enough to be honest, otherwise they are
| not your comrades.
|
| If your words and tone sound nice, they can still be mean,
| doubly so.
| pdonis wrote:
| _> I've noticed quality issues in your code recently that's
| resulted in some rollbacks_
|
| I would tend to even leave out the first part of that phrase.
| Focus on the actual objective measure: the rollbacks. They
| happened, and the goal is to figure out how to not have them
| happen in the future.
| xandrius wrote:
| Yeah, code quality is marginally important if whatever QA/UAT
| process allowed that code to go to production.
|
| If "bad code" can make it to production it's usually the
| fault of the system as a whole, not the author.
| nrclark wrote:
| I have mixed feelings about this.
|
| For the most part, I think "you can't bolt on quality after
| the fact" is true. Code reviews and CI/CD automated-tests
| are helpful, but can never be thorough enough to catch
| every mistake that a low performing developer might make.
|
| If that developer causes enough problems over time, that is
| absolutely something that their manager can and should
| address.
| xandrius wrote:
| I'd think about actioning the individual only if it was
| exactly the same issue every time (how did the same
| issues manage pass time and time again, didn't we learn
| anything as a team?). Otherwise I'm more in the mentality
| that breakages are a great way to improve internal flows
| against (inevitable) failures.
|
| I think the real problem would be when a developer cannot
| manage to get any code into production (e.g. Code stuck
| in PR for weeks) but once the rest of the team and our
| systems approve it then they have proven their worth.
|
| Also, if developer X's code keeps passing code reviews,
| CI/CD, QA and UAT, and it's not the fault of the systems
| in place, I would ask myself what kind cutting edge stuff
| are they working on?
| quietbritishjim wrote:
| I disagree, at least in this case. In the comment you're
| replying to, the new manager is technical and familiar with
| the codebase, and can assess that the reason for the
| rollbacks is a genuine quality issue. This is useful
| information, and if you leave it out then you leave your
| report partially in the dark, wondering if the rollbacks are
| happening for some other reason (I can think of plenty).
|
| I'm not saying it needs to literally be in the first sentence
| or phrased exactly like that, but I don't think that's what
| they meant anyway. Rather, you do need to be upfront about it
| instead of alluding to the problem without giving away what
| you actually think.
| antman wrote:
| "I have noticed you ate brutalizing your subordinates and that
| has increased quality and output but I know it is not
| sustainable and the team is going to crash" any ideas how to
| communicate it are welcome
| NhanH wrote:
| What's wrong with saying what you typed above verbatim? It is
| a fairy standard scenario and your wordings probably have
| been said in one-on-one millions of times. You need to follow
| up the sentence with "what's next", since the scenario does
| not have a simple solution (the manager can tone down the
| demand, but then output and quality goes back to where is was
| and we have to deal with that). But now that is more about
| the work itself rather than communication
| sublinear wrote:
| > "I've noticed quality issues in your code recently that's
| resulted in some rollbacks. Can we talk about how we can
| address that?"
|
| This is just about the laziest and least trustworthy language
| possible to use. Your reports aren't going to know what they
| don't know and are just going to become paranoid and work
| slower. The code quality will likely not improve from a
| conversation prompted this way. This is also a continuous
| process, not a magic high stakes meeting. If you're in charge
| you should see patterns in the code reviews and know what their
| knowledge gaps are causing these issues. They're looking to you
| for help if you're the one bringing this up in the first place.
|
| If that's too time consuming or over your head you should not
| be a manager. Leverage your own knowledge and use mentorship to
| avoid conflicts with your reports and the improved productivity
| will please the people above you as well. You aren't giving
| anyone what they need by merely communicating requirements.
| Your job is to fulfill those requirements with the team you
| have.
| piterrro wrote:
| Fully agree, quality is teams's effort and having a blameless
| culture where the team pushes for higher quality bar is
| essential. Chasing a single individual only makes sense when
| they have a track record of repeating the same thing multiple
| times - means they are not learning from their past mistakes.
| jimberlage wrote:
| Out of curiosity, the OP's language is "quality issues",
| not "quality issue." Why did you assume there wasn't
| already a pattern of behavior implied there?
| whoknowsidont wrote:
| I'm not OP, but just by the way it was worded. It feels
| vague and grandstand-y. " _I_ have noticed " is such a
| silly way to word what's happening here and it's hard not
| to imbue underlying meanings to it.
|
| And then "can we talk about how we can address that."
| More vague, leading statements.
|
| Speak to the facts. "The team / org had to roll back this
| release, the team does not think there is a process
| improvement that would have alleviated this problem, and
| the team relied on you to properly make this feature. Our
| exceptions of all team members is [...]"
|
| Make it clear:
|
| 1. This is affecting the whole team (equally)
|
| 2. The team as a whole shares this perspective (it's not
| just the manager nitpicking)
|
| 3. There are consistent and vibrant standards that the
| entire team must adhere to
|
| 4. You are not meeting those standard(s) or necessary
| actions for success.
|
| 5. Offer what you think will fix the problem (if
| anything)
|
| 6. Make it clear this is their chance to agree/disagree
|
| 7. Continue to talk it out.
|
| Honestly OP seems like a person who has struggled in his
| position as manager to properly speak to people, and
| instead of understanding why there was a struggle simply
| switched to more coded language.
|
| Most people will see through it and react negatively.
| dakiol wrote:
| Constantly pushing for higher quality is not healthy imo.
| You end up burned. I don't want to be a high performer (I
| end up burned) and I don't want to be a low performer
| either (end up fired). Something in between is something
| ICs shouldn't be afraid of aiming to (unfortunately
| management doesn't think like that and want to extract
| until the last drop of productivity from us)
| alsetmusic wrote:
| Exactly. A steady pace is how one achieves longterm
| success. This is something that I learned after burning
| out. Do the job well, but don't kill yourself.
| diatone wrote:
| I'm sure you mean well but reading GP's post I'm convinced
| that the laziest and least trustworthy language to use is
| actually, "you're sloppy."
|
| Good idea to think in systems and figure out how to lift the
| quality of the team but it's okay to give direct feedback.
| Especially if the feedback is like GP's in that it kicks off
| a constructive conversation, which iiuc is exactly what your
| final sentence there is waxing on about...
|
| Edit; to be clear I'm suggesting to not aim to avoid
| conflict. Certainly don't stoke it for no reason but there is
| a healthy kind of conflict and how it is engaged with, which
| builds trust, deepens human relationships, and leads to
| growth for everyone involved. Psychological safety etc
| sublinear wrote:
| Ok fair. Some devs do not respond well to advice and
| consider it just as condescending. Most I've worked with
| aren't like this though. Yes, we should use our own
| judgement.
|
| My response is based on my own experiences with management
| that are incapable of moving the needle on anything, rarely
| have any constructive input, and ultimately cause their
| team to either quit or be fired. Then they themselves get
| pressured to quit.
|
| It's very obvious to devs when someone delegating couldn't
| even do the work themselves or would do an even sloppier
| job. It's one thing to expect higher performance, but quite
| another to demand it while spending all day in meetings
| giving limp wristed handshakes and bullshitting their way
| through every question they get from anyone.
|
| I understand that it's already hard enough to hire good
| devs let alone promote one into management. I'm suggesting
| how an organization goes about making and promoting those
| people from within. This industry cannot go on like this. I
| don't care if someone isn't perfect when I hire them, but I
| do care that everyone wins.
| the_clarence wrote:
| This sounds so stupid. I'm sorry but feedback is already
| given in PRs. This kind of feedback is just a bad idea IMO.
| Focus on growth and areas of improvements. Your reports often
| already know what they should focus on, and they are on their
| own journey of time management. The only lever you have as a
| manager is to add or remove pressure. The only help you can
| give is through mentoring or therapy/coaching.
| jimberlage wrote:
| > "I've noticed quality issues in your code recently that's
| resulted in some rollbacks. Can we talk about how we can
| address that?"
|
| That's the first step in fixing the quality issues, not an
| end state. Reports don't know what they don't know, so step 1
| is to get their ideas on how to fix quality issues.
| beryilma wrote:
| > I've noticed quality issues in your code recently...
|
| Why is it always the report who is the source of the problem
| and not the manager?
|
| How about "I've created a toxic work environment and put my
| reports under a lot of stress. And I have not given them any
| opportunities to grow and learn new skills. I am planning to do
| better..." Words that will never come from the mouth of a
| manager.
|
| Have a hard conversation with yourself first before blaming the
| reports.
| LanceH wrote:
| Articles aren't written for reports, or at least the
| advertising on those articles are directed at the managerial
| and above level.
| interludead wrote:
| Navigating hard conversations is arguably the crucible for new
| managers
| binarymax wrote:
| I've got a good hack for the dopamine: PowerPoint and excel. Go
| to town on making kick ass presentations and reports. "Ship"
| those to the org during meetings and all hands. It's not the same
| as code for customers, but it helps. Also, if you have time, code
| non critical things that will never be a dependency for anything
| else.
| dowager_dan99 wrote:
| I build internal tools, do BS support requests and push little
| initiatives that align with my core values. Like get a dozen
| people in-person for a technical watch party - cheap, easy,
| super rewarding.
| starky wrote:
| Agreed, my go to when feeling like I haven't produced real work
| in awhile is to document processes, especially if there is
| something I've noticed has been done poorly or been asked about
| a couple times recently.
| ryoshu wrote:
| Delegation -> This is 1000% the hardest thing to do. You need to
| let go and trust your people.
|
| Where's my dopamine? -> Your success is the teams' success. When
| they are doing well, you are doing well.
|
| Quality over quantity -> Yes.
|
| The level of engagement -> Your job is to support the team -
| blockers are your problem, not their problem. Fight to remove
| blockers. That's your job.
|
| Managing perception -> Which leads into, your role, well done, is
| invisible. Protect them from the bullshit politics that any org
| has and let them do what they do well.
|
| Redefining success -> That's up to you and your manager. If
| you're a new manager, you need to manage across and up. That's a
| set of skills that we don't train people for.
|
| You're coming from an IC position and you know how to do the
| work. Managing people is a different job,
| dowager_dan99 wrote:
| Where's my dopamine? -> Your success is the teams' success.
| When they are doing well, you are doing well.
|
| It's hard to get a dopamine hit of a second-order signal
| though. When you're a developer there's a strong linkage
| between the work you complete and results. If you write code
| for a new feature, you get to see it take shape on your screen.
| When your team reaches a milestone, you see where you
| contributed and can often quantify your contributions.What
| happens after you move into management? Your day-to-day is no
| longer filled with relatively concrete tasks and goals. Your
| role is not to do the work yourself but guide and support a
| team doing the actual execution. How do you measure that?
| ad_hockey wrote:
| Agreed. "Where's my dopamine" is the right way to describe
| it. As an IC I could find a bug, craft a test that reproduces
| it, write a fix, see the test go green, see the PR get
| approved and land... I'd get a little dopamine ping at each
| step. As a manager I'd have days where I had constructive
| 1:1s in the morning and maybe made a decision on some
| strategic or resourcing problem in an afternoon meeting. Of
| course I recognised that the work was not only valuable, but
| higher impact than just fixing a bug. But the direct hit in
| the pleasure receptors just wasn't there. I'd finish a day a
| like that and instead of feeling happy with my work, I'd just
| feel exhausted and not looking forward to the next day.
|
| After a few years as a manager I switched back to the IC
| track. I sometimes wonder if my experience means I'm just
| hard-wired to be an IC, or if with more time and practice you
| can train yourself to get the dopamine feedback from
| management activities.
| ifthenelseor wrote:
| I'm still getting dopamine off getting a team member
| promoted, two years later. Every success they make reminds me
| that I helped them build that confidence and those skills.
| Manager-side successes might not be obvious and daily, but
| they have staying power like you wouldn't believe.
| Loughla wrote:
| >The level of engagement -> Your job is to support the team -
| blockers are your problem, not their problem. Fight to remove
| blockers. That's your job.
|
| The best managers I've ever had saw it as their job to remove
| barriers and bullshit from my day. It's what I try to do as a
| leader as well. It serves the purpose of making their jobs
| easier, and also takes up your time which creates less
| opportunity for you to micromanage and forces you to delegate.
|
| >Managing perception -> Which leads into, your role, well done,
| is invisible. Protect them from the bullshit politics that any
| org has and let them do what they do well.
|
| This is SO important, and where I struggle the most. Your team
| won't appreciate it, but when they have the time, support, and
| resources they need, they'll notice.
| brap wrote:
| I joined a new team as a manager and after 3 years was kindly
| asked to step down and become an IC. While there are many
| external factors to blame, I decided to do an honest postmortem
| with myself so I thought about these things a lot.
|
| As a line manager a huge mistake you could make (especially if
| you're joining a new team) is not being technical enough.
|
| You may not write code anymore, but you are expected to know the
| system very thoroughly, otherwise you'll be perceived as a
| glorified babysitter.
|
| As a new manager it's very easy to fall into the trap of not
| doing any technical work because you're a big boy now playing in
| the big boy league, but this will 100% hurt you.
|
| You need to stay on top of everything your reports are doing.
| Give them their space but always ask hard questions and dig deep.
|
| Frame it like this: if this report were to quit today, are you
| able to step in and complete their project? I'm not saying it's
| something a manager is supposed to do, but that ultimately YOU
| are directly responsible for your reports' work so you should be
| extremely familiar with it.
| exitb wrote:
| > if this report were to quit today, are you able to step in
| and complete their project?
|
| I've had many managers over the years, more and less
| successful, and this was possible just for one of them. And
| only because they were promoted to the position from a
| developer level on that team. They hated being a manager though
| and left the company promptly.
| dowager_dan99 wrote:
| Turning this person into a manager is a major fail. Typically
| their only move is to quit, and everyone loses.
| thanksgiving wrote:
| > You may not write code anymore, but you are expected to know
| the system very thoroughly, otherwise you'll be perceived as a
| glorified babysitter.
|
| I think the way "experienced" managers do this is to not
| actually understand the technical work 100% but rather make
| your manager think you understand it 100%. Even as an
| individual contributor, I fail to fully understand all the
| changes my team is making. I can't imagine being 100% fully up
| to date with all the changes at are in flight, have landed,
| etc. and why. The best you can do is some kind of abstraction.
|
| They call this "managing up" or something like that.
| chatmasta wrote:
| I'm pretty sure "managing up" refers to the extra work the IC
| needs to do so that their non-technical manager doesn't look
| incompetent to their own manager.
| ElevenLathe wrote:
| Managing up is just rebranded brown-nosing.
| majormajor wrote:
| I think it's the direct opposite: A huge part of "managing
| up" is making your your boss knows what's going on enough
| to help them make a wrong decision due to being unaware of
| details you and your reports are aware of. If you're scared
| of contradicting or correcting them you can't do that.
|
| A huge common mistake for anyone with a boss - at ANY
| level, IC or management, is assuming their boss knows
| everything that they know + more things. The intersection
| of what you know + they know is probably smaller than you
| think. And so being able to recognize what they will NEED
| to know in the near future is a valuable skill.
| majormajor wrote:
| For those sorts of things you need to understand:
|
| - the reason it's happening
|
| - the cost (time / people)
|
| - what else you are deciding not to do instead
|
| You don't have to be in the weeds enough to implement it
| yourself but you need to guard against both:
|
| - people working on things that aren't priorities because
| they only want to work on their own pet projects, by not
| being technical enough to tell when they're BSing about the
| technical justification for certain things
|
| - people doing things in inefficient or not-aligned-with-
| future-needs ways because they are more junior and don't know
| some technical things, or because you haven't shared enough
| roadmap context
|
| It's related to "managing up" in that it's good to be
| proactive about sharing some of that info upward as-relevant
| with your boss so that they don't have to go out of their way
| to know what's going on with you (or else you run the risk of
| them having a wrong assumption when they're making decisions
| that impact you and your reports).
| dowager_dan99 wrote:
| I've entered 2 new orgs as an engineering manager, after
| getting some experience organically. You need to prioritize
| between lots of things, including technical / people. Usually
| people is the right choice I've concluded, but the first time
| my teams were using all new tech for me and I really struggled
| after over focusing on relationships. The second time I still
| focused more on people but new the tech better, and forced
| myself to find time to go through more typical developer
| onboarding. It was way more successful.
|
| Some of the things you mention sound right for a team lead
| (i.e. single team) but not really for an EM where you might
| have 2+ teams. You need to be able to solve the problems the
| leaving teammates create for you, but stepping into the role is
| probably the last thing you should do. Don't get me wrong, you
| need to live the life to build credibility and empathy, but
| doing the job yourself is usually a substandard, unsustainable
| solution.
| codingdave wrote:
| Having full knowledge of the work is not the same thing as full
| knowledge of the system. Being able to step in to do the work
| of one of your people is one possible way to provide a safety
| net for the bus factor, yes. But not the only way, and I'd
| argue it is not the best way.
|
| This is your team - you are managing them, not the other way
| around, so if they have expectations of you that are incorrect,
| then fix those expectations. If you are not technical, tell
| them so. Communicate your needs and expectations, and then let
| them do the work. If there is a bus factor that is too high of
| a risk for a sustainable team, cross-train the team to remove
| the bus factor. Have a sense of the priority of all the work so
| that if someone quits, you can re-arrange the schedule, not be
| forced to jump in and put out a fire.
|
| At the same time, be building up your people so that they can
| jump in and replace you. After all, if you cannot be replaced,
| you cannot be promoted either. Don't pigeon-hole yourself into
| a front-line manager role unless you truly love it. Grow your
| team, but grow yourself at the same time.
| jiveturkey wrote:
| Not at all. I mean for a small team where you are or expected
| to perform as TLM yes. But generally speaking no.
|
| I can't read the article to tell if this is just an observation
| from you, or if you are responding to the article, because my
| DNS just broke for whatever reason.
|
| > Frame it like this: if this report were to quit today, are
| you able to step in and complete their project?
|
| That is not the manager's job. The real question here is, do
| you know the bus factor of your team and do you know what
| particular skills are most critical to replace?
| resonious wrote:
| I'm an IC on a team full of seniors with strong domain
| knowledge that recently hired in an EM from the outside. In
| short, it was pretty bumpy and despite the guy being an ex
| engineer, his constant questions about how the system works
| were a huge drag. Maybe to him he was digging deep but to me it
| felt like my (and my teammates') work was blocked by his
| inability to grasp simple concepts. Like the time spent
| explaining could've been spent just fixing the bug.
|
| So I guess with the digging deep thing, be careful to not take
| up too much of people's time!
| diatone wrote:
| How long are these Q&A sessions, would you say the work of
| ICs getting blocked isn't worth having the manager be able to
| eg: advocate for that work upwards?
| dakiol wrote:
| What's wrong with taking "too much" peoples time? I mean,
| it's a colleague, asking questions... it's not that you are
| going to work more because you're allocating time to help
| others.
| dyauspitr wrote:
| That's the team leads job. The manager's job is to manage the
| people. You are a babysitter or more akin to a teacher that has
| to stay out of the way of the kids doing things well and
| prevent the bad kids from ruining the class for everyone.
| dakiol wrote:
| IMO, if I have to choose between managers that are technical
| "enough" and glorified babysitters, I go for the latter. Little
| knowledge is dangerous and causes more pain than help. At least
| glorified babysitters know that they don't know enough and
| leave all the important tech decisions to the devs; that's
| relieving.
| alain94040 wrote:
| > if this report were to quit today, are you able to step in
| and complete their project?
|
| I don't think that's the main goal for a manager (even
| technical). I'd say generally, the manager should understand
| _why_ the team is building something, and the engineers should
| know _how_. The _why_ includes who is going to use what was
| built, when do they need it, what trade-offs can be made, etc.
| hnlurker22 wrote:
| New era manager mistake. Ask ChatGPT about time estimates and
| pretend you know that because you are an expert, then use that to
| micromanage people. Mistake is a nice word. I consider that to be
| pure evil
| dowager_dan99 wrote:
| Most of these are pretty accurate, but there's good news: giving
| a sh!t about your people will likely get you 80% of the way to
| being a good manager. If you genuinely care about them, their
| work and progression you're already aligned with the key aspects.
| You can learn & figure out the rest. It might be hard and very
| unpleasant at times, and stressful, but building the teams that
| build software is the most rewarding accomplishment of my life.
|
| I will add one too: sometimes you only find out you don't want to
| be a manager after trying it. Building a lead mentorship program
| where both management and the individual can live a realistic
| experience of being a people leader is invaluable. I've
| implemented this program twice now and it has been great for
| building leadership capacity with people who are excited to take
| this path.
| alsetmusic wrote:
| > giving a sh!t about your people
|
| One of the most stand-out moments of leadership I've ever
| witnessed was my boss protecting me and a colleague from
| another manager on a different team. He put his foot down and
| drew a line about what was to be expected of us (among our
| other competing responsibilities). Fight for me and I'll fight
| for you.
| wavemode wrote:
| > As an individual contributor (IC), your work spoke for itself;
| people could easily see it. Plain and simple. As a manager, it's
| less black and white, and surprisingly, for many new managers,
| part of your job now involves managing how others see you.
|
| This doesn't only apply to managers. Even as an individual
| software engineer, the more you move up (if moving up is
| something that matters to you), the more you have to play
| politics.
|
| Your work can't possibly "speak for itself", since the people
| it's speaking to (the managers with power over your career) don't
| speak code.
| toolslive wrote:
| It's important to know exactly what you are managing: a team? a
| project? a service? a product? "Engineering manager" is an
| ambiguous term here.
| urbandw311er wrote:
| I've been an IC, a manager, a CEO and now even an IC again. This
| advice is all really sound and easily digestible. Many thanks to
| the author for sharing it.
| purpleidea wrote:
| The worst is having a manager who thinks he's great, but is
| actually disloyal and shit. Not sure how best to deal with that
| situation other than to ignore and eventually move on... If
| they'd be willing to admit their failing and improve, that would
| be awesome. Asking for a friend.
| Daub wrote:
| As a (former) manager of a department in a design school, I
| defined three managerial imperatives:
|
| 1. Get rid of old, dead wood. Given that our program is
| scaffolded, with each course building upon the preceding, A
| single low performing lecturer can bring down the quality of an
| entire program. Don't trust student feedback when identifying
| such people. They favour nice lecturers over effective ones.
| Getting rid of low performing team members in a university can be
| a low process. It can sometimes be quicker to find programs they
| would be happier/more productive in, and engineer a transfer.
|
| 2. Hire effective new blood. Well duh, I hear you say. Finding
| good new hires can be a difficult task. For those who I really
| wanted to hire, I did my research on who they were and what they
| might want, and tried to show them that I was willing to build a
| nest for them.
|
| 3. Have a vision of what the department should be. This vision
| requires constant maintenance and should always consider input
| from the team.
| bearjaws wrote:
| #2 is considered taboo, but IMO if a team is full of people who
| are checked out, it may be time to make huge changes.
|
| People become jaded and start to tell you all the ways we _can
| 't_ do something, or it will take too long. They often don't
| realize what tools are at their disposal to help make change
| easier, and instead insist there is only one good path to a
| solution...
|
| Fresh talent really helps get people excited again, after the
| initial shock of layoffs. Not to mention new talent always
| comes in excited for an opportunity.
| the_clarence wrote:
| Reading the comments here just makes me feel like managers are
| useless. This role doesn't have to exist. It's just fluff.
| jimberlage wrote:
| I worked at a company that emulated Valve's hyper-flat
| structure on their engineering team, with 1 manager having 50
| direct reports. That's as close to a management-less structure
| as I can think of, since your manager can't attend meetings or
| do 1:1s anymore.
|
| It's great at the beginning. We started with a team of mostly
| self-motivated people and the lack of upward review made
| technical decision-making easy.
|
| Eventually, you hire someone who is not self motivated. Also,
| some existing people get wise to the fact that no one will
| check up on them, and read Reddit for half the day.
|
| About 4 months in, every team had 1 person like that. They had
| to work around them - one team can't ever get designs cause the
| designer is checked out, one team's backend work takes 1.5x as
| long as everyone else.
|
| People say things to the underperformers, but there's no teeth
| to anything, no one is anyone's manager, so it's just
| suggestions. They get ignored. Resentment builds into each
| individual team's culture. Deadlines start slipping.
|
| 1 year in, non technical leadership is fed up. They don't see
| benefits from the flat structure, and hire a new CTO and new
| middle management layer.
|
| The new managers come in briefed with "the team is lazy." The
| underperformers get pushed out, and have trouble finding work
| because their skills have absolutely atrophied. Any remaining
| high performers are permanently tarred with the reputation of
| the org from the flat structure days, and get micromanaged. To
| the new managers, they are kids who will misbehave the second
| they aren't watched (which, in fairness, is kinda what happened
| at the organizational level when they weren't watched.)
|
| Sone good middle management providing timely oversight and
| feedback could've avoided the whole situation.
| iLoveOncall wrote:
| On "Where's my dopamine?", while I'm not a manager but just a
| tech lead, so still working as an IC for most of the time, I do
| get satisfaction from eliminating repetitive work for people in
| my team and optimizing process.
|
| It's great to be able to tell your teammates that the meeting is
| canceled because you just sent an email explaining that you
| prepared everything for next sprint and here's a 5 lines summary.
| mikhmha wrote:
| What are you supposed to do when your manager has terrible and/or
| selective memory? My last manager would assign me work and then
| promptly forget half the time what he assigned me. It was
| bizarre. Sometimes it worked in my favour because I would do
| something he assigned me - then show him - and then he would sing
| praises for my "self initiative" and creativity. Like dude, you
| told me to do this. Of course this sort of amnesia will
| eventually come back to bite you when you are yelled at because
| "why are you working on Y?? you should be working on Z!!". Dude
| you told me to work on "Y" two days ago.
|
| I never understood whose blame the poor memory falls on? In my
| opinion it was on him to stay organized - something he never made
| an effort to do. Others would say it was on me to communicate to
| him what he told me. I don't get paid enough to be his executive
| assistant. And I don't see the point in communicating better if
| he would just forget again.
|
| Other times his memory was bizzare. Like he would remember some
| off comment I'd made to him in a 1-on-1 and then use it as a way
| to butter me up or appeal to me. I once mentioned to him I follow
| news in the "programming space" (aka reading this website). And
| he seemed to remember this whenever he needed to appeal to me to
| look into some new platform feature clients were requesting. "You
| read a lot about this stuff right??? Take a look into PDF
| generation using this library. You read a lot about this stuff
| right??" I think he thought he was juicing up my ego with this.
| So bizzare.
|
| Of course its the same manager who did the fundamental sin of
| complaining downwards to me, and about my peers whenever one of
| them messed up. Dude you're the CTO. If you can't maintain face
| then I will lose all confidence in your ability.
|
| OK I'm going to stop venting about my last boss now. Sorry!
| epalm wrote:
| About the poor memory stuff, just get it in writing. "In
| writing" could mean in an email, or a chat, or more likely in
| an issue tracker that has an audit log. When there's a
| discrepancy, just link to where it was written down.
| ChiMan wrote:
| The way to see this is that we're all individual contributors,
| from the janitor to the CEO. Because if you're not an individual,
| then what are you? And if you're not contributing, then what are
| you doing there? When you manage a project or team, you're just
| individually contributing in a different (though usually
| overlapping) way.
|
| Also, it's helpful to remember, when delegating, that one reason
| you're probably managing is that you either have tired of running
| your brain in fifth gear or, at your age, can't. So the way you
| contribute is, in general, by applying the hard-won lessons
| gleaned from your time on the brain-speed freeway while letting
| others, whose brains naturally run faster, either because of
| youth or disposition, do the fast-brain work.
|
| Personally, I don't generally enjoy managing in part because
| brain speed, which I value, seems to slow further because of the
| nature of manager or executive work. When I've gotten a taste of
| management and spent time on calls with other managers and
| executives, I was shocked to discover how slowly (and often
| haphazardly) they thought through problems that were quite
| understandable in an instant or two spent alone. They were all
| very smart people, and yet the managing--or, more likely, the
| group settings of meetings and calls--seemed to trap their mind,
| eventually habitually, in a socially constructed box from which
| they couldn't escape.
| YZF wrote:
| I hate the term IC. Its often used in a semi-derogatory
| context.
|
| Ah, I was wondering what was going on with my brain since I
| became a manager.
|
| Seriously though, I've known some people who are managers and
| extremely fast/strong thinkers. Yes, the nature of the job
| requires more of the big picture and less of the details.
| darkerside wrote:
| They are taking so many more factors into account that you
| don't see. It's like a junior engineer saying, why not just
| bang out the code? You're missing all the long term impact.
| mjr00 wrote:
| > The way to see this is that we're all individual
| contributors, from the janitor to the CEO. Because if you're
| not an individual, then what are you? And if you're not
| contributing, then what are you doing there? When you manage a
| project or team, you're just individually contributing in a
| different (though usually overlapping) way.
|
| The difference is in how your performance is judged. ICs are
| judged by their _individual contributions_ , hence the name.
| Managers are judged by the performance of their
| team/department/organization/company. It's not enough to say,
| as a manager, "I personally ran the sprint meetings and did
| 1:1s and performance reviews so therefore I'm doing a good
| job."
|
| The individual work managers do is much harder to tangibly
| measure. Things like establishing a culture, balancing your
| roadmap between one-off customer requests and internal
| production vision (and hacking in some AI crap to make your CEO
| happy), hiring the right people. Just doing the table stakes
| individual work of managing your direct reports' vacation time,
| promotions, and running team meetings is really only good
| enough for beginner, first-level line managers at bigger
| companies, where they just need people to execute established
| processes.
|
| > Also, it's helpful to remember, when delegating, that one
| reason you're probably managing is that you either have tired
| of running your brain in fifth gear or, at your age, can't.
|
| ehhhhh. Management is a lot more reactive, that's true, but
| saying it requires less brainpower isn't true. As a manager
| you're constantly context switching. You don't just care about
| the codebase and solving one specific problem, you also care
| about sales and marketing, your customer support team, the
| budget for next year. You're getting slack messages from
| executives who need an update _right now_ on your project, at
| the same time as an engineer needing to talk because their
| partner just filed for divorce and they need mental health days
| (and you need to support them while also figuring out how to
| rebalance their workload). It 's a very different way of
| working that uses very different parts of your brain. But it's
| not just sitting in the executive bathroom and delegating work
| while you smoke a cigar.
| interludead wrote:
| Management might feel frustrating to those who thrive on fast,
| solitary problem-solving
| mindvirus wrote:
| It is cynical, but quality over quantity is bad advice if you
| want to grow your career as a manager. It's a real failure mode.
| Not being aggressive about growing your headcount will hold you
| back. Pretty much all managers are evaluated on amount of
| headcount when it comes to promotions, especially if you're not
| tied to P&L.
| Gunseng wrote:
| I find it hard to take anything seriously where "imposter
| syndrom" is mentioned. That said, I think having full time
| managers at all is a mistake. This was discussed in detail in
| this podcast: https://37signals.com/podcast/everybody-works/
| blindriver wrote:
| Another mistake: Thinking your former coworkers are still your
| friends.
| smokel wrote:
| I don't agree. Trust allows for a lot of things to go a lot
| smoother. Sure, good friendships can end, but one can also be
| honest with good friends.
| interludead wrote:
| "Is my team shipping? Are they happy?" is a simple yet powerful
| metric for success. If more managers internalized this, I suspect
| we'd see healthier teams and better products.
| drewr wrote:
| > For over a decade, my dopamine (from work) came from a very
| predictable place: shipping new things. As a manager, those
| direct rewards will simply disappear, leaving you feeling
| unfulfilled for weeks (months in my case).
|
| Your job as a manager is still to ship things -- only now it's to
| ship more than you ever could alone. You get the privilege and
| responsibility to steward the skills of two or more engineers and
| shape the entire part of a business. The dopamine is harder won
| and often more rewarding. Management is difficult and exhausting
| but it's anything but unfulfilling. Let's not start new managers
| off telling them what they can't do but what they can do.
|
| Ironically, as a manager of software engineers you should still
| be very engaged with the team's code. How else will you
| understand your capacity and understand what gaps you need to
| fill? Run the test suite, review designs, read PRs, ask
| questions, give praise for attention to detail. You will keep the
| bar high on the team and advocate for their work more effectively
| within the organization.
___________________________________________________________________
(page generated 2024-12-07 23:00 UTC)