That means you need to be dealing with poor performers, rewarding with outstanding performers, trying to improve uneven performers, managing expectations from your management and shielding your team from the vicissitudes of your bosses as much as possible, fighting for things your team needs while shielding them from the demoralizing realities of working for a big company where HR and IT etc. don’t give two shits about the actual mission (if applicable), keeping an accurate budget, making sure your team is individually recognized for their success but that you take the blame for their failures, responding to changes in direction and getting your team on board, being the face of management even when that’s unpopular, and doing all the other little things required to keep the team going as effectively as possible.
There’s a lot of work to do there, and it can be incredibly rewarding when it’s going well and incredibly frustrating when it’s not.
It can also mean you have days when your team is working all out to deliver and the only thing you can do is order pizza and keep distractions away. Those are boring, often frustrating days.
It’s not for everybody, but that’s what I think a good manager does. I think it’s often easier when you manage a team and aren’t an expert at what they do (although you still need to understand at a relatively deep level), since that minimizes the chances of you trying to dive in and solve the problem.
I'm not surprised to hear a manager's work can go unnoticed. That's unfortunate :(
Good management is really rare. One in five or even ten maybe.
One in fifty, achieve the above but are able to produce teams that regardless of their manager in the future would produce good results at minimum. Great managers don't seem to just focus on the business but also leveling up each individual on the team.
I think plenty of individuals have had mediocre managers and they would describe them as good.
Working with "the best" ICs reshape your perspective of what is a great ICs. Just like managers. Much earlier in my career I used to believe that great ICs were one in 20, then it became fifty and now, two hundred.
Doing this well also requires building relationships with the team and trust. Recognizing little things like how people can be afraid of a project (and that fear can lead to spinning), and how to break things down/prioritize.
In software I think there are also system changes that can make individuals happier (often stuff described in books like the Phoenix project and working effectively with legacy code). A lot of which enable the things you described.
People are happy when they’re productive and goals are clear/make sense (and they have the space to focus on the work for them) and they get recognized for it.
Glad it's behind me, though.
Here's a couple:
> Chris was the best manager I've ever reported to. Period. He was supportive of his team, always motivating us to deliver excellence, even under daunting schedules set by the people above him. Because of Chris' support and commitment to his team, he fostered a deep loyalty and respect from our department.
> Chris is passionate about developing software and about technology in general. This means he is always in touch with the latest trends and best practices in the industry. However, he is careful not to introduce a new process or methodology to his group unless it has clear benefits and he has considered the input of everyone affected.
Chris has always been very well-respected by his engineers because his management style allows their best skills to shine. It's not simply a hands-off approach; he'll look to remove roadblocks where he can and offer help in any way possible. He is good at identifying an inefficiency and reaching out to help improve it.
More than just management skills, Chris is a kind, understanding, sensible and fair human being. At one point, we had a six-year run where no one left the group. I hadn't really noticed or appreciated this stability until someone from our HR department pointed out how remarkable it was. This could not have happened without someone like Chris managing the group.
But, what do they know? I'm sure they were mistaken. BTW: One of them was from a chap I laid off.
Testimonials from employees are a good indicator for a good manager.
I felt good about what I did, even though I didn't enjoy it.
> 27 years is a long time to stay in a job you hate.
This statement shows that we are in a privileged place, indeed. We get to have a career, where we can do work that we enjoy, and make a lot of money at it.
The great majority of people don't get that. Most of my friends don't like their jobs. Some, are very good at what they do, and make a lot of money.
The job was relatively easy. I liked the company I worked for, and my peers. I felt a great deal of Responsibility towards the company, my peers, and my employees. I made enough to live on, and save. I could have made a lot more money, elsewhere. Despite the obvious sneers and judging that I get, I'm actually no slouch.
Nowadays, I work for free, on software that helps others.
WFM. YMMV.
How do you do that? Apparently I'm an inconsistent performer now.
When I say uneven, I’m thinking of somebody who either: (a) is excellent at certain key aspects of their jobs but clearly below expectations in others to the point that it’s an issue, or (b) somebody who performs well but doesn’t always put in enough effort. In both cases, it’s subjective and difficult to determine that it’s to the point where intervention is required, because that’s usually an uncomfortable conversation. Often, you’re the first manager ever telling the person that they need to improve—-even if you’re not the first person to think there’s an issue. Typically, the other person will think you’re an asshole. As another commenter said, they may recognize later on that you were right but normally in the near term, you’ll have strained the relationship. (That’s why managers avoid those conversations. Sometimes it’s cowardice, sometimes it’s deciding that the juice isn’t worth the squeeze today.)
As for how to work on improvement, that always has to be case-by-case considering the issue and the personality. Sometimes the “stop doing that” conversation is enough. Sometimes coaching or mentoring or development experiences can help. If those don’t work, can you shift responsibilities around or find a different role that is a better fit?
Normally you try to gently do those things anyway before you have the direct conversation, and then hope the direct conversation provides some motivation/insight to take it more seriously.
If you’re on the receiving end of that conversation, I guess my advice would be to try to critically self-reflect and see if you can understand where your manager is coming from. If you can, then you’ve both got a common place to start from towards improvement. If you can’t, or you think they’re just being unreasonable about expectations, then it is probably time to move on or hope they move on quickly.
The "improvements" I've been told to make is to document why stories are slow - mostly context switching from prod support, context switching from my role as ASC, and of course just being slow when working with a system or language that I haven't worked on in a while.
So my perspective based on the feedback is, this isn't a performance issue (if it was it would be under communication instead of speed). It solely addresses visibility of the switching. I have requested consistent work, like being full stack in a single stack. The whole point of specialization of labor is to increase speed and quality, yet it seems this management tenent is wholly missed by my organization. You want consistent speed? Give me consistent work.
The best part is I got a 4.5% pay cut, yet they say they want to retain me. All while the company is talking about across the board increases (which I won't be eligible for) and having trouble filling roles that typically stay open for 6 months. Which is it - do I suck, or do you want to keep me?
They want to keep you, they just don't want to pay you (more than they have to).
After you leave, they will have to hire a new person and give them 120% of your current pay. (And the new person will be less productive, at least at the beginning, simply because they will be new.)
But the company is making the bet that you will stay, at least for a few years, because apparently most people do.
Many managers don't realize this. Even managers that have a ton of experience, all they do is fire or have harsh conversations with people who "underperform." The truth of the matter is a good manager is rare. 1 out of 10 literally and it's not an experience issue. A good manager is one who is highly highly unbiased and people are generally not like this.
The person you replied to is not a good manager. Based on his reply he is actually below average.
Basically for these managers good employees are those that can predict what the manager wants and how he thinks. If the person is able to guess and predict what his manager wants on a consistent basis, then objectives are more clear to this employee and as a result he can achieve them. These people are then perceived as "good employees".
Due note that a good manager makes objectives for each task unambiguous and crystal clear. A bad manager leaves a lot of room to fuzzy concepts like "quality of work" because he himself isn't clear about what he wants.
I have seen it many times. Employees who are basically geniuses fired because the manager wasn't able to realize how smart the person was. Instead the manager left the employee with vague instructions and expected him to just "get it." The manager didn't know that the employee is an expert in infrastructure and deployed him on writing algorithms...
This is an unwise and inefficient deployment of resources. It is the managers job to determine what each of his employees like and what they are exceptional at and deploy resources accordingly. It is also the managers job to understand in detail the nature of the assignment given to an employee so tasks can be handed out efficiently.
Bad managers tend to throw random people at random tasks without fully understanding the task or the person. In these cases there is an element of luck involved. How hard the task is versus if the person assigned to the task is suited for that task. An employee who handles the task well or is able to temper the expectations of the manager through communication is perceived as "good."
These managers are easily recognizable. I will tell you how to identify them. They perceive the world as employees who are "underperformers" and those who are not. The person you replied to put the world in 3 tiers lol. The world is very nuanced and it is impossible to divide people into three buckets like this. He is the quintessential example of "bad manager."
I'm unsure if you are asking for advice on how to improve because your current manager marked you as inconsistent or if you think GP is calling all people "who are trying to improve as inconsistent"
I'm a manager. I want to improve ALL of my team. To rephrase, I want each of my members to work on things that benefit themselves (they improve) and benefit the team - if we can't do that, I zoom out: how can they benefit the team, department, the company, the industry, the world. You might notice this means I may find a better place for them on a different team or even outside the company. All of this. ALL OF THIS is trying to help the person in an area that he/she wants to grow in.
Growth opportunities are very diverse: coding a new language, learning at a seminar, teaching at a seminar, side projects, art, games, mentorship
Its a lie manager making dev's effective at their job. All a manager needs to do is communicate the requirements properly most preferably in a written document. That is the only useful thing. Everything else like motivating are just BS which has become very clear in the post covid WFH situation.
Now looking back i can feel the needless interference by managers that slowed down the progress of work. The other sad thing is they assume they have power to fire people to some extent which usually junior engineers believe for the first few years.
Before concluding i had a bad manager, let me say i have had over 10 managers in the past 20 years and its not manager's fault its the job that's BS.
Precisely. Hence managers delegate this to devs to figure it out themselves and make documentation easy enough for them to understand on a higher level so they can make it look like they understand whats going on. This is what been exposed with WFH.
The important thing that pisses me off is the salary of manager is about 50% higher than IC's. IMO it should not be 70% of IC's salary considering the skills it requires. Manager does not have more responsibility than IC. Manager never takes responsibility for projects failure, its always blamed on IC. Its easy for a manager to get away because usually about 5 IC's will be in a project and one or two failure to deliver features are tolerated. Combine this with attrition its so easy for a manager to not take any responsibility.
I got a lot of joy out of helping everybody develop, find their groove and helping them coordinate and learn from each other.
The business demands I was shielding them from were extremely stressful though. A million things that everybody wanted done yesterday in wildly different directions.
At some point in trying to make concessions on the business side I started losing the support of a couple of senior guys on the team though. After a couple of months it was pretty clear there was no getting that confidence back. When the demands from both sides became too high to resolve, I didn’t have any choice but to move on. Really frustrating too because I gave so much to that job and team, but you can tell when you’ve lost people and there’s no easy fix like refactoring the code to make it all better.
As a manager, trust is the only thing that allows you to be effective; when your team knows that you are really looking out for them.
you kind of have to do this. idk how I could function effectively if I didn't have a reason to be looking at the code all the time.
Even if the manager specifically says "Hey everyone, give me some feedback. Be open and honest" - That's a trap. No one will ever actually do that, because if you bruise your manager's ego, they have the power to make your life a living hell.
As someone who has worked with managers who did tried to get too involved in projects, they just become a dictator. Since the manager will play an oversight role in the project, any small issues will be visible to them at all times. Normally, the team could work out small roadblocks on their own to keep stress low. If the manager is involved, they'll often try to "make themselves useful" and slow things down. Let's not even mention manager statements like "Hey guys, let's keep a note of this so we can work on restructuring our processes in case this happens in the future"... (Because everyone loves redrafting SOPs every 2 months, right?).
A good manager is one that stays out of the way and lets you do your job. Having a manager on a project kinda feels like that episode of The Office when Michael comes to Jim's party and everyone was just kinda standing around awkwardly.
1) I pick what I'm going to work on after the rest of the team picks their tickets.
2) I fix one bug per day, not matter what.
3) HIPPO (HIghest Paid Person's Opinion) is not an acceptable reason to make a decision.
It's worked well for me, your milage may vary.
Then I'll never know how to make things better. It's dysfunctional when you can't communicate safely and equally dysfunctional when problems are hidden for fear of a manager's ego.
If you cross the barrier the people in your team will be put under pressure having to do things like for example disagreeing with technical decision or debating something in a code review with... the same person that has the power to promote or fire them.
It creates a power gradient in every day activities.
That's "stealth" micromanagement regardless of the good intentions and technical skills of the manager.
Of the best managers I've worked for, one of the most obviously important things they did was keep other teams off our backs. Constant interruptions, shifting priorities, "just a quick question", and the like do more to destroy a team and its progress than anything else. Their name doesn't get attached to lines of code or completed items but a lot more things get completed as a result.
Do they need to be the one with hiring/firing/promotion/rewards authority? I don't know.
It was what it was, and it is what it is.
I just wrote about my own experience, and my own feelings about that experience, as opposed to rendering judgment (look through my posting history, here, and you’ll find very little judgment of others. I am too old and tired to fight. I have better things to do with my time, other than TCP/IP posturing).
1) reading emails. These emails generally consist of a few categories of things — stuff I need to be informed about, questions, asks for permission (a special form of question), documents (generally decision and decision docs, or stuff from Product), and meeting requests.
2) meetings. These meetings generally consist of stuff that couldn’t be handled over email, but is a lot of the same stuff. It’s also status updates, not from my staff, but with my peers. 1:1s and staff meeting (mine and my manager’s) are the balance.
3) There is no 3. Really, it’s a full time job to do 1 and 2. Every now and then I will carve out some time to write a document myself, but in general that gets delegated because I will do it more slowly than someone who doesn’t have a pile of time-sensitive email and meetings to deal with.
Oh I forgot - we give the people who do this control over the employment of the people who do the actual work. Very weird system.
> And yet one that billions of people participate in.
Most of humanity participated in slavery for a long time as well. A lot of Europe's city dwellers enjoyed watching the hanging of criminals at dawn or sun-down, too. People also developed the mass habit of accusing a neighbor they don't like for being a witch and were hoping to have them burned (because the neighbor's chicken pecked your watermelon seeds or whatever; yeah, people are that petty).
Appealing to statistics and what the majority does is missing the point of the big power imbalances that are sadly one of the constants in every human society or system.
It doesn't help that many programmers are rather introverted and prefer passive resistance as opposed to having a good and informative one-on-one meeting, of course. And many managers are stuck in the unenviable position of having to develop skills to extract valuable actionable info from introverted people who prefer to sabotage them behind their backs. I recognize that and I sympathize.
But the inconvenient truth is, and one many managers forget about all the time, is that most of us have zero decision power -- which is quite the shame because we need it in no small amount of situations.
Formulas like Scrum (or anything "agile" really) are a complete and pathetic joke. The process must adapt to the task at hand. The best performing teams I've been in had zero process -- they only had some 10-15 ground rules like "if you are stuck for more than a day please raise the issue with the rest of the team; nobody will think you're stupid, we'll only try to unblock you". Whatever needed to be done, we used our own breed of process that best served it. On the rare occasions Scrum was actually useful btw. Most of the time the schema was more or less "enable your ICs, actively seek to unblock them, then leave them the hell alone, they know what they're doing".
You alluded to (in another comment) that you don't make the decisions; that you facilitate the people to arrive at the right decision. Kudos to you but you should still recognize that you're the minority, sadly.
Most programmers are forced to work with managers whose ego is easily bruised. That's a fact of life, one that can't be fixed by going to another job because the odds are at least 90% that it will be the same there as well.
So yeah, there are problems on both sides, that's unquestionable. I mostly went on to rant about how appealing to statistics is a poor strategy to evaluate if a given system is good (which doesn't at all explain how many companies started getting more bang for their buck after they moved to a 4-day working week btw; among other examples).
It’s quite simple - you as a manager can only do the work of one IC but your are responsible for multiple ICs. If they sit idle, make the wrong decisions, are demoralized or leave the company, you hurt the org much more than help by technical contributions yourself.
I’d put the cutoff at about a team of 6. Below 6 you can do technical work yourself, above 6 you’re better off taking care of your team.
[1] This business jargon term has seriously got to go. It's bullshit and oddly demeaning.
As a manager-of-managers, when I hear that a manager is doing "a lot of sitting around, waiting for stuff to happen", it's usually a sign that something has gone wrong.
Don't get me wrong: I don't expect everyone to be productive 100% of the day, but if managers are reaching a point where even they feel like they have too much free time then one of two things has happened:
1) The company has grossly over-hired for the workload at hand. If all the tasks are done and the manager couldn't find anything to do if they tried, it's possible that the company just hired way too many people or greatly under-shot their workloads.
This really does happen at some companies that get so big and profitable that executives start chasing headcount and having the biggest department they can get away with. You end up with so many managers that most of them spend their days sitting around or, even worse, inventing new and unnecessary work for their teams just to fill time. It's not good.
2) Or: Managers have too narrow of a view of what their job is. Speaking generally (not accusing the parent comment) - This often happens when developers who haven't experienced good management or managerial mentoring get promoted into their own management positions and assume their job is literally just to delegate to the engineers and then check on them until it's done. In non-stagnant tech companies, there is always more for managers to be doing: Reviewing/updating documentation, helping with hands-on testing of the product, observing or interacting with customers to get a deeper understanding of the problem, coordinating with the sales team to get a better understanding of their domain, and the list goes on. Many of these tasks aren't immediately obvious without proper managerial mentorship, and they might be downright foreign if your only experience with managers has been of the delegate-and-wait variety.
Personally, my experience was that I was far busier as a manager than I ever was as an IC. IC work is more narrowly scoped and easier to constrain to specific time limits, or get targets and deadlines shifted according to however much work could be done. As a manager, the amount of work that could be done was both never-ending and also extremely varied, comprising tens or maybe hundreds of possible tasks that often needed attention in parallel, combined with the inter-personal demands of managing people and constant hiring.
From a security standpoint (because that’s my wheelhouse), if you’re not under attack, your metrics suck, if you chase tickets, a lot of them get closed without effective resolution.
We’re not manufacturing widgets, and can’t earn that bonus by making 10% more widgets.
In other words, only stupid people have a work ethic?
Big companies tend to hire "specialists" to do all those tasks you mentioned, which I think is a mistake. If the purpose of those tasks is to improve the function of product development, which can be rephrased as "make the coders more effective" then each of those people require a high bandwidth communication channel to the coders. You can only have so many people that you communicate a lot with, and so the effectiveness of those people in improving the effectiveness of product development is limited. Their job is to make sure the devs arent working in silos but they all just end up forming their own silos because its simply not practical to have high bandwidth communication with all these different groups of specialists.
Im talking about designers, product managers, project managers, user researchers, data analysts etc ...
My broader point is that I agree with your vision of what a manager should do but IME it's not how larger companies tend to be structured.
I use the time to triage my day. Works a charm.
The only problem here is an employer claiming ownership of a personal project, assuming the personal project isn’t interfering with employee product delivery and isn’t violating employer security policies.
My solution to this is dual employment. My secondary employer has trouble differentiating work time from personal time so they end up with the most liberal IP assignment policies I have ever seen. Everybody, corporate IP attorneys, know this.
So, unless it’s making money or an employer wants to lay down a provision patent they won’t fight you on it. They are fully aware the alternatives are moving to another company or to stop innovating. As a result most employers with silently bless the personal projects even on company time. They won’t bless these efforts directly because personal projects on company time or property are ethical violations that legally compel the employer to take ownership and shut it down. That is the last thing anybody wants.
I was careful to keep my side work to stuff that did not interfere, or compete, with my corporate employer, so there was never a problem.
As a JavaScript developer everybody wants to tell me how it’s done, what the right way is, and so forth. It’s not worth arguing over because the most incompetent developers tend to be the most vocal ones.
I have been writing JavaScript full time for almost 15 years and most corporate JavaScript I see is complete garbage. How do you know what excellent code is? Numbers. Code size, execution time, maintenance time, defect resolution time, test automation capabilities, new feature delivery time, and so forth. For example if your app takes 4 seconds to load and mine takes 50ms I will just assume I am less wrong, but you can’t advocate for that because will cry about code style and frameworks and other bullshit. So silently I write my personal project.
I also have a vision of where I want the team and the company to be and try to get strategies to achieve it. For example, increases pay bands justification, promotions, career ladder, more training budget, paying for software, approve open source usage requests that are blocking someone etc.
Experienced this on multiple occasions especially recently and it does indeed hurt - especially when you know what a difference it could make to users or fellow developers and it’s ignored or ignored and then some higher up miraculously suddenly invents an identical idea several months down the line.
Bonus points if it’s a whole team effort for almost two years that gets more or less scrapped despite the obvious need for it as a dependency for multiple teams.
One of my dreams, was to be in a place, where I could create and craft my own work, without having others take steamers onto it. It's personally gratifying, to know that all the "I could do this better if..." stuff was absolutely right.
These days, I have to keep the scope small, and, still, no one is getting rich, but I am pretty chuffed with what I'm doing.
Can't put a price on that.
One of the reasons that I hated being a manager, was because the job involved a lot of sitting around, waiting for stuff to happen.
I couldn’t work on my own projects (because I was on paid work time), and it would have been irresponsible, in the extreme, to put myself into the critical path (because it was no guarantee that I would be able to reliably work). I sometimes tasked myself with projects for work, but they were almost always ignored by my company, and that hurt.
I’ve heard that being a soldier in a combat zone is long hours of idleness, punctuated by short periods of terror and stress.
That pretty much describes my time as a manager, without the “terror” part (and the bullets and explosions).
It sucked.
I now work at home, on my own technical tasks. I get a lot done. My personal productivity is through the roof.
I take a lot of breaks. Sometimes, I even nap.
But I don’t have a time clock. I will often start coding, at 6AM (sometimes, before I even get in the shower, after my morning exercise), and will continue to code, until I hit the sack. I often test my software, while I’m sitting in bed, and will enter issues, from my iPad.
When I have a problem that I’m chasing, or I am in the middle of a big implementation phase, I can work for many hours, straight. I will barely come up for air, and I feel absolutely exhausted, when I finally step back (nap time!).
I’m not particularly concerned about a measured life. I get a lot done; far more than I ever did, when I was being paid.
And I’m having a blast.