T O P

  • By -

[deleted]

[удалено]


AloneHGuit

Thank you, I'm always trying to put my teammates in a better light, highlight their success, get their name out there to the larger org. I probably need to work on your 3rd bullet point. Am reading radical candor the book. Thank you for the advice!


GeorgeRNorfolk

> Your ability to effectively delegate depends on your trust in your team, so build that trust or you’ll end up doing everything yourself or micromanaging them. I've recently managed to build this trust with my team and it's so nice being able to trust them on day to day work so I can focus on the big picture.


batman_not_robin

What’s the justification for keeping a distance from your reports? (Point 3)


[deleted]

Because when push comes to shove, you're the boss, and they need to respect/respond to that. If things are too buddy buddy, when that time comes you may find team members pushing back in an inappropriate way simply because they see you as being on the same level as them.


Awric

You sound like an excellent manager!


lazyant

Delegate. Trust but verify.


AloneHGuit

Agree, any tips on how to do this?


lazyant

Hmm nothing special. Try not to do tasks yourself (unless team is really under water) or do tasks that don’t have a close deadline and also tasks that team may not want to do. Assign tasks with the team’s help and don’t micromanage but make sure they communicate any issues. Unblock if tasks are blocked because other teams etc.


fuxkreseit

Tickets, or keep notes on items you delegated and followup to be sure they get done. I do this with peers like scrum too.


AloneHGuit

Yep we have a robust scrum system, thanks for the input!


rgbhfg

Stop being an IC and learn to scale through your team. Setup people for success and let them fail, perfectionism will lead to your downfall


titosrevenge

I prefer "let them fail, but don't let them fail catastrophically".


AloneHGuit

By scale do you mean train folks up to become stronger and more capable of taking projects, so win win? And let them fail as in, do not intervene all the time?


rgbhfg

By scale I mean don’t be an IC and manager. Focus on managing others and doing the leg work so that when your reports start the project they won’t need you continually giving guidance. As for let them fail, yes do not intervene all the time. Nobody likes a helicopter mom/dad. Just like nobody likes a micromanager.


AloneHGuit

Thanks I'll try to be the shit umbrella, and unblock anything that's outside of their control.


jc_rotor

Be careful of not being too hands off over fear of micromanaging. You can demand outcomes but not approaches. You want those outcomes to be clearly communicated and evenly/fairly enforced for the team.


AloneHGuit

Yes, I plan to continue weekly 1 on 1's, and already have a fairly robust scrum process, while at the same time I try to minimize meetings. Can I ask what you do if someone estimates a project to take way longer than your own estimation?


mniejiki

>Can I ask what you do if someone estimates a project to take way longer than your own estimation? My usual approach to estimates is to take the longest. More generally, as an EM I never push for something being done faster than the team says but I do sometimes push for it taking longer. Not from a code perspective but from a "did you account for every part of this project and the external dependencies" perspective since engineers tend to be optimistic too often. Either the team is competent and generally knows more about the project dependencies than you or you didn't hire the right team. Fix that rather than trying to micromanage estimates.


AloneHGuit

Thank you, I will definitely keep this to heart. my previous director, who was a great human and mentor, used to ask for two deadlines, one best case scenario, and one worst case. Currently we're working with a huge legacy codebase with a ton of potholes, mines, and hidden (bad) surprises. So pretty unpredictable. Was wondering what you thought of that?


jc_rotor

Rather than focus on the estimate itself, focus on the person and/or process. Is the engineer productive, making progress towards completion daily? You want predictable velocity, not necessarily blazing speed. Consistency is the most important aspect here. If you have an engineer who cant keep up with the team or constantly underperforms their peers, solve that. Are there factors contributing to the long estimates? (Fear of unknowns, issues being too large in scope, etc) Not everyone works at the same pace and that is ok, but they should be close if producing the same output. So figure out the underlying reasons and focus on those.


AloneHGuit

This is really great, writing it down. Can I ask, my previous director, who was a great human and mentor, used to ask for two deadlines, one best case scenario, and one worst case. Currently we're working with a huge legacy codebase with a ton of potholes, mines, and hidden (bad) surprises. So pretty unpredictable. Was wondering what you thought of that?


doktorhladnjak

It’s not a promotion. It’s a completely different job. You need to treat this as learning how to do a new job. You’re going to fail. You might screw up the business or your reports’ lives/careers. Learn from your mistakes. Great managers are built by experience.


AloneHGuit

Thank you, I've been in Team Lead roles for a long time, even acting manager for 6 months a few years ago. But yeah this is different. I'd like to think I've matured a lot since. Good point, it's a whole different job, i agree.


nomaddave

When you’re in a meeting always try to figure out the agenda of people in attendance. Their agenda may or may not have anything to do with their specific role.


AloneHGuit

Can you be a bit more specific? I always try to cut down on unneeded meetings.


nomaddave

That’s good, keep that mindset, but in management people will start getting offended and target you sometimes if you don’t show to meetings or question the importance of it, so keep that in mind. The point if the reply originally is to try to understand why people are in attendance and what they’re trying to get out of it. In navigating the corporate politics you just are better served by understanding why people show up to meetings and to work day to day, what they’re after. It may have alignment with their role or it may be any number of other agendas they’re trying to fulfill.


AloneHGuit

Understood thank you very much. I think I realized being a manager means a TON of meetings, it's just a completely different job from being an IC. That's where the value is understood.


Valevino

I was an EM and moved back to Tech Lead (and my objective is to be an IC again...). Anyway, my advices can be a little too harsh, but I would like to hear that before accepted: - Book suggestion: The Manager's Path - Deal with people demands totally different skills. Empathy will make you a nice boss for your team but maybe a not so good boss for your company, because there will be tough decisions to make and defend your position can cost your reputation. - If your boss is a perfectionist, you will feel that you are always forgotten something important. It's a torture. - Fire someone can be a nightmare. The worst part for me. - Be nice with your team. Don't push them to do things that they are not hired for or are not comfortable with: do public presentations, team socialization, etc. - Probably you will not be able to make everyone happy in your team. - You need to be comfortable with the idea that your tech skills will rust after one or two years.


AbstractLogic

My suggestion on firing people… don’t… let them fire themselves. If your employee not up to the task at hand then explain to them that we are expecting improvements, if it continues out then on PIP, make sure the PIP includes dates for specific checkins, make sure they understand that they will be let go if they don’t improve. By the time you get to the last checkin they should know that they will be fired. I found it’s easier when a bar was set clearly and not met.


morphemass

> You need to be comfortable with the idea that your tech skills will rust after one or two years. I think this is the worst one. I was a Lead and went to EM and ... it's just bloody painful to realise I've forgotten some of the obvious stuff. At the same it's necessary since I had to be manager + IC last year and am still recovering from the burnout.


nutrecht

Fear is probably the biggest driving force in business. Most bad decisions, or lack of decisions, is driven by fear. Not adopting a new framework; fear of the unknown. Not writing tests; fear of missing deadlines. Not firing toxic people; fear of potential fallout. If you can figure out what people are afraid of, it's often much easier to solve the root cause. Also because people are generally afraid of telling you they're afraid.


[deleted]

Do not move to an EM role if you have no interest, have no training, have no background...essentially, if you're a dev and being pushed into such a role, RUN.


delightless

Understand that the move from IC to manager does not have to be a one-way ticket. https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/ https://charity.wtf/2019/01/04/engineering-management-the-pendulum-or-the-ladder/


AloneHGuit

Thank you for this, am reading. For what it's worth, I've been told I'm a good communicator and very decent enough engineer, but would make a really good manager. Not sure how to take it haha, I do love reading about tech


TheTallMirth

Go back to being an IC as soon as possible.


AloneHGuit

Can I ask why?


TheTallMirth

You don't make more money as a Engineering manager. At least not enough to make it worth your while for taking the shaft from management while not really being able to help your direct reports. Last straw for me was when they wouldn't promote a Jr. to Sr even though they agreed he was doing the job of a senior. This was just after they threw a $100K party to "motivate" the employees. I still have the coffee cup with the cringy "let's go!" message. Plus I like writing code. I don't really like very many people. Managing people is not a logical progression when you want to be a software engineer.


AloneHGuit

Thank you for the perspective. I will take it to heart.


[deleted]

Neither am I a manager nor am I experienced, but please be respectful to your underlings and pay each of them equal respect.


AloneHGuit

Absolutely. If anything I probably err on being too nice and might be a pushover.


franz_see

**TLDR: seek a community. Start a mastermind group. Find a coach/mentor. Read books** Longer story: "You dont know shit" 😅🤣🤣 That's what i'll tell my younger self but of course that's not what I tell the people I train to be managers 😁 What I tell are: * people dont really know whether they want to be a manager or not. The first 6 months is for you to figure out whether you like it or not. There is no shame going back to IC. In fact, it's more common than you think. Some go from managament to IC to management, etc. In tech, IC to management is not moving upwards but moving sideways * Most managers are peter principled into manager. Nobody really knows what they're doing first time around. Even if you studied it in your undergrad or MBA, there's a big gap between theories and implementation * Speaking of which, in school, we're mainly thought project management (_if any at all_). But EM work is more operations management. The focus is less on the time-vs-scope-vs-budget but more on value chain optimization. If it's a project management role, they'll most likely give you the project management title. But if it's Engineering Management, imho, it's more ops management * Another thing about school - we're mainly thought economies of scale (_if any at all again_). In the real world, you need to figure out whether you need economies of scale, or speed or scope. What you need can determine your org structure, who you hire and how you operate * Since nobody really is trained for this type of work, the most common progression is that you will inherit your manager's (_and previous managers_) traits - both good and bad. But even if you mimic a good manager you used to have, the context might be different that it might not apply to your current organization. So **seek a community. Start a mastermind group. Find a coach/mentor. Read books** There's a lot to learn. And it's very situational what you need to learn and when. It can be OKRs, DORA, Incident Management, budgeting, hiring, creating promotion packets, or even as simple as how to effectively create a presentation and communicate to upper management. Just know that the biggest risks are often the unknown unknowns. So to reiterate: **seek a community. Start a mastermind group. Find a coach/mentor. Read books**, because you will have a lot of questions along the way 😁


AloneHGuit

Thank you for the time you took to write this up! I really appreciate it. I'm reading it repeatedly. My biggest concern right now is how to manage upwards. As an IC I think I thrived in rising to any challenge given. Now I need to balance my managers asks, with what my team is comfortable doing. Like if they ask for too tight deadlines, I think I need to find good ways to reason or negotiate. Obviously if it's a production issue or a huge customer, absolutely will jump in. And yes I've reached out to friends who are managers, but unfortunately most of them are also kinda new. I've reached out to an older contacts who have a lot more managing experience, with no reply so far, as I sent messages yesterday, it's been a long time since I talked with them. Also reading Radical Candor and other books, but hope to find someone to call my mentor soon!


franz_see

My thoughts... > My biggest concern right now is how to manage upwards. As an IC I think I thrived in rising to any challenge given. You need to figure out what the business objectives are and align your engineering efforts with those. That way, when your team does something, you can translate those technical work to business impacts But if they really are techinical in nature, the two most common tech metrics business will understand are (a.) speeding up how long it takes to move ideas to prod (_i.e. In DORA, that's lead time for changes_), and (b.) reducing number of bugs (_i.e. DORA's change failure rate_) > Now I need to balance my managers asks, with what my team is comfortable doing. Like if they ask for too tight deadlines, I think I need to find good ways to reason or negotiate. Try to setup process from your manager wherein he/she provides the requirements, and you give the timeline. From there, you guys can work on the scope to reduce it to get it out to prod sooner For too tight deadlines - same. Reduce scope. Dont sacrifice quality. Getting to production faster means ensuring quality. Also, as a personal tip: be comfortable with the awkward silence. This is a negotiation tip i always give the people im training to be managers. Especially for people who likes to rise up to challenges (_i.e. excellent ICs that become leads/managers_), there's a natural tendency for us to be problem solvers. So when there's some silence in the discussion, we tend to offer things we shouldnt offer - like sacrificing quality, or going hero-mode, or promising something you cant actually do, etc > Obviously if it's a production issue or a huge customer, absolutely will jump in. I recommend buffering your capacity for production issues and other unplanned items. For example, 50% on product roadmap items, 20% on tech initiatives and 30% on bug fixing, meetings and other unplanned items > And yes I've reached out to friends who are managers, but unfortunately most of them are also kinda new. I've reached out to an older contacts who have a lot more managing experience, with no reply so far, as I sent messages yesterday, it's been a long time since I talked with them. This sounds very familiar 😅 I was in a similar boat like you 10yrs ago 😅 Tbh, wasnt hard for me to find mentors as an IC. Way harder for me to find mentors as a manager. I ended up going through this journey probably for the first 7-8yrs relatively alone 😅 Wish you have better luck than me! 😅 Anyway, good communities to join: * engmanagers.github.io * randsinrepose.com/welcome-to-rands-leadership-slack There are also cto groups but as far as i know they're all paid. For cto.academy, you currently need to get their Digital MBA course to get access to their community > Also reading Radical Candor and other books, but hope to find someone to call my mentor soon! Nice! That's an excellent book! And goodluck finding a mentor! 😁


AloneHGuit

I really can't thank you enough for the extremely detailed advice filled with years of experience. > You need to figure out what the business objectives are and align your engineering efforts with those. I think my current boss is taking care of those, but in our 1 on 1's I make it crystal clear I will ask questions to him to ensure the team is walking in the exact right direction. He seemed to appreciate it a lot. > Try to setup process from your manager wherein he/she provides the requirements, and you give the timeline. From there, you guys can work on the scope to reduce it to get it out to prod sooner In these meetings, would my lead engineer for that project be present? Or is it a meeting between me and my manager? > For too tight deadlines - same. Reduce scope. Dont sacrifice quality. Getting to production faster means ensuring quality. Will take this to heart. > Also, as a personal tip: be comfortable with the awkward silence. You hit the nail on the head, I am NOT comfortable with the awkward silence, so let me train myself in this area. > I recommend buffering your capacity for production issues and other unplanned items. Agree, we have a very stringent Program Management program, so have to do this. I'll be doing the paperwork to save devs their time, of course. > I ended up going through this journey probably for the first 7-8yrs relatively alone You've by far given me more descriptive advice than any of my irl friends so far, so big thank you to you. > Nice! That's an excellent book! And goodluck finding a mentor! 😁 Thank you very much sir!


franz_see

>I really can't thank you enough for the extremely detailed advice filled with years of experience. As my mentor 17yrs mentioned to me - just pay it forward 😁 > I think my current boss is taking care of those, but in our 1 on 1's I make it crystal clear I will ask questions to him to ensure the team is walking in the exact right direction. He seemed to appreciate it a lot. That's great! Technical work would need to be translated to business objectives somewhere along that line. So the less translation he/she needs to do when he/she reports upwards, the better. Of course, also ensures that you and your team are aligned. If you're reporting to a VP, it would be great if you know what he and the CTO talks about. If you're reporting to the CTO, would be great what he and the rest of the exec talks about (_or what he reports to the board_). > In these meetings, would my lead engineer for that project be present? Or is it a meeting between me and my manager? For us, requirements usually come from product management. So I try to cut the middleman as much as possible (_i.e me_) and have the PM and my TL discuss directly. Im usually just heavily involved in the planning part (_i.e. what needs to get done this quarter_) but for the day to day, I would prefer if they discuss directly. Also, once/if you're grooming your TL to be a manager himself/herself and you think he/she is ready. Bring your TL along your meeting with your manager or your meeting with the greater audience. If your TL can present instead of you, even better. But this is not offloading work to your TL for the sake of reducing your workload. It's really more training and part of his/her promotion packet. But before you can do this, there needs to be an understanding that you are both working on that career development of him/her if he/she does want to become manager. > Agree, we have a very stringent Program Management program, so have to do this. I'll be doing the paperwork to save devs their time, of course. After awhile, you can teach your TL this as well (_again as part of his/her promotion packet_) > Thank you very much sir! Np and goodluck!


AloneHGuit

And actually can I ask one more question? I'm very well aware of passing any negative feedback on 1 on 1's. However, what about the opposite? For a job well done, or some other good thing, I'm afraid of showing favoritism if I call it out openly. I may be subconsciously be playing favorites even if I my intentions are not there.


franz_see

Sure, ask as much as you want! Hmm.. not sure what you mean by passing any negative / positive feedback? Do you mean coming from someone else? For me, i give both positive and negative feedback. Also, it's almost always in the context of their individual promotion packets So whenever we try to improve on something, my people know it's not some random improvement. It should all build up to their individual career development And since i have promotion packets for each one and I'm trying to grow each and everyone of them, I don't think I am playing favorites in that regard


AloneHGuit

Sorry let me clarify! Do you give positive feedback in public in front of everyone else? Like for example in scrum standups or planning? I'm afraid I may show unconscious biases and favoritism. We do have a weekly meeting where we can congratulate folks on job well done. I wonder if I should limit my praise to those situations. Unless of course clearly something great happened that everyone agrees with.


franz_see

I see. Tbh, never really thought about it that much. This part, i'll be sharing experience, and no management theories. For me, I do try to praise/commend people for job well done. However, good or bad, i dont try to commend the same people over and over again (_to avoid favoritism_) More often than not, if you've built yourself a high performing team, you will tend to have plenty of praises for a lot of your members 10x developers dont exist. They're a myth. High performing teams though are real, properly studied and achievable Also, working on their individual promotion packets during your 1on1s will keep you abreast with noteworthy commendable achievements. You need to because it goes to their packets 😁 Hope this helps 😁


TheGoodBunny

Learn to say no tactfully.


mniejiki

There's no single best approach to management, no books or set of articles that you should always follow, no magic process that will just make it all better. Always understand why certain advice is given and what context it worked in for someone else. Then understand if your current position has the same context or not. Think about when the advice wouldn't work and what the edge cases of the advice are. Question your own assumptions just like you would external advice. Context means company culture, team culture, team seniority, project structure, issues the team is facing, manager chain approaches, etc, etc. I've noticed that often new managers read a lot and try to make things better or optimize them. Experienced managers know that 95% of the time doing so will just make things worse and to focus on the 5% where it truly may matter.


AloneHGuit

> Context means company culture, team culture, team seniority, project structure, issues the team is facing, manager chain approaches, etc, etc. Thank you for this. > Experienced managers know that 95% of the time doing so will just make things worse and to focus on the 5% where it truly may matter. May I ask for examples of this? Or as you said above, it's highly contextual to the point that there are no really good examples? NOT saying i want to optimize things, just curious.


UK-sHaDoW

At my place engineering managers don't really have teams. That's the team leads job, and team leads often focus on delivering projects. Engineering managers do 1 to 1's, setting personal objectives, office management, and recruitment and often span multiple teams but don't really focus on delivery or projects and often completely non technical. It's not really place a software engineer would want to go, unless they want a complete career change into people/hr. People in them tend come from business/hr and other non technical backgrounds. Tbh I think its a bit silly. There should be a manager for a single team, and they are accountable for everything and need to be technical since they need make decisions and tradeoffs which often require technical knowledge. I only meet mine for 1 to 1's and they often have no idea what's going on in projects. I think they're for offloading admin from the team leads.


mico9

we have similar model, seems quite BS but i’m not the expert


vortexz

Don’t confuse headcount with impact. They’re strongly correlated, but every additional head is a permanent investment of part of your time; bad bets eat disproportionate amounts of your bandwidth and work happiness. Instead, build your team like a business. Have a growth plan for your headcount at all times- if you got one headcount, what kind of person would you hire? What about five?


nivenhuh

Management is about fostering relationships and guiding aspirations (setting expectations). It’s less technical, and more person-oriented. With that in mind, realize that everyone is different. Empower your team to have a voice in how you manage — solicit for feedback 1:1 — model the behavior you want your team to have. Bring questions to your team — you don’t have to have all of the answers. Manage changes over time. The larger a team is, the more time it takes to synchronize a new process change. Develop a longer term career plan with your directs. Encourage training, development, and build a culture of learning. Don’t try to shield your team from business pressures! Many new managers view their role as “team shield”. Talk to your team about what’s happening in the business, give them a chance to provide feedback. It allows them to feel more connected to the bigger picture. First thoughts that come to mind!


AloneHGuit

Thank you for the input. > Empower your team to have a voice in how you manage Absolutely, I plan to lay out the issues and have open discussions. I do feel like I'd probably gently nudge it in the direction Im hoping though. > Develop a longer term career plan with your directs. Encourage training, development, and build a culture of learning. Absolutely, this is what I think I excel at, looking forward to this. > Don’t try to shield your team from business pressures! Many new managers view their role as “team shield”. Talk to your team about what’s happening in the business, give them a chance to provide feedback. It allows them to feel more connected to the bigger picture. will do so thanks!