8 ms·
The best managers I have had were ones who had previously worked as developers. While the most clueless ones had zero programming background. I tend to encount
by eljimmy 5y ago
The best managers I have had were ones who had previously worked as developers. While the most clueless ones had zero programming background.
I tend to encounter the latter in smaller companies that have revenue pipelines outside of tech and aren't entirely tech-oriented.
- Trasmatta 5y agoA trend I see in tech is product managers who have zero technical experience or knowledge. I find this somewhat odd, and difficult to deal with as a team member. While it doesn't need to be their core competency, I feel like some background knowledge in the tech should almost be a necessity if you want to be leading development.
- deleted 5y ago[deleted]
- dpeck 5y agoProduct managers aren’t (or at least aren’t supposed to be) developer managers and is not what is being discussed in the article.
- deleted 5y ago[deleted]
- ricardobeat 5y agoDepends entirely on the company, the titles and roles are frequently mixed up.
- dpeck 5y agoReally? I’ve often seen HR not really understanding it, but engineering leadership ceding the people management aspects of the job to a PM is next level neglect.
- cmiles74 5y agoI think the line is little more muddled and mushier than that. Where I work, the product manager runs the stand-ups and is responsible for writing and prioritizing stories as well as grooming the backlog. They seem a lot like the project manager to me. :-P
- dpeck 5y agoThe writing and prioritizing stories and backlog grooming is exactly what a PM should be doing. Leading the standups seems to happen often but I see it as an anti pattern. But talking about how the team builds systems, who’s doing the building, and things like that should never be within the domain of a PM.
- oytis 5y agoCan't agree more. Product manager, product designer/architect, engineering manager and a team lead are distinct roles with totally different competences required. Companies that don't understand that are rarely good places to work.
- fidesomnes 5y agoThis is borderline sexism, report to HR immediately!
- dmitriid 5y agoThe best PM I had came from Customer Support, where he learned some scripting to automate tasks. So he wasn't really a developer, but understood the technical side of things. And he was really good at prioritising stuff.
- ratww 5y agoPeople able to empathize with Customer Support or with Customers are always good at prioritising, IMO. You end up doing more bug-fixing and less architecture astronautics.
- Waterluvian 5y agoMostly true. Except that time I had an engineering manager who previously did embedded dev in the 90s and obsessed over all the wrong things for a bunch of Python and javascript projects.
- dmd 5y agoBeen there. I had a manager who would obsess for weeks about trimming a byte or two here or there in the metadata of a multi-gigabyte file.
- dr-detroit 5y agoThis line of thinking is demonstrably weak and yet I encounter it in 99% of pseudodevelopers I work with.
- Alex3917 5y ago> I tend to encounter the latter in smaller companies that have revenue pipelines outside of tech and aren't entirely tech-oriented. These are often the best companies to work for though, because the tech teams are outside of the normal management structures and can do whatever.
- wil421 5y agoMy current manager was a dev for an old ASP stack. He may not be up to date on the newest stacks but is miles better than non tech/IT managers. When he needs to get out of the way he does and isn’t a micromanager. He also knows databases really well which helps out the team. Our former VP was a securities trader turned IT manager, who knows how he probably knew people, and was terrible.
- lmilcin 5y ago> The best managers I have had were ones who had previously worked as developers. That is not my observation. Having some ability to program can definitely be a plus, but it is also frequently a hindrance, if the manager is not aware of the dangers. Best managers I had were just good at managing. They did not try to make technical decisions but instead tried to figure out a process to work with a collection of various experts that would let these experts to make best use of their expertise in context of the project. In other words, they were focused on making right conditions for people, team, project to succeed rather than focusing on making technical decisions. They tried to complement the team with their management expertise rather than trying to be lead developer. Ability to program (as in developer who has just been promoted to management role) is frequently a hindrance. It is a crutch that the new manager uses which prevents him from learning his new trade well. It lets him understand stuff without needing to communicate with the team, it lets him see through bullshit without having to build rapport and honest relationship and it lets him make passable decisions without consent from the rest of the team. Which works fine for a while but in the end tends to result in mediocre manager and team. Also a programmer manager frequently only ever learns to work with other programmers. This might be fine for strictly development team but leaves the manager out of the water when interacting with non-development teams, clients, etc.
- silicon2401 5y agoI've also had a bad experience with a programmer turned manager. He micromanaged to a frustrating degree, almost checking things in as much detail himself as if he was the actual engineer working on the task. Additionally, he had a very hard time adapting his working and communication styles, and instead asked for a lot of things to be done his way or recommended his way instead of understanding and trying to help me with the things I was struggling with, which I always found backwards. My previous manager never even coded, while the manager before that was also still actively developing, and both had a much more personable yet effective style. Everybody has their pros and cons, but I just wanted to agree that being a programmer manager isn't necessarily good or bad.
- lmilcin 5y ago
- Frost1x 5y ago>I tend to encounter the latter in smaller companies that have revenue pipelines outside of tech and aren't entirely tech-oriented. These orgs also tend to treat all tech as cost centers (perhaps, correctly in their context of business). The more non-technical the manager, the more likely tech is a cost center and necessary evil, usually resulting in toxic development cultures.
- dragonwriter 5y ago> The best managers I have had were ones who had previously worked as developers. I’ve had a few managers that did that, one of whom was very close to the absolutely worst manager I’ve had in any job. Understanding the work is a useful thing for a manager, and having done it is one way to get there. Understanding people is more important, and working as a developer is not much of a way to get there.
- Trasmatta 5y agoTechnical experience is naturally not going to turn a bad manager into a good one, but a good manager will always be better if they have technical experience as well
- skeeter2020 5y agoIF they can resist the urge to jump in the pool with the developers, IF!
- pc86 5y agoIf there's enough work to actually justify a manager, they shouldn't have enough time to do much of anything. Maybe a bug or two that would otherwise go to a junior/weak mid.
- eropple 5y agoI've found this to be a function of the team and the culture to too much of a degree to make a sweeping statement like that. If your team is one you can trust, and your managerial responsibilities align more with what I tend to call a "producer", you can be surprisingly personally productive. But it requires a team that requires guidance rather than motivation and a company that doesn't impose structure from above, and those are admittedly pretty rare. In some management roles I've had too many reports or too many reports who expected hands-on management and yeah, it becomes a full-time, full-time thing. In others--and, to no surprise, my preferred situation--it's much more of a "first among equals" situation where, yeah, a good chunk of my time is spent in meetings (clustered early in the week when I could) to firewall off my team, but it'd be rare to not be able to carve off a full day or two afternoons for deeper work, whether it's code or architecture or analysis. And in those roles it was usually necessary to write a good bit of code, because I'd been an IC before a manager and had done most of the work--and one of the artifacts of doing more work on it, then, was documentation and making it accessible for the next person.
- irrational 5y agoI had a manager for the better part of a decade who was non technical (this was a Fortune 500 company). He was awesome. Anything we said we needed, he would get to us. Any technical decisions he 100% left up to us and trusted we knew what we were talking about. He mainly left us alone and spent his time trying to get us more money and running blocking to keep us from being disturbed. My current manager has a technical background. I now spend the vast majority of my work week in meetings. Not because my job has changed, but because they have so many meetings that we never had under my previous manager. Scrum, backlog, retrospective, one on ones, touch bases, etc. I seriously maybe have 5 hours a week to actually program these days. If we want anything, he is likely to say no and that we can get along with what we already have. He often has opinions on how we should do things based on how he did things years ago instead of modern best practices. Give me a non-technical manager any day.
- sdoering 5y agoI learned long ago, that it really depends on the manager's personality and his/her understanding of the role. But also on the expectations being transported down from above. The problem is, imagine a company with your second managers mindset and his/her boss takes a look into the calendar, sees there are no management meeting tasks (Jour Fix, standup, and so on) in there. His/her boss would think he/she is not doing anything, because the signifiers that declare a manager actually managing are missing. I don't see these signifiers as actually managing - I see them as creating disturbance - but modern management culture seems to be seeing these signifiers as sign of real managerial work. I also find a lot of managers need to please their own ego by feeling they do something. They often need to feel important - hence too many meetings as signs of them having control.
- irrational 5y agoI’ve come to the same conclusion. So many of these meetings seem to exist merely to give him the appearance of doing something and therefore justifying his job and salary.
- skeeter2020 5y agoIt doesn't really matter which perspective a manager comes from people or technical-oriented, their job is shield you from disruptions and remove roadblocks. Some of these are going to fit certain skillsets better but I think it's a mistake to define one or the other as universally "better".
- NikolaNovak 5y agoLooking over the comments here I feel there's a lack of common definition and thus expectation. I've always personally found it useful to make a distinction between team lead and manager. The way I define them is team lead is the or among the most senior and experienced team members. They still do some hands on work, the high value stuff, and they support, coach train the team on technical stuff, do high level design and ensure it all adds up to coherent working quality something. Manager understands people, client, goals, process, company - how to support their team, how to protect the team, and how to get shit done - and crucially, how to get the right shit done based on company's and user's priorities. I find its crucial to distinguish the roles and expectations. One of the best managers I ever had I did not respect at the time - I judged them as a team lead and their tech knowledge was limited...but when they left - team fell apart, and shit I didn't know existed started hitting us and we got torn seven different ways.
- skeeter2020 5y agoThis is true and obvious, but before I became an EM I had great managers who were either technology or people-focused. Both can be good IF they recognize their skills & gaps, and mitigate accordingly.
- cmiles74 5y agoHaving worked with a lot of managers, it can cut both ways. Perhaps it's the lessons these managers learned (or chose to learn) when they were more directly involved in the development process that really matters. The people who came away from the experience with something like "the pace of change is rapid, keeping up is difficult, and some core problems may never be solved" seems to be much easier to work with than someone how chose to learn random facts like "caches are bad" or "caches are good" or "Oracle is the only real database server" or "Java is the only proper language."
- Cthulhu_ 5y agoI think it's hit and miss. Yes developers will know the field, but they may lack the interpersonal and management skills needed, and they may not have the right personality; as a manager, you need to let go of technology, and you have to be able to deal with people all day long, sometimes with overtime as well. I mean not to generalize, but a lot of developers are neurodiverse introverts, the flavor that doesn't go well with typical management skills. I mean managers and sales and the like also have their own flavors of neurodiversity - to generalize, it's things like psychopathy (or the ability to suspend their own moral compass) and high extroversion.
- deleted 5y ago[deleted]
- corpMaverick 5y agoTo be a good Technical Manager, you have to be good a the technical stuff and also good at the management stuff. You can also be mediocre at the technical stuff if you are really good at the management stuff or viceversa.
- kiawe_fire 5y agoI thought the same when starting my current job (small company co-owned by two software devs), but this has proven false for me. The biggest problem I have is that, while both managers are OK software devs (but not great), anything I advocate for that is above their skill level is perceived to be “too complicated”, or “takes too long to do, let’s just get it done quickly for now”. So, instead of proper config files or method dispatching for client-specific behavior, we end up with if/else and switch statements with hard coded client primary keys. Then, when a huge bug comes along on a Friday at 5pm as a result of how we built the thing, I get to be the one to dig us out of the hole while my managers are busy “working on the next big feature” which will almost certainly be done just as poorly. So, conveniently, only myself and our customers ever get to experience the consequences of their decisions. And what can I do? I can fight to get my way, sometimes, on new features, but when “their way” becomes a problem, I can’t use it as an example to support my ideas or say “I told you so” without hurting feelings or going against the people signing my paycheck.
- pc86 5y agoThe Venn diagram of "OK software devs" and developers who think config files are "too complicated" are two circles a couple city blocks apart.