On being an Engineering Manager
codeplease.io
codeplease.io
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!
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.
Seen everything in an interview at this point.
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.
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.
By the way, I was just last week promoted from Lead Engineer to EM. I am, as you say, qualified to hire, fire, design and code. I think you're too dismissive of key aspects of running a business. Coding isn't everything. It's not even the most important thing.
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.
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.
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.
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.
I specifically mention that you look for particularly hard or challenging problems in which to do the pair programming precisely because it's an opportunity to both "scratch the itch" as well as teach. In every group I've ever worked in, worked with, or managed there were inexperienced people and those people tend to get less-interesting tasks simply because they lack the experience or knowledge required for hard, challenging, or critical problems. The best way to speed up their learning curve is to give them tasks that exceed their current capabilities, and the best way to minimize the risk is to provide the safety net of a more experienced and/or capable partner to help them learn to think through the problem and catch errors. As an added bonus it is entirely possible that the more experienced partner actually learns something from the pairing as well.
It is not true that all juniors avoid harder tasks, my experience was that they seek them. They are eager to prove themselves. Also, what is hard for them is not hard enough to challenge me.
Supervising and teaching a junior dev working through a hard problem most assuredly satisfies problem-solving itches because in addition to having to think of solutions yourself (often internally) you also have to think about what they're doing and when they struggle you have to figure out a way to lead them to a better path and insure they understand both why they were struggling as well as why a particular path is better. Simply telling someone to do X isn't teaching.
I did not say that juniors avoid harder tasks, they almost always underestimate their limits and try and take on more than they are capable of. I said they tend to get the less interesting tasks, because no sane manager working in an actual business hands out the "re-architect our entire infrastructure" job to the most inexperienced member of a team.
There are interesting tasks for juniors, even easier to find that interesting tasks for seniors, they just don't tend to be large like "re-architecture everything" which should not be task for single person at all. And which is also largely political task (meaning it is as much if not more about negotiating and convincing people).
My experience with younger people is different than yours, clearly, but that might be influenced by how your and my company chooses people and how management behaves. My experience is really that they are very likely to underestimate difficulty and size of task.
The advice that most of them needed to hear were usually brainless easy to me - mostly concerning organization of work and code, when to ask customer, how to refactor safely, that sort of thing. Algorithmic or read-up-on-it technical or math or anything else requiring deeper thinking were things they were good at.
"Algorithmic or read-up-on-it technical or math" aren't the things I consider to be deeper thinking for programmers but instead are skills and methods that we'll always be continually having to add or hone. Deep thinking, which through my experience with others qualifies as hard due to the relative rarity in which I've seen them capable or willing to do, are much closer to the things you feel are brainlessly easy. That's not unusual since we often under-value the things that come easily to us by assuming that it comes easily to everyone. Learning how to _think_ about a problem, how to understand it at a fundamental abstract level and then build a mental and theoretical model needed to bring that vision to the point where implementation can occur is far harder than writing the code for the vast majority of people.
I also used to think "this is obvious and easy for me so it must be for others as well" but time and again that's proven not to be the case. I learned to focus on making sure my people can think the right way so that at worst they can respond to surprise difficulties or crises on their own but the best hope is that they become better than I am. With the right people in the right environment, if I'm doing my job well I will make myself redundant or superfluous.
Such task is just about worst possible choice for teaching task. Imo, if you want to do that task and have time for it, do it and don't apologize for that. As long as you don't cherry pick all cool tasks it should be fine.
And you if you think you need teach them something, pick up task best suited for whatever you want to teach. Not one you wish to do yourself, but the one that is best for learning.
Don't have personal hidden agendas around things like teaching and pair programming. Pair if you think pairing is helpful, not when you actually want to do it personally, but feel ashamed because your title is manager.
> giving to other engineers features that I would like to do myself" [...] I want to give my team members the interesting work and not hog all the cool stuff myself ...
It even implies that they are fully capable and that he trusts them to do those tasks. It also implies that he indeed would like do that task, because he finds doing that task "cool".
Both are marks of good leader and so is being self-aware. None of them implies him team members need to be taught or that teaching instead of doing task them would satisfy his wish to do the cool thing.
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.
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.
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.
I also am not an engineering manager.
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.
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.
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.
Any particular position you would be willing to recommend?
I find this challenging too. Any suggestions from other pessimists/skeptics for presenting a more positive outlook?
I've found that this is the only sane way that works if you're trying to manage a team of 15-20 people.
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).
I find that pessimists miss a critical factor a lot of times.
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)
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.
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.
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.
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.
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?
>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.)
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.
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.
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.