
Ask HN: Do Software Engineers Need Managers? - zpatel
I have experienced and heard from a friend who also worked in a large company that many of the managers or project managers did not add any significant value (except in startups).<p>So my question is whether the Software Engineers (especially the senior one&#x27;s) really need managers? I have been thinking about this and planning to work on a POC of a tool (may be based on blockchain like model) that would reduce or eliminate non-coder managers. While this would be my wish, am I thinking totally out of the line or too creatively :) ?
======
matt_s
It is hard for software engineers to see the value added of a good manager.
Often a manager will have deep knowledge of the software being built, current
priorities, and will know (from their team) where 'thar be dragons' in the
code.

When I was an engineering manager at a large corporation, most of my time was
spent in meetings about status, resources, future projects, finances, cyclical
HR things, escalations with other teams, etc. Then the other half of the role
is gathering information from the team about how things are going (PM's would
be the task master) and finding out where there were problems either with
technology (rare) or other teams (often).

These things cannot be scripted away - they all involve talking with other
humans.

~~~
zpatel
Agree with you on the value of good manager, however concern is around bad or
inexperienced managers which are out there by plenty. Typically the manager
becomes a dumping ground for things which should be done by Business/IT
Analyst, Product manager, Project Manager and Technical Operations/Support
Manager. Once these are addressed properly then what you have got is
essentially a Sr Engineer/Tech lead who is entrenched in the code and also
knows who is best for the right task with in the team. Some of the other
things like larger roadmap and talking to HR can be done by director or Senior
managers, so yes I do see some need for managers, my whole point is that there
is no need for Junior or Mid level managers for most cases.

Also creating a per team manager role creates more politics and overall bad
working environment for good Engineers. I would not have argued this 10 yrs
back, but considering the advancements in tools, processes and changes in work
culture and attitudes, don't you think its viable to have a great degree of
tooling for atleast the first level managers?

~~~
matt_s
Ideally one would hire self sufficient engineers that don’t cause drama which
causes political battles.

A small organization doesn’t need much management, but the larger corporate
environment has middle management - managers of managers. This layer is really
only there because of numbers. If you have 7 managers with 8 engineers each,
one director isn’t going to be able to make big picture decisions for 7 teams,
let alone get thru HR reviews for 56 people, salary planning, etc.

What about mediocre and bad engineers? If there are a few and there is a
system, they will find a way to meet basic criteria in the tool/system. You’ve
heard jokes about teams that measure lines of code, and suddenly people are
pumping out lines of code.

When you get a group of 20 or more people together they are going to disagree
and some will outright dislike each other. These are the roots of political
battles in an org, which beyond small teams, can’t be avoided.

~~~
zpatel
Yes, Sr. Management & Directors add values. Most first level managers are not
effective in resolving disputes between Engineers, but rather just take sides
with say one of their top coder, although the opinion of that engineer on say
an architecture approach may be not be the right way to go..think you get the
idea ? There may be many such scenarios or just lack of maturity or decades of
management experience that makes such managers ineffective at resolving
conflicts, and hence my point is that they are not required to manage Sr.
Engineers with 10-15 yrs experience.

------
bsvalley
How would blockchain help in this case? Not sure I get the idea... Blockchain
within an organization doesn't make any sense. I've had different managers and
they were horrible or useless for the most part. Usually in big corporates
they're useless and in startups they're too cocky and bad team players.
Though, there are good managers out there but it's pretty rare.

You need a manager to resolve conflicts between peers, to hire/fire people and
to report to upper level. That alone takes a lot of pressure off a team...
I've had experiences on both sides, management and individual contributor.
Being a manager is pretty stressful for these 3 reasons. Other than that, it
either falls into micro management or into a tech lead role. As soon as a
manager starts getting involved in technical decision it usually goes against
the tech lead of the team or architect. If a manager asks for status updates
constantly it's pure micro management and against the Project Manager.

In other words, conflicts between peers, firing/hiring people and giving
status updates on all the major issues is something that is hard to automate.
We do need managers, but we need them to stick to these 3 things and that's
it.

~~~
git-pull
I glanced over, I didn't see the blockchain part.

But my point is that stuff like Aha, at a smaller startup, can articulate
business goals / customer stuff to individual issues on Github/Pivotal
Tracker. That in itself is a software solution that supervises itself.

Not every startup fits that. But I think if they were open to it they'd like
it. There is a downside though, it's 74/mo _per user._ Ugh. That cost.

[https://www.aha.io/product/pricing](https://www.aha.io/product/pricing)

But agreed on blockchain in itself not making much sense in this case. The
_only_ times I've seen it intertwined with issues was with open source,
cryptocurrency places like Gitcoin.

> Other than that, it either falls into micro management or into a tech lead
> role. As soon as a manager starts getting involved in technical decision it
> usually goes against the tech lead of the team or architect. If a manager
> asks for status updates constantly it's pure micro management and against
> the Project Manager.

You articulated this a lot better than I could. This is where I've seen
manager's occasionally can harm more than they help.

------
kwillets
I just quit a job where I dealt with both self-managed and micromanaged roles,
and I was much more productive (and better rewarded) in the self-managed one.
I found I'm better at managing lateral relationships, eg data-scientist to
data infra, or data infra to devOps, than being micromanaged on a ticket
queue. I was surprised that I enjoyed fairly mundane backup or recovery tasks,
because I could see user impact directly.

The micromanaged situation had strange priorities as well; the overhead of
trying to figure out why we were doing so much stupid stuff just added to the
frustration.

~~~
zpatel
My main goal is to drive more ownership towards Sr. Engineers so that they
deal with a "VirtualManager" tool for micromanagement and some guidance for
issue resolution etc, and only as needed with Director or Sr. Manager (for
guidance or difficult conflict resolutions).. So the Sr.Engineer gets to be
more entrepreneurial (in some way).

------
zer00eyz
It depends on your engineers really.

If you have great team, who enjoys, uses or deeply understand the product and
VALUES their craft then no you do not. However you have to empower this team
with a larger degree of control than most organizations are willing to give.
Product people need to come with goals, not products and hash out a way to get
there with the engineers... Just because a product person wants to build "X"
doesn't mean it is going meet the goal in the most cost effective way, and a
good engineer might suggest something else to get to the goal that saves time
and effort when it comes to building and running whatever the feature is that
is being suggested.

------
tboyd47
In order to be effective, yes, they do.

If developers are left to work on whatever they want, they end up creating
projects that either have no value to their parent company or have value but
don't get sold to anybody. Developers need managers to redirect their efforts
in the most profitable direction. The main issue is that _bad_ managers have a
strong negative impact and most managers on software projects are bad.

If you truly believe that managers provide no value, then wouldn't a manager
replacement tool also provide no value?

~~~
zpatel
So there would still be Directors and Sr. Managers who would outline their
vision for the product/teams, which would be further mapped to UseCase
scenarios or feature Stories by Product managers.

"The main issue is that bad managers have a strong negative impact and most
managers on software projects are bad."

>> precisely this is the main motivation of my Ask, to see that if tooling
could reduce (if not eliminate) bad team managers..so basically only Tech lead
or Sr.Engineers (who code up to a verifiable percent) would be part of the
Engineering team which in turn would be managed by an intelligent
"VirtualTeamManager" tool and this tool would be tuned with inputs from
Sr.Manager and Director (of that team).

Let me know your thoughts further..

~~~
tboyd47
What do you think a tool would be better at doing than a person?

~~~
zpatel
This tool would not intentionally play politics or not be improved in short
time (like bad behavior or ineffective manager) , and so the employees would
trust it more than a bad manager.

Think of it like an "AI Manager", the tool could learn from various scenarios
or data points across teams and bring some sort of management consistency.

------
hiaux0
(I have no experience working in Software)

There is always the need of someone who has the bigger picture in mind. Task
distribution.

And for the "large company" part. I assume that most large companies are still
operating in and old-fashioned way of working.

~~~
zpatel
Indeed, there needs to be folks (director and Sr.Mgrs) who look at big picture
but my focus is more on the low/middle managers or even PMs. Regarding low
level tasks the Sr. engineers can self create these tasks i believe for the
goals they need to be targeting.

And yes, you are right in that the big companies are operating in the old
fashion way and i was thinking of a implementing a tool that would disrupt
that in some ways..:)

~~~
hiaux0
The practices indeed need a major revamp! Good luck with that my friend

------
smt88
Yes.

Managers are useful for decreasing the non-programming brain cycles that devs
are spending every day.

Managers can re-prioritize based on feedback from marketing/sales/CEO, wrangle
issue trackers, make sure devs are happy with what they're working on, screen
new hires, talk to customers, and lots of other non-programming things that a
software team must do.

A great manager clears away the "boring" or tedious obstacles that get between
great devs and the next iteration of the product. They also set the tone for
the team, motivate individual members, and keep things organized.

~~~
zpatel
Wonderful summary of a great manager (hopefully you are not a manager:) .. In
practice, what % of managers would fit the bill as you described (esp. in
larger firms) ?

~~~
smt88
I have no experience at large firms. At startups, I meet them often. But I
also only choose to work with startups with good, employee-supporting
philosophies, so I can't say how common they are.

------
muzani
A manager's role is three parts: information routing, training, resource
management.

A manager collects information from a team and abstracts it to upper
management. Upper management can then use this info to understand what the
organization is capable of.

It's also the manager's job to understand where the company is going, what the
strategy is, and communicate this effectively to the grunts.

They also relay and filter out information between departments. They help
engineers understand what sales (and clients) want, and sales to understand
what the product is capable of.

They suss out flaws, normally with people. Sometimes engineers might not be
willing to voice out concerns.

The engineers might also want more resources, whether it's an outside service,
hardware, more manpower. The manager looks at this from a higher level and
finds the best solution. They appeal for budget increases and extend
deadlines.

And if you have a really skilled dev turned manager, their job is to mentor
and train. This is possibly the most effective thing a manager can do.

~~~
zpatel
Yes, however, we don't have good managers (due to lack of maturity or
experience) to fill the job description you laid out. If you take a survey of
people leaving teams or companies, you will find that many people leave due to
bad managements.

~~~
muzani
I supposed that's why management is paid more - the skillset for a good
manager is rarer than that of a good developer, even if they are less
critical.

~~~
zpatel
Well, but they pay the bad manager's "more" too, which is bad !

------
git-pull
At startups, senior engineers only need light supervision.

Their time should be spent listening to customers, directors, and other
stakeholders to check if they're sorely missing things. They should keep lines
of communication open and be proactive.

One thing we don't see often enough is the "Principle Software Engineer" role
in startups.

At most startups, it's an open office floor plan. The data analysts, sales
person, and marketer would come up to me with a request for something that was
actually detrimental to their doing their job, but it wasn't getting focused
on in our sprints.

At Boostable (W14), I was handling all server / e-commerce / front-end issues,
_plus_ setting up systems for marketing and sales needs that wouldn't have
otherwise been done. And it brought substantial value to the company, for low
hanging fruit a manager would have kept kicking the can down the road.

The issue is, these proactive things were never recognized or appreciated the
way I think they should have been. Heh. It's as if it the work being
unofficial made it less valued, when the way I saw it, it was shared success.

If a programmer is impactful and setting the best practices for the team, they
can report directly to VP/CTO. Less supervision. Mentor fellow employees.

~~~
zpatel
Great insights on the multi-faceted responsibilities of a Sr. Engineers
especially at early stage startups.

So my query was whether tool(s) can help permeate some of this culture in a
large company and thus reduce or eliminate the manager who would otherwise
have been unproductive not only from the perspective of marketing or for the
company, but potentially also have demotivated the Sr.Engineers or just in
case he/she was not a good manager ?

~~~
git-pull
I don't know if I view managers as having to do with marketing, we would try
out _project managers_. This was after my time at the company, but they're
sort of like manager's, except performing more of an organizational task,
rather than potentially hiring/firing. They'd play more of a mediator between
engineers and other teammates in the group dynamics.

Tools: at Boostable we had Aha ([https://www.aha.io/](https://www.aha.io/)).
And we would have the founder Alex split the tickets up. Aha would disseminate
the tickets into Pivotal Tracker
([https://www.pivotaltracker.com/](https://www.pivotaltracker.com/)).

Aha played a really big role in top-down delegation of tasks and equating them
to business objectives. That software is pretty cool and I recommend checking
it out, because I think in some cases it can make manager's redundant.

After that, it was autonomous. I created a lot of issues by myself directly in
Pivotal (which probably lends to them not being recognized officially, since
Aha was where the business impact was overviewed)

~~~
zpatel
cool, thanks for sharing your experience. Definitely a unified tool that would
map Product Roadmap -> Deliverables (Implementation Tasks) -> QA verifications
in a trusted manner could reduce dependency on dev mgrs, PMs and inturn give
more ownership to Sr. Engineers..

------
Zombieball
I am not sure I understand the proposal, it seems that you’ve categorized
managers into 2 buckets:

1) Managers who add little to no value.

2) Sr. Managers who do add value (big picture roadmap, headcount balancing,
etc.

I don’t think you are suggesting (or even can) automate the tasks managers
from bucket #2 are performing. As for bucket #1, if they aren’t adding value
can’t you just eliminate this unnecessary layer from the company? Fire the
manager and the team will presumably be just as well (or better) off? What is
there to automate / produce tooling for? The non-value added tasks?

~~~
zpatel
Correct, however, Companies will not fire #1 overnight or even understand if
they can do that. Through some tooling, these will be rendered as not required
(with data points to prove), just like "Architect" jobs have reduced as Sr.
Engineers have taken up that part as well.

~~~
Zombieball
What tooling are you referring to? I skimmed through other comments and didn’t
notice any concrete examples?

Do you envision something like project planning software?

I think a key point of a good manager is also people development. But I
imagine engineers could self-organize mentorships.

~~~
zpatel
This tool will basically deal with Product, Delivery and Team aspects:

1\. Product Direction

a. Source in Initiatives (road map) , Product stories managed by
Product/Project manager, Sr. Manager and Director thus providing inputs on the
business aspects and requirements.

b. Tech Lead/Principal/Sr.Engineer provides feedback on 1a.)

2\. Delivery Mgmt

a. Stories will be mapped to Features for which the Architecture/Design (done
by Sr.Engineers) would be reviewed/voted by team. Override of a technical
approach (with justification) can be done by Principal/Sr.Engineer, however,
this could be escalated to the Sr. Manager / Director by other team members
(anonymously) . Sr.Mgr and Director would also chip in and provide their
inputs if required and accordingly lead to a resolution based on data points,
pros/cons etc. In this way, conflicts or ego issues can be minimized.

b. Feature will be prioritized by Tech Lead / Sr. Engineer based on comments
from team or directly proceed to c)

c)Feature will be assigned to an Engineer for implementation

d)Feature will be verified by QA as well as Business lead/user post deployment
or software release

e)Delivery feedback to be provided by the Product manager and Business user,
this will be used to provide opportunity for improvement and/or appreciation
of the effort (and hence motivation).

~~~
zpatel
One more thing, based on the votes for data points/issues, the tool would also
provide recommendations.

