
Ask HN: What mistakes in your experience does management keep making? - oggyfredcake
Lessons from Mythical man-month aside, what mistakes does management keep making and what do they never seem to learn? And of course the effects on those on you and your peers?
======
jerf
I'll add one that even after 200 comments I don't see: Failure to explain the
reason _why_. Coming down to their developer with a list of tasks without
explaining why those tasks are the most important and will lead to company
success.

You might think startups are small enough that this couldn't happen but that
was actually where my _worst_ experience was. The founders are visibly in a
meeting with a couple people, maybe "suits", maybe not. They come out of the
meeting and the next day your priorities are rewritten. Cool beans, that's a
thing that can happen and that's not my issue. My issue is, _why_? What are
the goals we are trying to hit now? What's the plan? Why is that better than
the old plan?

This is especially important IMHO for more senior engineers responsible for
architecture and stuff, because those matters can greatly affect the
architecture. Telling me why lets me start getting a grasp on what parts of
the code are long term and what can be considered a short term hack, what the
scaling levels I need to shoot for, and all sorts of other things that are
very hard to determine if you just come to me with "And actually, our
customers need a new widget to frozzle the frobazz now more than they need to
dopple the dipple now."

Not necessarily the biggest issue, there's a lot of other suggestions here
that are probably bigger in most places, but this is one that has frustrated
me.

(I'll also say this is one you _may_ be able to help fix yourself, simply by
_asking_. If you are in that senior role I think you pretty much have a
professional obligation to ask, and I would not be shy about working that into
the conversation one way or another.)

~~~
noxToken
> _This is especially important IMHO for more senior engineers responsible for
> architecture and stuff, because those matters can greatly affect the
> architecture. Telling me why lets me start getting a grasp on what parts of
> the code are long term and what can be considered a short term hack, what
> the scaling levels I need to shoot for..._

This right here has been the biggest problem in my experience. We'll have
unforeseen issues arise in production, and the business side will come up with
methods to fix the issue. Without context, all of these fixes to our products
have been fine, but they never take the future into consideration. It makes me
paranoid.

I used to adhere pretty well to the adage "Write code for what you have now
and not some mystical thing that may arise in the future" while still
maintaining enough abstractness to extend things. New requirements would come
in, we would implement them, and everyone is happy. 3 months later, a new set
of requirements that destroys how we wrote something else. If we knew a road
map before we started designing and implementing, we could have saved everyone
time and money by designing for X + Y instead of X alone.

I get that you can't know everything that is going to happen. I get that there
will be times where you must refactor the code. That's fine. However, tell me
where the product is going. It may seem like a trivial change to you as a
business person, and the only way we devs can keep the change trivial is by
proper design.

~~~
jerf
I think of YAGNI as a very important principle, and encourage young developers
to practice it rigorously, but as you grow in your arts you should eventually
be able to reliably predict _some_ elements of the future, and as you approach
the middle of your career you should be able to start successfully heading
such things off at the pass.

I think it is important while young to be very aggressive with the YAGNI
because otherwise you will have a much harder time developing that prediction
skill, as the data set will be much noisier.

~~~
noxToken
This is something that I struggled with at first. I kept gravitating towards
abstract solutions, and returning to that code was always annoying. Too many
layers for so little payoff.

------
muzani
* Killing things that are low profit margins, under some misguided Pareto Principle approach. Sometimes these things are loss leaders designed to pull customers for other products.

* Spending too much on marketing/sales before people want the product. They usually just end up burning their brand if the product is too low quality.

* Too much focus on building multiple small features rather than focusing on the value proposition.

* Trying to negotiate deadlines for product development. "We don't have two months to finish this. Let's do this in one." In software estimation, there's the estimate, the target, and the commitment. If the commitment and estimate are far off, it should be questioned why, not negotiated.

* Hiring two mediocre developers at half the salary of one good developer. They usually can't solve problems past a certain treshhold.

* Importing tech talent, rather than promoting. Usually the people who have built the product have a better understanding of the tech stack than someone else they import.

* Startups that rely on low quality people to skimp on the budget. These people later form the DNA of the company and make it difficult to improve, if they're not the type who improve themselves.

~~~
elliottcarlson
> Importing tech talent, rather than promoting.

is often at odds with both the point above and below it. When a company is in
rapid growth, there may be a point where the talent they relied on is not
quite ready for the promotion they are hiring in for. Without expanding that
search outside, you may become stale in the organization, and not provide the
right mentorship to ensure that those interested in getting promoted will be
able to do their job properly once there. I think the point should be, that
you would want to ensure that those you import will be able to help promote
from within as things progress.

~~~
Boothroid
Here's another one - promoting without advertising the role first. Come annual
review time: 'I am pleased to announce that x, y and z are now Senior
Consultants and will be managing a, b, c, d, e and f' (who were never given
any chance to apply for the role).

~~~
drpentode
At review time, when you're asked what your goals are, mention the promotion.
Ask what you need to do to get there. 90% of the time, the manager is more
than happy to help you.

------
stickfigure
I've never met a manager that wouldn't rather pay four average people $100/hr
to solve a problem that one smart person could solve in half the time for
$400/hr.

There seems to be some sort of quasi-religious belief in the fundamental
averageness of humans; consequently the difference between developer salaries
at any company varies by maybe 50%, whereas the productivity varies by at
least a full order of magnitude.

Until "management" realizes this, the only way that a developer on the upper
end of the productivity scale can capture their value is to found their own
company. I sometimes wonder what would happen if some company simply offered
to pay 3X the market rate and mercilessly filter the results.

~~~
marcus_holmes
In my experience, the 10x programmer is a bit of a myth. Where I have seen
people do some incredible feats of productivity, it usually came with a clutch
of bad stuff, too. Like:

\- they didn't work well with others and soaked up a lot of management time
dealing with their shit.

\- they had really limited areas of expertise where they were amazing, but
couldn't fill in for a sick colleague.

\- they worked in 2-3 day sprints for ridiculous hours, and then stayed home
or might as well have.

I'm sure there are incredible people out there who can 10x and also be great
team members, and I'm sure management are idiots if they don't pay them 10x.

But in my experience, the people who claim to be 10x are usually just
insufferable egotists who have no idea of the pain they cause for everyone
else.

~~~
MatthewWilkes
I think it depends on perspective. I don't think there's a 10x programmer, but
I've worked with plenty of 0.1x programmers. If your organisation is not doing
a good job of managing your developer team you may have a very skewed view of
what 1x really looks like.

~~~
Aaargh20318
> I've worked with plenty of 0.1x programmers

I think the -1x programmer is even more common, the ones that have negative
productivity and actually create more work for other programmers. I've
encountered many of these types over the years.

They are usually the very hard working type too. The kind who when
encountering a problem always solves it by piling on more code, never
refactoring, never taking a step back and thinking about the problem. You
don't want to be seen idling at your desk, better keep typing.

~~~
quickthrower2
I've worked with this type. In this case very outgoing too and favoured by
management. Man that code though! That code!

------
JamesLeonis
Want to jump ahead a few years from Mythical Man-Month? Let me recommend
Peopleware by Tom DeMarco and Tim Lister.[2] It's painful that we haven't
crawled far out of the 80s practices.

The first chapter says: "The major problems of our work are not so much
technological as sociological in nature." Sorry Google Memo Dude. DeMarco and
Lister called it in the 80s.

Speaking of DeMarco, he also wrote a book about controlling software projects
before Peopleware. Then in 2009 he denounced it. [1]

    
    
        To  understand  control’s  real  role,  you  need  to 
        distinguish between two drastically different kinds 
        of projects:
    
        * Project A will eventually cost about a million 
          dollars and produce value of around $1.1 million.
        * Project B  will eventually cost  about a million 
          dollars and produce value of more than $50 million.
    
        What’s immediately apparent is that control is really 
        important for Project A but almost not at all important
        for Project B. This leads us to the odd conclusion that
        strict control is something that matters a lot on 
        relatively useless projects and much less on useful 
        projects. It suggests that the more you focus on control,
        the more likely you’re working on a project that’s
        striving to deliver something of relatively minor value.
    

I always think about that when I'm doing a Sprint Review.

[1]:
[https://www.computer.org/cms/Computer.org/ComputingNow/homep...](https://www.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf)
[2]:
[https://en.wikipedia.org/wiki/Peopleware:_Productive_Project...](https://en.wikipedia.org/wiki/Peopleware:_Productive_Projects_and_Teams)

~~~
austinjp
Fascinating.

Is the A/B situation DeMarco describes about knowing ahead of time that A will
turn minimal profit while B will turn maximal profit?

If so, the conclusion reached seems right: tighter profit margins require
tighter control. And control requires resource, which is a cost that further
diminishes returns.

But if the described scenario is about _not_ knowing ahead of time whether A
or B will turn a large profit, how should this be handled? Regular review, and
a scaling-down of control as confidence in profit increases?

Of course, profit is only one metric. There may be others that are more
critical.

~~~
jaggederest
My metric for projects is that if I'm not returning near-term value at least
double my billing rate, it's probably not worth doing.

If you are, the difference between 2.2x, double, and 1.8x is pretty negligible
- non zero, for sure, but not worth the additional 20% effort to minimize
variance.

If you aren't, as he says, no amount of diligence will fix it, because it's
simply the wrong project.

It's the classic penny-wise pound-foolish.

So by my conclusion, many of the 'project management' activities that people
do are at best wasteful or indeed actively harmful.

------
lb1lf
Working for a company building heavy hardware, I see the following happen time
and time again:

* Reorganizing seemingly for the sake of reorganizing. Result: Every time the new organization has settled somewhat and people know who to interact with to make things flow smoothly, everything is upended and back to square one.

* Trying to make our products buzzword compliant without understanding the consequences - we've on occasion been instructed to incorporate technologies which are hardly fit for purpose simply because 'everyone else is doing it' (Where 'everyone' is the companies featured in whatever magazine the CEO leafed through on his latest flight. Yes, I exaggerate a bit for effect.)

* Misguided cost savings; most of what hardware we use, we buy in small quantities - say, a few hundred items a year, maximum. Yet purchasing are constantly measured on whether they are able to source an 'equivalent' product at a lower price. Hence, we may find ourselves with a $20,000 unit being replaced by a $19,995 one - order quantity, 5/year - and spend $10,000 on engineering hours to update templates, redo interfaces &c.

* Assuming a man is a man is a man and that anyone is easily and quickly replaceable (except management, of course) - and not taking the time and productivity loss associated with training new colleagues into account.

Edit: An E-mail just landed in my inbox reminding me of another:

* Trying to quantify anything and everything, one focuses on the metrics which are easy to measure, rather than the ones which matter. As a result, the organization adapts and focuses on the metrics being measured, not the ones which matter - with foreseeable consequences for productivity.

~~~
tome
> a man

"a person"?

~~~
lb1lf
>> a man

> "a person"?

-Definitely a person; however, the gender balance in my immediate surroundings is -ahem- slightly skewed and I all too easily fall into the trap of calling any person a man.

(Judging from the time clock (whose logs are openly available on the intranet,
presumably through oversight rather than by design), there are currently 217
people working in the hall I currently sit in. Of those, one appear to be
female.)

------
ChuckMcM
There are some very common ones;

* Building a one more generation of product than the market supports (so you build a new version when the market has moved on to something new).

* Rewarding productivity over quality.

* Managing to a second order effect. For example when Nestle' bought Dryers they managed to 'most profit per gallon' which rewarded people who substituted inferior (and cheaper) components, that lead to lower overall sales and that leads to lower overall revenue. Had they managed to overall revenue they might have caught the decline sooner.

* Creating environments where nobody trusts anyone else and so no one is honest. Leads to people not understanding the reality of a situation until the situation forces the disconnect into the mainstream.

* Rewarding popular popular employees differently than rank and file. Or generally unevenly enforcing or applying standards.

* Tolerating misbehavior out of fear of losing an employee. If I could fire anyone in management who said, "Yeah but if we call them on it they will quit! See what a bind that puts us in?" I believe the world would be a better place.

There are lots of things, that is why there are so many management books :-)

~~~
serpix
> Tolerating misbehavior out of fear of losing an employee.

What if said employee pulls in 10x, 100x more revenue/value than average
worker for the company? Would you fire him because the rule book say so? That
said I trust in effective communication as soon as possible to manage
difficult situations or misbehaviour. Often the reasons can be deeply personal
or family related and people are preoccupied with stuff outside work. We are
human and human relations are variable, not absolute.

~~~
ChuckMcM
In my experience only (all disclaimers apply) I have never seen an employee
whose productivity outweighed the damage they did to the rest of the team if
their misbehavior was tolerated by management. I understand how scary it can
be to have to let someone like that go, but the dozen or so cases that I had
good visibility into over my career the ones where the employee was
accommodated all had worse outcomes than those where the employee was let go.

------
sulam
I have held management and non-management careers in roughly equal proportion
over my career. My list would look like this:

1) believing you can dramatically change the performance of an employee --
it's very rare to save someone and less experienced managers always believe
they can.

1.5) corollary to the above: not realizing the team is aware and waiting for
you to fix the problem and won't thank you for taking longer to do what's
necessary.

2) believing that people don't know what you're thinking -- people see you
coming a mile off.

3) thinking you can wait to fix a compensation problem until the next comp
review -- everyone waits too long on these.

4) believing HR when they tell you that you can't do something that's right
for your team -- what they're really saying is that you have to go up the
ladder until you find someone who can force them to make an exception.

5) not properly prioritizing the personal/social stuff -- at least this is my
personal failing, and why ultimately management has not stuck for me.

6) believing your technical opinion matters -- I've seen way too many VP's
making technical decisions that they are too far from the work to make, trust
your team!

It'd be fun to see a list of these from the non-management point of view. I'd
start off with the inverse of #6 above:

1) believing your technical opinion matters -- the business is what ultimately
matters.

~~~
groby_b
You can't change it dramatically overnight, but you can certainly change it
enough that it's worth it.

It's a boatload of work. Expect to spend as much time per week as you usually
spend on 3-5 people. Then make the call if you can afford to do that. It's
buying you a _lot_ in terms of employee goodwill and team morale. (The second
one only if you don't neglect the team over it, obviously :)

~~~
sulam
In our current job-hopping world, where you are lucky to even get 4 years from
an employee, you can take someone from good to great, acceptable to good, or
bad to acceptable in the time you work with them. Your investment should
almost always be on the first two, especially because the last one is a much
bigger investment of time and energy. Keep in mind many times what you're
fighting is not just lack of experience or some other easily fixable thing,
you're fighting personality traits the person has had for years, and will
continue to have (to a lesser degree) even if you _do_ "fix" things.

It is one of my signals of inexperienced management that they believe they
can/should take on this sort of challenge.

~~~
groby_b
Yeah, ~10 years as a manager (and 30 in the industry) is not a lot of
experience. But it's enough to know that "focus on the stars" mostly aims at
making the managers life easier - anybody can manage a team of great
performers.

Of course it's a judgment call. Some things, you cannot fix. But some things,
you can, and the cost of doing so is _much_ less than rehiring. Good
management means making those judgment calls, not just saying "meh, I don't
care about low performers, too much work".

Maybe, just maybe, that's a tiny part of the reason people on my team seem to
stay longer than 4 years. Because we don't just treat them as disposable cogs.

~~~
sulam
I'd be happy to discuss over a beer. I don't believe there are any hard and
fast rules in life, and I've tried to help people more than once in my career
(currently I do it in a non-management capacity which is arguably harder). But
I think we can agree some situations aren't going to be saved. Good management
is knowing how hard to try and when to stop.

~~~
sulam
Oh and an addendum: the error bar for inexperienced managers is way too far in
the "this is fine" direction.

~~~
groby_b
_That_ , I'm not debating. Rule of thumb for new managers: Assume the world is
on fire, just in case ;)

------
tboyd47
Trying to write code alongside their devs.

Here's what happens when a manager tries to fill tickets himself: his sense of
control of the project is derived not from relationships of trust and
cooperation with his reports, but from direct involvement in the code. So
naturally, any challenging or critical piece of code ends up getting written
by him (because otherwise, how could he be confident about it?)

The manager is essentially holding two jobs at once so they end up working
late or being overly stressed at work.

The devs will feel intimidated to make architecture decisions, because they
know if they do something their manager doesn't like, it will get refactored.

They will also feel as if they are only given the "grunt work" as all the
challenging work is taken on by their manager.

The code itself is in a constant state of instability because there is a
tension between the manager needing the other employees' help to get the code
written on time, while also needing to have that complete control and mastery
over the code that can only come from writing it yourself. So people's work
gets overwritten continually.

This is very bad and it's very common - managers should learn to delegate as
that is an essential part of their job. If they can't delegate they should
remain as an individual contributor and not move into management.

~~~
kaspm
Interesting, as a manager, I try very hard to do as much of the grunt work as
possible and the devs do more feature coding. Out of curiosity, where do you
rank data modeling?

I tend to want to either design or review all data design, either relational
or other, partly because of my background in data engineering and partly
because I have business awareness that the devs don't have. It's just not
possible to convey every nuance of a constantly evolving business to each dev
on the team without it being distracting.

How would you like your manager to handle being involved in data modeling?
Develop a spec and then review? pair modeling?

~~~
tboyd47
Maybe data modeling is something that's officially a "manager-level task" at
your company, so it's something you have to be involved in. But I would try to
err on the side of delegating too much, rather than too little. If you have
knowledge in a certain area that gives you special insight into how to improve
implementation of code, I would challenge you to try to disseminate that
amongst your team and hold them accountable for following it themselves,
rather than setting yourself up as a gatekeeper.

All this assumes you trust your team to be thoughtful and do good work. If not
then that's a whole 'nother issue.

~~~
kaspm
Thanks that's helpful!

------
ideonexus
The biggest recurring issue I have with my managers over the last twenty years
is their need to add unnecessary complexity to projects. I think a good
manager stays out of the way and just monitors employees for any obstructions
that are preventing them from meeting their goals. Yet, my experience is that
when a manager sits in on a project meeting, they can't help but start giving
input on the project itself, adding complexity to defined business rules or
adding obscure use cases to the system. Too many managers can't help but
dominate meetings because their dominant personalities is how they became
managers in the first place.

The worst is when you get two or more managers attending the same meeting.
Then nothing will get done as they eat up all of the meeting time arguing
about business rules, magnifying the complexity of the system until you end up
with some Rube Goldberg chain of logic that they will completely forget
minutes after they've left the meeting. A good manager knows to trust their
employees and only intervenes to make sure those employees have the resources
they need to do their jobs. The most effective managers are humble and respect
the expertise of the experts they hire.

~~~
le-mark
The best manager I every had was famous for telling his guys to give him the
easy 80%, and worry about the hard stuff when someone will pay for it. That
person was pure gold, highly effective.

The worst, there have been many. These guys just complicate simple task so no
one knows what they're supposed to be doing anymore. Managers should
ruthlessly limit scope wherever possible.

------
alexandercrohde
\- Trying to "create a buzz" around the office, asking for a "sense of
urgency," and other things that result in an illusion of productivity.

\- Focusing on fixing problems, rather than preventing problems

\- Acting as yes-men to bad upper-management strategy, thereby creating a
layer of indirection between the people who think it's a good plan vs the
engineers who can explain why it's not quite that easy

\- Trying to use software tools (e.g. Jira's burndown charts) to
quantitatively/"objectively" measure engineers

~~~
marcus_holmes
Jira management :(

I've seen so many "managers" spend all their time staring at Jira instead of
talking to their actual team or reading the code.

I'm convinced Jira is an anti-pattern for management

~~~
elliottcarlson
Jira has a lot of bad use cases around it, but I don't think it's a bad tool.
I rather be looking at the board to get status updates than interrupting
someone to see where things are at, and basically resorting to
micromanagement. It should however not be used as a replacement to talking to
the team or reading the code - but it should be one of the tools in the shed.

------
greenyoda
Promoting technical people with no management experience into management jobs,
without providing them with any training or guidance. (Happened to me.)
Writing code and managing people require very different sets of skills, and
just because you're good at the former doesn't necessarily mean you'll be any
good at the latter (or that you'll enjoy doing it).

(Similar problems can happen when a bunch of people with no management skills
decide to found a company and start hiring people.)

~~~
wjossey
What kind of things did you do to self educate, given you lacked formal
training or guidance?

~~~
greenyoda
I read lots of books about management, I tried to emulate what managers who I
thought were competent were doing, and I made lots of mistakes and tried to
learn from them.

There were some mistakes that I was never able to recover from, like being too
friendly with the people who reported to me - that makes you really dread the
prospect of having to lay someone off, makes it hard to give difficult
feedback, etc.

Eventually, after being a manager for several years, I decided to go back to
being a developer, and now I'm much happier.

------
mychael
A few patterns I've seen:

* Preaching about the virtues of a flat organizational structure, but making unilateral decisions.

* Hiring people for a particular challenging job, but have them work on menial unchallenging tasks.

* Creating multiple layers of management for a tiny team.

* Facilitating post mortems that would be better facilitated by a neutral third party.

* Using vague management speak as a deliberate strategy to never be held responsible for anything.

* Rewarding politics with promotions.

* Marginalizing experienced employees.

* Talking too much about culture.

* Trying to be the company “thought leader” instead of helping people do their best work.

* Assuming that everyone underneath you views you as a career mentor.

* Negging employees.

* New hire managers: Firing incumbent employees after you’ve only been on the job for a few weeks.

* New hire managers: Not doing 1:1s with everyone who reports to you.

* New hire managers: Create sweeping changes like re-orgs after a few weeks on the job.

* New hire managers: Doing things a certain way because it worked well at a previous company.

* New hire managers: Changing office work hours to suit your personal life.

------
redleggedfrog
The worst mistake I've seen management make over 20 years of software
development is not listening to the technical people.

Estimates get shortened. Technical decisions are overruled for business or
political reason. Warnings about undesirable outcomes are ignored. Sheer
impossibility deemed surmountable.

I feel this is the worst mistake by management because the technical people
are the ones who suffer for it. Overtime, inferior software, frustration,
technical debt, lack of quality, are all things management doesn't really care
about because they can always just push people harder to get what they want.

~~~
snvzz
>I feel this is the worst mistake by management because the technical people
are the ones who suffer for it.

How is this a mistake then? It seems As Planned. It'd be a mistake if the
management suffered for it.

~~~
redleggedfrog
In every case the companies they were trying to build up failed. Being vested
owners, they lost money, and time.

~~~
snvzz
I agree that makes sense, but the statement was "technical people are the ones
to suffer for it". If that was true, it'd be as intended

------
cbanek
Overly optimistic schedules. Even with a known gelled team, being constantly
overscheduled is a nightmare. You cut corners, and are always stressed and
tired. Other teams that believe the optimistic schedules may become angry or
blocked on you. Over time this just leads to burnout, but since nobody seems
to stay anywhere for very long, nobody seems to care.

~~~
cpitman
This! In the same vein, believing that "this time" the team will work faster
because of lessons learned. Refusing to accept that historical performance
really is the true performance of the team. Failing to account for the
previous project completing almost on schedule only because of major overtime.
Etc etc.

On my first project I learned that every time a PM said the word "hope" (as in
"I hope we can meet this deadline") that we were screwed. It was said a lot.

------
Mz
When I had a corporate job, they were overly controlling about schedules and
how much you could earn in a way that was completely unnecessary and that I
felt came back to bite them. People who wanted more money would take on part
time jobs for evenings and weekends. Then, when management tried to put a gun
to our head and insist we work overtime, these people had prior commitments
and couldn't be there. Bonus points for the whole atmosphere of fear with the
entire approach of trying to pressure people to work overtime on demand, at
the convenience of the company.

None of this was really necessary. Every single year, they watched the backlog
of work gradually climb over the course of the summer. Then, around September,
they began insisting on overtime at psychological gun point to try to clear
the backlog. It would have been entirely possible to allow people who met
certain quality standards to work some overtime during the summer and cap how
much could be worked. People could have competed for overtime slots instead of
feeling forced into it. It would have worked vastly better for everyone.

Of course, an elegant solution like that takes a bit more planning on the end
of management. Simply demanding extra hours at a certain point is a simpler,
brute force method. But, I felt it had a lot of downside to it and was mostly
avoidable for the company in question.

It makes me wonder how many companies basically create drama of this sort.
Because this crisis was entirely created by management, IMO. There was zero
reason they had to wait until it hit a certain volume and then force overtime
on us.

------
Spooky23
#1 in my book is sunk cost fallacy.

Everywhere I've worked, the folks running the show have too much ego and
political capital invested in products or projects that are turds. The result
is massive financial losses for the business.

~~~
probablybroken
My experience has been similar in the past. In more recent times I've seen
numerous products rewritten from scratch by completely new teams on different
continents - the mindset being that they would do things "properly" \- only to
encounter all the problems that the original teams had to deal with, and re-
implement the same mistakes, but in a different language. In one case, the new
team quit to a man ( and obviously, the old team were nolonger around either
), resulting in the loss of two complete product implementations, and all the
domain and implementation knowledge.

------
zilchers
Something I see a ton is management by crisis - 20 people from an organization
could tell certain managers that there will be performance issues in 3 months
if we don't pay down tech debt, but nothing actually sinks in until there is a
performance crisis in 3 months.

~~~
tomohawk
The corollary to that is that many technical types will make things work
despite management ignoring the fundamentals. Sometimes its better to let
something fail sooner than to make it work, when it's clear the fundamentals
will eventually overtake the effort.

~~~
zilchers
Ya, great point, though at big companies it can be very hard to just let
things fail. Though that reminds me of another answer to the parent question
which is managers who reward people who fix broken stuff, but don't reward
people who didn't build fragile things to begin with.

------
pbourke
* Acting as if employees are fungible rather than taking advantage of their relative strengths

* Short-term thinking ("we don't have time to fix the tech debt, we have to get something on the board this quarter")

* Over-resourcing projects from the start, rather than letting a small number of employees germinate it and set it on the right path

* Punishing people, often indirectly, for taking risks, conducting experiments, doing quick prototypes, etc

* Frequent shifts in direction, priority or emphasis. If "everything" is important at one time or another, then nothing truly is

~~~
mychael
> Punishing people, often indirectly, for taking risks, conducting
> experiments, doing quick prototypes, etc

You hit the nail on the head with this one. People seem to forget that so many
important parts of our daily life were once upon a time passion projects and
20% time projects (Gmail, Adsense etc)

------
pcunite
1\. Arrogance (only do what I say, don't think for yourself)

2\. Fear (you're getting a lot of attention and praise, this somehow makes
_me_ look bad)

3\. Short sightedness (that's a good idea, we can't use it here, now go do
something productive)

A good manager loves his team and opens doors, prevents road blocks, and
facilitates approvals for them. He is a steward of their success. He removes
fear of failure. He is not self absorbed but finds joy in the team. So,
without these attributes, the negative effects are too sad to write about.

------
quadcore
I think management fails when they don't understand that the nerds hired them
and not the opposite. We are the technology, we did it in the first place. We
hired managers to help us. By default, we know better than them (because we
are the one who do the tech), they should listen to us and not the opposite.
Now, when everybody knows his place, we can collaborate and do great work.

I got the luck to work with great managers at amazon. From what I've seen,
programmers are driving the company there - or at least, they have their word
to say, often, and power that comes with it. On my team, decisions relative to
product development were clearly strongly driven by us. Seems to work pretty
well for amazon.

~~~
forthelove
The tone you use here helps make my point: just because "nerds" are experts in
everything tech does NOT equate to good decision making / good management for
the company as a whole. Sometimes it does. Often times it does not. Things
aren't usually that black and white; "I built it, so I should run it." Just
had this convo with a coworker the other day. He was telling me about all the
complaints from the dev team and how we should let them drive the bus. I had
to remind him of all the good-tech-but-bad-business ideas several of them have
offered in the past. In my experience, the rare "nerd" who also intimately
understands the nuances of every day business (relationships, the board,
profit margins, brand experiences, etc.) is hard to beat.

~~~
quadcore
_just because "nerds" are experts in everything tech does NOT equate to good
decision making / good management for the company as a whole. _

You think a programmer's job and abilities stops where they don't. Programmers
do understand what the customer want. They ship to customers. I'm not saying
programmers don't need help though.

~~~
forthelove
False. I was directly reacting to what the OP said (below), which said nothing
of a relationship w/ customers. Personally, I'm a proponent of having devs
closely involved in every step of the product, including messaging and
marketing. But that's not what this post was about.

> We are the technology, we did it in the first place.

> By default, we know better than them (because we are the one who do the
> tech)

------
Jaepa
Security comes last, if at all.

This was back when I was a junior dev, but I had to demo how an unprivileged
user could delete every user in our system before I could work fix that
section of code without getting fussed at for trying to discuss something
unimportant. Even then the immediate response was, well we have a nightly
backup so we're fine.

------
Deestan
1) Trying to solve lack of skill with More Rules For Everyone.

One of your teams write messy code? Don't try to educate them. Instead enforce
strict coding standards that forbid all but the most basic complexity.
Everyone else now have to make their code more verbose and objectively _worse_
, while the problem team still writes bad code but now they make even more of
it in a neater formatting.

2) Raise wages only for people who threaten to leave.

3) Run a high tech software development shop but have an IT department that
assumes everyone only ever need Excel and Outlook.

Ports are blocked. Local computer admin is locked. Updates are forced, delayed
and centralized. Hardware is underpowered. Network blocks ping.

4) Demand to be in full control.

Make sure nobody does anything you don't understand. Shoot down experiments
you can't see the point of, even if they're small. Hire skilled and
experienced people, but demand that you can understand everything they do.

5) Let random people deal with hiring and interviews.

Hiring is both a hard and sensitive process. On one hand you are giving people
an impression of your workplace, and on the other hand you are trying to
evaluate the skill of someone who has a different skill set than yourself.

Giving this job to some burnt out elitist asshole who throws resumes in the
garbage because they did or didn't include a cover letter, or a wannabe drill
sergeant who tries to be "tough" and "test them under pressure" during
interviews, gives you a bad rep in tech circles and doesn't help you hire
skilled people. Giving it to someone who can't be bothered to reply to
applicants or update them on rejections is also shitty.

6) Open fucking landscape workplaces.

Fuck.

------
smackay
There is one cardinal mistake that management makes (and development blithely
accepts):

* Management is always right.

This truism is built into the entire fabric of software development: whether
your process is an agile one where the product manager has ultimate knowledge
of what is needed and on what timescales; the project that is delayed not
because of bad planning or poor company organisation but because the
developers are not working hard enough; that the only variable that affects
the business is how productive / expensive the developers are - all the
factors that describe how effective the management is are completely ignored
or irrelevant. The list goes on and on and described in better detail in all
the comments here.

Of course the solution to all of this is better data. You can be sure that the
volume of data is inversely proportional to the strength of belief of the
above statement. This leads to the second fundamental mistake that management
makes:

* Not reading High Output Management by Andy Grove.

------
quickthrower2
Task mastering. Ie a Focus on pumping through the JIRA tickets or equivalent
as fast as possible. Meaning no time for respite or learning. Meaning lots of
shitty metrics and pressure / humiliation if you don't meet them. I get a
weekly report of tasks that took more than 25% over estimate within the team
and names, for example. It doesn't help that anyone else can log time against
my JIRA either. A three person meeting could burn up all the time.

~~~
Mc91
At my company we had a good manager. Whenever we saw a problem in the systems,
even a minor, low priority one, we opened a JIRA ticket for it. After all,
JIRA was there for the convenience of the workers in the IT department.

Then a new manager came in. When he discovered we had JIRA, he told us he was
going to use JIRA to evaluate us on how fast we fixed tickets and how many
tickets we fixed.

We in the IT department maintained JIRA. That night I completely purged
virtually all tickets of tasks that could not be done quickly. I put those
tasks in a directory on my laptop only visible to me. From that time on, we
only opened tickets for simple tasks we could do quickly. As volume counted as
well, we would open multiple tickets for a multi-step task, whereas before we
would have opened only one.

Eventually there were some office politics between divisions at the company
and I and others were laid off (which I knew was coming, but decided to stay
for the severance). When I left, the files containing all the the system flaws
I had noted were erased.

The new manager was laid off shortly after I was.

~~~
lsadam0
Honestly, poor management aside....I cannot believe you are bragging about
this. Rather than confront and address the problem, your solution was to
actually delete shared knowledge?

~~~
gsylvie
Confront and address? You ain't gonna get your boss fired without a scratch.
He's just bragging that he achieved a local maxima, and I think he's correct.

Maybe during the exit interview he could have said, "oh by the way, there's a
file on my computer..."

But then he might suddenly find the severance offer is retracted.

~~~
lsadam0
I respect your point, but I still could not disagree more. Actions like this
only serve to increase dysfunction, not improve.

~~~
gsylvie
Do you have the insanity and the tenacity to un-rot the fish from the bottom
up?

> Corollary 1. Who can, and sometimes does, un-rot the fish from the bottom?
> An insane employee.

[http://yosefk.com/blog/people-can-read-their-managers-
mind.h...](http://yosefk.com/blog/people-can-read-their-managers-mind.html)

~~~
lsadam0
What about the rest of that paragraph?

> Someone who finds the forks, crashes, etc. a personal offense, and will
> repeatedly risk annoying management by fighting to stop these things.
> Especially someone who spends their own political capital, hard earned doing
> things management truly values, on doing work they don't truly value – such
> a person can keep fighting for a long time. Some people manage to make a
> career out of it by persisting until management truly changes their mind and
> rewards them. Whatever the odds of that, the average person cannot
> comprehend the motivation of someone attempting such a feat.

In answer to your question: yes, I do. Just like the rest of your link states,
it pays off.

------
WisNorCan
Not firing people fast enough when:

* the employee isn’t good and everyone knows it. Manager lacks discipline or has a low talent bar.

* the person is very talented, but a jerk. Manager is worried it will hurt productivity to get rid of them.

------
donatj
Giving junior devs all the greenfield applications as "learning experiences".
Because groundwork should always be laid by those with the least experience.

Haphazard task assignment - I build a feature, then when they need an
enhancement, it often gets given to someone else with no understanding of how
it works, even though I am free.

Cargo culting in general. We do "Kanban" just to say we do, despite it having
zero relevance to how we actually work. It's buzzwordy. Insistence on daily
standup despite having very good communication and everyone knowing what
everyone else is doing, were a small team in an open office.

Pushing for faster code review and generally treating it as a negative thing
that just slows us down.

Previously we actually hired more devs to "help" get a project out the door -
I think we all know what the mythical man month has to say about that.

Having to argue about basic security practices. I got in a heated argument
about how we needed to encrypt temporary passwords even though they were
system generated. I'm still angry. They wanted to be able to look them up for
users. Sigh.

------
gwbas1c
\- Bouncing a developer from task to task without ever finishing a task

\- Letting whatever customer screams the loudest dictate product behavior, and
then effectively alternating product behavior based on which customer is angry
this month

\- Deferring technical debt until a customer screams

\- Hiring unreasonable product managers who have unreasonable expectations.
(This just leads to a lot of time being burnt in haggling and a much worse
product delivered.)

\- Treating software as an art project, getting obsessed with pixels and fonts
instead of functionality

\- Not paying enough

(edits)

\- Interrupting programmers constantly for trivial matters

\- Allowing the entire organization to interrupt a developer at any time
because he's unofficially become a "go-to" person

\- Not backing up critical processes when departments interact. (This is the
information needed when there is a bug, support escalation, ect.)

\- Expecting developers to handhold people in other departments

(more edits)

\- Micromanaging task priority, assuming that a developer jumped on a specific
task and completed it instantly

~~~
donatj
> alternating product behavior based on which customer is angry this month

This strikes way too close to home.

------
ww520
Reinventing the wheel when new management come in, i.e. don't check their ego
at the door. The new management think they have to make their
mark/impact/whatever in the products/processes by throwing out the old's. I've
seen new VP/CTO came in, canceled a release pending product, and promised to
rebuild the product quickly with his oversight. As with any rewrite, the
project dragged on and on. The product ended up delayed for a year and half.
The company bellied up shortly after.

------
rsj_hn
There is people/resource management and there is also technical management,
and most companies really struggle with the latter.

What I mean by technical management is the following:

* onboarding new developers: showing them how to get the dev environment going, how to debug, how to use testing infrastructure, configuration management

* propagating information about design rules: documenting and evangelization of contracts between different different pieces of code, and all the various rules -- what must be authenticated, what must be logged, how to consistently check for access rights, which common module/library to use for what, etc.

* enforcing software development lifecycle: making sure there are design reviews/sign off/etc

It seems that managers offload a lot of the above to senior roles who rely on
force of personality and personal effort to get this done, which creates a lot
of randomness and also stress. Devs often don't learn these things except by
creating breakage and then relying on experience or institutional knowledge.

It's very strange that on the one hand when it comes to corporate policies
such as vacation time and provisioning productivity software, or even using
the bug tracking system, there are handbooks, mandatory trainings, lots of
online resources, etc. But when it comes to the technical rules such as which
library to use, we pass to a medieval guild system of ad hoc 1 on 1 mentoring
over Slack.

But perhaps I've just been working in the wrong companies.

------
shados
Assuming that because someone shipped software that looks good , that they're
good.

Everywhere I worked, there's always one "super star" who keeps getting
promoted for shipping something quick that looks good on the surface, but did
so either by introducing massive amounts of tech debt (beyond what would be
acceptable for an MVP), or by shitting on everyone else (working in a corner,
ignoring any request for help, ignoring their direct reports, or generally at
the cost of all of their other duties).

Makes everyone else look bad and them look good, and generally creates a
pretty toxic atmosphere until management gets it (at which point its usually
too late).

------
matt_s
From the trenches in large corporate (aka 'enterprise') tech departments:

* Technology decisions in large organizations will often not be made based on technical evaluations or merit. Some other arbitrary thing will influence a decision. You will get stuck with technically inferior product and have to deal, some call this job security.

* If you propose something and it gets floated up the management chain, chances are good that management will not "buy in". Not until they hire consultants to come in at $300-500/hr to spend 6 months or more and come back with the same decision. Possibly using a technology the consultants are pimping out, see point above.

* Buying COTS (customizable off the shelf software) with a 20% yearly maintenance/support fee to do basic IT functions is viewed as being cheaper than hiring software developers to build and maintain it. Even when there are open source solutions.

* Maintaining a list of "approved" vendors. This really narrows your possible solution set. When the vendors know this they will keep increasing fees.

* Offshoring work to save money. Many times this is not really done to save a department money. They will use accounting loop holes to track the offshore work as a 'service' and not labor. It will cost your department more in terms of delivery time but they don't care.

* Decision making by committee. Your job is to make decisions and the dysfunction is so bad that people will not work together. Not in a dramatic way, just passive aggressive, ignorance, etc. Every decision takes forever because they have to confer with multiple peers, go through management hierarchy for some, etc.

------
jondubois
\- Not knowing what is important and what is not (micromanaging at the expense
of team happiness and autonomy).

\- Negativity.

\- Not changing their minds often enough.

\- Generalising past negative experiences and applying them to new situations
without properly acknowledging key differences.

\- Not recognising the strengths and weaknesses of individual employees - They
prefer to just throw more engineers at the problem as though they were rocket
fuel.

\- Not letting engineers feel a sense of ownership over a part of the product
that they're building out of fear that they might leave.

\- Not giving raises until it's too late; seriously undervaluing the long-term
acquired knowledge of their engineers.

------
asveikau
Not knowing the difference between "high performer" and social biases. Eg. Is
your top person your top person because they are really doing good work on
their merits, or do you just like them personally and therefore give them
important projects, attention, recognition? Are your lesser favorites the ones
doing real work? If they had equal opportunity, would they outperform the
"top" people? Maybe they are outperforming them already?

------
ratherbefuddled
There are several mistakes that I keep seeing over and over again.

Short term-ism. It seems to stem from the need to report financially on an
annual basis, which means everything gets tied to that - bonuses, sales
discounts, hiring, project deadlines. The reality is that many extremely
worthwhile things take longer to do than whatever time is left in this
financial period and are harmed by trying to shortcut, sometimes irreparably.
Tying everything to an arbitrary accounting period often encourages behaviour
from management that is counter productive in the longer term. Yes a company
has to report, but it doesn't have to treat those end of year numbers like
they are the basis for everything.

Distrust. Often management simply do not trust their employees to know better
than them. I've seen senior management who haven't got their hands dirty for
two decades overruling far more qualified and experienced people on technical
and operational decisions inappropriately with disastrous consequences (e.g. a
new product suite developed over five years for a 9 figure sum arrives on the
market on a legacy platform with far less functionality than what it is
attempting to replace). Usually this stems a senior manager assessing risks
poorly where they are in unfamiliar territory.

Lack of empathy. I've lost count of the number of initiatives and re-
organisations and changes introduced top down style which fail miserably
because there is zero engagement from employees. Usually the management have
simply forgotten to think about what a change means to them and how it will
affect their work. The assumption seems to be if a change makes a business
easier for a manager to manage, it must be the right thing - even if that
makes the people that do the work less effective. Often there's a drive to
make revolutionary changes for the wrong (career enhancing) reasons. Usually
it's better to encourage change to happen organically at all levels of the
organisation and often it's better to evolve. People are people, if you don't
take that into account and empathise you will have a bad time.

------
amrrs
Analytics Team of Captive Organisation (X shared functions) :

* Management (Manager) hardly aligns their goals with the client/partner (X) for whom we support instead they're primarily interested in filling up their Kpis in their ppt for their own organisation (XSF) even when we're fully funded by X.

* New Projects and tasks are kicked off just to make more number of slides in the weekly meeting rather than delivering valuable insight on time that could just go on in an email.

* Employees are just another data point in their Kpi sheet, empathy for wasting employees time and career doesn't seem to exist.

* Fresh grads out of college has been taken into the organisation with no clear idea about how to help them with a successful career and nor this responsibility exists.

------
celim307
Stressing and emphasizing employees to give trust to a company but not giving
any in return.

Loyalty and "Do it for the team" sentiments are commonly paraded, but if you
hide company performance and important developments, you not only have
employees making decisions without context, but also sow seeds of distrust and
signal you don't see your workers as capable minded adults.

------
indigochill
Incomplete targets.

For example, I used to work in a support department where the key metric
agents were graded on was "replies per hour". Naturally favoring this above
everything else led to a couple issues:

1\. Little time spent on reply quality

2\. No care given to handling a ticket after the first reply, because sending
a stock first reply to a ticket is much faster and easier than working through
the individual challenges of each ticket.

Management identified these as problems, but never changed how they graded
staff in performance reviews, so the problems persist. From what I've read of
other companies, this seems the rule rather than the exception.

Everything else I can think of's already been mentioned.

------
tappytapson
Not wanting to take the time to evaluate if the decisions made at the start of
the project are still the right ones. It somehow feels safer to say "we aren't
going to change anything" and keep accelerating toward the cliff.

------
mindcrime
Thinking they can bend reality through sheer force of will (aka managerial
edict), right up until reality smacks them in the face. Example:

M: How long will this take?

D: Three weeks.

M: That's too long, we have to demo at a trade show in two weeks.

D: Fine, we can take out half the features.

M: No, we have to demo in two weeks, with all the features, end of story.

D: It can't be done, end of story.

M: Do it anyway.

D: We can't, what your asking for is literally impossible.

M: Fine, I'll loan you three more developers.

D: No, that won't help. Haven't you read _The Mythical Man Month_ for crying
out loud?

M: Of course it will help, how can it not help?

D: Nine women can't make a baby in one month.

M: That's not really relevant, get all the features done in two weeks.

D: Then why did you bother asking me how long it would take in the first
place?

M: Just do it.

D: ~grumble~ -- storms off in a huff.

...

...

...

...

...

...

2 weeks later.

M: Is it done?

D: No, I told you it wouldn't be done.

M: Oh, OK. Well how long will it take to finish?

D: Another week.

M: OK, fine.

------
Arcanum-XIII
\- Agile/scrum (any methodology in fact) as religion : even if it doesn't fit
the objective, that's the way...

\- not take into account the maintenance // evolving stuff part. The more
legacy and problem you have, the more your ignore the issue.

\- judging performance based on spurious criteria or worse affect

\- micro management

------
r41nbowdash
* firefighting instead of building resilience

* fear of senior devs/architects, not holding them responsible for keeping stuff in order

* playing blame game instead of looking for structural solutions

* information compartmentalization to keep leverage, like we're running a spy cell and not a dev team

------
Karunamon
Managers making tech decisions without the input of the people who work with
systems every day who are in the best position to determine whether that's a
good decision or not.

True story:

A deployment of a distributed application at $dayjob a long while ago had
"must have RAID6 or equivalent fault tolerance" added to its project
requirements by clueless managers. The engineer who specced out the system,
who was responsible for its POC, and had spent many, many hours setting up the
environment and tweaking it for performance protested, since the application
had fault tolerance built in. The idea being that if a node loses a hard
drive, we don't care. We just throw a spare drive (that's kept in stock) in,
rebuild the node (a literal 10 minute process), and no data is lost.

Protests, backed up with data, that long RAID6 rebuild times on TB+ drives
_increased_ the likelihood of data loss (a restripe takes longer than our
average rebuild-the-damn-machine-from-scratch time and leaves the cluster
degraded longer) went ignored.

The RAID6 requirement added about 50% to the cost of the project, and ended up
having to be thrown out around ~6 month mark since the cluster write
performance was unable to keep up with the RAID0 that the engineer had
originally specced out. We now use the engineer's original idea, even though
he long since moved somewhere where presumably, his experience is trusted
rather than insulted. This incident was a contributor to his decision to
leave.

To this day, RAID6 is an inside reference to management cluelessly screwing up
a project against the wishes of people who know better.

------
FractalNerve
Mistakes by Management:

* Accept that the Internal IT sabotages External IT (using politics/compliance/HR).

Background:

Interesting projects are often handed to external IT, while the internal IT is
perfectly capable to implement most or parts of it, they're held back from the
project by the management. However internal IT is very often the only rep the
external IT can talk to. Management never allows true of co-operation of
internal and external IT to restrict costs and to 'benchmark' the internal IT.

Real Story:

1) I'm the "external IT" and the internal IT together with their project-
manager (senior enterprise architect) block all my communication to the client
and want to be aware of everything beforehand.

2) They're unhappy with my progress, but blocked my selection of a cloud-
computing instance via HR.

3) Just got access to their lowest tier EC2-instance via a ridiculously
complicated connection processs.

4) I'm not error free, but my consultant manager is on the customer's side, by
principle.

5) The data I received is a very small and useless fraction that can barely be
used for machine learning (at least with my limited skills).

6) I'm so frustrated and work remotely, away from both offices I've to report
to.

7) I see me failing in this settings and I'm afraid of that. I don't know what
to do.

~~~
kuriho
Internal IT here. Points 1-3 are all very understandable from a customers
point of view and do not strike me as sabotaging. Your other points are not
relevant.

------
mbesto
I believe that nearly all mistakes that management make are largely due to
empathy. I think this is effectively why we've seen so many large, uber
successful, companies being started by people with comp sci/software
backgrounds. Worth noting - conversely, it doesn't mean that all comp
sci/software people have the ability/capability to lead technology teams.

~~~
jcrben
Too much or too little empathy?

~~~
mbesto
Too little. Sorry should have clarified that.

------
adeel_siddiqui
Would just like to add one in addition to the points already made in the
comments: Offering you a significant raise, a different and more interesting
project/location, when you have put in your papers. Asking you to rethink your
decision of quitting.

Seems like I didn't exist for the manager until I put my resignation.

------
newscracker
Putting their own compensation and bonuses way above what decent people would
do for employees. Their short-sightedness and selfish thinking does a lot of
harm to thousands of people in every organization. Why am I calling these as
mistakes and not just brushing these off as "it's a capitalistic system, just
live with it"? I do so because good management that doesn't do all this keeps
many more people happier than bad management. But this is the norm, and
management that doesn't do this is a rare animal.

What's the point of making profits and more money if we can't increase
happiness levels among more people, especially the ones who work on building
the stuff that makes the money in the first place?

P.S.: My point is concise and can be counter argued in many ways. This is what
I wanted to say without writing a whole book.

------
pjbster
Sticking around and believing that they're essential.

When organisations are formed of people with perfectly aligned incentives,
they don't need to be managed. Such people know what needs to be done and have
the expertise and autonomy to make it happen.

Of course, such an organisation is hopelessly unlikely to retain this utopian
state as the number of employees rises above 2. And it becomes vanishingly
improbable if outside funding is involved.

So management is the act of taking care of something which can't take care of
itself. A symptom: like an antibody, it arises when a system gets of out whack
and its continued presence indicates a chronic condition.

The best thing management can do is to put systems in place to make itself
redundant. So, by this definition, anything it does which promotes the
opposite goal is a mistake.

------
dbattaglia
1\. Focused on project management/process (agile) while remaining clueless
about actual software development.

2\. Obsession with development costs being a capital expenditure (CAPX). All
code must be new features.

3\. Project deadlines created by management and sales only, always aligned
with a fiscal quarter.

4\. Projects, not Products.

------
super-serial
Not doing their job - as in not getting requirements and understanding
workflows of clients, then having me directly answer calls from these clients.

I'm not particularly fond of the phrase "no one told me it needs to work like
that" but I must have said that at least 10 times this year.

------
altitudinous
The same ones. For many years. I don't dwell on them because people generally
don't learn from other peoples mistakes, they have to make those mistakes
themselves. There have been businesses and business management for many
thousands of years. If people learned from other peoples mistakes we would
have business perfected by now. Instead we are constantly starting over making
those same mistakes. I left the rat race many years ago to run my own business
which has been successful; for variety I am looking at returning to the
corporate world, I know exactly what to expect because it doesn't change.

~~~
tajen
You may be a "zebra" = Belonging to 1% top IQ but not succeeding to
communicate with people who don't notice patterns and second degree concepts
that are obvious to you. There are help groups, although they won't help you
with the groupthink.

------
lobotryas
Treating different departments differently in a company. In my experience the
sales and marketing teams get the new toys, shiny offices, and budget for fun.
Tech teams (this includes eng, ops, it, etc) get whatever's left.

------
curun1r
My list:

1) Re-orgs upon re-orgs believing they'll fix underlying problems

2) Related to 1), lack of accountability when it comes to decision making,
like when no one is accountable for the previous, failed re-org when deciding
to re-org again.

3) Spending way too much time trying to make perfect decisions, especially
around product vision. Much better to decide quickly, be flexible going
forward and iterate.

4) Providing perverse incentives. As an example, one place I managed didn't
give lower-level managers a budget, only a headcount. So, of course, everyone
hired only senior and above developers. This created logjams during promotion
time and forced a lot of turnover which could have been avoided with a more
balanced hiring plan that included more junior devs.

5) Seagull management, especially from the C-level. For those not familiar,
it's swoop in, shit all over everything and then leave others to deal with the
mess. Either provide minor course corrections or devote a significant portion
of your attention to that area until it's stable.

6) Being too good of a motivator. This doesn't sound like it should be a
problem, but I had one manager who was so good at selling shitty ideas to the
team that we kept working on the wrong vision. A good vision should largely
sell itself.

7) Not caring enough about their employees as people. When the difficult
conversations need to be had, it's a lot easier to deal with it if there's an
underlying relationship where the employees feel appreciated and considered.
It doesn't mean you have to be their friend, just that they believe you care
about them. The easiest way to make them believe that is to actually care
about them.

8) Not devoting enough time and energy to hiring. This was my secret as a
manager. I put a lot of time into recruiting (lots of after-hours meet-ups and
mixers) and was picky with who I hired, built a great team, worked to keep
them happy and focused and then spent 3 years getting awesome reviews for
doing basically nothing but shielding them from unnecessary distractions.

9) Rewarding busy over good. Who deserves most organizational praise, the
employee who valiantly wrestled with a production issue until 4am or the
employee who pushed a non-event release to production and went home at 4pm?
I'm amazed at how often managers recognize and reward the former when the
latter is giving customers a better experience.

I could probably come up with another 20 or so, but these are the ones that
have cropped up the most in my experience.

------
j45
Hiring non technical people for roles that are becoming increasingly more
technical.

Many fields such as hr, payroll, etc have become far more technical in the
implementation and use of system.

Management isn't realizing how much how quickly their business is changing and
the impacts to their business.

Sometimes I wonder if perceived non-tech roles need to introduce an excel
competency test not to measure excel talent, but the ability to work with data
and details at a baseline level for the organization, or become the weak link.

If you can't work with the details of a business in a basic sense....

------
lhnz

      * Micromanagement of skilled people.
      * Over-investing when things have gone badly
        wrong, and being sluggish to invest in a team
        which is having success.
      * Hiring unskilled engineers to develop features
        which are meant to be reused by other teams.
        Bad or complex architecture leads to lots of
        workarounds and bugs, which destroy efficiency
        in other teams.
      * Not investing in fixing inefficiencies, instead
        just asking people to work longer hours.

------
agentultra
One of my favourite books on management is _Extreme Ownership_. The classic
mistakes I've seen made are: _bypassing the chain of command_ and _forgetting
the mission_.

There's a process by which my team accepts change requests, error reports, and
feature requests from stakeholders. We plan our development in cycles and I
co-ordinate efforts between teams so that people aren't getting blocked or
stuck. The mistake here is when stakeholders bypass the chain of command and
directly assign tasks to people on my team without telling me.

They don't realize the impact this has on productivity, momentum, and due
dates. Not to mention morale! My developers don't like it when they have the
next couple of days planned out for themselves and someone comes over and
interrupts them to work on some non-related, trivial issue. They feel like
they have no ownership or autonomy.

This all segues into _forgetting the mission_. A group of people need a clear
mission in order to prioritize and co-ordinate work. Often times management
will forget what the mission is and prioritize a customer's change request and
delay important projects in order to meet their goals of keeping the customers
happy. Sometimes you have to remember to say _no_ when doing the opposite
harms the mission.

------
acobster
I work for an agency. The one I see most often is promising a specific
deadline and/or budget at the beginning of the project, before we even know
what the MVP is.

------
andersthue
All these :
[http://www.paulgraham.com/makersschedule.html](http://www.paulgraham.com/makersschedule.html)

------
pipipzz
I have worked as an Android developer for 2 years at a startup and the worst
thing is the micro-managing part. Companies take so many tests for developers
and hire project managers or product managers who don't know shit about tech
or how anything works. All they know is to ask "When will it be done?" and
don't care about the complexity of the implementation or the time taken to do
something the right way , an optimised solution. Another issue is releasing
app/software without thorough testing and then blaming the developers for any
bugs and crashes. Third and very important aspect is the "Why?". Nobody cares
to explain why we are doing things certain way, why are we changing the
designs, why are we moving the button, etc. Developers are not robots whom you
can give any task and expect them to complete it in a ziffy. Developers want
to understand the reason behind the changes, the results of these changes so
that they know they are doing something worth the time and effort.

------
bradgnar
Everything I can't stand about management revolves around agile methodologies
for profit. Agile itself is a good thing, but once you throw in companies
trying to profit off of its processes you end up with this weird dogmatic
dumpster fire that inhibits people from really doing anything besides keeping
track of the current sprint or planning for the next sprint.

------
flukus
There is no such thing as "done" software. Everything program that is written
must be maintained but PHB's never even consider maintenance costs.

Consequently, there is no such thing as a "build" and "maintain" phase of
software. Something that takes 10 developers to build will take 10 developers
to maintain.

------
beaker52
The manager of my current team came up with some complex way of solving a
problem that we're facing as a business. He implemented a proof of concept and
showed the business without involving anyone else in the dev team at all. Now
the business wants to roll with this "solution" to a key part of our software
we've been desperate to refactor with foresight of incoming requirements.
Instead we're ploughing forward, saving refactoring for later to implement
this proof of concept. No design work is to be done - only implementation
because we're on a tight fictional deadline. He's throwing more developers on
it to "help" and even micromanaging the implementation.

The same manager expressed displeasure that he wasn't involved in discussions
with the business about a new project that rose whilst he was away on holiday.

Follow this guide at your peril.

------
astonex
* Everything must be done urgently and asap.

* Moving developers on and off of projects in the middle of development.

* Not listening to the lead developers' time estimates

* Focusing on the quickest possible development time instead of quality (and then complaining about going over-budget when bug fixing takes way too long).

* Worrying more about for how long you're sat in your seat rather than the quality of your work.

* Doesn't reward exceptional work.

* Gives developers work that they're not skilled in without adjusting the time estimates

* All 7 hours of the day must be billable time spent coding.

* Constantly wants to change what technologies are used for projects

* Over complicates tasks and/or tries to add their own 'good ideas' which are actually a nightmare to do.

This is my current boss. My stress levels are off the charts. Fortunately I've
found work elsewhere and will be leaving soon.

------
daxfohl
Not enough one-on-one time with the coders. As a coder, it's very easy in a
stand-up for any coder to say "yeah yeah yeah, I've got this covered". Then a
week before release everyone realizes that person has a month's worth of work
ahead of them. I've been all three: the "yeah yeah" guy, the manager, and one
of the other coders that has to take the slack. It's a situation that seems
easily avoidable just by a little better teamwork. Oftentimes "yeah yeah" can
just mean "I have no idea what I'm doing", but dev2 (or mgr) could do and
teach that task in half an hour, but dev1 just doesn't know who to ask.

------
tnolet
* mistaking agile for not having to make up their minds what they want.

* thinking projects can be planned back-to-back with no rework, maintenance, slack or anything calculated in.

* mistaking the end of a development cycle with the actual release moment. Last code commited == app is live.

------
mikekchar
Believing that they are too important to remove impediments from people doing
the actual work.

------
bsvalley
I honestly think that being a manager 1st layer is the least enjoyable job in
a tech company. So I wouldn't blame them too much since they're already
dealing with a bunch of problems:

* Managers are easily replaceable because they don't have any expertise but people skills. My grandma has those skills, could she take on a manager role? Of course.

* You often get promoted internally to manager. So it's hard for you to move horizontally between different companies since they don't know you. You need to prove yourself again. Plus there is 1 manager job out there versus 10000 dev jobs.

* You get away from coding, far away from product then have to deal with expenses, HR issues, infinite meetings, etc.

------
ricokatayama
One simple and subtle thing: not being empathetic.

There are a lot of process problems, a lot of productivity issues and lack of
strategy, but the cold relationship kills the team's vibrancy and drains the
energy, preventing people to do more in a better way.

------
rad_dev
There are some amazing responses here.

My number one pick is always finding the next new thing in management from a
New York Times bestseller. Then sending an email on the greatness of the
process to the whole team and lo-behold expecting everyone to embrace it.

2nd for me is getting stuck on project names. It seems finding a cool sounding
name is somehow more necessary than how it works.

To quote an example, we were using the waterfall model for our development.
Then somewhere management read about "Rapid Application Development or RAD"
and we embrace it ASAP. But not before dissing that RAD was not the word they
wanted because rad the word had negative connotation to it so we needed a new
name.

~~~
gkop
What negative connotation?

~~~
falsedan
It's SoCal surfer/skater slang, which sounds unprofessional in a formal
business environment. So, stuffiness.

------
j45
Management who incorrectly see IT as a cost center cause a lot of problems.

Every business is becoming or is a software business in that software of one
kind or another is increasingly tracking the details, data and processes of
the business.

Failing to realize this shift, technology is not utilized as an enhancement
and leverage tool for competitive advantage, instead their competitors do.

Business technologists who both understand business and can solve problems
with tech will likely become a new class of business professionals like
accountants.

That, or technologists will inherit the jobs of hr, accountants because the
existing folks are not able to keep up and innovate constantly.

------
haddr
Some very important mistakes are made by management that is non-technical, and
too much management-oriented. I'll explain with the following list:

* creating extra administrative burden around daily things, and trying to commit devs to that

* favour management roles over engineer roles

* ...thus effectively limit technical career: higher positions are non-technical and managerial only

* create two "islands": management and technical, with limited interactions

* treat engineers as easily replaceable parts, keep one or two experienced ones (for extinguishing fires) and forget the rest.

------
0x4f3759df
Assuming that saying 'Do X' is really 'Do X'. Truth is I have to fix 10 bugs
before I can even set up a test case for 'X'...

Also just the general cluelessness of the state of the software.

Managers need to convince the higher-ups that the software is in good shape
(because their job is on the line), meanwhile the devs know its got 1000 bugs
in the ticket list plus 3000 bugs that didn't make it to the list.

Failure to explain management objectives. 'We promised company X feature Y in
Z days'

------
jaggederest
Sort of a meta-statement, but an inability to learn from past mistakes.

You can't just throw water on the fire until it's out and then go "Whew, isn't
fire bad?" and leave.

------
simonhughes22
They don't make decisions based on data, despite believing themselves to be a
data driven company. All decisions flow from the top, and are ego-based, not
data driven.

------
LoSboccacc
not sharing company goals with engineering - engineers have to second guess
whether it's the moment for building or polishing, for adding new features or
for consolidating before a big push etc.

this cause a wealth of secondary problems like deadline that seem arbitrary,
focus on random features that need to be rushed every stint without logic or
order, developer burnout and the need for ever-increasing micromanaging.

------
gsylvie
Becoming managers to sooth their self-esteem issues.

I don't mean this as a cynical joke at all. In my experience too few managers
see the job as a job, and instead they see it as a power and status boost ---
a way to be "winning" in the game of life.

It should be a calling. It should be the thing you were put on this earth to
do.

Of dozens of managers I've encountered, I've only met 1 or 2 where it seemed
to be their calling.

------
cel1ne
A book recommendation: [https://www.amazon.de/Heretics-Guide-Best-Practices-
Organisa...](https://www.amazon.de/Heretics-Guide-Best-Practices-
Organisations-
ebook/dp/B00D5S7C5K/ref=sr_1_1/257-6578943-3771904?ie=UTF8&qid=1502959460&sr=8-1&keywords=heretics+guide+to+best+practices)

------
martijn_himself
Management have the misguided notion that if you adopt the Agile methodology
(TM) you will deliver successful software projects.

Loads of people uninterested in software engineering and technology follow
agile training and the end result is loads of pictures of walls covered in
Post-it notes, disgruntled developers and no working software or product to
show for it.

------
johngalt
Failure to focus on the logistics surrounding the team, while relentlessly
pushing out carrots and sticks for more productivity.

If you have the right skills, training, tools, and processes; things get done
well. When there are gaps in these areas, no amount of discipline or
incentives will make up for it. Don't make the cheese bigger, make the maze
smaller.

------
thinkMOAR
Dont lie. In any way. Nothing is more upsetting then (the longer the worse)
your manager/boss who has been lying to you.

------
p0nce
Complexte denial of technical debt, to the point of making products irrelevant
and any kind of market fit impossible.

------
INTPenis
* Not including the right technical resource when interviewing new hires.

* Failing to identify when they need and don't need micromanagement.

* Basic PM tasks like meeting protocols and case management.

* Not listening to technical resources to recommendations on scaling.

* Penny pinching when dealing with redundancy and scaling.

* Not communicating with their team.

* Not being honest when failing.

------
Parmegeddon
This guy’s having the worst luck ever…

[https://www.youtube.com/watch?v=0sW8HGonB8o](https://www.youtube.com/watch?v=0sW8HGonB8o)

[https://www.youtube.com/watch?v=S4s6faeBSGk](https://www.youtube.com/watch?v=S4s6faeBSGk)

------
k2xl
I wrote a post with some lessons I've learned (from mistakes I've made) on
management

[https://medium.com/@k2xl.com/leadership-
meditations-d29868a8...](https://medium.com/@k2xl.com/leadership-
meditations-d29868a899a3)

------
gavingmiller
Not training managers on how to manage.

When devs are promoted into management or team lead positions they are not
given adequate training on what it means to manage / lead. Thus devs don't
learn what good management is, and the stereotype of the bad manager
perpetuates.

------
icco
\- Acting like 1:1s and performance reviews aren't the most important aspect
of your job by putting them off, ignoring them or saying you dislike them to
your reports

\- I'll repeat: "misusing agile in order to micromanage"

\- Requiring all decisions to be signed off on

------
amaiti504
1) Underestimating the complexity of the problem

2) Closing down a project as soon as the o/p pops out without thinking about
scalability

3) Lack of courage to say 'NO' to the client

4) Highly optimistic deadline

5) Daily meetings to ask how much work has been completed. Give me a
percentage.

------
charlieo88
* Multiple items on the priority list that are priority #1.

* Micromanaging, always the micromanaging.

------
monodeldiablo
Massive problem in tech: Valuing easily-quantifiable metrics for productivity
over "softer" forms of productivity. Current tech culture reminds me of a
random idiot who makes claims like "Xavi wasn't much of a midfielder because
he rarely scored goals".

On one small project I was on (6 person team), we had a guy -- we'll call him
Carl -- who was right at the bottom of the pile of commits. I mean, maybe
20-30 over the course of a 6 month project. From an earlier collaboration, I
happened to know that he was a very good programmer, but he wrote practically
zero code for this project. And Carl wasn't that popular with our bull-in-a-
china-shop director, who claimed that Carl was dead weight slowing our fast-
paced team down. He constantly asked the rest of us what Carl was
"contributing".

So, after months of pressure, Carl "left" for a separate team as the project
wound down, in spite of our vociferous appeals to management to keep him on.
He quit a few months later.

Why were we so desperate to keep him?

Because Carl was the glue that kept the group working so productively. He
managed the egos, kept focus on the goal, and fostered respect for everybody
on the team. He intervened during technical and interpersonal disputes. He was
calm and quiet and rational. During design discussions, when the more
outspoken members of the team were trying to ram through their visions of the
world (guilty!), he would bring brilliantly insightful and cogent questions
about the long-term and medium-term ramifications of said designs. He was an
unofficial liaison to our internal customers. He volunteered to break bad news
to management when there was a delay, but deferred to other members of the
team when it came time to claim credit for our progress.

Carl was, in short, our unofficial PM, and a damn good one. He realized that
his social skills were more valuable to the team than his technical skills.
But his contributions weren't valued by management because they weren't as
visible as our commits. Our team fell apart in a matter of months after he
left, as we quickly became overwhelmed by all the stupid shit -- and toxic
politics -- he had deftly absorbed and deflected. We wasted two of those last
months working on a feature that he had opposed, only for none of our clients
to use that feature upon release. Just as he had predicted.

In general, all the things he brought to the table -- humility, empathy,
patience, foresight, listening, respect, selflessness -- are the sorts of pro-
social traits that tech companies (and especially SV tech companies)
aggressively select _against_ , in spite of the fact that they are precisely
the kinds of traits that lead, in my experience, to far greater productivity.

The current culture is borderline toxic. In all the talk of "10x" programmers,
people seem eager to overlook that a 1x programmer might have a 10x positive
impact on their team in other ways.

------
lifeisstillgood
Failing to "build great things really well". Even a boring accounts system
that has good scaffolding like build and test rigs can be a joy to work on.

Just keep building great stuff really well.

------
callesgg
Continuing to use methods and behavior that has never worked efficiently
before and expecting changes in details to have large improvements in
efficiency.

Not looking for root causes for issues.

------
viach
I think there is inverse proportionality of development speed vs code quality
+ maintainance cost which management does not take into a count, ever, no
matter what.

------
adamb_
Not thinking about team morale until it becomes a issue. Negative mindsets can
spread through a team quickly, and once they take hold they can be hard to
root out.

------
pleasecalllater
No mistakes. "We don't do any mistakes, if you are not happy here, you can
leave". All other mistakes are usually caused by this one.

------
juliansamarjiev
Leaders need to learn to give freedom to people and create responsible leaders
that can operate on their own. Not give orders to followers.

------
SirLJ
Outsourcing (and loosing the knowledge), almost always ends up more expensive
in the end, compared to in house teams...

------
timwaagh
i don't think they make too many mistakes. from their perspective its about
minimizing cost and maximising earnings and i think they do this reasonably
well. some managers can get a bit fanatical about this, which can shoot them
in the foot sometimes but that is not the case at any company i worked for.

~~~
gaius
_don 't think they make too many mistakes_

Nailed it. Customers, employees and shareholders may be unhappy but managers
are always happy...

------
mk89
Lack of listening (I am not talking about "hearing" here!). Like most of the
problems in this world.

------
Newtopian
That reading ".NET programming for dummies" to the last page makes him/her an
expert programmer

------
youdontknowtho
"It's not about technology"...and then racks up technical debt that has to
continually be paid.

------
freebs
Instead of posting these here where they will sink into a black hole, leave
them on mplyees.com.

------
losteverything
Not terminating non performers

Not forcing coasters to retire to make room for rising (or risen) stars

------
LeicaLatte
Management, like most people, is bad at saying no. It takes practice to do it
well.

------
kovek
What core principles or values does or would good management abide to?

------
scandox
Sticking with bad ideas too long and abandoning good ideas too soon.

------
carc1n0gen
Rushing new features before we finish fixing existing ones

------
Aaargh20318
Not understanding your own product.

------
andreasgonewild
Using other human beings as tools.

------
loco5niner
Moving to an open office plan.

------
oleg123
just read the basic findings W. Edwards Deming. Same mistakes he talks about.

------
arca_vorago
#1: Management cutting corners in the budget in areas that need the money, but
keeping the money flowing in areas that don't. For example, I was a one-man-
miracle show brought in to do an infrastructure upgrade for a company drowning
in technical debt. I managed to impliment what would have been a $45-70k$
system for ~$19k, at the core node level, but when requesting a ~$8k
horizontal cabling job to be done by a contractor, all I got was "no, it's not
gonna happen". Which brings me to...

#2: Not putting more effort into communication and discovering needs of
departments they have been unable to communicate properly to get approved. I'm
a senior sysadmin (taking a break and transitioning to data science), but for
a long time all I wanted to do was be in the datacenter with my head in a
terminal and doing good work. In retrospect since my break, I have realized
that as a senior that's not my role anymore except in case of escalation no
one else can solve. I was not playing the board-room politics game to get what
my department needed, and that was a failure on my part. Generally, I am now
calling for high investment in the CTO/CIO position because they should be the
people who can talk to the technical people who don't need to spend all day in
a meeting room, and spend all day in the meeting room advocating for them and
the things they and the department need. Execs like to stay on their pedestal
and force others to rise to their level, but they need to spend at least some
effort on actually listening to the middle-men and "going down to their level"
so to speak.

I don't care what industry you are in, those two things alone would vastly
improve the workplace for workers of all types (not just IT) and business in
general. Those two misteps, particularly combined with lackluster reward
systems (once spent a year working overtime-exempt salary hoping for a raise,
and instead, after having spent the overtime while salary fixing up a place,
got shifted to hourly once I was no longer working late and on weekends,) are
recipes for hemoragging good talent. Good talent might temporarily forget how
good they are, are be stuck for some other reason, but it's only a matter of
time before they drop your company like hotcakes and move on. Pay them fairly,
and as far as retention goes, real, substantial bonuses can make all the
difference.

Never forget, that regardless of industry, your internal IT team is much more
critical and important than you can imagine, and ignoring IT as your bastard-
child _will_ come back and bite you in the ass. Removing technical debt should
be a #1 priority.

It's one reason I am so thankful for being a senior sysadmin for so long. As a
senior, since we touch so much of a company, I got to see the internal non-it
mechanisms of so many companies I think I have gained a level of macro-
business insight not many have.

[https://youtu.be/2e9xTsOoqmw?t=1116](https://youtu.be/2e9xTsOoqmw?t=1116)

------
Boothroid
* Zero career direction and zero technical speciality for devs

* Underestimation of difficulty whether through cynicism (burn the devs) or cluelessness

* Inadequate training and expectation devs can just piggy back learning technology x from scratch whilst writing production software using it

* Trying to use one off contracts as a way of building resellable products

* Insistence that all devs time must be billable and trying to defy gravity in ignoring skills rot etc. through lack of investment in training

* Expectation that devs can be swapped between technologies without problems

* Swapping people in and out of projects as if this will not affect progress

* Deliberate hoarding of information as a means of disempowering devs

All of this inevitably leads to a bunch of pissed off devs. The ones that are
happy to eat it become the golden boys and get promotions. Those that point
out the bullshit leave once they can and are replaced with the desperate at
the bottom who sooner or later arrive at the same position of wanting to leave
once they realise what's going on. I think tech can be pretty miserable if you
are not in the upper echelon of lucky types that can score a position at a
Google, Facebook etc.

Oh and a couple more:

* Give no feedback unless things go wrong

* Treat your highly educated, intelligent and motivated devs like children by misusing agile in order to micromanage them

~~~
pestkranker
> * Trying to use one off contracts as a way of building resellable products

Can you tell me why? Sometimes, asking a client for 50k instead of 80k with a
"spin-off" agreement can pay to both parties. The client can get long-term
support with new features without the need to pay for it.

~~~
Angostura
This was the one that really struck a chord with me. You start of trying to
take the product you created for one specific client and then generalising it.

You end up, in practice creating a individual bloody application for each
client.

(Not a coder, more a manager who created specs and tried to shield the coders
from the worst of the shit-storm).

~~~
pestkranker
It is not individual applications. It is SAAS.

