I’ve been reading some variant of this, for many years.
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.
As a manager, your main job is to make your ICs effective at doing their work.
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 agree with all of this. But I can honestly say in my entire career I've only had about two good managers. One of the biggest issues in my experience is knowing who the bad/good performers are. Most managers have no idea. I've seen bad performers just let be, and I've seen great performers fired for seemingly no reason at all. Both kill team morale.
I'll add that if a good manager works with an underperforming IC and makes a meaningful difference, it is VERY UNLIKELY the IC will acknowledge this in a timely way, or perhaps even know it happened. The best case scenario I've ever experienced is several years after the fact. That's a long time to wait for some positive external validation.
Oh for sure. My first comment is pretty much me bagging on managers. But in their defense, it's a really hard job. So hard I've never taken it on because I'm positive I wouldn't be good at it. I think my experience of most managers not being as good as I'd like largely boils down to the job being extremely difficult.
I'm not surprised to hear a manager's work can go unnoticed. That's unfortunate :(
I think management is like sorcery. There is no fixed rules and most of it is interaction between people. I fully understand why many technical people shun management work (even when it pays more).
Good management is really rare. One in five or even ten maybe.
One in five to ten for delivering positive business results in a short period of time. AKA these are good managers. They're able to have good results because of themselves. Under promise over deliver. Set lower expectations.
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.
Many managers are bad but can keep the job for a long time. This is because it's not the people that you are managing that judge your performance. So you can very well be a bad manager and still keep your job. The key here is that you only need to be a manager that delivers results. You don't need to be a manager that is good.
Well, many of my employees chose to give me testimonials on my LinkedIn, and they had nothing to gain from it.
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.
Yup. But it wasn't all hate. I worked for a company that I believed in, was a peer with some of the finest scientists and engineers in the world, ran a team of very high-performing engineers, and was proud to be a member of that brand.
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.
I'm an engineering manager with only 4 years in the role, and I think it's more of a lot of things I hate with intense periods of excitement, joy and satisfaction. You might be able to get 20+ years of that, depending on the details. That's why the OP's original analogy of a far less dangerous, corporate version of military combat resonated with me.
It’s hard. At least for me, this is the hardest classes of employees to manager—-it’s much easier to get rid of somebody who is clearly failing or reward and further develop a high performer.
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.
Thanks. Basically I'm told that some stories I complete quickly while others drag out. I'm on a team that works with multiple systems (10ish), multiple languages, multiple stacks/architectures, and am expected to be full stack.
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?
> 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.
I can assure you that much of underperformance is a perception and miscommunication issue. If the employee is motivated and not stupid then if he's underperforming it's because objectives were not communicated or the manager failed to realize that the assignment was impossible not to underperform due to missing some challenging detail.
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."
>"trying to improve uneven performers"
>How do you do that? Apparently I'm an inconsistent performer now.
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
The earlier guy you replied to was a "bad manager". This guy you just replied to is a good one. He gets it. Note how I said a good manager very much assigns the right task to the right people.
> As a manager, your main job is to make your ICs effective at doing their work.
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.
Let’s say that’s the manager’s only job. But “communicating requirements in a written doc” is serious hard work, the same way “typing code in a text editor” is a lot of work. To do the former requires negotiating with other teams, understanding the limits of the audience, estimating effort, and basically developing a rough sketch of the solution in your head to make sure the request is reasonable.
> But “communicating requirements in a written doc” is serious hard work
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.
As a manager, I quickly realized that trying to be a technical contributor was a subtle and insidious form of micromanagement. Also, I could give myself my pick of the coolest tasks, which was unfair.
One of my favorite jobs was managing about a dozen Python programmers for 3 years…because I don’t know a lick of Python and it forced me to focus on the team more than the tasks.
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.
It sounds like you were trying to be too nice and were trying to appease both sides; that’s a losing proposition. You are working with adults, and adults should be able to handle bad news (if handled properly), and a good manager should be able to bring the bad news but at the same time give enough context so that everyone understands.
In a perfect world you would be right, but spend some time with a bunch of clueless executives who don't know how clueless they are (or are trying to pretend they do have a clue) and you'll realize there's no amount of context that will help them realize why there's bad news.
Maybe. It was my first time being full time management only. Balanced it effectively for the better part of 3 years. There were a lot of unique challenges (in the non-exaggerated sense) and learning experiences in that job.
The alternative is you give yourself the low priority low probability work. The 'noodle around this nasty thing nobody wants to touch' work that delivers tech debt reduction or a velocity win. It can be very fulfilling, but no critical path, no OKR or delivery date etc etc
this is right. no, you don't get the big win. but you do get to put in that cleanup that everyone is always talking about. and you get to actually write the tests that no one else has time for.
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.
yep, The self-assign for many managers should be boring spikes, documentation and execution tasks. You will need to get your tech fix somewhere other than your day-to-day.
There's been times where it's the right thing to get involved, and other times when it's not. For example, we had an issue with full ticket completion: sometimes 3 of 5 requirements would get complete, and then the work was merged. I wouldn't review line-by-line, but I would cross-check the features and note if I found something missing. To be clear, I would not dictate how to do the work. In the meantime, we instituted processes to ensure work was completed in full, and once the team norm'ed around the new process, I stepped back.
Not the person you replied to, but it's because manager's will never truly fit into a project. Most people don't want to go against the manager, or question decisions made by the manager.
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.
At least that's what you think. I'm sure your direct reports have a lot of opinions on that setup that they'll never reveal. I say this with 100% confidence.
> I'm sure your direct reports have a lot of opinions on that setup that they'll never reveal.
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.
Because you either manage people / goals / interactions with other teams or do front line work.
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.
It sounds like you're saying that even reviewing code of subordinates is micromanagement? If you have a team of junior developers, who should review their code? Someone from another team?
Each hour put in as a manager is many times the return of you as an IC (for better or worse). As technical work is an endless pit of time, it’s very difficult to be a hands on manager that’s effective.
Very entertaining to read a thread of managers telling themselves they shouldn't do any work, and then simultaneously describing not doing any work as "many times the return of you as an IC" (presumably counting themselves not interfering with the people doing the actual work as equivalent to doing the sum of that work).
If you think "hands on keyboard coding" is the primary/only form of work that matters, then you've missed out on a lot.
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.
If you want that then hire someone to stand outside your office with a stick and reply rudely to emails. We don't need to give them hiring/firing/promotion/rewards authority.
As an IC you can't tell other teams managers or higher ups or PMs to fuck off if they call you directly and tell you they think what you are doing isn't good. Or if they ask for unreasonable stuff. At least without fear of getting fired. A manager needs to prevent this from happening
I guess it depends on what the person is doing. A guy with a stick won't be negotiating timelines and requirements, explaining why things can't / won't / weren't done, dealing with fallout or shifting the requirements / timelines of others based on teams productivity.
Do they need to be the one with hiring/firing/promotion/rewards authority? I don't know.
I don’t especially care what people think of the job I did, or how I did it. I made enough to be where I am, today, and I like it.
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).
Your imagination is very far from the reality of what managers do. I’ll give you a run-down of my day:
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.
I'm not sure what's more unsettling to me: That we have managers here who believe that reading emails and sitting in meetings is considered contributing and making an actual difference... Or that HN has this many managers on it who apparently really cannot code or directly contribute alongside their team; yet are posting on a more technical forum, on a regular basis. Strange. Guess it's like a hockey fan who watches every game but has never laced up skates themselves.
Former manager here - you'd be very surprised at how much effort it takes to act as a human shield for your developers to keep the interruptions to a minimum and keep their roadmap stable. It's work, and it can be delicate. Try running interference with a company president who wants to bother your developers when they're trying to get something out the door, or trying to make sure stupid ideas die before they become your team's problem.
And yet one that billions of people participate in. You are either a genius of epic proportions or just wrong in your thinking here. As long as people in coordinated groups get more done than individuals, I believe you are wrong.
Btw, I never said “telling the rest of them what to do.” That is a complete misconception of management, at least the way I believe the best managers practice it. I only get involved in decisions that my team has been unable to make themselves. Even then, I rarely find myself having to be the decider. My role is to facilitate a good decision, not to tell people what to do. The team looks to me for prioritization and providing context, not to top-down manage them.
The other guy is definitely a bit jumpy and as a programmer I can't agree with him (fully) but that part of your comments stood out to me:
> 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).
I undoubtedly compressed too much into too few sentences. My allusion to genius||wrong is raising exactly this concern. How do you decide which? For me in this argument it comes down to results. Why do people organize in this way? As I stated,I believe groups get more done than individuals and that coordinating those groups becomes the central feature of management. It can be done poorly or well, but if it facilitates the group being more productive than an individual it is superior from a pragmatic perspective.
Managers do work. They decide you what need to be done, when it’s due, they coordinate processes inside and outside the team, they (hopefully) review what gets implemented, make sure the team has the physical things it needs, build budgets and roadmaps, isolate the team from organizational bullshit, work on hiring and more.
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.
No kidding... We got managers here saying they don't know a lick of Python their "IC's" [1] work on, or they can only contribute by ordering pizza when their team is working hard. Seriously...talk about textbook Dunning-Kruger. It use to be people got promoted to manager from becoming experts in the task they would now manage... Now they are spawned from business school, I guess. It's fine to be a manager and manage a team, set goals, deliverables etc etc... yes, it's a real job. But damn you for not being able to roll up your own sleeves and put pen to paper with the rest of your team to achieve those goals.
[1] This business jargon term has seriously got to go. It's bullshit and oddly demeaning.
I am currently a manager and the few times where I have said “I am going to write part of this solution my team is working on.” Were the times that I got a big pile of management work and blocked the team. I have since learned my lesson.
> 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.
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.
There is always more stuff to do but a smart person would quickly notice that only things that show up on metrics or are personally fulfilling are worth doing. The managers I’ve seen promoted chase metrics only and don’t sweat the other stuff. The good ones also take care of the people. The terrible ones try to do everything and anything that they think might be good for the company and ultimately piss everyone off and burn themselves out.
And it’s NOTORIOUSLY hard to attribute effective metrics to IT.
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.
No you're simply wrong. Plenty of smart people have a sense of loyalty and want to do what's best for the company and their colleagues, not just what's expedient for themselves.
"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."
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.
Even then, the manager needs to reaching out to those specialists, coordinating and nurturing those relationships. No one says the eng manager needs to be all of those roles, but as the member of the team without a "real workload" they should absolutely be the liason to the rest of the org.
Is it really that bad for a company to have over-hired? Wouldn't it be better for the employees wellbeing to have a company that over-hires rather than under-hires?
I feel you in terms of the hacker lifestyle you’re describing. I often work from home too (1-3d/w). Fully emersed and free, getting a lot done. But I‘ve found going for a >1h walk a day really helps. The body feels more awake, my eyes are more relaxed, my thoughts are reordered and some new inspirations and ideas emerge.
> I couldn’t work on my own projects (because I was on paid work time)
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.
It was that (my employers had very good lawyers -especially wrt IP), but also, I felt a great deal of Responsibility towards my company. I know that my attitude is often derided in this crowd, but it was what it was. I did a great deal of work on the side. The job wasn't super-demanding, and I often spent time at my "day job," thinking about the side work; though not actually tapping on a keyboard. Technically, that was a Bozo no-no, but no one got hurt. In fact, a great many people, all over the world, benefitted from it.
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.
My primary motivation now for personal projects is a silent anti-Dunning/Kruger.
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 have a blast being a senior data scientist, and I've recently turned down a manager role precisely because of the points you raised, despite the better pay. Your comment made me glad of my decision.
As a manager I feel my days are always short, I work in a big company and have 1:1s with other departments to develop relationships, to try to influence other team’s roadmaps , to check how other people are doing that used to be on my team and how can I help, to talk with end users, to mentor junior developers… I can pick and choose what I feel has more impact on above.
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.
> I sometimes tasked myself with projects for work, but they were almost always ignored by my company, and that hurt.
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.
Well done, sounds like a great setup you've created for yourself. I'm a manager and looking for a financially viable way out/back. I haven't coded since I left college and and have some small ideas for some side projects, has anyone here hired offshore coders for small projects like an addin for outlook etc?
It was a long time coming. My stint as a manager helped me to make some great relationships, and I know that I helped a lot of other ICs have great careers, and great personal lives. None of us got rich, and there wasn't a whole lot of crazy (until the last couple of years, when we worked with an American startup, and I couldn't shield my team from the dysfunction).
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.
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.