Developers, your manager is likely clueless | Hacker News Reader

Developers, your manager is likely clueless

ewattwhere.substack.com

73 pointssidcool96 comments

For a software project, you need 2 main people to run it effectively:

- a tech lead who is intimately familiar with the code being written, who keeps the code design/architecture on the right path, and oversees all the work being done. This person can make great strategic decisions about how to schedule the work to find opportunities to group common work together, divide the work so that people are not working on top of each other, and make decisions taking in the long term health of the codebase and short term delivery pressures.

- a business/product expert. This person prevents the tech lead from being in endless meetings. They sit down and figure out the requirements for the product/project. The clearly communicate these requirements in documents condensing the endless meetings into a coherent clear vision for the product with the long term vision and short term priorities being made clear. The tech lead uses this condensed information to plan the software development.

You cannot have one person do both of these things. The tech lead cannot be in endless meetings and keep the needed level of intimacy with the codebase and properly direct the work being done. The business/product expert needs to be an expert communicator, to make that interface between the tech lead and business/product requirements effective. They need to be able to ask the right questions to get the information about what needs to be built, and then clearly paint that vision to the tech lead. The business/product expert does not create tickets of work to be done! They just communicate the vision. The tech lead breaks the work down strategically.

This is the best case for a CEO/CTO relationship.

The CTO shouldn't be writing code, it's too low leverage. But they must be ABLE to write the code at least 80% as well as the best person actually writing.

The CEO should be speaking with all of the key stake holders, and then having strategic conversations with the CTO as equals

> But they must be ABLE to write the code at least 80% as well as the best person actually writing.

The CTO? The CTO of what type of company? You’re having a laugh if it’s anything other than a startup or medium sized tech company.

I don't know why you're downvoted - it's absolute nonsense to think that your CTO should be 80% your best developer. Your CTO should not be writing code at a company with >100 employees - why would they maintain 80% of the skillset of someone who's entire job is writing code? Is the assertion that what a CTO does is only 20% different than what a software engineer does?

Yep, I did a spit-take when I read that.

> You cannot have one person do both of these things.

Isn't that basically what Apple does with their "DRI" concept? One individual directly responsible for the whole project, both for the technical implementation and the product/market fit. This avoids the lengthy back-and-forth negotiation between the tech owner and the product owner about what the user wants vs. what can be done, and also avoids the usual "Wait, I though you were the owner of that?" discussions that we've all seen happen when things get complex and ambiguous.

1: https://mentorphile.com/2019/03/05/fostering-apples-culture-...

Not sure about that. I'm not familiar with Apple's DRI concept. But it sounds like there could be a DRI for the tech and a DRI for the business side of things. If not you would probably want the tech role to be the DRI and pull the info from the business/product expert. The alternative would be to have the business/product expert be the DRI and maybe take on a project manager type role. There is also the possibility that someone does do both roles and is super efficient, or just works 100+ hours per week. But in reality my guess is they end up becoming the business/product expert and delegating the tech lead to someone else

If all us managers are going to get painted into this very unflattering box I guess we can do the same with the developers we're expected to manage. Prior to my management life I completed an applied Comp Sci degree and a MSc in SW Engineering. I have 10+ years of development experience, code regularly and obsess of staying technical relevant, while stile recognizing my huge weaknesses and leaning on domain experts whenever possible. Contrast this with the coding bootcamp grads with < 2 years experience who think they're "Senior Software Engineers". #PROUD-DINOSAUR

You're clearly not the manager that this article is referencing.

They do say 'likely'. 'Likely' your devs are clueless too. Competent people vs incompetent people is not 50/50.

I'm in a similar boat with 16+ years experience and 3 directing a department. The vast majority of candidates are contemptible. The good candidates that get hired are not without their own problems. Creating a "fuck the management" or "fuck these talentless kids" environment only ensures that the generation that takes over after us will not be prepared. I hope agitprop articles like OP's will be replaced with a little bit of common sense.

> ensures that the generation that takes over after us will not be prepared

Recently there was a post on the front page here about managers making jokes about firing their employees.

From what I remember, most of the comments were a variant of "that's great advice".

I'm older than the average demographic here, and I have to say I was taken aback by those comments, because I thought that type of thing would be common sense (the Golden Rule).

3 decades here with 2 decades in tech management. I gave up trying to be as good as my best developer a decade ago. My job is to facilitate great developers to write great code and engineer solid systems so no one above me shits on my head.

Also…to be just technically smart enough on our platforms not to be bullshitted.

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.

A 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.

Product managers aren’t (or at least aren’t supposed to be) developer managers and is not what is being discussed in the article.

Depends entirely on the company, the titles and roles are frequently mixed up.

Really? 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.

I 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

The 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.

Can'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.

The 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.

People 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.

Mostly 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.

Been 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.

> 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.

My 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.

> 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.

I'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.

Yep. Developer managers tend to pull the team with their development ability (because they have presumably been good at it before they got promoted) at the cost of management practice and focus on the team.

This means you are in a fundamentally different team.

I have seen it is hard for developers to shed their development skin and become real managers. They might feel they need to prove their ability by being able to make all these decisions or even code themselves. There is probably couple of other things happening.

But that also means the team has less development responsibilities because manager will make all most important development decisions. And people who do not have important responsibilities tend to devolve.

Now, the world "tend" is everywhere here and it just represents the fact that every manager is different. I just mean this as a general observation from 20 years of working in development in companies like Canal+, HP, Intel, Samsung, Credit Agricole, Credit Suisse, Citi and others. There were better and worse managers and there were definitely some good managers who were developers before.

>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.

> 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.

Technical 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

IF they can resist the urge to jump in the pool with the developers, IF!

If 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.

I'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.

> IF they can resist the urge to jump in the pool with the developers, IF!

Honestly, in most intellectual work, the first-level manager having an intermittent toe in the water of the actual work (not focussing there, of course!) I find to be a pretty good sign—if they don’t, my experience is that they either don’t understand it or are overcommitted (usually, too broad a span of control, but sometimes too much pushed down to the first level of management that should be at higher levels), or are inventing no-value work for staff in their slack.

I 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.

I 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.

I’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.

It 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".

Looking 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.

This 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.

Having 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."

I 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.

To 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.

I 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.

The Venn diagram of "OK software devs" and developers who think config files are "too complicated" are two circles a couple city blocks apart.

My current manager is very technical, we work in a FAANG level company, and he was an IC not so long ago. He's a micromanager sort, suggests it's okay if people want to work over holiday days, and tells people regularly they should be thinking about how to contribute at all times (while they're home eating dinner, taking a shower, on the commute, etc.). He's the second worst manager I've ever had.

The worst was also a former engineer, but he liked to play politics, lied about just about everything, and regularly blamed delays and failed projects on his team. No engineer was spared--every single one of us ended up with negative comments on our performance reviews for periods where we were assigned to high visibility projects. It got to the point where nobody on the team wanted to work on any such project. This guy was promoted to a director position eventually.

Some managers suck. Some don't. And it doesn't matter if they've ever been an engineer or not.

Also, engineers aren't special here: talk about egos and negative, hyper-competitive behavior....

The managers who are most liked by their subordinates are the ones who are the least jerks. The managers who are most liked by their superiors are the biggest jerks.

Feels a bit cynical. Sure, it's annoying if your boss says:

“So listen, I keep hearing about all these bugs. And I really think we need to put a stop to it.”

Doesn't really mean he's clueless though. He's probably telling you that he is getting shit for bugs, and there's a company perception that the product is buggy. Ask questions and find out. And if that's the perception, help him with a pragmatic way to share the real story.

My experience is that if the team isn't translating what they are doing, why, etc...upwards, then the boss eventually makes up something to measure.

That’s probably a fair, if charitable, assessment.

But if the IC is having to dig to understand what a manager means then the manager has failed at one of their core duties, being communication channels through the company. If someone isn’t a good communicator they’re definitely not going to be a good manager.

He's probably telling you that he is getting shit for bugs

But being a "shit umbrella" is literally part their job. A good manager should be filtering inputs from external sources, tossing out the useless input, and translating useful inputs into actionable tasks or discussion points for the team.

Instead of "stop coding bugs", the manager should be having a discussion about defect escape, test quality (across the spectrum of test types), and doing some self-reflection on whether or not task descriptions are adequate (if they only ever capture the "happy path" and don't describe desired failure behavior, it shouldn't be surprising there is undefined behavior in the software).

> Doesn't really mean he's clueless though. He's probably telling you that he is getting shit for bugs, and there's a company perception that the product is buggy. Ask questions and find out. And if that's the perception, help him with a pragmatic way to share the real story.

I think this means he is clueless in the way that a developer asking "what is a for loop" would be considered clueless. Managing company perception of what your team is working on, and advocating for their work both in terms of features and fixing bugs is like Engineering Management 101. Doing all this "asking questions to find out" stuff is what the manager should be doing.

> My experience is that if the team isn't translating what they are doing, why, etc...upwards, then the boss eventually makes up something to measure.

Again, managers doing this are clueless in the same way that a developer "making up" syntax would be. They should be replaced by better, more clueful managers.

I have absolutely no idea why we as an industry tolerate arduous coding tests and take-home projects for "individual contributors", but have a propensity to give people managers a free pass on obvious stuff like this.

I suspect management job descriptions are based on the output of the team to be managed rather than the requirements of being a good manager.

It's not just cynical (and jaded). It's condescending.

I mean, in one sentence the author writes:

> Well, that and Kevin needs to learn how to code, so he can then learn just how ignorant “Stop putting bugs in the code” really sounds to a development team.

And in another it's:

> Detailed tellers are so happy that they finally have the power to get everyone to write code “the correct” way. Tellers are especially bad if they have lots of energy and vigor as you can’t just wait for them to go away. This manager type is probably single-handedly responsible for causing software engineers to be reticent about working for a manager with technical chops.

So the manager is clueless if he or she can't code, but also clueless if he or she can and crosses the author's undefined boundary for too much direction and detail.

The message: the author (and her prototypical developer) know it all. Everyone else probably sucks, probably beyond repair.

Yes, bad managers do exist. Exceptional ones are not super common. But the same could be said of developers and I'd say that based on the following, the author exhibits a toxic attitude that every team should look to avoid.

> So, as a developer, what can you do?

> Not much, unless you have a good shot at getting the manager removed without hurting your career. You might be tempted to somehow educate your manager, and if the skill gaps are pretty small, and the trust level is high, the managing-up school of management can be effective. However, most development manager skills gaps are on the scale of the Grand Canyon.

It should be condescending to these bad managers. I've only ever had one technical manager and he was by far the best manager I ever had. People who cant code shouldn't be managing development teams and I'm sorry if that hurts your feelings but it's the truth from where I stand. I'd even go so far as to say you are far better off with a technical product owner than a non technical one.

The impression from reading the post is that just about every manager is bad. The ones who can't code. The ones who can. The author, on the other hand, knows it all, has nothing to learn, and can do no wrong.

As someone who started as an engineer, moved up to management and then started my own companies, I've seen first hand that very few things hurt an organization more than employees who think they know it all and that everyone else is a problem that can't be fixed. You can (usually) fix bad code. You can almost never fix a toxic attitude. This post contains way too many of the toxic attitude red flags.

Most managers are bad because most managers core skills are not management. Many engineers complain about non technical background managers but many people will note that even managers with technical backgrounds skills soon become irrelevant. It's the ability to actually manager people, and further projects, that actually makes a manager good or bad.

Unfortunately you rarely get to evaluate your manager properly before starting a new job and there is no guarantee that they will be there for any length of time once you do start. Having a good manager feels like winning the lottery.

I feel the opposite, most (engineering) managers/directors are bad because they've either lost their edge and having coded in years (or decades) and cannot appropriately respond to team issues or they were never technical to begin with.

Easiest way to lose a locker room is having a manager/director who is technically inept.

Now I'm confused: is the manager supposed to solve technical problems?

>Easiest way to lose a locker room is having a manager/director who is technically inept.

For example, there are plenty of excellent soccer coaches that have never played soccer.

This type of thread shows up every couple of months here, and people use their anecdotal experience to define a whole role (which is different within itself and between organizations), which just feeds prejudice about a particular type of people, non-dev managers.

When in reality you have great managers from both technical and non-technical background.

Depends more on the team than the person tbh. Sure you can have a great manager in either lane but if they don't gel with the team, it's ultimately going to fail. Most of the teams I've worked on don't want people managers in the chain of command, obviously anecdotal.

> Easiest way to lose a locker room is having a manager/director who is technically inept.

I think a better way to look at a manager is to compare it to the HR department.

Managers aren't hired by the people they will be managing, they're hired by the company.

In the same way that HR always represents the company's interests more than the employees, a manager is the exact same thing.

It's not in the interest of most company executives to hire a manager with the backbone to say "no" to management, or be on the side of the team being managed.

I think it's very rare when a manager is hired to actually manage properly. Most companies seem to value the very qualities that most people hate about bad managers.

But... most Coaches, continuing the locker room analogy, are not good athletes. It's incredibly rare for them to be as skilled as the folks they are coaching and its very likely they were never as skilled as the people they are coaching.

Yet they are good coaches. Managers !== Coaches but I think you understand what I'm saying. Yes there are managers who are so technically incompetent that they are not good managers but most technical managers last management skills rather than technical skills and in most cases the technicals are not as important as the management skills. Any CTO/VP/Director of a mid/large sized company is a good example of this. They are no longer hands on. Their effectiveness comes from their ability to manage others.

Pretty low-effort blog spam stroking developer ego about being (yet again) the smartest people in the room and everyone else being monkeys. The inferiority complex is kind of tiring.

Aye. The folks I've worked with who most insisted that managers were useless were the ones who most badly needed supervision.

Classic case of https://www.urbandictionary.com/define.php?term=STEMlord

Kind of a low-value article full of Dilbert-style foibles.

I've observed managers who had very little knowledge of the tech, but were excellent at critical thinking, sensing BS, and "managing up".

See also "All You Jokers, aka How To Train Your Manager".

Slides: http://paul-m-jones.com/talks/how-to-train-your-manager.pdf

Video: https://vimeo.com/80271777

(I am the author/presenter.)

While there are some good observations in the article, and while I agree with the detrimental effects the observed behaviours have on the effectiveness of teams, I feel there is also a missed opportunity of understanding the manager's perspective.

If we start with the basic assumption that people will rarely try to do intentional harm, we can conclude that most harm is done unintentionally. So while the choice of the term "clueless" might apply, it also doesn't help with creating a path towards mutual understanding.

My current perspective on how we think and work is that we all have a mental model of how the world works. It is modified and reinforced by our actions and the effects we perceive. We will then try to apply our model to novel situations. I find the term "clueless" to not be accurate. It is more that people act mostly based on clues. But it might very well be that the mental model is inaccurate or even inadequate.

I don't think the simple quality "has been a developer" is a sufficient indicator to predict a manager's success. I find the trait "is flexible adjusting the mental model" might be more fitting, but also harder to discern from a CV. So my critique to the author would be in a similar class of error. Applying an inadequate mental model to solve the problem.

I believe we could all benefit from more goodwill and empathy towards our team members (and I am including the manager in the team, as well as the whole organization). Asking "what is our mental model and where does it break down?" has been tremendously helpful for me in the past.

This is something that we talked about during our last podcast where we interviewed our CTO. He believes that a flat hierarchy in an organization is a way to solve for this. There are good and there are bad managers. An organization needs to compensate for this.

If you're interested: https://www.youtube.com/watch?v=AflK5qst1qc

IME flat hierarchy == shadow hierarchy. You're still going to get one and I believe intentional > accidental, even when it comes to making mistakes.

The thing is that a strict hierarchy is enforceable. A shadow hierarchy is one that can be circumvented if needed. If the organization encourages lower level devs to "skip" up hierarchy levels if needed then they do. If a bad manager doesn't like it, they can take it up with the dev but in that case the dev hasn't really done anything wrong at all.

It's largely an issue of company culture.

> “Stop the bugs, we need to stop putting bugs in.”

> Focuses on Jira metrics, praises people for completing “lots of Jira tasks”

This is not a problem of ignorance. It's a problem of micromanagement VS trust.

Managers create arbitrary requirements and productivity metrics in order to apply the carrot-and-stick method. It's about power and control.

> So, as a developer, what can you do? Not much, unless you have a good shot at getting the manager removed without hurting your career. You might be tempted to somehow educate your manager

Not at all. A team of developers can go very far in pushing back against micromanagement. But only if you stick together and send the same message, consistently:

1) trust us to do our job and organize our priorities, as you would expect from any other professional

2) trust us to peer-review our work and productivity

3) provide us with training, time and resources as requested

4) protect the team from unreasonable pressure from upper management and other teams

5) if you provided 1,2,3,4 and we fail systematically, move people to other teams or fire them

Are there any name-brand companies (or even largely unknown but reasonably successful companies) that have managers as described in this blog? Does this tend to be a big consulting problem vs "pure software" companies? I can certainly see this being the case someplace like Booz or Deloitte, based on anecdotes from friends that work at those companies.

I've been with the same employer for ~20 years, so obviously a limited experience, but I'd guess 80% of our SDMs were developers themselves and the remaining 20% had complementary roles within dev teams. I've yet to find a manager who was "just an MBA" with little experience as a development team member.

Maybe I just lucked into one of the good companies?

> Maybe I just lucked into one of the good companies

If you have a good manager, then yes. You did.

I will be counter argumentative.

In general, I think developers make even worse managers.

I will not discount that there are many 'managers' who, despite their college degrees, lack the ability to manage. That said, managers do not need to know how to do what their staff does in a nuanced details. If they do, the manager is prone to micromanage, or second guess their staff.

After decades, I still have to bite my tongue in meetings where there are two-way, technical decisions and allow my teams to come to their conclusions.

(edit: wow. Turns out not so counter after-all.)

Kevin replied, “Stop the bugs, we need to stop putting bugs in...and the way we're going to do that is first, stop paying lip service to code reviews, second, actually take some time to write unit tests for each feature, and third, quit deploying to production from your freaking dev box, Hank!"

If your manager is clueless, doesn't it mean that the person who hired the manager (presumably the manager's manager) is clueless too?

That would strike me as the larger problem, since the manager role is likely going to be filled by the same type of person over and over again.

LOL, why is my article flagged? I mean, I sort of love the notoriety, but still, why?

I hope orgs without managers will become more and more popular.

Am I missing sarcasm or is this some reference I don't understand?

The most successful organisations have managers, they just know how to manage properly. To state the obvious, an organisation of any significant size needs management.

It's conceptually interesting. I'm curious as to what you believe a manager does, and how you think the 40-60 hours of work should be distributed throughout the organization.

"Organizations without managers" of any significant size invariably develop a shadow hierarchy where some people do the work of managers and end up in meetings of people who are Not Managers, except that they're, surprise--actually managers, without the title.

I consulted for quite a while and have worked at my share of companies and I have never seen implicit shadow hierarchies result in healthy dynamics in and across teams.

Well put.

I can see those shadow hierarchies exploding when somebody who is de facto manager eventually (and inevitably) has their de facto authority challenged.

A transparent hierarchy is not only more workable, but it seems to me to be a lot fairer.

I'm guessing he means something like this

https://hbr.org/2011/12/first-lets-fire-all-the-managers

Or any of these

https://www.happy.co.uk/blogs/16-companies-that-don-t-have-m...

I understood what he meant. Of the two on that list I know about directly, I know that both Valve and Zappos happily built exactly that shadow hierarchy and that it became (or has become) very difficult for new folks to gain traction even for just doing "their job", let alone to grow in their careers.

And then there is the manager in the middle that had a previous tech background from 10 years ago but never took the opportunity to keep up.

This type of guy tries to explain to you the task at hand used to be done in a matter of hours when he was still coding himself, and does not understand why it can’t be the same now.

Yead grandpa, I know, I’m stupid. So here you go, here is the keyboard, show me your skill so I can learn from the best!

(Actually the best manager I ever had was really technical and was showing and teaching me stuff in a peer programming fashion!)

Absolutely the worst and most of them drove me out of the company due to their incompetence.

It's a valid and interesting question though why the same task implemented in a 'professional environment' today sometimes (often?) takes many times longer with worse results than 20 or 30 years ago in a small team and with development tools that were much more primitive than what we have today.

Why can't it be the same now, indeed?

Everything should be faster and easier in modern programming languages, frameworks and tools, but very often it isn't. Why?

To be fair, some of the "bloat" can be the fault of developers who wants to use the latest framework that requires a lot of time to learn how to use correctly. New frameworks also often has bugs, issues and poor 3rd party support.

I'm not against learning new tech as part of the job, as it can be a motivating factor for the developers. At the same time we can't ignore that for a startup, it is probably better to use a known technology so that they don't end up fighting the framework as their needs grow beyond the basic tutorial/blog post

Here's a suggestion: If someone finds themselves sending multiple patches to the framework or implementing missing database libraries, they may have chosen the wrong framework/language. It can be very motivating, but the time could have been spent on improving the product.

Usually the answer is that it's not actually the same task.

I ask that myself often.

new things are not always better, and inexperienced devs just use the hype-of-the-month framework to build stuff that miserably fails- see the articles from today about Event Sourcing and CQRS for example...

A colleague and i literally going through this now, as im reading .. just ticking boxes. haha

My manager is clueless, but sets me up with doomed projects, where he then sweeps in to save the day, by changing the scope and removing features or renegotiating goals with the customer.

PS: Most management gets there coding experience from excel. So copy & pasta code is good.

Scope negotiation and changes happens at every org.

Reply on news.ycombinator.com