In the fifties management studies (Drucker etc) was focused on the manager as a systems creator - who would bestride the business world fixing, innovating creating smooth clockwork systems.
Today Google's eight rules for managers is basically a cross between HR and a life coach.
Systems are now run by software - and the inevitable conclusion is that coders are the new managers.
As more and more software eats more and more of the world, there is less and less need for anyone who is not coding or talking about the code.
We may see the end of rigid hierarchies at the same time (a similar but related issue), which kind of points to two things
- code is the thing. And discussions around the code matter. And the prime examples of doing this are in FOSS - so expect more open public disagreements leading to better quality code
- Public (internal) discussion of issues means a lot of self-governance and a lot of "politics". This goes on anyway but if it is kept public it is kept honest
- management has always been about resource allocation and it is best to view senior management as financiers not executives - this might be the best split internally - senor management buying from internal self organised resources.
- Incodentslly I think a lot of the problems facing most companies today are that they cannot work out how to measure quality work during rmeote work and cannot get people to communicate if they are not all in the office. Having a big email discussion list is unwieldy - but if that is your organisation then conways law will explain how your software works. if you don't like it, it is waaay easier to adjust your email lists than move offices.
Edit: imagine Bezos' two pizza teams - each can be viewed as a independent contract supplying a business-micro-service - at a doctrinal level style guides and devleads / linting rule, and at an operational level it's which micro-services, how to combine their output, etc etc
(i need to expand this but Amazon might not be a great company to work for but the organisational design seems to point i the right direction )
>Today Google's eight rules for managers is basically a cross between HR and a life coach.
Is Google something to aspire to? They got early into a very lucrative market and have basically been milking it for decades. Good for them but luck isn't reproducible. Their ability to deliver new products is so bad it's literally a joke. I can't even remember any viable new product from them in the last decade (the 10th iteration of chat doesn't count). In terms of productivity they were known as a rest and vest company. Great for engineers but I can't imagine it's great for a company without a near infinite spigot of money.
>> As more and more software eats more and more of the world, there is less and less need for anyone who is not coding or talking about the code.
This just doesn't match my experiences at all. So much of what we do to build software has nothing to do with the actual code. I've recently worked in both a very micro-services oriented organization and a magnificent monolith and they have very similar, non-code problems; the difference is were they exist in the software and in the organization.
If you're interested to see how your "operational management defines composition" idea can go horribly wrong, google what happened when Dell migrated their hierarchy to align with micro-services
I mean, I'm not convinced by the comment, but I think the article is talking about managers of developers, nearly all of the people here are involved in development, mostly at companies which are predisposed to trying to replace humans with software (because their product does the same)
So the interesting question is, in that context is a manager becoming ever less necessary
I mean a company is effectively "just" a machine to deliver a service / outcome from inputs. It is a set of processes - which can be codified. why not in software? And if you want to chnage the process, make a release.
This is how you get a "why do I have to ask on HN to get lucky to have someone at Google who knows how System X works see my post to get support on this stupid product?" reality. Inflexible machines that run on rules are not even a unique feature of software, but they are good at slowly making your customers stop liking you.
The hard part of the "machine to deliver a service / outcome from inputs" is not "formalizing a process in code." It's designing that process, in all its gross real-world complexities, and then (even harder) changing it as the underlying world changes.
If it was easy to actually nail down the requirements in advance, you could ship out the coding to meet a spec to the lowest bidder.
Yes. And it's not like human management does this "design a system" so well at the moment that replacing them with coders focused on explicit expressions of a process is going to be much worse.
A number of comments are "it will be awful if the code is bad because the code is inflexible". Yes. That's called bad law. What we want is to write good law.
IMO this is truer than you may realize. The future of human work is customer service and empathy, understanding people and what they want in detail. Everything else can be automated.
>>>> Systems are now run by software - and the inevitable conclusion is that coders are the new managers.
I shudder at the thought of being managed as badly as most code works. Most sufficiently complex technologies have to be operated in manual override mode most of the time.
Reminds me of the short story Manna [1]. It gets a bit weird towards the end, but the first few chapters at least seem like a reasonable prediction of the hellscape that would result if you put a fully automated management system in charge of people.
Its freedom to manage yourself, if you can hack the system sufficiently enough, that it avoids interacting with you. So as strange as it sounds, if you are clever and already managing your manager, nothing changes.
You would think that keeping the team effective is the basic job of a manager. Dealing with people who don't know how to do some part of their own job is of course an unfortunate, yet inevitable reality. But this is on the level of "developer who doesn't know how to code". The article leaps into teaching the manager to do their job, but often just switching teams or companies is much easier. Plus, after you put in all the effort, not every manager can turn around and appreciate it, many will just take credit and give you nothing. So if you're going this direction, there should be some thought given to deciding whether your manager would recognize your efforts.
It sounds like you're assuming "managing up" is about managers who don't know how to do their job. I don't think this article is saying that.
My best managers weren't ones who knew every detail of each project and could give unsolicited effective advice. They were ones to whom I could tell what was going on on my project, could ask for help, could tell them what I needed, and then rely on them to follow through on helping make that happen. Sometimes that was needing more time for a deadline, sometimes it was needing a mediation in a complicated relationship with another team, and sometimes it was using manager clout to go escalate a request for compute resources.
In any case, two-way communication is going to create a more effective relationship than expecting your manager to simply _know_ what you need.
I mean, if you’re in an adversarial relationship with your manager you should think of changing that, but a lot of these are just misunderstandings and the inability to have the entire team in their head at once. Like, as a developer, you can be pretty good at writing code and still get useful feedback from a code review. Having a communication channel open with your manager helps them do their job better and also helps you, and doesn’t necessarily indicate any sort of personal failing.
The fact that you implicitly assume that sharing information with your manager means they are failing to do their job is probably indicative if a bit of an adversarial attitude. At least it also came across like that to me. The way I see it, most managers I've worked with have been stretched for time and me giving information will only make things better for me and my team because the quality of their help will be better, regardless of how good they are at their job.
I agree you should not try to push through a bad situation, it really depends on the people involved and it's hard to give generic advice.
There’s an “if” in front, to help people recognize that my comment applies to healthy relationships and not unhealthy ones. No comment on your relationship with your manager.
However at the end of the day, what's important to me is to feel I've tried doing the right thing.
This means I can't do things conditionally or "only if I trust my manger won't take credit for it". If I want to be credited for my work, I feel that it's mostly my responsibility take credit for it.
It can be very difficult to change people, teams, processes, companies so I understand why we may want to get something out of trying hard to improve things we feel others should want to improve as well. It's not always as obvious as "a salary increase" or "public recognition", but employees who try to improve processes indicates to management they are interested in sharing their input and committed to making things better. This fosters credibility, and creates a more positive work environment.
Job hopping may often be easier but is often seen as a red flag by employers and it can make it difficult to build a strong, long-term career.
What is unfortunate in my opinion is working with developers unwilling to learn more about systems and infrastructure. With the rise of DevOps, it's often the norm that many developers don't know how to do some part of their job. As opposed to your comment this is not on the level of "developer who doesn't know how to code" but "developer who don't know how to work with the underlying systems, builds, deployment processes, and the underlying infrastructure powering their code".
When people are unwilling to learn from others, they are missing out on opportunities to grow and improve. This can lead to a feeling of being stuck in a rut, and can ultimately lead to dissatisfaction with one's job or career; as much for people who lack some expertise and are unwilling to learn, than for those who can help them increase their competence in this closely related field of work, who often end up doing most of the work in this field
Another manager here and i might be able to provide some insight into WHY you find managers who cant manage people.
Most large multinationals have very rigidly defined jobs, job descriptions, point levels and compensation bands.
The terminology may not be the same but the overall effects of the system are the same.
Lets say you have a great tech, they are a "tech level 3", position level 100 and salary range "G".
If they want to make more money they need to move to salary range "H" and need a JD that matches that salary range.
So they are promoted to a manager role to keep them, and to pay them what it takes to keep them. Did they want to be managers? Are they suitable for the job?
I've dealt with this scenario many times in my career. Sometimes it would be far better off for everyone of the system wasn't so rigid, and that good people could be paid to do their jobs and not be artificially promoted to management positions.
It is an interesting "cobra" unintended consequences effect.
The goal of the system was fairness and to manage costs. The unintended consequence is having many unqualified managers as people game the system to their advantage.
Not disagreeing that many excellent technical ICs get promoted into roles where they are ineffectual managers, but dual career ladders that let technical people stay in technical IC roles while getting promoted have been around for quite a while by now. The last 3 companies where I was a manager all had them, and principal developers were parallel (in hierarchy and pay) to senior engineering managers.
I think the biggest problem is that engineering management is not thought of as a craft to be learned and improved. Most managers don't put anything like the amount of time and effort into getting better compared to technical ICs.
Maybe we should dispense with managers except at the very top and just choose a random person from the team to be acting manager for the week. If some person from the team will end up being manager anyway, choosing randomly minimises the disruption to work, since your best performer will be saddled with managerial duties only occasionally.
Had a similar experience: I think regrettably if the timescale is this short, no-one knows who to talk to (from other teams/the proper managers the level above), there's some need for memory/dealing with long-running things, and so you end up with backseat driving, revisiting the same issues without decisive action taken, etc
Kind of similar, but I was thinking of replacing them with team assistants (a kin to PAs or secretaries) for teams. This is nothing but just renaming the current roles except that it takes the connotation of a manager being better, more experienced or more jiggly valued than rest of the team. Perhaps that'd work?
Designing comensation systems for other people is a people management tasks. How do you envision a situation where ICs are doing management tasks but not given the title and/or pay of a manager?
A lot of managers were well-performing ICs that got a promotion, either because a manager position needed to be filled (and they were the least bad option) or they needed to be promoted to keep them (which in some cases is the only way to give them a raise).
Neither of these means they have even the basic skills to be a manager at all, let alone a good one.
Unfortunately since these types of managers don't recognize good manager skills, they'll go on to promote more unqualified ICs below them into manager positions.. and the cycle repeats.
The bad ones are managers who were never good IC nor tech people. The ones who simultaneously have very little social skill.
For all complaints about social skills of programmers ... have you ever tried to cooperate with manager? All the social work will be on you cause they just can't do it.
Managers might be a good idea for a factory line; might. Managers job is again not to direct and guide people but keep the boat floating and the milking going. The mentoring etc is kindness and an extra -- if it was their job they would be called leads or mentors. When was the last time the average manager was fired/reprimanded for not mentoring and improving and leading people? They are there to make sure the river keeps flowing.
Software industry is weird because you are trying to apply factory line management to computer scientists, engineers, mathematicians, ... Let's see how long this keeps going.
The problem is that if your manager doesn't know how to do his/her job then some of this advice may actually be harmful, as they're viewing everything through the lens of their own inadequacies or insecurities.
Which is not shocking considering that at many companies the skills that get you promoted from junior positions (technical ability), have nothing to do with makes you successful in a more senior/management role (managing people/selling)
This is something I really didn’t understand when I started my career, and I realized I just got lucky with my managers for looking out for me.
I still kind of don’t get how managers don’t assume their staff want to promote upward (at least as a default), but I respect that I am also not a manager and don’t know the amount of things they need to juggle.
Think (some) single parents with kids, (some) people doing elderly care for their parent(s), people who have decided the work/life tradeoff isn't worth it, etc. Almost every team has at least one person who wants to interact as little as possible and have a decent salary, and in return, turns out quality code and meets expectations to the letter, then logs off.
There is also a very fine line to walk with an employee who wants to get to the next level for salary/prestige/ego, but isn't willing to push themselves or improve, and constant conversations of "hey, if you want level N+1 you need to be more involved in code reviews and be better at meeting your commitments (or estimating those commitments)". It's not fair to try to hold a level N to a level N+1 standard in the name of "career development", and there is a point where it's not worth your (or the employees) time and stress to "pull" them up to the next level.
Yeah, I guess it’s tricky. As a new parent I had essentially told my manager I wanted to put the brakes on career progression for one year, and he was very receptive. So I understand that perspective a bit.
ya. i want maybe 1 more level and then that's it. max stress/responsibility I'm willing to accept.
even that I'm not sure about, if my TC wasn't tanking right now i might not even want that level
I feel like I’ve seen this posted written multiple times by different people and it feels like it’s written in a very idealized world like somebody is at a place that values good management and thinks this type of thing is what most managers are.
Something I (cynically) learned in school and then relearned in the professional world is to get good marks there’s two steps (1) remove any excuse for the person to give you a bad mark and (2) make it easy to give you the good mark, ie you should be making your manager’s life easy and your manager’s life should only become easier if they give you that promotion.
There’s a post here talking about life coaching as management and if that the case then, sure, this type of communication hits on (2), but my experience has primarily been with results focused management and being able to solve assigned problems was the key for (2).
University taught me the same, especially in CS. Use professor's style, clear and readable code, don't be clever, turn in work early, etc.
Professional life is similar: be autonomous as much as practical, fill in when managers are gone, over communicate just a bit, complement their weaknesses, be humble.
Here's a good question to your manager: How did you feel about that?
Asking for immediate, gut feedback about something that you did, or happened to the team, gives you a read on how much managing up is needed, and/or gives your manager an opportunity to say, "I was surprised by that and I need to know more" or "That's not the direction I was shooting for, let's adjust this."
I also once explained that there was only 10 tonnes of concrete coming in the next truck and doing both #1 priorities was physically impossible, so it was time to choose. My manager, laughing, said, ok, so now you're really going to make me choose, huh?
Humanitarian logistics was easier than software because sometimes the choices were so stark and unavoidable.
As an Engineering Manager I've found two simple tools can help with almost all of the items mentioned here: brag docs and one-on-ones.
Brag docs help you, the IC remember what you did all year and your manager at review time. The keys are the right level of detail, capturing the soft stuff that doesn't get recorded anywhere else and the discipline to keep it current. If anyone else has had to spend a day or more 2x a year getting their performance reviews done, the commitment of 10-15 minutes every week or so is an easy sell.
If your manager hasn't butchered your 1:1s, turning them into status updates (and you actually have them scheduled) many of the other points listed are great topics for discussion. I love it when someone on my team asks a specific question about promotions or upcoming work opportunities or something we both experienced. I rarely have the answer but always get it and follow up. It makes me feel good to be helping the individual (and the team) and we're actively building a relationship on respect and caring.
I don't see these activities as the typically negative "managing up". Taking active responsibility for yourself and your team is a good strategy. I look for motives when people act, and these all tell me the person cares about themselves, about other and wants everyone to get better.
Yeah. I interviewed with a startup at the beginning of this year and the Engineering Director was telling me how he brought his friends on-board like it was some sort of selling point. People he has known since high school. Hard pass.
Friends plural is slightly worrisome, but we're they qualified for the positions?
I personally love the idea of recruiting friends and working alongside them. Obviously I could see this going both ways, but given that everyone is qualified I don't see the problem.
The problem comes later where a friend-coworker is found to perform poorly/behaves inappropriately/slacks off etc. and has been given multiple warnings. You are now in a difficult position of having to prioritize either your professionalism or your personal relationship with them.
Given that friendships tend to last much longer than jobs I'd hazard a guess and say that most people would let the issue slide.
There's also the risk of cliques, concerns over unfairness in internal promotions and pay rises, and groupthink from being surrounded by like minded people to be worried about.
I have a similar thought, as I rarely become friends with incompetent people. If I were to launch a startup with my friends (that I have worked with over the years) that would be an incredibly competent core of engineers
You have the filter pointed the wrong way. I don't go through a list of friends and filter out people that are incompetent at their jobs, rather the competence filter results in only competent coworkers joining the friends list
People that are competent are more enjoyable to work with, so there is a higher likelihood of us becoming friends.
Incompetent people are annoying and I don't become friends with them
Not only does this article make it your job teach the manager how to do their job, the article does not admit a cardinal truth: the manager unnecessarily eats into the value that you produce and should therefore be eaten in turn. If you can manage up, you can eliminate the manager, and gain your total share of the value production.
You can't eliminate a manager just by managing up. Do you want to be making the calls of who gets put on a PIP and managing them through it (or out?). Do you want to sit in meetings talking about business priorities and advocate for yourself and your coworkers? Do you want to be the one to manage compliance concerns around process for yourself and your co workers? If yes, are you then going to complain about meetings and how you can't get anything done?
Bad managers are clearly bad, but good managers make it look super easy and boring because hard business priorities get communicated as a simple and well crafted message, employee issues are handled without fuss and out of sight before they become big issues, and compliance and audit concerns are solved at a system/process level before being rolled out to teams.
Nothing racist about this remark. TCS, Infosys, Wipro, etc. produce bad managers, along with additional baggage: they inculcate sycophancy across the management chain.
Even though most of the management in American companies is incompetent, I won't hire these people for this reason alone: they perpetuate chamchagiri/sycophancy across the chain.
Why is it racist? Just because they are Indians? If so, you are missing the point: these consulting companies don't judge managers by competence, they judge managers by the number of tickets closed, by the number of billable hours, their chamchagiri(sycophancy).
If they get paid per ticket closed, they’re judging the manager on the measure most important to the business.
The problem is you are likely to get stuck in a local optimum where you burn out workers to close tickets. Growing them and making them want to stay takes longer, but ultimately leads to better results.
Your past statements do not whitewash your current statement. See the unfolding Kayne West saga. Your statement stands on its own.
My question was: do you think this is limited to Indian consulting companies or is endemic to all consulting companies? You seem to be doubling down on I would say the accusation stands verified.
Everything the OP listed out. A software engineering manager is a mixture of lead developer, project manager and coach. They need to vet the output of their team, understand and guide the implementation plan, help the team grow and stay current, and use that information to hand out raises.
The question you should be asking is: why would any manager allow themselves to be in such a state of ignorance for very long? We can give a newly promoted manager some leeway, but after 1 year if they still don't know how compensation planning works, they are doing the team a disservice.
I feel like this list may be applied to parenting, teams in school, etc. Good communication is a big part of successful relationships and teams/groups.
OT but I am making a year-end resolution to skim everything Julia and Patrick have written on their site, then make a list of deep-dive pieces.
The amount of useful content these two crank out is mind-boggling. They hold down day-jobs and write more useful stuff than 98.3413% of writers out there!
I would love to see a fire-side chat on how their process works.
This just reaffirms my belief after a decade in industry that middle management is useless.
I wish businesses could move to a more decentralized form.
You just don’t need these people if they can’t help you in you current or future job.
All managers should know the below. It’s proof the job is not effective.
> Here are the facts your manager might not know about you and your team that we’ll cover in this post:
>What’s slowing the team down
>Exactly what individual people on the team are working on
I think this is talking about direct (line) managers.
But I’ve had managers who lead. I’ve had managers who facilitate. I’ve had managers who manage their boss (which overlaps with facilitation but is different). I’ve had managers who only serves as tiebreakers. All have their value, but it’s very hard to relate to someone who doesn’t want to do any of those. Especially ones who are scribes.
Why is being a scribe bad? You only chronicle data that you don’t participate in so that later you can report on who did what. In other words, it’s not my fault it was Steve who made that decision.
And then we had Mike whose only job seemed to be getting promotions. Still have no idea what he did all day, except get promotions. Wouldn’t lead, wouldn’t tie break, didn’t chronicle, didn’t up manage, barely down managed.
All managers should know everything relevant; all people should be perfect. But meanwhile, no one is, and this post is useful advice for reality.
I cannot claim to know everything I "ought to" know for my job, and I don't expect my manager to either. But that doesn't make me, or management in general, "useless". We do what we can.
Then split up the job. If it is obvious you're spread too thin, stop doing it and making yourself near useless, split the job into multiple and focus.
We've done this with multiple other disciplines. Management is one of few continuing to converge and trying to do the impossible while insisting they are a net gain on average. That's irresponsible from a support role with a disproportionate amount of power compared to those they manage.
All the people here must be incredibly awesome because in my experience after having worked as a contributor, a project manager and a manager, when you leave developers to themselves they spend a lot of time fixing issues they care about and improving systems they like working on but very little time actually wondering if these bugs and these systems were the one who needed to be worked on right now to be able to keep the engagements we took towards our customers and for the project to survive.
as an IC.. i agree. boss me around a little bit. Don't make me miserable but I don't give a hoot what makes money, i just want to write quality code. if you need to steer me towards something more profitable, do it, that's your job, i don't like thinking about those things.
Not GP, but I'm in a company which is pretty decentralized (after being heavily centralized a decade ago). Decentralization puts different pressures to have good middle management (at a minimum), but I think in some ways, it even increases the pressures on management to make a decentralized company effective.
Well and I think you’ve been seeing a lot of it the past couple of years. There’s some natural informal organization if a team is physically collated—which often isn’t the case and can be good or bad in any case. If everyone is remote, a lot of that informal organization doesn’t happen.
It’s also the case that the realty of any established company is budgeting, procurement, etc. There need to be processes. I expect a lot of developers wouldn’t like to spend a day a week on this sort of necessary evil.
My experience with "flat" structures in the past has been the lack of an explicit hierarchy created an implicit hierarchy, which caused compensation to not match actual role and some diabolical politics. Never again. I've kind of moved on to wanting to work at places that run on information and not confidence instead. You can work out which type of place you are at pretty quickly by talking to upper management. Unfortunately most people want confidence and not information.
All they know is to say "that's nice, can you do it in half the time you estimated with half the resources?" because that's the only way they can justify their job. This is what they learn in MBA school or from their project management certificates.
depends on how big the company. When a large company needs to decide where to allocate the resources, a smart non-technical manager will be there fighting for you, and that's a full time job once you are in the 100's of engineers, because nobody has monopoly on truth, and normally the exact allocation has to be hashed out in a bunch of fulltime meetings, even in well-run orgs. As an IC, I'm glad someone else is doing it for me.
I dont think anyone expects ics to play management roles. What i am for is management with a technical background, otherwise its like mixing water with cooking oil. One sits on top and pretends to mix.
Replace the aqueous part with vinegar or lemon juice and you have yourself an emulsion, which also makes a delicious salad dressing. What sort of role is like acetic acid in your analogy?
You lost me there but people with tech skills should lead technical people. Otherwise its like sending the senate to lead soldiers on the battlefield. They have no clue and either lose wars or use large numbers to win battles. And thats what some of the companies do - they hire loads and loads and loads of people to achieve what could be done with fewer, better organised, and better led people. Without exception, unicorns and faangs have been built by engineers working directly with stakeholders. Then they go down the path of layered management and bloat and end up the chryslers and fords of tomorrow.
Instead all non technical management should he fired, including pdf certified scrum masters and other imaginary roles, and tech people with skill and interest should be promoted.
tl;dr; do your manager's job also because they don't have a clue and it's up to you to clue them in.
There's also a pretty conclusion where if you suck up and do your manager's job, you get the superpower of being appreciated by your manager, it makes you more valuable than the dumb engineers that just do their job.
I don't read the article like that: it's not a list of (all) things your manager doesn't know, it's a list of (some) things your manager might not know. In other words, these are all things your manager should know, but they might not know some of them. And then the advice is to tell them. (But with concrete examples and more worked out.)
> I don't read the article like that: it's not a list of (all) things your manager doesn't know, it's a list of (some) things your manager might not know.
I have a feeling this is the same core truth, but worded differently and with less distaste for managers.
> In other words, these are all things your manager should know, but they might not know some of them.
Should, but don't, is not doing their job. Most engineers don't have the luxury of using this defense their day to day job. Yeah, I should be doing testing, but I don't know. I should be writing clean code, but I don't know. I should be communicating with my colleagues, but I don't know. I should know what weight this bridge can hold, but I don't know.
Most of these examples wouldn't work with just 'tell them'.
> And then the advice is to tell them
Tell them what? Manager, this isn't working? I'd be laughed at for this kind of approach. Maybe it would work if I went in a structured approach, with my homework done, with actionable items in the context of the company, but then I'd end up doing their job.
----
I don't want my point to be that managers shouldn't be told what issues might exist, I hope the point I get across is that we shouldn't be doing their jobs and it's their responsibility to get this information through the numerous tools they hold under their belt, and not depend on engineers to spoon feed them.
Imagine if this is the only way a manager gets the know how. If I'm an engineer with a loud mouth I can crash the entire department by feeding my manager select information.
> Should, but don't, is not doing their job. Most engineers don't have the luxury of using this defense their day to day job. Yeah, I should be doing testing, but I don't know. I should be writing clean code, but I don't know. I should be communicating with my colleagues, but I don't know.
This is needlessly antagonistic. All teams have gaps, but effective teams help each other out. For instance, a good manager will give you air cover when things are underestimated or unforeseen difficulties arrive. Similarly, good engineers will point out risks and potential problems even if it is not directly in their execution path.
The most toxic teams are ones where everyone keeps their head down and looks for every opportunity to say "not my job" whenever any larger or unusual challenges are identified. Based on your comment it seems like you think that ICs can't get away with this, but managers can, and I assure you that neither is true.
Yes, but in order to do the level of management you are asking, it necessitates they become micro managers. This is a considerably worse state of affairs, as you allude. Managing is about helping you grow as an employee, helping you with your career and helping you do your job. The best managers are the ones that stand in the way of things that block these. How do you suppose they do this without you telling them what you need?
I gave the article another read and found some advice even weirder. I'm not going to go through all of it, but this bit stood out to me.
> I’ve found it really valuable to start out conversations about compensation / promotions in a fact-finding way – instead of saying ”hello, i want a raise”, it’s a lot easier for everyone to start with “hey, how does this work? can you explain it to me?”.
How does what work? If I want to learn more about compensation / promotions, I ask about that. If I want a raise, I want to discuss the raise. We can conflate them, but why?
But the conclusion I would like to summarize my point:
> Being good at telling your manager the right information at the right time and asking for what you need is a superpower. It makes you way more valuable to have on a team (because your manager knows they can trust you to give them the information they need), and it’s more likely that you’ll get what you want (because you’re making it easy for them to do that!).
Flipping this upside down, "being good at asking your team the right questions at the right time and asking for what you need is a superpower. [...]". This is great advice! Both for a team member and for a manager. The difference is that the team member has to deal with the actual production also, while the manager's 'production' is the actual thing being flipped. So if things are flipped and I end up micro-managing myself, is the manager actually doing his job?
Of course when there are issue that makes sense to bring it up, we should do it, but I'd argue that it's more of the manager's job to be on top of things and ask the right questions, at the right time, without micromanaging, because that's his job, and it's why it's such a hard job to do right. It's a lot easier in my opinion to find good engineers than to find good managers, and I believe this advice is good for engineers that have bad managers and it's worth calling it out.
I think this is a much clearer take, well, at least to me! The key here, and if I'm mistaken - forgive me, is that a good manager needs to be a good communicator, but doesn't get in your way. By the same token, it can be said that to help them help you, communicating with them is essential. It may seem obvious, but I'm sure lots of us have experienced bad managers that don't do this...
In the fifties management studies (Drucker etc) was focused on the manager as a systems creator - who would bestride the business world fixing, innovating creating smooth clockwork systems.
Today Google's eight rules for managers is basically a cross between HR and a life coach.
Systems are now run by software - and the inevitable conclusion is that coders are the new managers.
As more and more software eats more and more of the world, there is less and less need for anyone who is not coding or talking about the code.
We may see the end of rigid hierarchies at the same time (a similar but related issue), which kind of points to two things
- code is the thing. And discussions around the code matter. And the prime examples of doing this are in FOSS - so expect more open public disagreements leading to better quality code
- Public (internal) discussion of issues means a lot of self-governance and a lot of "politics". This goes on anyway but if it is kept public it is kept honest
- management has always been about resource allocation and it is best to view senior management as financiers not executives - this might be the best split internally - senor management buying from internal self organised resources.
- Incodentslly I think a lot of the problems facing most companies today are that they cannot work out how to measure quality work during rmeote work and cannot get people to communicate if they are not all in the office. Having a big email discussion list is unwieldy - but if that is your organisation then conways law will explain how your software works. if you don't like it, it is waaay easier to adjust your email lists than move offices.
Edit: imagine Bezos' two pizza teams - each can be viewed as a independent contract supplying a business-micro-service - at a doctrinal level style guides and devleads / linting rule, and at an operational level it's which micro-services, how to combine their output, etc etc
(i need to expand this but Amazon might not be a great company to work for but the organisational design seems to point i the right direction )