Hacker News new | comments | ask | show | jobs | submit login
Ask HN: Do Software Engineers Need Managers?
32 points by zpatel 11 months ago | hide | past | web | favorite | 37 comments
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).

So my question is whether the Software Engineers (especially the senior one'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 :) ?

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.

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?

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.

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.

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.

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.


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.

Okay, ignore the blockchain part, what i meant is that the tool could have mechanisms to ensure trusted verification of task completions, decisions etc.

I share your experiences at large firm and startups . What I feel is that tech leads, Architects or Sr. Engineers have lot of stress to deal with when they have bad managers which is ultimately bad for the team , company and individual development.

I think my question should have been phrased a bit differently as some level of mgmt especially at Director or Sr. Manager level should be sufficient to take care of hiring/firing, budgeting etc. Also with better tooling , conflicts can also be minimized as they are caused by egoistic views which are not based on data (think pros/cons of a solution etc).

So in short first level managers and Project manager roles can be minimized and/or their roles adjusted as shared resources across teams, not as product owners and team managers which is a mostly redundant role.

Blockchain would surely count for promotion points for the involved suspects, and that reason isn't to be overlooked.

I'd add in career progression

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.

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

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.

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?

That is the biggest load of bullshit I've ever heard. What if your business focused managers fuck up and accidentally write some code? Then they can no longer understand how to work on valuable and sell-able projects? Managers destroy projects and companies and create worthless work all day every day.

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

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

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.

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

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

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


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.

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) ?

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.

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.

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.

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.

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

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.

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 ?

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/). And we would have the founder Alex split the tickets up. Aha would disseminate the tickets into Pivotal Tracker (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)

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

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?

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.

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.

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

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

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact