3 ms·

I have a really hard time working for someone who isn't technical, regardless of their role. I also have a hard time buying into the narrative that someone can

by chpmrc 4y ago

I have a really hard time working for someone who isn't technical, regardless of their role. I also have a hard time buying into the narrative that someone can be just a good manager. As an engineer and a manager I took my time to understand the basics of management, design, marketing, business development etc. to have educated conversations while building a product so I don't see why someone in those roles shouldn't do the same. I would also feel the need to catch up with whoever the best engineer seems to be on my team because I'd just assume they wouldn't respect me if they perceived me to be vastly less competent (a degree of technical incompetence can be offset by good soft skills of course). Either there's a misconception about how complex "technical" stuff is, that prevents those (smart) people from touching it with a 10 foot pole, or (conventionally) technical stuff is indeed more complex than (conventionally) non technical stuff. I lean more towards the latter (after all market demand and compensation are a good indicator of that) but I'd be very happy to be shown that's not the case. I know plenty of engineers that are successful "solopreneurs", I don't know anyone who isn't technical and managed to do the same without a technical cofounder. Not claiming "engineering is easier than marketing", just that, on average, technical people can do 80% of what's required to build and launch a product, non technical people can do around 20% (although the ratio might change once these no code tools become more popular / powerful).

muglug 4y ago
> I have a really hard time working for someone who isn't technical, regardless of their role. In both cases — technical manager and non-technical manager — the engineering culture at the organisation ultimately determines whether the arrangement is successful. In the past I’ve experienced friction working for a manager who had different ideas about how particular technical problems should be addressed.
IntFee588 4y ago
If you're someone who has pride in their work, you should want to learn. Technical curiosity is invaluable in this field and it seems odd that there are people who insist on sticking around despite lacking it. I don't think a lack of technical curiosity/professional pride is exclusive to managerial types, but there is a surprising number of people who hate the technical side but still want to be bossman.
Beached 4y ago
i worked for a non technical manager, and it was ok. because he trusted his employees. he said this is the deliverable, and these are the constraints, what do you need, who do you need, and how much do you need. we told him, and he went to fucking bat. obviously he picked up a little here and there, but by no means could do the job of a junior. it worked well, he shielded us from the corporate politics, got us everything we needed, didn't over commit us, and we delivered on estimated dates and to scope almost every time. because we picked times and materials and he made sure it happened and that we could focus. was good times
- somishere 4y ago
  Totally agree there's no hard and fast rules here. That said, this person probably lucked out with a dependable team, and no doubt relied on intra-leadership (from yourself or peers I would assume!) to manage - and deliver - effectively. This kind of dependability doesn't usually appear out of thin air. It's also a bit of a catch 22 to replicate. I've worked with similar people and there is definitely a place for them (tho probably not at the peak of the structure). But it's also nice to have someone that can critically discuss a solution and sign off on decisions that they fully understand. IMO.
kelnos 4y ago
> I have a really hard time working for someone who isn't technical, regardless of their role. I also have a hard time buying into the narrative that someone can be just a good manager. I agree, but in my case I think there's also a "narrow band" for what I'd consider a technical manager to be. I want them to be able to understand if, at times, I need to get into the weeds describing a technical problem. I wouldn't do this often; I don't think it's necessary or useful to burden a manager with deep technical details most of the time. But I want it to be possible to do that when necessary, without seeing the manager's eyes glaze over. But at the same time, I also want a manager who is primarily focused on the "people" aspects of management. Engineering managers should not be coding, or even doing code reviews. Part of it is because I don't believe managers should be in so deep on the technical details, because to do so means taking too much valuable time from people management duties. But the other bit is that I don't like the power dynamic. I don't want a manager to force -- or even have the unconscious appearance of forcing -- a report to change some code in a code review because they have the added "I'm the guy who decides if you still have a job" power. And in the reverse interaction, if the manager is writing code, I don't want their reports to have to walk any kind of "don't piss off the boss" tightrope when providing code review feedback. The power dynamic bit is a reason why I also think that a team's technical lead (for orgs that have tech leads) shouldn't report to the team's manager, but should report up a level. I think it's valuable if the technical lead feels like they can argue against the team's manager's opinions without being afraid of (even unconscious) retaliation. So I think it's hard. Another top-poster here (the CTO of Surescripts) seems to have it right: when he's at work, he focuses on people and the business, with the technology an important part of the job that he doesn't dive too deeply into (but can still hold his own in technical discussions). And he keeps his technical/engineer side happy through deeply technical side projects on his own time. I think that can be really hard to do, especially for an former developer who is new at the manager job. (Not to mention having deeply technical hobbies and side projects takes up a lot of spare time, spare time that many people may not have.) But I think it's essential for having a healthy team with reports who respect their manager, and understand that the manager respects their technical expertise, and doesn't try to dictate technical decisions.

by chpmrc 4y ago

muglug 4y ago

> I have a really hard time working for someone who isn't technical, regardless of their role. In both cases — technical manager and non-technical manager — the engineering culture at the organisation ultimately determines whether the arrangement is successful. In the past I’ve experienced friction working for a manager who had different ideas about how particular technical problems should be addressed.

IntFee588 4y ago

If you're someone who has pride in their work, you should want to learn. Technical curiosity is invaluable in this field and it seems odd that there are people who insist on sticking around despite lacking it. I don't think a lack of technical curiosity/professional pride is exclusive to managerial types, but there is a surprising number of people who hate the technical side but still want to be bossman.

Beached 4y ago

i worked for a non technical manager, and it was ok. because he trusted his employees. he said this is the deliverable, and these are the constraints, what do you need, who do you need, and how much do you need. we told him, and he went to fucking bat. obviously he picked up a little here and there, but by no means could do the job of a junior. it worked well, he shielded us from the corporate politics, got us everything we needed, didn't over commit us, and we delivered on estimated dates and to scope almost every time. because we picked times and materials and he made sure it happened and that we could focus. was good times

somishere 4y ago
Totally agree there's no hard and fast rules here. That said, this person probably lucked out with a dependable team, and no doubt relied on intra-leadership (from yourself or peers I would assume!) to manage - and deliver - effectively. This kind of dependability doesn't usually appear out of thin air. It's also a bit of a catch 22 to replicate. I've worked with similar people and there is definitely a place for them (tho probably not at the peak of the structure). But it's also nice to have someone that can critically discuss a solution and sign off on decisions that they fully understand. IMO.

kelnos 4y ago

> I have a really hard time working for someone who isn't technical, regardless of their role. I also have a hard time buying into the narrative that someone can be just a good manager. I agree, but in my case I think there's also a "narrow band" for what I'd consider a technical manager to be. I want them to be able to understand if, at times, I need to get into the weeds describing a technical problem. I wouldn't do this often; I don't think it's necessary or useful to burden a manager with deep technical details most of the time. But I want it to be possible to do that when necessary, without seeing the manager's eyes glaze over. But at the same time, I also want a manager who is primarily focused on the "people" aspects of management. Engineering managers should not be coding, or even doing code reviews. Part of it is because I don't believe managers should be in so deep on the technical details, because to do so means taking too much valuable time from people management duties. But the other bit is that I don't like the power dynamic. I don't want a manager to force -- or even have the unconscious appearance of forcing -- a report to change some code in a code review because they have the added "I'm the guy who decides if you still have a job" power. And in the reverse interaction, if the manager is writing code, I don't want their reports to have to walk any kind of "don't piss off the boss" tightrope when providing code review feedback. The power dynamic bit is a reason why I also think that a team's technical lead (for orgs that have tech leads) shouldn't report to the team's manager, but should report up a level. I think it's valuable if the technical lead feels like they can argue against the team's manager's opinions without being afraid of (even unconscious) retaliation. So I think it's hard. Another top-poster here (the CTO of Surescripts) seems to have it right: when he's at work, he focuses on people and the business, with the technology an important part of the job that he doesn't dive too deeply into (but can still hold his own in technical discussions). And he keeps his technical/engineer side happy through deeply technical side projects on his own time. I think that can be really hard to do, especially for an former developer who is new at the manager job. (Not to mention having deeply technical hobbies and side projects takes up a lot of spare time, spare time that many people may not have.) But I think it's essential for having a healthy team with reports who respect their manager, and understand that the manager respects their technical expertise, and doesn't try to dictate technical decisions.