Hacker News Reader

I'd be interested to see whether your subordinates agree with that assessment. One of the better programmers I've worked with was promoted to our manager and tried to "keep coding" and it made her one of the worse managers I've had: the team was constantly blocked because her tasks got delayed when she (as is the nature of management) was pulled away for meetings with higher-ups or other unexpected work. In turn that meant there was pressure not to interrupt her when she was at her desk so it was hard to bring problems to her, even though that's a manager's primary responsibility.

What if the manager only takes care of minor things that are not on the critical path? That being said, given how busy managers can get (it's a totally different world that many subordinates would not appreciate, don't blame them), I can see how difficult it can be for even non-critical stuff. And besides that, I suppose that if not involved in critical things, the alleged benefit of "being on the ground" is mostly lost. Curious to hear people's opinions on this question.

The solution to that is simple: the manager should act like they're assigning tasks to a junior developer or intern: optimizing for "learning about the environment" (which is a goal shared by new team members and managers) and "keeping out of the way" (which is good if you are unsteady due to being new or if you are unsteady due to unpredictable external tasks.)

I realized early in my management career that I should keep coding, but I should a) never let it interfere with my management duties and b) should only be for non-critical path stuff. I focused on quality of life type improvements such as sprucing up a dashboard used by ops personal, refining the CI/CD process, simple utilities to extract/transform data, etc. Another key requirement and benefit is that by letting your team do the "real" work, you're showing your trust and letting them grow.

The place where I continued to actively participate was in architectural and system level planning discussions. In that capacity, it was to mostly ask questions, ensure focus on objectives, and very occasionally offer advice. It's mostly facilitation and mentorship.

When I managed developers, I didn't have a list of programming cases that had my name on it. It's more that I would pitch in on complicated or challenging pieces of the code, typically with pair programming. I found this develops a different kind of relationship with developers (I'm a valuable resource, not a micro manager) and allows you to establish your technical skills without becoming a blocker for deliverables when you have to spend your time managing up. It allowed me to stay involved and very familiar with what was happening "in the trenches" without taking on a bunch of programming tasks which are better handled by dedicated developers.

There are folks who would get in to competing with their own direct reports or would be very harsh for what the conceive as mistakes leaving little room for alternative thinking and options. I think these type of folks are not the best cut out for management without further coaching and reflection. However solution is never shutdown the coding for managers or make them as technically as dumb as possible.

A "engineering manager" should have at least one task, it shouldn't be blocking or critical. The manager should at least build the code, push it, and see the unit tests actually run. With enough experience you should be able to spot things, eg, "HEY! There are no unit tests for this part!".

Not doing this makes you the restaurant owner on Gordan Ramsey's Kitchen nightmares. These restaurant owners are always confused whey their food sucks, why food is rotten in the fridge and why everything is failing. If you want to know why you shouldn't leave the 'process of developing software' -- just watch one show of Kitchen nightmares. Also, if you 'are too high up to code' -- change your title to: "project manager".

> A "engineering manager" should have at least one task, it shouldn't be blocking or critical. The manager should at least build the code, push it, and see the unit tests actually run. With enough experience you should be able to spot things, eg, "HEY! There are no unit tests for this part!".

If you're saying we don't need managers anymore because that's what our CI/CD pipeline does, I agree!

I think a good manager has other responsibilities such as negotiating with other teams to enable their team's success. They don't need to understand the low-level details, but they should be able to comprehend complexity when explained, so even if I only produce '1' feature, they can be certain that my good job didn't produce '10' additional bugs to be discovered by the customers.

That's the difference between a manager and a lead in my org. A manager shouldn't be hands on (besides private or on the side research).

As a point of fact, there are plenty of episodes of Kitchen Nightmares where the main reason for failure seems to be the owner meddling too much with the people who are actually doing the work.

Did you even watch the show? In about half of the episodes Ramsay kicks the owner who can’t cook but thinks he can out of the kitchen and lets staff handle it

My experience of moving into engineering management has very much been that I need to keep writing code to truly understand what people are facing, and ensure I'm not coming up with crazy ideas that will be a pain to implement.

The only caveat I'd add to that is that I can't keep on working on things in the critical path, at least as the sole developer picking up those tasks, because I'm hugely more likely to have things come up that prevent me from doing those things in a timely manner. That then leads to other people being blocked on my work.

The best balance I've found is for me to either pair with a developer who's able to remain focused on a task when I'm inevitably dragged away to do something else, or for me to pick up non-urgent tasks like refactoring, or developer tooling. The latter is probably my favourite as it means I'm applying my experience to tools and libraries that can then be used in widely applicable circumstances to make the rest of the team more productive.

Letting go is the most challenging part. If you build/hire the right team you trust them to tell you nifty technical things. Manager's job is to remove road blocks and protect the team from "outside interference" and distractions, like reorg discussions, new features/deadlines, scope creep and stuff... What you describe is more of a technical lead.

I agree, I'm troubled by the notion of not coding at all. However I think you need to separate "coding as part of the work effort to achieve tasks of the team" and "coding to keep you on top of the technical aspects of leadership". I actually think the latter is pretty essential, while it's a mistake if you are doing coding that is irreplaceable within the team. (I'm currently making that mistake, but that's another story).

...you need to separate "coding as part of the work effort to achieve tasks of the team" and "coding to keep you on top of the technical aspects of leadership"...

This. I've been in a management position for a few years now and was scrum master for a few before that. I try to grab a programming task every sprint, but I absolutely don't have the time to commit to large programming tasks that are critical to team goals.

I'll grab some easy tasks (stuff that takes <2 hours or so). Or, I'll pick up some analysis/prototyping work that isn't time sensitive. Or, I'll just help team members when they struggle with complex problems.

These days, I actually prefer mentoring or pair-programming with the junior developers. I have 4 of them on the team and making them more productive and independent is going to pay much larger dividends than trying to complete a complex task between meetings.

I think it's helpful if EMs to continue coding, even if it isn't at work. I've been an EM for 4 years now and keep working on side projects every now and then.

1. As an EM you do sometimes have to resolve conflicts about code between senior members of the team(if it involves the team's tech lead) and it helps to not to have strayed too far.

2. It's much easier to drive new engineering initiatives if you are fluent at code and can quickly read and understand code documentation about a new library/way of doing things.

3. Sometimes while chasing deadlines, it helps if an EM can just sit with an individual contributor and do pair programming. Reminding developers about deadline won't motivate them as much as an EM sitting beside them and helping them out with coding.

4. EM jobs can be a bit hard to find, so being fluent at coding helps you to secure a job much easily since individual contributor jobs are far more prevalent than EM jobs.

I usually try to pick up a side learning project every couple of months to just have some fun and learn something new. After moving to an EM role, I missed coding a lot and had thoughts about moving back to being an IC since EM at my company was a lateral move. Though I chose to stick on since the amount of stuff that I could pick up at a given point of time was no longer limited by my own personal bandwidth.

I completely agree with your point about team members not having to dumb down complex concepts. Sometimes team members can come up with really novel solutions to problems which cost more time to implement on the short term but pays off in the longer term. Unless one is comfortable with the technical chops of a project, it's easy to dismiss ideas which aren't conventional.

> 3. Sometimes while chasing deadlines, it helps if an EM can just sit with an individual contributor and do pair programming. Reminding developers about deadline won't motivate them as much as an EM sitting beside them and helping them out with coding.

I'm in a somewhat different field, but I had this experience a couple of times when I was younger-ish and didn't feel good about it. I don't think it raised my productivity

It may have been a good management move -- mitigating a high-stakes delivery risk by literally keeping an eye close, i.e. sitting next to me at my desk, but it felt more like panicky micromanagement (lasting for two or three days only, thankfully) than sharing the burden of an unplanned delivery.

(Unplanned delivery requests sometimes happen in my field. But what we do isn't as bottom-up as programming; it's more like a progressive GIF, iterative refinement from high level concept down to action plan, so unexpected intermediate deliveries can be good for the client.)

That's a nice insight, I'll be sure to check with the dev next time it happens to see if it's actually helping or not.

I personally do it in crunch situations for the following reasons: 1. Since there are more eyes on the code being written, mistakes made are an intersection of what either the driver or navigator would make. 2. It makes the developer less likely to procrastinate. I only use this as a last resort though and timebox it to an hour.

This works if there are small tasks that you can take care of pretty easy to stay reasonably current.

There’s a line where as a manager you’ll either do your engineering or management roles a disservice or not. Think of a napoleonic era army — You need to understand whether you are the sergeant who keeps the troops marching and fighting, the junior officer who passes orders on and keeps bullshit away from the sergeant, or the staff officer who makes sure the food and bullets show up, etc.

I completely agree (assuming not blocking task). No one is in a better position to represent, empathize, direct, and assist in employees' careers than a manager that "gets it". Additionally, studies show that employee satisfaction, trust, and respect for their manager is higher when they feel their boss is capable and can do their job.

Steve Jobs said it well: "The best managers, he says, are 'the great individual contributors' who don’t actually want to be managers but step up because they don’t see anyone else who can do the job better."

https://qz.com/work/1152331/watch-a-young-steve-jobs-give-ad...

>Steve Jobs said it well

Steve Jobs was a class-A asshole who people who are trained in leadership agree was a poor leader of humans, even if he had great success in business. I'm not sure I'd take his leadership musings without a few grains of salt.

edit: everyone -> people who are trained in leadership

>who everyone agrees was a poor leader of human

Everyone agrees?

Because I'm not sure I do. Jobs was probably an "asshole" for whatever your definition of that is. To suggest that he wasn't a capable leader of people is a rather different thing.

His leadership style was authoritative, petty, and probably even mean. It was also extremely effective. It's a style that was hardly unique to Jobs, and I can point to many other effective leaders (especially in the military) who used a similar style to achieve fantastic results. From Patton to Vince Lombardi the evidence is everywhere. Hell today we see much of the same behavior at SpaceX!

I would argue that an authoritative style of leadership, with small doses of intentional praise, can be really effective under certain circumstances. Particularly when the goal is very big, very audacious, and very hard.

There are lots of ways to lead people. Which one is most effective depends on many factors.

Effectiveness is not "good leadership". He may have been very effective, but he fucked people over, probably gave people PTSD, treated others with disdain, etc. I know some people see the Elon Musks and Steve Jobs' of the world and think they're awesome and effective, but it's a net negative for the organizations they are a part of due to the human cost.

I never said Steve was a good leader or manager. What I agree with is that the best managers of engineers are DOERS/ENGINEERS themselves. Steve was not an engineer.

Exactly! People repeat what he said like they are "words of wisdom", people committed suicide under his watch. Guy did not pay child-support for his daughter.

I don't like mixing the 2 but maybe because I don't do it often (I'm more on the technical side). When I do, I feel I am half-assing the technical part and short-changing the people expecting better management. A no-longer-codes, ex-coding manager has some of the advantages, in that they should still not need things dumbing down, but do need to delegate everything technical to the team because their hands are tied. If things are not dumbed down too much, and they are involved in technical discussions even if not the actual implementation, then they can stay on top of the technical side.

Not saying your way is bad, just difficult! Some mistakes I have been guilty of with your approach are:

If you do not delegate work well then you as a coding-manager can become a bottle neck. Sometimes work as a manager is unpredictable and breaks the flow of the coding part. Your coding work has to be passed to someone else (wasteful, as they need to get up to speed on it, context switch, etc) or others have to wait for you to finish the interruption manager-stuff and carry on with your technical work.

A manager like that can be tempted to make snap decisions (which may later turn out to be wrong or costly). Whereas a "dumb" manager can genuinely use the excuse that they have to consult with the team before making a technical decision. Of course you can always say you need to consult with the team, but it is really tempting to speed things up by short-circuiting the process and making decisions right away.

Ha! And oh, how I did try to be like you.

And oh, how I did get railroaded into endless eons of meetings, where no coding shall occur.

And oh, how I did get overruled by the scrum master, the moment I tried to deviate from the script of this iteration's sprint. Engineering manager, though I was.

And oh, how planning and retros taught us no lessons at all. How they were just working lunches at a hoteled desk via Skype. No desk. No one to look in the eye. No credible threat in hand.

No large, faceless corporation will ever get another hour of my time. Not even the time it would take to destroy them. For they do it to themselves by driving people like me away.