On being an Engineering Manager

http://codeplease.io/2018/01/15/on-being-an-engineering-manager/

by RPeres • 9 years ago

200 67 9 years ago

twobyfour• 9 years ago

A manager should be optimistic. A team's moral compass is highly influenced by their lead. I am skeptical and pessimistic by nature, I find it to be somewhat of a struggle to keep a positive outlook. In this particular point, I failed.

I find this challenging too. Any suggestions from other pessimists/skeptics for presenting a more positive outlook?

wmij• 9 years ago

I also find this challenging. One thing I can suggest that has helped me on my current project, is to do a morning standup. It's always brief but I use this time to set a mood/tone for the day. I try to lead with something relevant for the team or business, hopefully good news, but still try to motivate with a sense of direction towards what we're working on and where we're going. We'll each give our status and have an opportunity to bring up blocking issues, successes, or anything else. But I've found that my team looks for this ritual to assess my mood. I try to stay optimistic towards the effort, our business and the opportunities we're all working towards. When it gets slightly frustrating on a day to day basis where the "business" side may not be meeting the "engineering" side, I try to make dry light humor where we can laugh a bit during standup knowing that we're pointed in the same direction. Not an exact science, but on the day to day, try to find something to laugh about. This usually finds people willing to pair up together to take on "the cause" or whatever the team needs to get done.

swap322• 9 years ago

One thing I can suggest that has helped me on my current project, is to do a morning standup

I've found that this is the only sane way that works if you're trying to manage a team of 15-20 people.

rb808• 9 years ago

I too like to dwell on the negative side. When you're the boss everyone really is looking to you so it is important to keep everyone's morale up.

Hopefully by the time you're a manager you realize the grass isn't perfectly green anywhere, and every team has good and bad points - remind everyone of the good that is happening. Maybe you have to start policies that people will like ie interesting tech or tools. Even if things are going badly you can have team lunches or drinks that are non-work related - it really helps team spirit.

zer00eyz• 9 years ago

I find that pessimists miss a critical factor a lot of times.

Things that are empirically bad are just going to suck.

Things that are just "hard" are going to suck too.

In business RARELY are things actually bad (site outage, layoff) and often just "hard" (I need you to work late).

When things are hard you can say they are HARD and let them be HARD and use the occasion as a chance to create camaraderie. Stuck late in the office, then start singing show tunes badly - bring in food and beer (if appropriate) or good coffee the day after - hard times build great teams if they aren't "every day"

Find a things to have with your team to make it more entertaining - I worked in an office that ran on the back of quoting film, and there is a film quote for EVERY situation. A good friend of mine works in a "nerf gun" office, and I used to work in a place where "team lunch" was a thing that was sacred (you would leave every day for an hour). Alone these things don't do much but when it is HARD (or bad) the activity restores a sense of normalcy for you and your staff.

Be honest about hard, sometimes you just need to STFU about bad (layoff).

ska• 9 years ago

   I find that pessimists miss a critical factor a lot of times.

Optimists miss critical factors all the time also. Which leads to all sorts of problems with expectations.

I think the real answer is to be optimistic about people, but realistic about projects.

You are right about hard vs. bad, but it's also worth noting you have to be careful about pushing your own ideas of team support. When you are asking more of people (stay late) it's worth thinking about what you can give them that they want, not what you envision. And if it gets really HARD, think about how hard you can advocate for getting them something material after (promotion for performance reasons, extra time off, a situational bonus, whatever)

clusmore• 9 years ago

My partner struggles with pessimism, usually caused by focusing too much on the work ahead and too little on what has been accomplished. One technique we've found that helps is to keep a "done" list, separately from the "todo" list. The size of the todo list can be intimidating, but having a separate list which only records accomplishments that you can look over when you get stressed to remind you of just how much shit you've got done. From the perspective of a team, this could just be making sure that you spend enough time celebrating your wins.

amorphid• 9 years ago

It's a lot easier to be optimistic about a product you actually care about in some way.

yannis7• 9 years ago

I find that the biggest intellectual mistake of pessimists is that they take an actuarial view of reality: "99% of startups fail, thus we are doomed from the get-go and our <current problems> are evidence of that".

This might be correct if you take a 3rd-person perspective view, but ignores human agency and the ability to steer situations - sometimes via sheer willpower.

See Paul Graham's essay on Intellect vs. Determination.

tboyd47• 9 years ago

Savor the small victories.

gopalv• 9 years ago

I mostly break-down leadership tasks into 4 groups

1. delegation

2. negotiation

3. vision

4. inspiration

A typical EM only needs to do two of those well, same with higher up the ladder, though not the same two through the ranks - in my experience, great ones hit all 4.

Delegation is mostly about tasks, negotiation is about interactions (either salaries with HR, deadlines with PMs or even figuring out what a specific employee wants out of a job, because not everyone responds to just money or prestige).

Vision is more complex - a manager needs to be able to guess the rate of funding for the current project, read the way the wind is blowing and navigate the team.

Inspiration is so rarely seen, because it is hard to connect the results to the actions (the "be positive" part of the blog) - but I've had engineering managers who've made me feel that I'm in a "safe space" to do interesting things, instead of the reality that I'm in a closely watched, judgemental situation with large sums of money attached to each action and reaction.

gdubs• 9 years ago

Management is not always equal to leadership. They can be very different roles. (And, they can of course overlap.)

One is more focused on tactics, the other on strategy. One is deciding which direction to sail, the other is making sure everyone is keeping the boat going in that direction.

bonniemuffin• 9 years ago

"giving to other engineers features that I would like to do myself" is one that I struggle with as a data science tech lead. If I'm leading a team of people and deciding who does what, I want to give my team members the interesting work and not hog all the cool stuff myself, but I don't think it's a good use of my time to be doing only the tedious stuff. I'm not sure how to strike a balance there.

huebnerob• 9 years ago

This is a gross oversimplification, but why not just dole out the good projects round-robin, where you're just one of the members of the cycle? There's no reason why a manager should never be able to contribute work, just that they probably shouldn't always take the 'good stuff'.

pugworthy• 9 years ago

Because as a lead, they may know a lot more about something, or have experience with it, or have thought about the specific problem space a lot more.

Sometimes it's that classic, "I can do it in 4 hours, but you will take 2 days. You do it, and learn something, and next time we'll be equals" kind of thing.

fallous6• 9 years ago

If it's a particularly challenging feature or problem you might consider pair-programming as a solution. It allows you to apply your expertise (and scratch the itch of wanting to do things) while also letting another engineer contribute, learn, and/or demonstrate a different view.

The two things that a good engineering manager does well is handle the internal bureaucratic and process needs of the business and to improve the people those you manage. Often the best way to improve people is to teach them how to think about problems, and in the case of pair-programming they will be exposed to that teaching either intentionally or by osmosis.

watwut5• 9 years ago

I think that other engineer would be much happier if he got another task with little bit of autonomy and trust, instead of being forced to look how you scratch your itch while he nods along.

Teaching people because they need to learn something and acting like they need to be taught while in fact you just want to do something by yourself is not the same - and your underlings can tell the difference.

throwmeaway32• 9 years ago

I would say you need to keep in mind that delivery of the team against product commitments should be a priority, and being able to do that in a long term sustainable way is very important. So in my view you should absolutely put out of your mind what you'd like to do and instead view it as what is the best way to complete the task at hand ( and making sure that can happen in a consistent reliable way). I'm a EM myself and there's no way that my day-to-day is consistent enough to code in a reliable manner especially when put up against other priorities that I have to deal with. What's more important?, you finishing a business critical feature you signed up for or helping a team member with crisis they are having dealing with another team member? (Or if you are more tech lead than people lead then compare it against more long term strategy planning and architect-ing you could be doing.)

swap322• 9 years ago

this is kind of unproductive. The job of the manager should be to push the envelope of the team as a whole. As such if he already has a high performing team, he should be as hands off as possible, focusing on other crucial areas. If not, his job is to create small proof-of-concepts of ideas and let the team take them forward.

mattbrewsbytes• 9 years ago

I would also hog all the tedious work as an engineering manager. I tried to make most of it go away but in order to allow people to grow in their careers, they have to be assigned "stretch" work.

Being a manager is an entirely different role than being an employee. Kind of like how someone could be a really awesome director of movies but may not be a good actor.

griffinmichl• 9 years ago

Personally as a manager, I find doing the tedious work to be one of the best uses of my time. It helps keep my engineers happy and focused, which is the most important part of my job.

darioush• 9 years ago

On the other hand my ability to focus on a task has dropped considerably. I am no longer able to code for 1h straight. I would say that 15 minutes is a victory... When coding I try to be out of the critical path...

Sorry, you are no longer coding as an engineer on the team and are losing insight into how the codebase functions with a speed you are probably underestimating. Engineering isn't about writing code that eventually works, it's about consistently delivering good-enough code on time.

... the company comes first, the team second and the individual third...

I think if you focus on building the team, there is no way the company and individuals do not benefit. Plus, high functioning teams often stick together across companies and employees follow managers. I'm not a manager just my 2cents.

slivym• 9 years ago

I completely agree on your second point, obviously in the long run everything has to be for the company, but hands on the team is number 1. Particularly in larger organisations the only way to manage is to focus on your team and its sphere on influence because often there is no "best for the company". The best thing you can do is build a great productive team.

hdi• 9 years ago

I completely agree and I think that if you take care of the people they will take care of each other (team). So when you've built a well oiled team that trusts each other the company benefits as well as they will be more productive and play well with each other.

I also am not an engineering manager.

beilabs• 9 years ago

While I hold the title of CTO for a funded startup I feel I have taken much more of an engineering manager role.

Ticket review, deployment, product development and general firefighting seem to be the order of the day; We have a team of 12 engineers, my biggest issue is being able to let go of the important tasks and be able to trust my team that they can deliver in the 9-5 schedule they enjoy (Entirely the opposite of the life of a founder).

Being able to hire someone to just take some of the devops tasks off of my plate is my immediate priority. I have certainly found that my skills are getting a little rusty as I'm no longer in the trenches cutting code each and every day, much more in a review / implementation position.

gregdoesit• 9 years ago

On the other hand my ability to focus on a task has dropped considerably. I am no longer able to code for 1h straight. I would say that 15 minutes is a victory. This is a problem I will try to fix somehow during 2018.

My suggestion is: don't try to fix it. As an engineering manager with a team of more than 5 people, coding is no longer the most impactful thing you're doing. Making people and the team do better is far more leverage. As a fellow EM who also loves code, I've stopped coding at work. I find there are many, lot more impactful activities I can do: from hiring activities, onboarding & training, making oncall better, spending more time with my high & low performers and building bridges with fellow EMs, PMs, executives and other stakeholders and so on.

Also, you've not mentioned 1:1s. With a team of 12, 1:1s take a lot of my time (I do weekly 30mins - this is a lot, but has been essential to spot issues early and support people better)

Good luck for 2018!

kuahyeow• 9 years ago

Agree. At some point you have to give away your Legos

base6983• 9 years ago

How do you get another job if you've stopped coding? Most jobs I've seen, even in management, still require the interview song and dance.

dboreham• 9 years ago

That doesn't make sense because logically you'd be interviewed by even more senior managers than the position they're hiring for, and hence those people haven't coded in 10 years.

sidlls4• 9 years ago

Can't speak for the parent to your comment, but in my case my intent is to continue as a Manager and seek promotion to Senior Manager/Director as soon as it is feasible.

My policy is this: in this industry if the job description includes anything that hints at coding it's not a management job. It's an Individual Contributor role with some people-management thrown in, and one (coding) or the other (managing) is likely to suffer.

cbm-vic-20• 9 years ago

According to the "HN Who's Hiring" monthly post, nobody hires Engineering Managers. At least, not the kind of companies that post to that thread.

sytelus2• 9 years ago

coding is no longer the most impactful thing you're doing

This is pretty bad sentiment for an engineering manager. The reason you do coding is not because you want to contribute in overall output but because you want to understand nitty-gritty details of what your team is doing and where are the bottlenecks. For example, I as an engineering manager quickly learned that our build system was too slow and too fragile. Or that talking to one of the external system was huge struggle. Or that there was lot of code duplication in many places for certain functionality. Many junior and less experienced engineers would usually tend to just accept these pains and rather focus on their immediate deliverables. An experienced engineer would immediately see this as opportunity to sacrifice little bit of short term goal for huge long term gain. You can't build a city by only supervising things from 30,000 ft.

At absolute minimum, an engineering manager should do code reviews very frequently spending at least 20% of their time. My litmus test for an effective engineering manager is if they can debug and fix a trivial bug that any of their junior developers easily can. There are "engineering managers" who can't even build their own product that they claimed to have lead. Those are usually a disaster-in-works.

sidlls4• 9 years ago

I'd agree if the team has no senior engineers, or in which the senior engineers are not adept at finding and communicating the issues you note, that the EM should fill in the gaps. I'd be skeptical of the long term viability of such a team. What you describe is more properly the purview of a Lead/Principal Engineer, in my opinion. The people in those roles should be able to communicate the technical issues to the EM, and the EM should have the technical chops to understand it (and the code). She shouldn't be hip-deep in builds and coding, and shouldn't need to be.

That's not to say no coding should be done by the EM, but it shouldn't be "impactful" in the same way an IC's coding activities should be.

jlengrand• 9 years ago

So happy to hear that I am not the only one suffering of #6 \o/. This has been really bumming me over the last months.

Chyzwar• 9 years ago

The direction is most important, everything else is secondary. I can develop better code if I know what is coming in following months. I can optimize where it is needed or hack quick solution when I know technical debt cost.

Being a team cheerleader is nice but leading in the right direction is critical. And yes, you need to be technically sharp if you want to make any assessments on individual performance. Code reviews, architecture design, post-mortem and sprint reviews should be EM main thing.

toolslive• 9 years ago

Managing engineers is different from managing a manager (yes, they need to be managed too) : you don't approach your manager with a problem, you approach them with a choice in possible solutions. The trick is to make sure that whatever they choose, it's going to work out fine. An engineer is different: you don't approach them with a task or a solution, but with a problem optionally with constraints.

aalleavitch2• 9 years ago

This is definitely the biggest pitfall I’ve run into both as a managed engineer and as a manager. It’s intuitive to think delegation involves forming a specific task and giving it to someone else, but that’s a waste of their brain power. Giving them an open problem to solve is going to result in freeing up your mental energy and will make them happier due to increased agency. In general, you want to give workers as much agency as they can competently handle.

lbotos• 9 years ago

As a manager, the company comes first, the team second and the individual third.

I think managers should take a little more nuance into this equation.

As a manager you sit between the interests of the business and the interests of your reports. Depending on the context the hierachy might actually be individual/team/company.

If you keep the model of company/team/individual, you will be seen as great at "managing up" (in this case also you might be seen as a "suck up"), decent at managing across departments, and your team will probably think you could care less about them.

There will be many times where this hierarchy changes and knowing when/how/why those changes happens will take you to next level management.

E.G. In a 1:1 with your report _they_ are a priority. (managing down)

In a company wide address on team performance, the needs of the company+the team need to be addressed. (managing up and across)

In an executive meeting, the needs of the company are paramount (managing up)

etc etc.

RPeres• 9 years ago

I do care deeply about the team and each individual, some of them are my friends. Ultimately, in order for all of us to have a job, the company needs to succeed. But I agree with the nuance. Thanks for the feedback.

DoofusOfDeath3• 9 years ago

Having awkward conversations, about missing a deadline, a particular behaviour, or some other thing, has created a psychological burden in me. In some cases it actually keeps me awake at night, thinking about some displeasing situation, which of course has ramifications in my overall performance later.

The best solution I've found for this is to start reading books related to managing teams, having difficult discussions, etc.

Once I did this, I found these kinds of discussions to be more of an intellectual exercise, opportunity for experimentation, etc. I.e., it gave me a level of personal detachment that made the discussions much easier, and hopefully more productive.

fprct• 9 years ago

The best solution I've found for this is to start reading books related to managing teams

Any particular position you would be willing to recommend?

DoofusOfDeath3• 9 years ago

Improve my ability to focus.

Depending on how bad this is, and how long it's been a problem, you might consider getting tested for ADD.

I waited way too long to do that, and I had decades of unnecessarily reduced productivity.

DoofusOfDeath3• 9 years ago

Or even without ADD, you might wish to look for a correlation between your attention span vs. how well you slept the night before.

Getting a good night of sleep seems to get more difficult as we get older. Lack of sleep impacts many aspects of mental performance, including attention span IME.

andrewljohnson• 9 years ago

I disagree that something a manager should be chastening developers for at a product company is missing a deadline.

When your only stakeholder is the user, deadlines are all artificial. It might be different at a consulting company.

I'm not saying companies shouldn't estimate and schedule work, but missing estimates is almost never an individual developer's fault, it's systemic and/or a failure in management.

If a developer isn't productive enough for their seniority level overall... that's something a manager has to address. But if a developer misses a deadline, it's probably the manager's fault. It's probably the manager who needs to be working on their estimation and tasking methods.

vram222• 9 years ago

When I was doing management in software companies, I found Management By Wandering Around (MBWA) [1] to be useful.

Being an unstructured activity (but still planned, in the sense that you knew that you were going to do it now and then during the day or week), you tended to get more out of it in terms of information about progress, status, issues, and being able to help team members, technically or otherwise.

[1] https://en.wikipedia.org/wiki/Management_by_wandering_around

It was supposed to have originated, or at least been used early on, at Hewlett-Packard (and also earlier by Abraham Lincoln :) see [1]).

Although I worked for a while in a company that was a joint venture with HP, I did not learn about MBWA there, but later on, in another company where I was doing management. Read about it in a management book, thought it was a good idea, and tried it out; turned out that it was useful.

AllegedAlec• 9 years ago

Not to detract from your experience, but this sounds a lot like micro-management.

You should not have to check up on the status of ongoing projects; you assigned those projects to someone with clear deadlines, etc. etc. If you don't trust that person to be able to finish it: why did you assign it to him? If you do trust that person to be able to do what you asked: why are you bothering him about the status of the project?

vram222• 9 years ago

Thanks for your comment, I am open to discussion or disagreement, although I may or not agree with the specific points raised - on a case to case basis.

Not to detract from your experience, but this sounds a lot like micro-management.

In this case, I disagree that it is micro-management, although I do think that if overdone, it can degenerate into that. It is a matter of degree and also of how it is done.

See my replies and quotes of excerpts of your comment below.

in the sense that you knew that you were going to do it now and then during the day or week).

So the emphasis is on "now and then" (and "now and then during the day or week" did not mean "multiple times during the day with the same person", at least as I used to do it).

Once a day with a few people (not every member of the team per day, e.g. in the case I am talking about, I had a team of 10, and might have had the one-on-ones with say one to three of them per day, and not every day either), and that would be enough, unless there were some serious issues, in which case more management or help or guidance is definitely needed, or the manager is not doing his/her job.

Also, it was not like I was grilling them on goals and deliverables each time I talked to them - it was more like sitting down next to them and asking "how is it going?" and only if they mentioned any issue or problem, would I delve into it and see if I could help. Sometimes they would themselves tell me that they had an issue and ask for advice/help. It was not an antagonistic relationship. In fact the chief accountant of the company, who sat in a section next to us (this was a company with cubicles, ha ha) once said to me (presumably he could overhear us talk since he sat near us) that "you have a good team". I took that as a compliment.

Actually I also used to informally (as in, not a formal code review, although we had those too) look at the code they were working on currently, and sometimes would spot issues (could be small ones like redundant computations like checking the length of a string being looped over, in the for loop itself, instead of before it (aka code hoisting - see Writing Efficient Programs by Jon Bentley).

It was technical and project management, BTW, not MBA-type management. (Project management might have a different connotation in Indian companies from some Western ones, in case you don't know that. In Indian companies it tends to be a blend of both technical and project management (as US people understand the latter term). (I've worked in/with both Indian and US startups and large companies (all 4 combos), that is how I know this.)

Also, in this particular team, they were all freshers, just out of company training after being recruited, so more management was needed. [1] But I think MBWA can be helpful even with more experienced people who report to you - maybe at a lesser frequency.

Multiple issues with your comments below:

You should not have to check up on the status of ongoing projects;

Sorry, wrong, IMO. A manager's job is to manage (though not micro-manage; hell, even micro-management may be appropriate in certain situations, depending on the skill and experience level of the managed people, and a host of other factors.

Please don't generalize. And checking on status is a normal part of management duties.

Repeating:

>You should not have to check up on the status of ongoing projects;

That is so far off the mark that I am almost at a loss for words (but not quite :) If an employee cannot handle the fact that the status of their work has to be checked on, then they are violating the contract that they voluntarily signed up for when they joined the company (except for free-wheeling companies where they may be no such agreement), because in most employment agreements, it is a standard clause that the employee has to follow the instructions of their managers (obviously, only regarding work, not anything else, and within reasonable limits, but status reporting and checking is very much a part of reasonable limits).

As I've heard it said, a project or a company is not a democracy. Just check out real democracies if you want to get an idea of what chaos can happen if you run a project or a company as such, ha ha. That does not mean that it has to be a command-and-control situation and everything is to be decided top-down either - that often does not work too. It just means that there can be a reasonable amount of discussion about how to do things, what to do, etc., between the team members and the manager, but ultimately the manager's decision has to be final (mostly - and any enlightened manager who does not have ego issues should/will accept the suggestions of team members if they are better than what he/she thought of). Of course there can be incompetent or evil managers, for that the remedy is to go report the issues to higher levels or other options (including legal), as needed and makes sense.

And:

>You should not have to check up

The manager carries the responsibility for the results of his subordinates, so he definitely can and needs to check up. I am not sure, but based on your comments, you might be coming from the background of some small US startups, where everything is on the fly, free-wheeling, "cowboy coder"-style, etc, or might not even have worked much in real companies. I don't mean to denigrate that approach in total, but in many cases, it does not work. I have been on both sides of the fence, for non-trivial periods of time, both working for/with small and large (so-called "enterprise") traditional companies, as well as small free-wheeling US- and Indian-based startups, at different times in my career, including switching from one type to the other and then back again, so have seen both (or rather multiple) sides of the picture, and have come to realize that there are pros and cons to all those approaches.

In fact I have even worked in traditional (aka non-startup companies) of both the free-wheeling / "cowboy" as well as the more formal / process-driven kind.

you assigned those projects to someone with clear deadlines, etc. etc.

Who said the deadlines were clear? Were you involved in that particular project, so that you know?

If you don't trust that person to be able to finish it: why did you assign it to him?

Even this statement shows you talking about stuff you do not know about. Who told you that I assigned it to him? Can it not be the case that I was given a team to work on for the project, and had no say in the choice of people? Does that seem impossible to you? Do you always get to select your team members, if you are or have been a manager? (Then you might not be much aware of business realities, which are not always (or even mostly) aligned with what people involved would like things to be like.) That was the case here, in fact - I did not get to choose the team. Stop making so many unfounded assumptions.

If you do trust that person to be able to do what you asked: why are you bothering him about the status of the project?

See reply to above point (too). Sorry, I'll have to call that a very idealistic and impractical notion. In business, to quote a saying: It's not the things that are expected that get done, but the things that are inspected.

[1] There is more that I can say, including some shockers, but this comment is getting long, so I will just give a hint or two:

The company used software engineering practices (it was not a startup, BTW), and required software engineers to use checklists for different phases of the s/w dev life cycle.

I have seen (example of shockers) team members do things like dutifully place a printed copy of the checklist for, say, program spec creation or unit testing, on the desk at the side of their PC, and then proceed to happily ignore it while doing the actual work!

Another and worse example: a dev on my team (actually saw this on his screen) wrote an if statement to check for an error after some operation, and then happily printed a message that there was an error, and went on to write the code for a following operation (after the if statement and error message printing) that depended on there being no error. IOW, print the error message, but then go on as if no error happened!

I rated him the lowest of the team during appraisals, because that error of his was avoidable by sheer common sense; you do not even need to understand anything about programming to avoid it. I mean, it's like saying: I see a deep ditch in front of me, I yell out a warning about it, then proceed to fall into it!

Of course this was an outlier, but you may be surprised about how often such kinds of blunders can happen, even at somewhat higher levels in companies.

(Edited for typos and re-wording.)

On being an Engineering Manager

Related Stories