The conversation

Lessons learnedExperience excerpt · English

New managers who had been engineers before management and care about the work always tell me "I …

… New managers who had been engineers before management and care about the work always tell me "I feel like I'm not doing anything, I should be helping or something." And I tell them, your job is to look. Look at your team, who is working late nights, who isn't. Who is meeting their commitments, who isn't. Let their actions guide you getting them what they need to be the best they can be, things that you, and only you, as the manager can get for them. That often means blocking incoming requests for more "stuff" (features what not), carving out time for your "doers" to help bring the new people up to speed. As part of an IBM manager training video there was a discussion about how the US Navy trains every person on a submarine to do every job because you never know when the person whose job it is won't be available to do it. That really resonated with me and I tried in future groups to try to overlap skills and cross train folks so that everyone could both appreciate what their peers were doing, but could also help out in a crunch if one part of the work needed more effort briefly.

Original discussionLoad 'em up and throw 'em under the bus168 source comments · at import
7

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 7

Direct replies available in this import. Original-language excerpts.

JE

> Your job is to look A really dramatic way of learning this is to be a volunteer firefighter. After a couple of years of experience where you know all the roles, they have you try out incident commander in an exercise. Now your job is to keep your head up, your eyes open, your hands off the equipment and manage your team. And you fail and fail again until you finally understand the role of a tactical commander (line manager).

Full original
KE

I learned a similar lesson outside of tech... with low wage employees. Often people would have problems dealing with our employee's and complain, but if we dug a bit deeper, it was very often an issue with training, manuals, high turnover, or managers not being good at setting expectations.

Full original
JD

The cross training point is absolutely crucial. I've managed or worked on multiple Ops teams where one person was the "network expert" or the "kubernetes expert" or whatever. If that person left the company for any reason, or even went on vacation, it was a disaster . People on a team can and should have their specialties but you absolutely must document and cross train so that someone can fill in when the expert is unavailable. Anything else is a horrible failure by management.

Full original
SC

> who is working late nights, who isn't Add to this who starts work early and who doesn't - just tracking when someone finishes working doesn't give you any information without knowing how long they've actually been working for when they leave.

Full original
CO

> And I tell them, your job is to look. Look at your team, who is working late nights, who isn't. Sounds like a toxic environment...

Full original
GH

And, of course, there are people working for that manager who don't think they are doing anything and that middle managers are a waste of oxygen--even though, in fact, they're shielding their team from a lot of crap and, as you suggest, they're doing a lot of coordination of a situation that would otherwise end up with a lot of wasted motion.

Full original
PR

> New managers who had been engineers before management and care about the work always tell me "I feel like I'm not doing anything, I should be helping or something." Your points about managing (interfacing with the company, translating company’s demands into a reasonable, steady stream of work) are spot on, but I would also note that the expectations for engineering managers are all over the place right now. In my first engineering management job I was severely chastised for writing too much code, even though I had the time and was choosing non-critical tickets for myself. The company insisted that managers should manage/delegate and developers should develop with little to no overlap. I internalized this as the way management was meant to be. Later in my career I took another management role and followed the pure delegation strategy. I was later chastised for not writing enough code. T…

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.