People often talk about the extemes. Managers or no managers.
Why can't we have something in-between?
Like, instead of a manager, we have a team assistant. Someone who does burocracy and orga, but hasn't any power and the power is exercied in some way by all of the team members.
This would remove the "if all do it no one does it" problem and still prevent single people decisions.
> Someone who does burocracy and orga, but hasn't any power
They are even less useful without power.
Problem is most of the managers are junior in their position. They don't have leadership experience. Often just got a promotion and come up from a different background and only have a few years of experience on management position.
Or, they have some experience at different scale. So when they start on a bigger organisation, they are just like junior employees in my opinion.
Proper leadership requires lots of experience and skills.
The way it works best in my experience is the team helping them to work efficiently.
If they (managers) are not informed enough, they start micromanaging everyone and everything around them because they feel nothing is aligned or everything is out of control.
Same story when they are misinformed. If the information is negative they panic and start direct communication with every team member. And when it is just false positives, they may look very unaccountable or impulsive.
The best is to inform them before they seek for information and updates. And use their powers to solve team problems. They have power to provide the support or remove impediments.
If managers are getting things done by wielding their authority from the org chart, odds are they aren't great leaders to begin with.
In most organizations, leaders arise naturally, and they don't always match the org chart. Wise managers let those people shine, and help them succeed. Then the informal leaders help the team succeed, and the manager gets what they want because they did the cliche of hiring smart people and then letting them do what they do best.
In such a scenario, managers may ask what they are doing... because the team is doing it all without much help. But that is a good thing. The manager did their job, of building an effective team.
"leaders arise naturally, and they don't always match the org chart. Wise managers let those people shine"
Two points I see here.
1. managers are placed above the real leaders artificially
2. leaders arise without any formal process
The first point is what systems like Holocracy want to eliminate. The second point is what Holocracy leads to, some people following leaders and nobody really knows who that leader is.
My idea was to decouple the orga/bureaucracy stuff from management and create a new team assistant role, so things can go on orderly and there is someone to talk to.
The second part was creating some kind of process that helps to make decisions, so no "hidden leader" can wreak havok in the background.
> If managers are getting things done by wielding their authority from the org chart, odds are they aren't great leaders to begin with.
Agree. If an organisation has power distance between managers and others, perhaps they have more fundamental problems to begin with.
By power I meant the privileges and rights that comes with their responsiblities and tasks. A simple example would be rights to ask for more resources or budget.
At my workplace the organisation is pretty flat (director of IT services is officially the only one above ~25 devs and ops people, and he's busy with sales and long term strategy).
I miss having more people with official power when discussions go on and on without reaching a conclusion, and when there is work that everybody agrees needs doing but nobody wants to do.
I've had a few really good managers over the years and in all cases I wouldn't have wanted their jobs - yes they had power over me, but they always communicated clearly and asked for my input when appropriate, set clear goals and (most importantly) acted as a political shield while the rest of us were doing our jobs of getting stuff done.
Mind you - have had awful managers as well - but fortunately not very many and not for a long time.
Edit: I should also add that I've certainly been an awful manager at times....
Management & no management is binary. If we used an indicator variable (1 for “has management” and 0 for “no management”) then there’d be no way to have any idea of “quality of management performed” along a different axis in the “no management” case.
I don’t agree that separating this as a distinct inficator variable would actually be useful.
This is actually a lot of what the Holacracy system does (though most business mags get it totally wrong in the US -- less so in the EU).
Unlike some of the fad "flat"/structureless stuff that just eliminates managers, Holacracy focuses on decentralizing those management functions that still need to exist (because management is needed, even if there are no managers) in roles and processes, and reducing the "Lead Link"/"Circle Lead" role in each team to something that takes ~10% of a person's time and is focused around the garbage collection for the team and helping the team get problems out of their way.
Having recently experienced "agile", one of the things I've concluded is that the PM needs to be fireable by the team. I don't mean unemployed, I simply mean the team needs to be able to tell the PM they will no longer be working with them.
I just put in my 2 week notice at a shop that I've been working at for 6 months, and what I've found is that effectiveness isn't the goal. Having done freelance for the past 8 years, I was actively shocked by how ineffective and wasteful the processes were here. I once witnessed a discussion about whether to CC multiple people or send each person their own copy that took over a week and eventually involved a VP.
I put in my 2 week notice this Monday. It took me all of 2 days to start filling my time again once I made the decision, and I can't even tell you how much I'm looking forward to going back to working for myself. It feels like having a straight jacket removed.
I'm sure there are shops out there that end up using agile and don't become these ridiculous monstrosities, but I feel like those shops would be successful with or without agile.
> I'm sure there are shops out there that end up using agile and don't become these ridiculous monstrosities, but I feel like those shops would be successful with or without agile.
I think that's the key. Agile isn't a silver bullet, it's just a tool. If your problems are screws and you grab a screwdriver, you're probably in good shape. It works great for my team, because we all trust each other and genuinely take the quality of our product to heart. It doesn't work for our neighboring team because nobody gives a fuck besides getting credit for all of the good stuff and deflecting blame for all of the bad stuff.
I don't have a whole lot of faith in "there's one way to run a team/be a leader and you do it like this" sort of thing. The style of leadership I was taught in the military would not fucking fly on my team, but honestly, it would serve my neighboring team fairly well. Their problems are nails.
At Slalom _build[1], we have People Managers and Team Leads.
Your people manager stays with you as you transition from project to project. They never have more than six direct reports. They are the person that handles all the bureaucracy for you and helping you through the org.
Your team lead is sometimes a people manager but probably not yours. They change based on the project you are on and are responsible for it's success. Their focus is on delivery not your career.
I'm interested in seeing where this goes as it breaks the responsibility up without breaking the career progression. There isn't a "technical path" ... yet.
This is the organization of the company I work at. Overall I've learned through experience that this decoupled structure is nice in theory and it's useful to have as an option, but it should actually be avoided in practice if at all possible. A developer can end up in a situation where their boss (people manager) really doesn't know about or understand their day-to-day work at all, and then their team lead may be vying for authority over the team with a project manager and product owner, all of whom report in different organizations and have different motivations and incentives.
This has been in my mind recently.
I am head of development at a startup and have something like 30 direct reports. I don't want to be doing this job for a long time, and am maneuvering the team structure to make myself redundant with the following actions:
- I am trying to convince the execs and HR to increase pay transparency and to reward people who want to progress in their careers as engineers more than those who want to become managers.
- I have promoted one person with more leadership skills (and less technical ability) to be a dev lead; essentially a mentor, gathering feedback from the team and helping them solve process and communication issues, and keeping track of OKR metrics.
- I hired a department assistant, to do resource allocation, manage Jira permissions, tidy up boards, etc.
- We have 1 project manager who is responsible for our three internal development projects, controls our budget and fights with other PMs for resources.
- All others are Developers and QA. Some are more senior, so they have architecture roles. Everyone gets to give their voice, but one of them has an official role of architecture lead, who has the final say, but that's mostly cerimonial.
My role is to help them focus when they start to drift, shield them from politics, and most importantly give a cerimonial ratification on their ideas, if they match the values of the company.
So all 4 non developers are essentially assistants. I hope to soon be able to step out and leave the team working happily with a 10 to 1 ratio of dev to non-dev.
This solution sums up the problem. When you have many of those dev leads, the least capable among them will be promoted to be their leader. This is human nature in group formation.
30 direct reports is an astonishing number, and it makes me feel like you're either onto something brilliant or are crazy and this structure is going to crash and burn once things get really complicated and fast-paced. I suppose it depends on how routine a lot of the work is. You'd be spending a minimum of 15 hours a week just on 1:1s, but I could see that being as high as 20 or 30 hours; 15 is already two full days out of the week. That is, unless you just don't do 1:1s at all, which seems incredibly risky long-term.
Given a six-month check-in and annual review once a year for each report, you'd have a total of 60 such events a year, meaning you'd have at least one annual review or six-month check-in every single week. You'd have to keep up with the unique performance characteristics of 30 different people in order to conduct these reviews in any reasonably useful and professional way that actually encourages real growth. If there's any sort of interpersonal conflict or unexpected project complexity, this could easily burn through enough of your time that you'd have to blow off nearly 30 people in the meantime.
Yeah, I started doing 1-on-1 with all of them when the team was about half size. The reason I got one of the guys "promoted" as dev lead is so he can take most of the mentoring and feedback gathering. He is not their boss though, with no authority to assign work or make demands.
Nowadays I do 1-on-1s with the dev lead, the assistant, and the product owners (senior devs and architects), so only 5 people.
Still, that would mean the dev lead would need to do 25 1-on-1s, so we have a structure of peer mentorship, with two phases: a formal and an informal. The formal is to maintain quality of information gathering and fairness. The informal is to allow for rapport and flexibility in the part of the mentor. We started this recently, we'll see how it goes.
Well that's just what a manager should be doing. Their job is to ensure everyone else can work. Quite literally a "production assistant". They should deal with all the BS that workers don't want to, so they can get to the real work. Which is the main flaw in promoting workers to management, as they're two entirely different sets of skills.
There's a post on joelonsoftware about this, and I think it constitutes most of the first few chapters of the book peopleware.
> Someone who does burocracy and orga, but hasn't any power and the power is exercied in some way by all of the team members.
I worked at a company that tried this, more or less. It worked well for a few months, until the bad apple employees realized that managers had no power to correct their bad behavior. Then it become a free for all.
Counterintuitively, it created far more bureaucracy than ever before as people started hoarding information, refusing to grant access to shared resources, claiming others' work as their own, and other selfish behaviors.
Bureaucracy is largely reflected through managers, but this experience taught me that bureaucracy isn't necessarily created by the managers. The power structures will organically assemble themselves as people compete for what they think are limited opportunities for raises, promotion, and advancement.
Having healthy management in place to deal with formalized and visible bureaucracy is much better than letting the bureaucracy grow organically in the shadows while pretending it doesn't exist.
It's hard to find a good one because execs don't like the idea of ICs having assistants, which is one of the perks that execs use to make themselves look better by getting credit for someone else's work without spending their own salary on it.
Most companies could chop an entire layer of middle management, perhaps many layers, and get an instant boost in productivity and happiness. I wonder if there’s any mechanism for workers and senior management to make this happen and share the rewards.
I've said this before, but a manager's work is split into thirds:
1/3 is in service of the team. Some of this is bureaucratic (approving expense reports, hiring/firing/promoting), and some of this is being a team facilitator. In meetings, watching that everyone is talking and that one person isn't dominating. Helping with conflict management. Pulling together people from three teams for a meeting and leading it.
Again, that's about 1/3 of the job. Half of this could be done by team members, but these are skills that require knowing tech but aren't tech.
1/3 is getting senior management what they need. Does the project need another developer? What is the high level status of the team? Is there technical debt that needs prioritizing that requires more than what the individual team can commit to? These are things that can be done by developers, but it's going to look a lot like what the manager does, and someone is going to be pulled off of more and more development work to do these.
And the last third is to the rest of the management team. These are the work to make the department run that people don't notice.
I worked at a place that had a very lean management:worker ratio, and instead developers ended up doing a lot of the management work, effectively becoming managers without the pay bump or recognition.
I like the way you've broken this down, and I realize you're just giving examples, but your first third (service of the team) doesn't include any long-term development of employees. (Probably just because your purpose here isn't to make an exhaustive list, but it got me thinking about this.)
I mention this because I think one thing that separates mediocre managers from really good ones is that the good ones understand each employee's strengths and weaknesses and try to help them chart a course for success. That means finding their place on the team and it also means growth. It's to everyone's benefit if, 6 months or a year from now, that employee is a better employee. A manager is in a unique position to coach and mentor, and to create the conditions for growth and encourage it. A self-starter employee will do some of this on their own, but they usually need the manager to participate too by doing stuff like recognizing realistic opportunities for an employee to take on more responsibility and taking a chance by trusting them with it. A lot of managers don't seem to even attempt to do any of this or aren't even aware that it's a thing, and then their team languishes and stagnates and they wonder why they aren't getting anything out of their people.
Certainly, long term development of employees is part of that third, and a significant one at that. But much of growth is subtle - it's about looking at projects and going, "Person A can get it done quickly but Person B would grow and appreciate the task, and Person C feels a bit of ownership over a part of it, and will grab due to an assertive personality if I let them sort it out themselves. So I'm going to have to massage a few egos here.) That doesn't take a lot of time but it is definitely emotional labor.
Emotional labor can be hard to quantify, and so outside of 1:1s and ad-hoc goal setting meetings and reviews, it's both important and hard to quantify in terms of time. Further, it's another task that can be a peer task - that is, it's something that technical leads can do for their teams and management can reassign the rest.
The original comment was talking about taking out most of management, so it's probably something they wouldn't consider as a key management priority that couldn't be done by developers.
> I worked at a place that had a very lean management:worker ratio, and instead developers ended up doing a lot of the management work, effectively becoming managers without the pay bump or recognition.
I think you don't understand the reason for middle-management. Let me paint you a picture where if you'd be CTO (or any other top-management) you'd be greatful for middle-management.
Imagine you are CTO of a pretty successful eCommerce company.
What you need to oversee as a CTO:
- iPhone and Android application
- Front-End Website application
- Back-End Website application
- SAP (Or something similar) integrations for billing and documenting
- BI infrastructure and reporting via tool like Tablou/Salesforce or similar integration with replica read-only DB
- DevOps (AWS, Azure, GC, or similar) maintanence and R&D
- Bonus: A lot of meetings with other top-management regarding company stuff (structure, plans, vision, etc..)
Now, how many people (Developers, QA, DevOps, BI, ...) do you think work under you - at minimum 30 (bare in mind I'm talking about successful stable company, not a 2-man garage startup).
Do you really think one guy will want to deal with all the 1-1 bullshit, day-to-day operations, everyoen asking raises, people leaveing, people coming (hiring)? It is literally impossible.
I think you don't understand the reason for middle-management.
I think I do, I’ve worked at places with more middle-managers than engineers! They mainly held meetings with each other all day as us engineers got on with the real work, self-organised when necessary.
It wasn’t too bad since we were mostly left alone but we still resented their generous salaries being paid off our labour.
To use a RPG analogy, managers tank for the team. They produce visibility little output. Their job is to keep the team focused on what they do.
Without a manager, team members need to justify a $5 expense to finance, deal with back and forth iterative design with product team, argue that the hardware partner isn't delivering what they promised, deal with security expectations from bigger partners. There's a lot of unnecessary meetings in there and you don't want the people doing the work to be in them.
Without a manager, the CEO sits next to your back end guy, rants about bugs that the guy is already fixing, and pokes him for update schedule progress every four hours.
It is possible for middle management to get bloated, but this is sort of a response like we have too many meetings, therefore we need more people to handle meetings.
It's difficult because almost every word in your answer is a minefield that cannot be handled simply:
measure: how does one truly measure anything related to a team or individual? Just as lines of code is a bad measure of a developer, even very quantifiable things like sales numbers don't tell the whole story. A salesperson who hooks clients on promises that can't be kept is not doing a good job, no matter how it might look in one quarter. Goodhart's law exists for a reason.
total: a team that appears to be high performing but depends on the output of a small portion of that team, or that is high performing despite several team members, is not a success. People who carry a team often leave for better compensation or challenge. People who appear to have high output themselves at the expense of others should be removed from the team. People who are ineffective on a particular team should find a new environment where they can achieve more success.
output: Not all teams exist to produce specific output. An IT department might replace 50 broken keyboards across the company in a quarter, but it would be foolish to ask "what can we do to get that number to 75?"
their team: A manager usually exists both to help direct reports do a better job, but also to provide timely and pertinent information to other teams, and many organizations have teams that primarily serve "internal customers". An operations team could be given a goal of "zero new bugs or outages" and freeze all new deployments to achieve it. But the development teams would obviously be upset, and the entire company would likely suffer.
the output of a team is knowable. It doesn't matter if that output is the result of only a portion of the team, if the manager is enabling that small portion then that's what success looks like.
Depends on the industry. For grunt work it's pretty easy. If you're manufacturing widgets, count how many widgets you make per employee hour while staying below a certain defect rate. For professional jobs where the task is never the same and your contribution is applying your intelligence to defining, understanding, and solving new problems in the best way, it's not easy because developing a test of productivity can be nearly as hard as doing the work, maybe even harder.
Calling this a study of managers is quite a stretch... it's an arbitrarily designed game theory problem in which some people are labeled "managers" and others "workers" with no real relationship to those titles in the real world.
But yeah, managers can be useful and/or sneaky. They can also be sleepy, hungry, boring, sociopathic and all of the other things humans can be.
Agreed. I'm all for experimental economics, but let's not exaggerate the generalizability of a result. Better to see it as a particular form of theory that needs to be backed up empirically in more real world contexts.
Sure, but a good manager is the one who's sneaky on your behalf. Telling stakeholders a longer timeline than necessary, boosting your accomplishments so you get a raise, taking the bullet from execs, those are all kinda sneaky but I sure as hell respected the managers who did that for stuff for me.
The manager you don't want throws you under the bus, over promises and demands crunch, takes the credit for your work. Equally sneaky, but selfish.
If you ever have a manager who jokes about being a horrible manner with some weird sense of pride during an interview, don't take the job. I learned the hard way.
I went against my gut feeling and took a job at a <1 yr company(new startup/spinout backed by $$$$ org) because i'd get exposure to certain tech. Manager was (& is) a nice person but didn't instill confidence when talking about how things were planning to be.
I left that job 2 years ago after ~8 months. Mentally fucked me up and it took a long time to recover from the ineptitude and incompetence in that company.
I looked at their glassdoor reviews and the same complaint and comments me & co-workers made when we left 2 years ago are still repeating with people who are joining and leaving today.
I hear ya, and I hope you're doing better now. Working for don't-wannabe manager was not a pleasant experience for me. It took me a good couple months to decompress after that.
> Telling stakeholders a longer timeline than necessary
I understand what you mean, but this only creates a escalation problem. Everybody has to lie to get anything done. So, it is impossible to know if the decisions taken in the company are reasonable or not.
I guess that this behavior makes sense if everybody up the ladder are themselves lying.
> taking the bullet from execs
I guess that this is part of the same type of company. Where execs punish mistakes, like if mistakes were not part of your job. I have seen such companies driven by fear and the irony of it is that everybody is unhappy and mistakes are repeated again and again as the goal is just o hide them not to learn from it.
> The manager you don't want throws you under the bus, over promises and demands crunch, takes the credit for your work. Equally sneaky, but selfish.
I guess that this is the manager that ends being promoted to be an exec and creates a new cycle of unreason, pain and lack of productivity.
Most companies are not that perfect unicorn. I worked at a Berkshire Hathaway company and was constantly going to war with upper management over bullshit. My direct manager was a saint, and while the company was doing well, I can't deny it seemed everyone hated it there. I'm happy at a much smaller company.
I've recently landed in a managerial role. If there's one thing I've learned is that your primary role is to shelter the people under you from all the shit that's coming from above (like that famous comic of the birds on a pole pooping on the ones at the bottom.)
If your boss asks to deliver an _unreasonable request_ by tomorrow, your job is not to make sure it's delivered on time, your job is to say "No."
Might seem obvious but very few managers I've worked under learned that lesson, that's the reason managers are seen as being useless. A good manager promotes a healthy workplace.
I haven't kept up with it, but I used to read https://randsinrepose.com — some interesting insight from a software engineering manager.
65 comments
[ 5.4 ms ] story [ 127 ms ] threadWhy can't we have something in-between?
Like, instead of a manager, we have a team assistant. Someone who does burocracy and orga, but hasn't any power and the power is exercied in some way by all of the team members.
This would remove the "if all do it no one does it" problem and still prevent single people decisions.
They are even less useful without power.
Problem is most of the managers are junior in their position. They don't have leadership experience. Often just got a promotion and come up from a different background and only have a few years of experience on management position. Or, they have some experience at different scale. So when they start on a bigger organisation, they are just like junior employees in my opinion.
Proper leadership requires lots of experience and skills.
The way it works best in my experience is the team helping them to work efficiently. If they (managers) are not informed enough, they start micromanaging everyone and everything around them because they feel nothing is aligned or everything is out of control.
Same story when they are misinformed. If the information is negative they panic and start direct communication with every team member. And when it is just false positives, they may look very unaccountable or impulsive.
The best is to inform them before they seek for information and updates. And use their powers to solve team problems. They have power to provide the support or remove impediments.
If managers are getting things done by wielding their authority from the org chart, odds are they aren't great leaders to begin with.
In most organizations, leaders arise naturally, and they don't always match the org chart. Wise managers let those people shine, and help them succeed. Then the informal leaders help the team succeed, and the manager gets what they want because they did the cliche of hiring smart people and then letting them do what they do best.
In such a scenario, managers may ask what they are doing... because the team is doing it all without much help. But that is a good thing. The manager did their job, of building an effective team.
Two points I see here.
1. managers are placed above the real leaders artificially 2. leaders arise without any formal process
The first point is what systems like Holocracy want to eliminate. The second point is what Holocracy leads to, some people following leaders and nobody really knows who that leader is.
My idea was to decouple the orga/bureaucracy stuff from management and create a new team assistant role, so things can go on orderly and there is someone to talk to.
The second part was creating some kind of process that helps to make decisions, so no "hidden leader" can wreak havok in the background.
Humans tend to fear competence more than incompetence. It’s the same cognitive bias as loss aversion.
Agree. If an organisation has power distance between managers and others, perhaps they have more fundamental problems to begin with.
By power I meant the privileges and rights that comes with their responsiblities and tasks. A simple example would be rights to ask for more resources or budget.
I miss having more people with official power when discussions go on and on without reaching a conclusion, and when there is work that everybody agrees needs doing but nobody wants to do.
Mind you - have had awful managers as well - but fortunately not very many and not for a long time.
Edit: I should also add that I've certainly been an awful manager at times....
I was just thinking if the system in place could be improved in a way that it worked even if some of them aren't good.
“Manager” is somewhere in the middle. “Insane bad manager” is the extreme, not the mere existence of a management structure.
I don’t agree that separating this as a distinct inficator variable would actually be useful.
Unlike some of the fad "flat"/structureless stuff that just eliminates managers, Holacracy focuses on decentralizing those management functions that still need to exist (because management is needed, even if there are no managers) in roles and processes, and reducing the "Lead Link"/"Circle Lead" role in each team to something that takes ~10% of a person's time and is focused around the garbage collection for the team and helping the team get problems out of their way.
I just put in my 2 week notice at a shop that I've been working at for 6 months, and what I've found is that effectiveness isn't the goal. Having done freelance for the past 8 years, I was actively shocked by how ineffective and wasteful the processes were here. I once witnessed a discussion about whether to CC multiple people or send each person their own copy that took over a week and eventually involved a VP.
I put in my 2 week notice this Monday. It took me all of 2 days to start filling my time again once I made the decision, and I can't even tell you how much I'm looking forward to going back to working for myself. It feels like having a straight jacket removed.
I'm sure there are shops out there that end up using agile and don't become these ridiculous monstrosities, but I feel like those shops would be successful with or without agile.
I think that's the key. Agile isn't a silver bullet, it's just a tool. If your problems are screws and you grab a screwdriver, you're probably in good shape. It works great for my team, because we all trust each other and genuinely take the quality of our product to heart. It doesn't work for our neighboring team because nobody gives a fuck besides getting credit for all of the good stuff and deflecting blame for all of the bad stuff.
I don't have a whole lot of faith in "there's one way to run a team/be a leader and you do it like this" sort of thing. The style of leadership I was taught in the military would not fucking fly on my team, but honestly, it would serve my neighboring team fairly well. Their problems are nails.
Your people manager stays with you as you transition from project to project. They never have more than six direct reports. They are the person that handles all the bureaucracy for you and helping you through the org.
Your team lead is sometimes a people manager but probably not yours. They change based on the project you are on and are responsible for it's success. Their focus is on delivery not your career.
I'm interested in seeing where this goes as it breaks the responsibility up without breaking the career progression. There isn't a "technical path" ... yet.
[1] https://www.slalombuild.com/
How do you figure it does this? What you describe just seems like a basic, run-of-the-mill, cross-reporting model to me.
My role is to help them focus when they start to drift, shield them from politics, and most importantly give a cerimonial ratification on their ideas, if they match the values of the company.
So all 4 non developers are essentially assistants. I hope to soon be able to step out and leave the team working happily with a 10 to 1 ratio of dev to non-dev.
Given a six-month check-in and annual review once a year for each report, you'd have a total of 60 such events a year, meaning you'd have at least one annual review or six-month check-in every single week. You'd have to keep up with the unique performance characteristics of 30 different people in order to conduct these reviews in any reasonably useful and professional way that actually encourages real growth. If there's any sort of interpersonal conflict or unexpected project complexity, this could easily burn through enough of your time that you'd have to blow off nearly 30 people in the meantime.
Nowadays I do 1-on-1s with the dev lead, the assistant, and the product owners (senior devs and architects), so only 5 people.
Still, that would mean the dev lead would need to do 25 1-on-1s, so we have a structure of peer mentorship, with two phases: a formal and an informal. The formal is to maintain quality of information gathering and fairness. The informal is to allow for rapport and flexibility in the part of the mentor. We started this recently, we'll see how it goes.
There's a post on joelonsoftware about this, and I think it constitutes most of the first few chapters of the book peopleware.
In my opinion the problem is just that managers are seen as people in positions of power, this needs to go away.
Creating a new role with new naming would get rid of all the baggage.
Managers necessarily have influence, or quickly grow it, by the nature of being a good manager.
I worked at a company that tried this, more or less. It worked well for a few months, until the bad apple employees realized that managers had no power to correct their bad behavior. Then it become a free for all.
Counterintuitively, it created far more bureaucracy than ever before as people started hoarding information, refusing to grant access to shared resources, claiming others' work as their own, and other selfish behaviors.
Bureaucracy is largely reflected through managers, but this experience taught me that bureaucracy isn't necessarily created by the managers. The power structures will organically assemble themselves as people compete for what they think are limited opportunities for raises, promotion, and advancement.
Having healthy management in place to deal with formalized and visible bureaucracy is much better than letting the bureaucracy grow organically in the shadows while pretending it doesn't exist.
It's hard to find a good one because execs don't like the idea of ICs having assistants, which is one of the perks that execs use to make themselves look better by getting credit for someone else's work without spending their own salary on it.
1/3 is in service of the team. Some of this is bureaucratic (approving expense reports, hiring/firing/promoting), and some of this is being a team facilitator. In meetings, watching that everyone is talking and that one person isn't dominating. Helping with conflict management. Pulling together people from three teams for a meeting and leading it.
Again, that's about 1/3 of the job. Half of this could be done by team members, but these are skills that require knowing tech but aren't tech.
1/3 is getting senior management what they need. Does the project need another developer? What is the high level status of the team? Is there technical debt that needs prioritizing that requires more than what the individual team can commit to? These are things that can be done by developers, but it's going to look a lot like what the manager does, and someone is going to be pulled off of more and more development work to do these.
And the last third is to the rest of the management team. These are the work to make the department run that people don't notice.
I worked at a place that had a very lean management:worker ratio, and instead developers ended up doing a lot of the management work, effectively becoming managers without the pay bump or recognition.
I mention this because I think one thing that separates mediocre managers from really good ones is that the good ones understand each employee's strengths and weaknesses and try to help them chart a course for success. That means finding their place on the team and it also means growth. It's to everyone's benefit if, 6 months or a year from now, that employee is a better employee. A manager is in a unique position to coach and mentor, and to create the conditions for growth and encourage it. A self-starter employee will do some of this on their own, but they usually need the manager to participate too by doing stuff like recognizing realistic opportunities for an employee to take on more responsibility and taking a chance by trusting them with it. A lot of managers don't seem to even attempt to do any of this or aren't even aware that it's a thing, and then their team languishes and stagnates and they wonder why they aren't getting anything out of their people.
Emotional labor can be hard to quantify, and so outside of 1:1s and ad-hoc goal setting meetings and reviews, it's both important and hard to quantify in terms of time. Further, it's another task that can be a peer task - that is, it's something that technical leads can do for their teams and management can reassign the rest.
The original comment was talking about taking out most of management, so it's probably something they wouldn't consider as a key management priority that couldn't be done by developers.
Also branded as "Flat Structure"
Imagine you are CTO of a pretty successful eCommerce company.
What you need to oversee as a CTO:
- iPhone and Android application
- Front-End Website application
- Back-End Website application
- SAP (Or something similar) integrations for billing and documenting
- BI infrastructure and reporting via tool like Tablou/Salesforce or similar integration with replica read-only DB
- DevOps (AWS, Azure, GC, or similar) maintanence and R&D
- Bonus: A lot of meetings with other top-management regarding company stuff (structure, plans, vision, etc..)
Now, how many people (Developers, QA, DevOps, BI, ...) do you think work under you - at minimum 30 (bare in mind I'm talking about successful stable company, not a 2-man garage startup).
Do you really think one guy will want to deal with all the 1-1 bullshit, day-to-day operations, everyoen asking raises, people leaveing, people coming (hiring)? It is literally impossible.
I think I do, I’ve worked at places with more middle-managers than engineers! They mainly held meetings with each other all day as us engineers got on with the real work, self-organised when necessary.
It wasn’t too bad since we were mostly left alone but we still resented their generous salaries being paid off our labour.
Without a manager, team members need to justify a $5 expense to finance, deal with back and forth iterative design with product team, argue that the hardware partner isn't delivering what they promised, deal with security expectations from bigger partners. There's a lot of unnecessary meetings in there and you don't want the people doing the work to be in them.
Without a manager, the CEO sits next to your back end guy, rants about bugs that the guy is already fixing, and pokes him for update schedule progress every four hours.
It is possible for middle management to get bloated, but this is sort of a response like we have too many meetings, therefore we need more people to handle meetings.
Why would it be difficult to measure what managers do? Measure the total output of their team. That's it.
measure: how does one truly measure anything related to a team or individual? Just as lines of code is a bad measure of a developer, even very quantifiable things like sales numbers don't tell the whole story. A salesperson who hooks clients on promises that can't be kept is not doing a good job, no matter how it might look in one quarter. Goodhart's law exists for a reason.
total: a team that appears to be high performing but depends on the output of a small portion of that team, or that is high performing despite several team members, is not a success. People who carry a team often leave for better compensation or challenge. People who appear to have high output themselves at the expense of others should be removed from the team. People who are ineffective on a particular team should find a new environment where they can achieve more success.
output: Not all teams exist to produce specific output. An IT department might replace 50 broken keyboards across the company in a quarter, but it would be foolish to ask "what can we do to get that number to 75?"
their team: A manager usually exists both to help direct reports do a better job, but also to provide timely and pertinent information to other teams, and many organizations have teams that primarily serve "internal customers". An operations team could be given a goal of "zero new bugs or outages" and freeze all new deployments to achieve it. But the development teams would obviously be upset, and the entire company would likely suffer.
But yeah, managers can be useful and/or sneaky. They can also be sleepy, hungry, boring, sociopathic and all of the other things humans can be.
The manager you don't want throws you under the bus, over promises and demands crunch, takes the credit for your work. Equally sneaky, but selfish.
I left that job 2 years ago after ~8 months. Mentally fucked me up and it took a long time to recover from the ineptitude and incompetence in that company.
I looked at their glassdoor reviews and the same complaint and comments me & co-workers made when we left 2 years ago are still repeating with people who are joining and leaving today.
Never again going against my gut feeling.
I understand what you mean, but this only creates a escalation problem. Everybody has to lie to get anything done. So, it is impossible to know if the decisions taken in the company are reasonable or not.
I guess that this behavior makes sense if everybody up the ladder are themselves lying.
> taking the bullet from execs
I guess that this is part of the same type of company. Where execs punish mistakes, like if mistakes were not part of your job. I have seen such companies driven by fear and the irony of it is that everybody is unhappy and mistakes are repeated again and again as the goal is just o hide them not to learn from it.
> The manager you don't want throws you under the bus, over promises and demands crunch, takes the credit for your work. Equally sneaky, but selfish.
I guess that this is the manager that ends being promoted to be an exec and creates a new cycle of unreason, pain and lack of productivity.
Old but relevant: https://www.dilbert.com/strip/1995-01-22
If your boss asks to deliver an _unreasonable request_ by tomorrow, your job is not to make sure it's delivered on time, your job is to say "No."
Might seem obvious but very few managers I've worked under learned that lesson, that's the reason managers are seen as being useless. A good manager promotes a healthy workplace.
I haven't kept up with it, but I used to read https://randsinrepose.com — some interesting insight from a software engineering manager.