Things your manager might not know (2021)
jvns.ca
jvns.ca
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 )
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.
They'll still have better insight on the subject than your average joe blow startup.
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.
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.
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.
See the Manna story below.
So the interesting question is, in that context is a manager becoming ever less necessary
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.
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
Where did you get this idea?
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.
Integrity is who you are when nobody is looking, and all 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.
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
1. How to manage people.
Maybe this is kinda snarky, but I've meet a few that didn't know basic management principles.
Manager here. This one hits close to home.
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.
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.
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.
How many managers got a 4 year degree in actual management? Answer: none.
Is it any wonder so many managers suck?
There’s also a few other tougher scenarios.
- they might not know you’re doing parts of their job.
- they might know of problems but fail to let their manager know.
- they might not know your career aspirations.
- they might know someone is problematic on the team.
- they might not know they get in the way more than they help.
- etc
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.
The only bad part is that it’s hard to effect large changes, which is what we need right now.
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).
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.
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.
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.
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.
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.
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
Now THAT is a superpower.
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.
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.
If nothing else do it because your manager will like it and it increases your chances of promotion.
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.
She really "gets" it. Technical whiz, and knows how to work with people.
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
>Where the technical debt is
>How to help you get better at your job
>What your goals are
>What issues they should be escalating
>What extra work you’re doing
How compensation/promotions work at the company
Edit: It’s by Julia Evans too. Awesome.
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.
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.
Valve Handbook for New Employees
https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployee...
Us lower managers are only human.
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.
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.
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.
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.
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 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.
> 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.
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.