Ask HN: Do Software Engineers Need Managers?
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 :) ?
37 comments
[ 5.2 ms ] story [ 89.9 ms ] threadThere 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.
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..:)
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.
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 ?
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)
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.
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.
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.
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
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.
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.
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?
"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..
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.
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.
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.
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?
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.
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.
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?
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.
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).