Should managers still code?
161–170 of 319 posts
Re: Should managers still code?
#162Directors manage multiple supervisors and own a complete function. They are like colonels. They don’t code as their job is aligning with senior management and across teams/divisions/organizations. It’s political.
Larger companies subdivide this more.
Re: Should managers still code?
#163I know most people will say yes but many will argue they don't need to actually do it to have that knowledge. But my experience is that with software and IT, things just move too fast for that. Managers need to continuously stay active at some level to keep up to date enough to make reasonable decisions from a management perspective. Of course it always depends what you mean by "manager", if you just want someone to approve leave, check on project status and organise birthdays, farewells and christmas celebrations .... well yeah you are wasting someone who can code on that.
Re: Should managers still code?
#164I've seen plenty of managers who increased team output 10% for a few months by coding and completely lost the thread in the meantime. That's how your entire team gets laid off. Leadership doesn't care how much code your team writes, they care that you're working on the right stuff. An engineering manager's job is: take long-term ownership for the performance of the team. That might include aligning with leadership, m…
You're characterising it as pure "code volume" question but it's completely not the point. Absolutely if they are coding just to directly increase the output of the team they are much better devoting that time to getting more output from the IC's they are managing.
But even better is coding in a way that helps the team overall work better. This can be because they do architectural work, they gain insight into the actual team challenges, it improves how they can estimate the time needed for different tasks, etc.
Re: Should managers still code?
#165I cant work for someone who doesn't understand what I do. An unused sword rusts in its sheathe. I remember working for a gent years ago, who was stressed out that my output was so low. He declared "I started this business in my living room let me show you I can do any job in this building" He came to my workspace, where I had 20 servers stacked on my workbench. He looked at them. Attached a single power cord. And the…
> He came to my workspace, where I had 20 servers stacked on my workbench. He looked at them. Attached a single power cord. And then wandered off telling me he could definitely do the work if he wanted to.
Frankly, all this anecdote tells me is "don't behave like a condescending asshole". If he'd said the same thing but then managed to do some non-trivial aspect of your job for a few minutes, I think that would still have been a bad tactic. It's just as possible to have humility about skills you lack, and to lack humility about skills you've maintained.
Re: Should managers still code?
#166Over the course of about two years this drove me to mental issues. I was unhappy, I could not have a technical discussion with people working for me, I felt inadequate and dumb. On a practical level, I was expected to make technical decisions, but couldn't, because all I had was poorly communicated information from people working for me. That is not enough!
I realized two things:
1. It is not possible to do technical management without coding yourself. CTOs that don't code are not good CTOs.
2. I never want to be in a work situation where I am away from coding.
Since then I've been very happy, first co-founding a business where I had a CTO role (and coded), and then solo-founding and running a business where I code all the time.
Re: Should managers still code?
#167I've seen plenty of managers who increased team output 10% for a few months by coding and completely lost the thread in the meantime. That's how your entire team gets laid off. Leadership doesn't care how much code your team writes, they care that you're working on the right stuff. An engineering manager's job is: take long-term ownership for the performance of the team. That might include aligning with leadership, m…
> your bottleneck really is just writing more code You're characterising it as pure "code volume" question but it's completely not the point. Absolutely if they are coding just to directly increase the output of the team they are much better devoting that time to getting more output from the IC's they are managing. But even better is coding in a way that helps the team overall work better . This can be because they d…
I think of it as the management control loop: "I have some spare cycles -> what is the most important work I can do for the team right now?" Coding can be the answer. But some people's control loop seems to be more like: "I have some spare cycles -> what is the most interesting/rewarding task I can do next?" The latter might lead to a lot more coding, but it's not good for the team.
Re: Should managers still code?
#168Earlier quoted context omitted.
> An engineering manager's job is: take long-term ownership for the performance of the team This is a rather naive, mid-level management-style take. The real EM job is to represent the team to the company, to be aligned with company priorities, and to be a backstop for the team. In other words, being the leader - the face, the prioritize, and the helper of the team. Performance-style nonsense is what is used in wareh…
I'm not quite sure where you're getting "performance = maximizing units of output" from my post, as the whole point was the difference between squeezing out a little more code vs. keeping the team on track doing actually valuable stuff. Either way, I think we mostly agree here: the EM is the face of the team who makes sure the team, as a unit, is doing valuable work as a sustainable pace that's understood as such int…
Yes, and no one said that this kind of evaluation has produced long term success. It has widely been recognized that when upper management is more involved in evaluation rather than leading teams of managers themselves, they address issues and market conditions too late. Thus, affecting businesses negatively over and over.
https://hbr.org/2016/10/the-performance-management-revolutio...
In other words, managers are being asked to NOT perform to certain metrics/evals but to make choices that benefit the company - even if it falls outside any evaluation rubric.
Re: Should managers still code?
#169I cant work for someone who doesn't understand what I do. An unused sword rusts in its sheathe. I remember working for a gent years ago, who was stressed out that my output was so low. He declared "I started this business in my living room let me show you I can do any job in this building" He came to my workspace, where I had 20 servers stacked on my workbench. He looked at them. Attached a single power cord. And the…
> I remember working for a gent years ago, who was stressed out that my output was so low. He declared "I started this business in my living room let me show you I can do any job in this building" > He came to my workspace, where I had 20 servers stacked on my workbench. He looked at them. Attached a single power cord. And then wandered off telling me he could definitely do the work if he wanted to. Frankly, all this…
The server stacks were well above his height.
He probably could have, in his day, wired up 20 odd desktops, got them going, and maybe shave 10 minutes off my batch time.
But he really had nfi with the servers, the stacks were 2ft higher than him already, they all had dual power supplies, lots of idrac ports. He absolutely would have shamed himself if he kept going. And the reason he hired me was the ability to reason and read vendor documentation.
They also take ages to boot compared to a desktop.
So yes I think ALSO dont behave like a condescending asshole, but if he understood what I was doing he wouldnt have needed to leave his office and make a fool of himself anyway.
Re: Should managers still code?
#170Strong yes for 3 reasons 1. Reducing dev friction. When I had managers who coded they were ruthless about removing friction in the dev and deployment pipeline because they had to deal with it too. If build times went up, deployment infrastructure broke or someone’s PR broke dev they would roll it back immediately. If someone consistently blocks PRs the manager noticed the trend and would address it. 2. You get a much…
For me a good manager is a facilitator, not a leader. Someone who removes obstacles for us. Whether they themselves are affected or not. Someone only fixing an issue because they have to deal with it too seems like a pretty bad manager to me.
They're not for pushing targets or trying to weed out non-performance, I don't work at a playschool. My manager is there to make sure I can do my job and that I can reach my maximum potential (including making sure I'm in the right job)