[ytygg775]

For everybody working as a programmer, this should be blatently obvious. Who hasn't experienced a non-programmer manager without a clue telling them what to do? I'll never ever work again for a manager who couldn't do my job, at least in principle.

Ideally they stay in touch with the programmers by continuing to program, occasionally but regularly. To not have their knowledge frozen in time the day they became managers. And to keep feeding their flame.

It's a necessary qualification, but not a sufficient one. The manager also needs to be a people person. Lots of programmers are not, and that's ok, they can be excellent programmers. Just not managers.

In summary, a better title would have been "Turn the people persons among your best programmers into part-time managers".

[dagw]

this should be blatently obvious.

Maybe I've just been lucky, but in my 15ish years of working I've found the correlation between "good programmer" and "good manager" to be zero or possibly even negative. Most of the best managers I've had either never could've done my job or hadn't programmed since Lisp went out of fashion. However what they all did have in common was that they knew their limitations and always deferred to the relevant experts when faced with technical decisions that they didn't have insight into. You need a lot of skills to be a good manager, being able to make good technical decisions is one you can easily delegate.

[tanepiper]

I don't disagree from my experience over 20 years, but I also guess than now I am a manager/leader - I'd hope this isn't the case for everyone?

The biggest thing I've learned is empathy and communication is key - tech doesn't matter in the end, but you have to be able to spot and stop bullshit.

I'm leading people across two major projects at a worldwide retailer - one being a new project driven by my tech decisions and architecture - and I'm also responsible for the welfare and upskilling of the teams.

The sacrifice is not doing day-to-day coding or even code reviews, but taking on more strategic decisions, and working more at the architectural level and handling all the stuff like stakeholder management, getting BIAs and Architecture reviews done, etc. That way the team can focus on what they need to do and not worry about management bullshit.

[alanfranz]

> However what they all did have in common was that they knew their limitations and always deferred to the relevant experts when faced with technical decisions that they didn't have insight into. You need a lot of skills to be a good manager

Can I ask you (sincere question, I'm investigating the topic) what kind of value did your manager provide if he had zero ideas about how your job was done?

I mean: if he trusts you, and does what you ask, that's great. But I'd find very difficult to manage a team without understand their jobs. How can I help them in their job, and help them improve? What's my role?

[torben-friis]

>I mean: if he trusts you, and does what you ask, that's great. But I'd find very difficult to manage a team without understand their jobs. How can I help them in their job, and help them improve? What's my role?

For the managers I’ve had that work that way, the work is basically human shield.

Meetings with stakeholders, random corporate demands, bugs that people attempt to escalate more than they should because someone in the chain is particularly vocal… their job is to deal with that so programmers don’t have to.

Additionally, acting as coaches (improving team relations, solving friction between colleagues, etc) and acting as an artist’s representative for their programmers, playing the necessary work politics so that they get their raises and promotions.

[denton-scratch]

One of my earliest line managers was a programmer. I don't think he was a particularly good one, but he was a good manager. He was a good-enough programmer to understand my job, anyway.

What made him a good manager was that he removed obstacles for me. He made sure I had the equipment I needed; he dealt with bureaucracy problems; and he hooked me in to experts when I needed advice. He was great. we got on well, and I was his right-hand man.

Then he got promoted, moved to Head Office, left me behind, and I never spoke to him again. He was replaced by a dullard checkbox manager, and I moved on within a couple of months.

[Multicomp]

Not GP. But for me, even a non technical manager has a full plate of duties.

1. Shields up, Scotty. Random drive by requests, intracompany resource raiders, time sucks for random asks, even just garden variety legwork to clarify (in the GTD sense) next actions on a company project all serve to keep the flow of programming moving

2. If I and a dev on my team disagree and can't resolve if ourselves, we need a judge to present our cases to and have an executive decision made

3. Our team culture and API are implicit contracts that everyone is stuck with no matter what, but if the manager encodes known processes and standards for how we work and principles the team assumes, everyone both on and off the team can benefit from the reduced friction and frustration they encounter when trying to work with the team (or in the team) because they are no longer trying to row against the current or "hold it wrong"

4. Even if all the available work is well defined and well specified, there won't be enough resources to do all the work at once. Even if you trust the devs enough to know and pick the higher priority work, communicating that out to external parties and ensuring that everyone involved has proper expectations is an important task that devs are just not invited to the right manager status meetings for etc.

5. If you see a dev spinning their wheels or getting stuck in the process, take a note of what you observed and stash it away until the next 1x1 with them or potentially see if 2 or 3 similar situations come up, then bring up the observations and work with the dev to see id they can improve their processes or if the business function has flexibility too

[quintushoratius]

IME (I'm not the person you replied to) a good manager does a few things:

- understands the business requirements for the project(s) you're working on;

- helps coordinate the non-technical parts of projects, e.g. facilitator, finding overlaps, and (when they occasionally arise) dispute resolution;

- works on road blocks to getting your job done.

None of those require in-depth technical knowledge.

A good manager may have opinions about the minutiae of what you're doing, but keeps those opinions to herself. After all, the manager's purpose is to leverage their reporting ICs into getting more done, not doing the task herself.

[skeeter2020]

This is a good question, and I largely agree. I think the answer to your final question is in the preceeding two: a manager should be continually asking them (a) for the team and (b) for each individual on the team. Then next ask "what actions am I taking right now to test/implement these answers?".

A good manager doesn't need to know your job (that invites micromanagement) but they do need to known the "interface" for your role and be willing & able to learn aspects as they relate to growth and improvement. Managers work on a 2nd-order system that's an abstraction of the software you're building but with added complexity because it involves people. Depending on the balance it can look very similar or very different from the one developers navigate.

[voidsnax]

I think a big part of an engineering manager’s job is protecting their team’s focus, and advocating for their team to the rest of the organization. Programmers should be insulated by an engineering manager from the vicissitudes and stresses of corporate politics, and their work should be protected from management-level priority thrashing.

[usrusr]

"they knew their limitations"

That's the key here. And it's really a coin toss whether previous programming experience makes a manager more aware of limitations or completely oblivious. Perhaps most likely both at once, acutely aware of being disconnected from the state of the art (or even from the state of the art within the org, even if that's also far behind) yet completely underestimating the actual amount.

[mamcx]

> non-programmer manager without a clue telling them what to do?

That is not a problem. In fact, the single thing that make a manager a good one is that a good one let the skilled do their job, and communicate back-and-forth with the rest of the people in a good way.

That is all.

And because this, the fact he can't understand most of I say not matter: It just insist to me to explain it like anybody can, and let the details to me.

I have this people before (some with actual skills). Nothing get closer to just the people that can do let them do it and not care about details but just outcomes.

And BTW: I work for "boring (but never actually!)" CRUD apps, and customers that are not only clueless about software: One of the biggest one was a guy with near zero formal education, coming from the street, that have invented his own things that is a bastardize attempt at accounting/financed with the most obtuse jargon you can imagine.

And the manager make it work well...

[lawn]

> Who hasn't experienced a non-programmer manager without a clue telling them what to do? I'll never ever work again for a manager who couldn't do my job, at least in principle.

Even if the manager could do your job, it's a bad manager if they always tell you what to do.

A good manager should be helpful and assist you, not command you. And that's possible even if they're not a programmer.

[goodoldneon]

> a necessary qualification, but not a sufficient one

I like that phrase

[pickledish]

For you and anyone else who might be curious, it has its roots in formal math / logic! This page has a good rundown:

https://en.m.wikipedia.org/wiki/Necessity_and_sufficiency#Si...

[P5fRxh5kUvp2th]

The single best manager I've ever had was completely non-technical. Some of the worst I've had were very technical.

The difference between them is who treats me with trust and who doesn't, the technical/non-technical divide doesn't matter.

[watwut]

Absolutely worst managers I had have zero technical background. They both treated people badly and also were incompetent and did not understood our work. Which led to absurd processes, being simultaneously under pressure and having nothing to do, social issues in teams and so on.

The worst thing about outside managers is that they generally don't understand teamwork and peer cooperation. They are too used to relationships based on hierarchy, negotiation and competition. And they don't have experience of actually cooperating with same level peers.

[andirk]

I worked at a company that almost only hired [nationality omitted] engineers. Seemed their goal was to become one of the managers so they could rule the others with an iron fist, much like they had been ruled for years. The very bad code proved that the engineering part of the job was mostly nominal. As a defensive measure, they knew to never hire good engineers. I was hired by one of the directors.

So in that case, the managers _were_ kind of technical but it would have been better if they weren't.

[prmph]

Were they a great manager simply because they let you do what you wanted, without any deeper guidance or feedback?

On a basic level, yes a manager needs to have reasonable trust in his team members and be able to interact with them well. On a deeper level, however, a manager who lacks any clue about the work being done will either frustrate the team or leave them to their own devices altogether. The former is bad under any circumstances; the latter is bad unless the management provided is supposed to be at a very general level.

[skeeter2020]

One of my scrum teams is all very senior developers working in a new area with lots of unknowns and technical challenges. I purposely "leave them alone" not because I'm a clueless manager, but because this type of work is always messy and will have false starts. The phrase "reasonable trust" screams "FAKE!" to me. You trust until it's broken, or you don't trust. I think what you might mean is trust but verify?

[prmph]

You're conflating "guidance" with lack of trust; the two things are entirely separate, and I'm not sure why they are being confused.

I'm leading a small (4 person) team working on a large multi-year greenfield project, and I sometimes schedule the entire team to meet with the client, who is a domain expert, so that we can hash out some fine decisions that he has unique insight into. My insights, as someone who bridges the technical and domain sides are also key to the success of these meetings.

Would you say I don't "trust" the team by not allowing them to work in a silo?

[P5fRxh5kUvp2th]

> Would you say I don't "trust" the team by not allowing them to work in a silo?

Yes, this means you don't trust them.

As I've already said, I've been doing this for roughly 25 years now. I can tell the difference between a technical decision and a business decision.

Even the wording ... "by not allowing them" implies both that you don't trust them and you don't have enough respect for the authority you wield to avoid using it cavalierly. I mean "by not allowing them to kick kittens". Sure, if they're about to start kicking kittens, #savethekittens. Otherwise, let them work.

Because here's the thing. Shitty managers don't know they're shitty, if they did, they would stop being shitty because recognition is the first step to becoming a non-shitty manager.

Because it's one thing to tell me all of the developers are inexperienced and don't have these skills so you don't trust them. It's another to claim you DO trust them and treat them as if they're inexperienced developers.

[prmph]

I'm not sure if you are capable of understanding the point I'm making, but I'm going to try again (hopefully for the last time):

Please read this sentence again in my comment above: > I sometimes schedule the entire team to meet with the client, who is a domain expert, so that we can hash out some fine decisions that he has unique insight into.

Without getting into specifics, the team simply does not have all the domain knowledge they need to successfully complete the project. I believe you understand what domain knowledge means. It does not mean I think the team is incompetent. No, but the client has some specific domain knowledge (not exactly related to software engineering) that should be incorporated into the project.

Now, according to the team structure, I bridge the gap between the client's domain knowledge and the team's core skills. And this is what shows that I trust the team: I schedule meetings where we all meet with the client, not just me, so that we can figure out some of the decisions together.

If my use of the word "allowing" is what is throwing you off, then let me phrase it this way: how do you expect the team to deliver a successful project by working without interacting with me and the client to acquire the domain knowledge that is needed? If you want the client and I to leave the team alone, how do you expect the team to even know what the client actually wants? The project is a large project; we are refining the specs as we go along. These are not rhetorical questions. I await your answers.

[P5fRxh5kUvp2th]

> Were they a great manager simply because they let you do what you wanted, without any deeper guidance or feedback?

Why do I get the feeling you're a technical manager trying to rationalize why you don't trust your developers?

The entirety of your second paragraph speaks to a belief that developers can't manage themselves. That without a manager, no work would get done and no software written.

But having been in this game for roughly 25 years now, I promise you I know how to get software written successfully. What I need is the manager to __believe and trust__ me when I tell them something. There's a vast difference between a negotiation to figure out what can be done in the next 2 weeks and arguing with a fuckwit who thinks they know better than you despite moving into management after 2-3 years of software development.

[spdionis]

Most managers I've known would love to have someone to "believe and trust" to delegate stuff to.

I feel like the micromanaging managers simply don't have enough work to do? I personally celebrate everytime I find a developer who can manage themselves, their work, and if they can also manage the team (at least partly) that's amazing!

[musingsole]

Desiring a coworker you can trust and trusting the coworker you have are too very different things.

I'd love to be a good person, but these pies aren't going to steal themselves.

[prmph]

> Why do I get the feeling you're a technical manager trying to rationalize why you don't trust your developers?

Because you're not reading my comment carefully, and ignoring the caveats I've put in my comment (it's a problem I've noticed with communication in general; people respond as if I don't mean them).

This is what I said: > On a basic level, yes a manager needs to have reasonable trust in his team members and be able to interact with them well.

So I do agree that trust is important. Feedback and guidance is not about lack of trust, and I'm not sure why you're confusing the two.

For what it's worth, I prefer a manager who is engaged with what I'm doing, not micro-managing me, but helping me to align my efforts with the overall picture.

[P5fRxh5kUvp2th]

> and I'm not sure why you're confusing the two.

pegged you correctly.

[kevin_nisbet]

My experience has been similar, I think it depends way more on the individual than whether they are technical or non-technical. I do suspect those with non-technical backgrounds are at a disadvantage though.

When I started my career I had a manager who couldn't even type, but just approached his role as I want to keep an eye on what's going on, and when I see friction or blockers I'll jump in and start working on removing those blockers.

I've seen a technical manager get promoted, from IC to VP of engineering within just a couple of years, and treat the VP role as his job is to tell everyone in his employ what to do, no feedback allowed (didn't treat those in his employ with trust as you put it). I don't know that I've ever seen a worse leader and had a litany of problems with them, and ended up deciding to leave within weeks of this person taking over. I don't even know if it's this persons fault, as the org didn't like hiring leaders externally, so basically the entire engineering org was just ICs with basically no leadership experience.

[P5fRxh5kUvp2th]

> I think it depends way more on the individual than whether they are technical or non-technical.

yep, exactly.

I think your anecdote about the engineer turned VP is fairly typical. imo it's generally more difficult for engineers to become _good_ leaders because it means moving from an environment where you have complete control to one where you don't and a lot of engineers can't bridge that divide successfully and become terrors like you described.

non-technical managers never had that control. They have their own challenges, but generally speaking, it's easier for them in terms of control.

in my opinion, of course.

[ido]

I often repeat how one of the best managers I had (he was the CEO of the company but it was a 5 person - including me - startup, so he was practically the closest thing to a manager) was a former restaurateur who never worked in software before!

[magicalhippo]

My manager has no technical background either, and for our team he's great. However, I think they key is he understands enough technical stuff and listens to reason. If we present good technical arguments, he will listen and take that into account. He won't try to force something through just because.

[ido]

Yep, he deferred to the programmers for technical decisions.

[P5fRxh5kUvp2th]

and that's a large part of what I meant by trust.

Even something as simple as believing when a developer says 3 weeks for something.

[prmph]

A technical manager might in most cases defer to the judgement of the developer. However, provided he knows his stuff, he can also mentor the developer to grow.

If you are arguing that managers with technical knowledge of the work being done are wholly unnecessary, then you are necessarily arguing that all teams are doing optimal work all the time, and have nothing to gain from external feedback.

I call bull on that. There are several times where, after discussing some estimates with my developers, it turns out that the overall approach was inefficient. By pointing them in the direction of a more efficient approach to the problem, and leaving them to work out the details, and making them feel free to discuss other alternatives, we have been able to get stuff done in reasonable time.

Your whole point of view seems to suggest some kind of conflict between technical managers and developer teams, where I see none necessarily. Managers are a resource for the team, not people who lord it over their teams.

I have been contracting and consulting for years. Without exception, the worst managers I've had in terms of demanding the impossible, and failing to appreciate the work I have put, were those without any clue what it takes to do what I did. The technical managers would work with me to write specs that made my work a breeze.

[skeeter2020]

Managers can optimize for people or process but rarely do both really well; I'm not surprised a restaurateur is the exception. Their entire life is essentially keeping a highly dynamic, human-centric, likely broken system running while minimizing work in progress and focused on delivery.

[cma]

> The difference between them is who treats me with trust and who doesn't, the technical/non-technical divide doesn't matter.

When something technical goes badly wrong, and there are two competing stories on who to blame, how do they decide?

[ptero]

If something technical goes badly wrong there should be a post-mortem concluding with enough clariry so that it is clear to everyone what the cause was.

[marshmallowmad]

How does a non technical manager know who is doing bad or good work? I wouldn’t want to work on a team where the person in charge of my compensation can’t understand if I’m doing decent vs. great work. Leads to the best folks getting frustrated and leaving over time. Mediocrity is all that will remain if manager’s can’t understand the work their team is doing and the obstacles they face.

[P5fRxh5kUvp2th]

Is it your supposition that managers should be doing things like code reviews to ensure quality?

If they're not working at that level, why isn't the output enough? Developer X's solutions are solid, developer Y's solutions tend to need bug fixes for the next 2 months, who is performing better? Why can't a non-technical manager do that too?

[prmph]

> why isn't the output enough? Developer X's solutions are solid, developer Y's solutions tend to need bug fixes for the next 2 months, who is performing better? Why can't a non-technical manager do that too?

How would a non-technical manager know that? By examining the git commit history? Or having the team tell on each other?

And if developer Y's work tends to need bug fixes, it might be that he usually works on a more difficult class of issues. How is the non-technical manager going to understand that?

[P5fRxh5kUvp2th]

After seeing this post my opinion has finally clicked over to "you're a shitty manager".

You're imagining a managers job is to ensure quality. That's a tech leads job. And QA, if you have them.

You're imagining yourself as Gandolf with the staff of perfection screaming "You shall not pass".

That is not your role, nor has it ever BEEN your role.

What's worse is that you're implying that you cannot manage teams working with tech you yourself have not worked with. This means you cannot manage projects that are in rust, lisp, perl, ruby, python, GCP, or any other technology that you yourself are not both familiar with and an expert in. When your company decides to move to the cloud and they choose GCP but AWS is the only thing you've seen, do you recuse yourself?

And when you hire a developer with 5+ years experience in GCP, HOW DO YOU MAINTAIN QUALITY?

The answer is you do it the same way the non-technical manager does it.

What you're not understanding is that your developers are BETTER THAN YOU at their job.

Just yesterday we had an interview with a senior manager who is being hired to take over the three teams I mentioned in another post that I regularly work with, 3 teams that have 20+ year developers on them. I gave him a thumbs down based solely on the fact that when he has someone who isn't performing up to expectations, he starts reviewing code. I do not want that for these teams, or the senior developers on them. Furthermore, I know if we hire someone like that, they will leave. I know they will because _I_ would leave. Furthermore, this department is in a bit of a political fight with another technical department. Them leaving means this department automatically loses that fight.

The problem with shitty managers is that it can often be very difficult to fully quantify their effects on the organization because any single instance of it can be very subtle.

The question is, how do you quantify a managers output?

And the answer is you do it the same way a non-technical manager does.

You don't need to be able to read code to know your Toyota should not force accelerate on its own.

[prmph]

I think you’re having a pretty narrow understanding of the word “manager”. All your argument ms boils down to an inability to perceive that I’m using the word manager in a general sense, as someone who manages technical developments. I’m not referring to a political manager.

Indeed if the only value added by a manger is to play politics, then I’m not sure whether the word manager should even apply to such a person.

How a good day, and best wishes with your “management” style.