Maybe it’s just the mood I’m in, but I found this list/notes style basically impossible to parse.
Why are any of these things true? Credentials alone are not going to get me to blindly accept any of this; maybe some reasoning would help, a few anecdotes, conversations with other experts (or at least quotes) so I can relate this content to other content and start to fit this info in with everything else I already know…
This reads like tacit knowledge, a series of immensely complex if/else statements, that don’t really come across well in text without immense effort, and that effort was not taken here.
I think almost everything he says is true (based on my own experience with management). The reason this post is good is because it provides very 'quotable' statements. Of course no one will learn how to be a good manager just based on these bulletpoints, but they can serve as a basis of discussion, so for example if you'd like to mentor new managers in your company (and you understand/agree with what the post says) then this can be a good starting point; you pick one quote, e.g. "As a manager, everything is your fault" -- then talk about it at length.
Worked fine for me. The brevity is exactly what I need instead of wading through tons of often unnecessary text.
It's all common sense - which too many of my bosses just didn't have - and the summary form help bring them to focus. IMO it's good. YMMV, I appreciate.
Not OP, but "It's all common sense" is exactly the problem, as I see it.
Common Sense usually means Big Hairy Ball of Experience-Grounded Implicit Knowledge Wrapped Up Into Pithy Statements, in my experience.
Sure, each point in the article may sound reasonable, but there are also 1000 other bullet points that also make sense. How do you sort out all the "good" Common Sense from the "bad"?
Not to mention that every bullet points also has tons of Gotchas, where it works 80% of the time and enumerating the remaining 20% cases turns into another giant bullet list which must also be internalized as Common Sense to be effectuated well.
That statement is vacuous because no decent human being would say: "I want to treat my staff like crap". It is easy to agree with your points because they are universal but don't provide any meaningful way to differentiate, e.g., what is and what isn't "treating your staff like crap".
> because no decent human being would say: "I want to treat my staff like crap".
Go not by what they say but what they do, and I've known plenty who have treated their staff like utter crap, from screaming abuse at them to ignoring them to undervaluing them to psychological bullying and more. I guess all your workplaces must be like heaven compared to what I've seen.
I don't understand where you're coming from. To me it's a decent and useful post and you are just tearing it down for no reason I can see.
It's not useful because it provides empty universally accepted statements (i.e. you don't have to actually have any managerial experience to come up with this list) with no examples of what each means in the context of a relationship with a direct report.
I would point out that there are plenty of people in managerial positions who do absolutely want to treat their people like crap and derive great pleasure and satisfaction from doing so.
The world would be better without such people, but they certainly exist and seem to have a habit of floating to the top.
For such people it might not actually occur to them that treating people like crap may be counterproductive to other goals like profit. Years ago I recall a family member telling me about their then boss proudly stating something along the lines of "if my workers are happy then I'm not managing them properly, employees need to be miserable to be productive".
The "decent" word is carrying much of the weight in your argument.
Not everyone is a decent person, but if being a decent person is actually a way to become a good manager, then the statement is not vacuous at all. Given the conventional wisdom that CEOs have sociopathic tendencies, the statement may be flat out wrong even. I just don't think it's obviously vacuous.
I agree, but for a different reason: There's a vast body of knowledge and literature pertaining to managing people -- assuming that and the associated social skills can be substituted by reading a list of semi-structure generalized anecdotes is lightheaded.
Also some of the points are very superficial/wrong, e.g.: It's hard to get people to own a problem space fully / But this is the goal / If they are the wrong person, you can still fire them
This is a super important point if you're a founder who has never been an employee before. It is impossible to understand it unless you've been in this situation yourself.
Some of this is easy to say, hard to do. But, I didn't see much to disagree with. Managing people requires patience and you have to learn how to do it (I do not believe people come formed in the womb to lead well, it develops, in some during childhood and in others its learned more formally)
I sometimes think Lord Moran's "The Anatomy of Courage" is applicable here. The courage & capacity to stand up for what is right in a "groupthink" meeting, or to confront senior managers and manage upwards is not infinite. Some people have recoverable depths here. Others become a spent force very quickly but can be useful for a precise outcome. Some can't do it.
I used to manage people. I found it very hard. Giving people bad news in performace reviews is extremely costly to me, I didn't like it enough to want to continue.
> It's hard to get people to own a problem space fully
At least in my experience this is because a manager doesn't want to give their reports full ownership over something. That is, responsibility for the outcome and (much more importantly) decision making authority for how they deliver results.
Managers (almost) always want people to take responsibility, but don't want to give up authority.
I don't think this is typical. I'm sure there are dysfunctional organizations where it is true. Please consider including nuance in a statement like this, or you end up with self fulfilling prophecies.
In many organizations, taking ownership and responsibilities are indicators of individual contributors stepping up, and are pathways to greater success, promotions, and results.
IIRC the UK is at-will for the first two years of your employment too. Some startups leverage this to an almost toxic degree.
I had one manager (who then became CTO and is now CEO of another startup) who, by all appearances, treated firing as the only tool in his arsenal for dealing with any personnel problem. I was never on the receiving end, but in a few cases I know for a fact that he lied (or hugely exaggerated) about what the terminated employee had been done. He is the reason I left.
* you can demand written explanation if you've worked for at least two years
But, for most contracts here a 3/6 month probationary period seem to be the norm for tech/professional roles, and then a 3-month notice period (to quit or be let go).
You don't actually need to give a reason, at-will means you can be fired without cause.
For those abroad, remember that most of the time health insurance is tied to employment in the US... so when you get fired your costs also skyrocket (especially if you're the insurance source for your family).
Here in South Africa it's challenging but certainly not impossible. If you provide 3 or so written warnings and set up sessions to try to allow the employee to improve, you may go ahead and dismiss the person. But you can't simply fire at will unless it's gross misconduct or similar.
But is that at the will of your direct boss or there is a process that they have to go through? Like, if for some reason I piss off my manager, they get mad and fire my ass on the spot? How common is this in tech companies?
Pretty uncommon at tech companies, but it's entirely based on the company's policy. The company can fire you at any time (as long as it's not one of several specific bad reasons like racial discrimination), but it's the company that employs you, not your manager. So only the company can fire you.
Generally big tech companies don't give your manager the authority to blindly fire you, but only because that's a decision the company made.
Short answer is yes. Long answer is yes, but reasonable companies will try to find some reasons first as firing for no reason will only increase company's unemployment insurance.
I've fired some people in an EU setting; and have also been let go myself (layoff round, I never took it personally). It's true that countries outside the US have more legal checks and balances around this topic. But it's not true that it's impossible to fire people. Basically, those checks and balances are mostly for good reasons. And I've noticed that better employers in the US tend to use them as well even if they are not required to. Mostly the bureaucracy around firing people is a bit more efficient but the process is loosely the same; or at least it should be. In some places it isn't of course.
Basically there are a few different scenarios here:
1) somebody committed a firing offense. This is rare but it happens and it requires immediate action. These are in a way the easiest because they are usually so clear cut and sometimes it involves legal action as well. I've never had to do this myself but I've seen it happen to other people around me. We're talking clear cut cases of "WTF did that person just do?!". You get legal involved and make it happen. It's unpleasant and you'll have no choice.
2) mutually agreed consensus about somebody's performance. This is the "it shouldn't be a surprise" situation. This usually happens after you've created plenty of opportunities for the person to improve. Often that just doesn't happen and you need take it to the next level. It's stressful and it involves building a case against a person such that they can't ignore the reality that they are indeed not delivering. Mostly people like this leave by themselves. For me the test of this done well is me being able to meet these people afterwards to have a friendly/courteous chat over coffee/beer a few years later. I'm often pleasantly surprised to see that people moved on and improved themselves. Sometimes firing somebody can be the best thing you do for a person from a career development point of view. Don't make it personal.
3) financial difficulty sometimes makes it necessary to make tough choices. Usually people that were performing less (see 2) would be the first ones to go. This sometimes comes as a surprise. In my case I got an excellent performance review, a little raise, and was out on the street two months later. It wasn't personal and I was definitely surprised/shocked. I've since had to fire people in struggling startups a couple of times. It sucks. For everybody. If it feels like failure, it's because it is. I've had to fire friends even. And we're still friends.
Simple recommendations when firing:
- Build consensus about the action with your direct peers. You are representing your company here and relaying a joint company decision. So, make sure it's a fair decision that everybody can stand behind. Firing somebody should not come as a surprise to your peers.
- Be straight about this happening on your recommendation though. Don't hide behind the company.
- Expect people to be shocked, emotional, etc. and be ready for this. So, don't ask them to take any difficult decisions on the spot. But inevitably, some paper work may be involved and some legal steps on both sides.
- Focus on the core facts of the situation and avoid any debating or arguing.
- Lead with the core message: "I have some bad news for you ...".
- Have an off-boarding plan and communicate that plan. "This is what happens next".
> This usually happens after you've created plenty of opportunities for the person to improve. Often that just doesn't happen
Doesn´t that mean you the employer failed too? It could be that someone is really not well fit for the role, but it could also be that the employer has no clue how to lead someone to success. As you say
> I'm often pleasantly surprised to see that people moved on and improved themselves
This is for me an indication that the employer lacks critical skills and needs improvement. Being a checklist manager and demanding improvement is the easy part, but making people grow in the direction you want is the hard part.
That's a very one sided view. It assumes the employee always means well and is super motivated to adapt and change. Or even capable of changing. When all that stops being true, it's usually quite obvious. The mistake is allowing such a situation to continue to exist and not intervening. Every dysfunctional team you've ever been on, that's what happened.
As a manager/supervisor/mentor, I've coached more than a few people to success to know that I'm actually objectively good at this. Quite a few people I've worked with have gone on to be extremely successful in what they do. And I like to think I helped them on that path a little. But there are exceptions to this where indeed I failed to get people off their ass and improve themselves. A handful of those situations escalated to the point where letting them go was the next logical step. Some people are just fundamentally hard to coach or even open to being coached.
> It assumes the employee always means well and is super motivated to adapt and change. Or even capable of changing. When all that stops being true, it's usually quite obvious. The mistake is allowing such a situation to continue to exist and not intervening.
> As a manager/supervisor/mentor, I've coached more than a few people to success to know that I'm actually objectively good at this.
Ok fair enough, that is a vital addition you made.
What I have observed is the pattern of "she doesn't function" => "she needs to improve" => "she needs to let go".
If you do provide coaching to a motivated person, I believe success is the most likely outcome.
I've been around people who were fired in Germany as well, both as what you described in 1) and 2).
2) takes a lot of effort, a lot of people and the negative effect of that person's performance on the rest of the team can be severely damaging too, that I wish we had at-will employment in Germany too sometimes, but it's there for good measures and I'm generally happy with it.
Yea this point alone hit me like a freight train. I have to reflect on this.
As a corollary I would also add that the fact that the chaos is felt is often not overtly communicated. Intuitively you'd expect people to react like the house is on fire, but it is closer to when the music stops and people no longer know what to do. That's what real chaos looks like.
I wonder how much of the "managing processes" part could be delegated to software tools? How many of these processes could be automated, or "managed" by some sort of workflow software. Would it be possible with the right software product to essentially distribute the role of manager across the team/company?
The problem is that a lot of processes still leave a lot to interpretation, or many scenarios have grey areas on how to apply a process. The author mentions it a few sections later, you don't want the processes to have a ton of overhead, rather make it clear the expectations on how to interpret the situation or know they should come to the manager to provide direction.
Yes, but some processes ARE well defined, and you want to ensure the steps of it are all met correctly each time. This could be similar to the checklists airplane pilots use, or surgeons as extreme examples.
> And you got more information than they do, always
This sounds like a dangerous thing to think. If the rest of my team does not have more information than me, I have failed to convey the important things I know.
My team, on the other hand, has lots of information from the trenches that I might lack.
> In every discussion/project/problem/situation, it needs to be clear who makes decisions
While I understand where this is going, I disagree with the literal translation. Ideally, in a well-run democracy, people will come to reasonable agreement on the next step forward without one single person having to make a decision.
Only when the democratic process of discussion and negotiation fails does a person have to step in and make a decision. ...or at least force the discussion onto the relevant subjects.
> This sounds like a dangerous thing to think. If the rest of my team does not have more information than me, I have failed to convey the important things I know.
Two points 1) I think the advice is for small teams / startups where I can easily see this happen and 2) One can tweak the advice to "And you got more *context* than they do" for larger organisations
> Only when the democratic process of discussion and negotiation fails does a person have to step in and make a decision. ...or at least force the discussion onto the relevant subjects.
One important tool to help the team come to the "right" decision for a project is to provide a vision and associated goals that can be used as a yardstick to evaluate the benefits of each alternative. The "debate" should flow into the same direction.
If they have information that would help make a good decision, you can ask them. It's not so easy for them to ask your bosses for the same. If they have information that would have been helpful and didn't share it, who screwed up in hiring and/or training them?
I way I learned it was "Structure + Processes = Outcomes".
By me focusing on S and P, I was able to delegate emotional ownership of O to my team. IMHO, that sense ownership is a "critical success factor". Which you touch on further down your list.
The other crucial bit of life advice I got from Luke, which may not be in the book, was:
"Sometimes you have to let people fail. Just have Plan B ready to deal with the aftermath."
But that's a much longer story.
--
Again, nice writeup.
Is it too much to hope that your common sense regard for the process of software development is early evidence that our industry might finally be moving past the Agile cargo cult era? (Hot damn, it's been a lonely, frustrating two decades, remembering how things were before Agile.)
--
PS- I've recently heard (read) the "First Pancake" metaphor for first effort, maybe a dozen times. Another gem I had first heard from Luke, back in the day.
This is a low quality solution for ownership and only works for some types, leads to burnout in others. It also contradicts one of the good points in the article: "Burnout comes from a felt loss of control and/or impact". You cannot expect from yourself to be able to correct processes for everything.
In my experience, better solution is (when it is possible) to have shared ownership. This is possibly an even bigger topic than burnout though and deserves its own discussion.
I think a better way to phrase his point is that responsibility rolls upward. You cannot delegate responsibility for an outcome, though you can share it.
In NZ we basically have this in law when it comes to safety. If someone gets hurt it's Management's fault. If they pulled all the safeties off the machine and stuck their hands in while it was running, then it's your fault for not training them not too. Unless you have paperwork to prove you did train them not to.
Processes should avoid back-and-forth. They need to ensure that clear communication happens when work is handed off from one person to another.
Assuming you're working on tickets, do you need to ask 200 questions every time you get an incoming ticket? That's a process problem; the process should ensure that whoever created the ticket puts in the information you need to do their work; and the process should ensure that whoever created the ticket knows how to fill in the information you need.
IE: If QA is filling out a ticket, they should know how to write a bug report, steps to reproduce, and how to collect diagnostic information that's unique to the product.
If support is filling out a ticket, they should know how to clearly explain the customer's problem, and what questions to ask the customer to collect diagnostic information that's unique to the product.
That sounds like a pretty siloed way to work. Conversations with the people involved is much high bandwidth and full-duplex which increases the odds of understanding the underlying problem and building what people actually want.
> Conversations with the people involved is much high bandwidth and full-duplex
That's impossible when working with people in different timezones, or when working with customers.
Specifically, regarding support: The people in support need to know how to support their product, and that includes knowing what information to collect if they believe they will need to escalate. They just can't randomly pull engineers into a support call.
You also can't have a support organization that expects "high bandwidth" communication with a customer. (IE, support can't go back to the customer for every ^%$#^#$ question the engineer asks.)
This is a pretty good list, in particular the section on 'Feedbacking People' is an excellent summary of the importance of using performance reviews to actually review how systems and processes are hindering or helping someone's performance, versus just trying to review performance without any context.
I identify with much in this blog post. One novelty argument:
Managing is hard because it embodies the dialectic between capital and workers. Therefore a deep understanding of the Marxist critique (and exposé) of capital will help provide an analytical framing around what an effective manager needs to do. You can approach it from other lenses but they all break down due to the two polar forces most strongly at play.
This has honestly aided me greatly. Your mileage may vary.
A difficulty with marxism is that it is thoroughly old fashioned about bucketing people into categories. In a feudal society you were born into a life where you were a serf, or a craftsman, or an aristocrat. Marxism massages the labels but essentially accepts this worldview. The primary handle on each person is a class label, assigned at birth. Talent is irrelevant.
One of the challenges of management after feudalism is making the best of the variety of individual contribution. When you are moving rocks around or ploughing, each individual is roughly equivalent. This was obsolete by the industrial era. A factor in Japan’s rise in auto was giving workers direct and individual (ie not union-filtered) feedback into the manufacturing process.
Now, the multipliers are higher still. There are regular situations where an aggressively small team has executed where several well funded teams of thousands failed.
My view is that capital is nearly irrelevant in mainstream technology now beyond achieving bootstrap and avoiding dumb renumeration errors that alienate talent. Rather, the key tensors are 1. how high you can get the ceiling on your core talent and 2. how small you can get that team, in order that this talent can be engaged with the big picture, in order that they can be identifying and focusing on the most important problems. They are related. The more capable your talent, the more it can participate in the big picture.
These dynamics do not resolve easily with the orgchart-centric, bigger-is-better assumptions of traditional worldviews.
Possible limit to the view - I have not had exposure to fields with vast ongoing capital cost, or complex cross-discipline stuff like silicon manufacture
> My view is that capital is nearly irrelevant in mainstream technology now beyond achieving bootstrap
Wasn't that true for traditional businesses as well? Beyond bootstrap, the company itself (revenue streams, assets, etc.) is the capital.
I mean, if I wanted to be a landlord in the middle ages the only capital I need is a bag of gold coins to buy enough land and build a fort and "bootstrap" my lordship... (and maybe a fake birth certificate :)
The labor movement predates Marxism, even if you exclude pre-industrial incarnations. I believe workers pooling their power is just a result of the dynamic between capital and workers, and Marx started out by describing, rather than prescribing it.
This article should be obligatory reading material for everyone. Considering how it focuses on empathy and leadership I find it a little odd that they use the terminology "hire/fire" which in my opinion is hostile/negative loaded words. Imo it would be better to use something like
allocate/re-allocate
assign/reassign
delegate/replace
on-boarded/off-boarded
hired/let go
words have meaning and should be used carefully when writing and discussing. especially if you are a leader. Fear based management is a real thing and something that is easy to fall back into if any issues and you are unwilling to accept responsibility. it is always so easy to blame someone ease. A true leader/manager knows this and accepts responsibility. This is also the essence of the article and why I think some of the words used is ... a little off ...
*edit, I'm European and rules are a little different here, firing someone is very hard to do. When you get fired it is usually because of something very serious.
yes. where I live, only when you have done something really bad - you can get fired. If you are fired it might be very difficult to find a new job.
If you get offboarded, or let-go, then it is different. You haven't done anything bad that could potentially block your future; there is a better narrative for you to use when looking for new employment.
I'm also European and do not notice a difference between being fired and let go. In both cases your contract is terminated by your employer. If it's about meaning, the meaning is the same. Since we likely do not live in English speaking countries (I don't at least), it's difficult to map these words to any concepts that might exist somewhere else and say one is better than the other. A more European thing would be to actually forbid the employer to signal in any way why your contract was terminated, so that it interferes with your future career.
I disagree with the idea that you should avoid hire/fire. Yeah they aren't happy words, but I'm far more annoyed by people who mince words and don't convey their point succinctly and clearly. At one point in the article the author uses the word "discontinue" as a synonym for firing someone, it took me far too long to confirm that firing is what he meant. That doesn't mean you shouldn't be tactful, but it is far more insulting to take someone into a room and tell them they are being "off-boarded".
When you are a manager you need to learn to put your ego to the side. Everyone thinks they can do this, but most people can’t.
You have look at some one else’s work and say, “I wouldn’t do it like that, but that is okay their approach is valid and good too.” Sometimes it isn’t or you could provide valuable feedback on how to do something better, but often you just want it done the way you want it done and that is waste of everyone’s time.
Another way to say that you manage process not people is to say your job is to remove challenges your employee might have in accomplishing their job. You aren’t managing them, not ideally, you are acting as a producer making sure they have what they need to succeed. Doesn’t matter what that is. One minute it could be advocating on your team’s behalf, the next it could be making sure there is a clear process for how to handle a project.
First time managers often think they need to provide their vision for every piece of work, or tell others how they want the job done.
I have given up on providing feedback to managers. I realized people does not change much. Most managers want to assert power and as an IC its hard for me to accept authority of manager considering my skill level compared to my manager. The best way to deal with manager is always discuss the requirements and nothing more. Your teams feed back is more worth than manager feed back on performance rating. I don't know who came up with this practice but I am grateful to them. This junior developers don't realize for a long time. Any one who has not demonstrated as a good developer is unfit to be a developer's manager.
>> * By default, mistakes are not their team's fault but theirs
As a middle manager I hear this all the time. Unfortunately the "shit flows upwards" mantra seems to stall out before it hits the top of the pyramid, so any talk of "owning fault" leaves me skeptical at best.
I will admit that the 'everything is your fault' resonated with me. The best boss operated exactly this way ( and I hope I will be able to emulate him one day ). I am obviously not talking about self-flagellating. In a corporate environment, it can easily backfire.
Still, the moment you are the boss, it really is your show.
There's some good stuff in here, but I feel like a lot of valuable context was left out to accommodate the author's unique formatting style. Not everything needs to be reduced to a one-line zinger.
Presumably he is US-based, in which case you can. I did find the verbiage of "discontinuing" people rather unsettling, but otherwise it's a thoughtful piece that resonated with my experience.
I see he is based in Berlin, Germany (according to his LinkedIn) where it's extremely hard to fire people (especially for reasons he mentioned in the post) once they are past the 6 months probation period. This smells like he is giving advice that he didn't do himself. Firing people is a pain for all parties involved.
You'd be surprised how many folks (many people on bluecard visas) take such severance "offer" without any legal consultation. Many tech immigrants in Germany do not know of their worker rights.
Yes! The difference between how German employees who got laid off deal with the situation compared to bluecard visa holders, is stark, but not surprising.
I also noticed the language. I have been thoroughly downvoted as a consequence. I am however glad to see that there are multiple other in this thread also commenting on the same.
Well, can't you? Sure it depends on country, but the problem normally seems to be that companies want to fire people and not compensate them. I think most countries allows you to fire people pretty much when even, it's just that it can be rather expensive.
You can't fire pregnant women, that's almost impossible, you can't fire because of skin color, religion, handicaps (unless it prevents you from doing your job), but other than that you can normally just fire people if they aren't a good fit, in terms of both skills and personality.
Yeah I worked with a company that had a very incompetent employee. They almost had enough warnings to fire the employee, then the employee came out as trans. No one was phased by that, however it made them impossible to fire. They couldn't do it without it appearing that it was due to that employee being trans. So they hired an extra person to make sure the job got done.
Well, not impossible. My wife's boss actually manage to fire a pregnant employee, due to incompetency, but it made much easier by the fact that reviews and complaints had come in earlier.
I understand why a company wouldn't fire a trans person, the shitstorm would be unbelievable, and you're rarely in a position where you can point out that the person is incompetent.
Your work and 'the work' are different things. You delegate 'the work', but make sure you do 'your work' as the manager. Don't delegate/offload 'managing'.
> It's also a favourite ploy of sociopathic but useless individual contributors, find someone to do your work for you, then repackage it as your own!
It seems like that could only work once or so per individual, unless there's some other kind of power dynamic in play. I know I wouldn't be put in that situation where someone takes credit for work I did more than once.
Nobody would let it happen if they knew what was going on. And generally the types of people who get up to it don't go broadcasting it around.
Two particular examples stick in my mind. One was a serial desk dropper who would get snippets of information from everyone individually, then package it up as their own to report to a boss.
The second was an IT consultant, working for a major consulting firm, who would lean on junior team members for docs and slides, then just outright steal them to use in reports. The thinking being that junior team members don't get to read reports for management.
It's like the old parable of the stone soup. You get 8 different people to "help" you with parts of the task, then present the completed task as your project. I have seen this done before although thankfully not very often.
Why are any of these things true? Credentials alone are not going to get me to blindly accept any of this; maybe some reasoning would help, a few anecdotes, conversations with other experts (or at least quotes) so I can relate this content to other content and start to fit this info in with everything else I already know…
This reads like tacit knowledge, a series of immensely complex if/else statements, that don’t really come across well in text without immense effort, and that effort was not taken here.