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.

> Chaos is felt less by the people creating it.

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.

The author mentions firing people in almost every point. Is firing people in the US so easy that it is a go-to solution to solve these problems?

OK post overall, but I will say that the line "Chaos is felt less by the people creating it" is so incredibly accurate.

I see a lot of comments about firing and chaos, but the single most important point to me is "you manage processes and lead people".

So many managers get this wrong that just fixing this one thing probably gets most startups 60% of the way there.

> 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.

Nice writeup. Agreed with all.

Yes and:

> You manage processes; you lead people

> Processes are expectations made explicit

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.

Journey of the Software Professional: The Sociology of Software Development, Luke Hohmann [1996] https://www.amazon.com/Journey-Software-Professional-Sociolo...

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.

> you hired (or did not fire) the wrong people

Right, what if I didn't hire them? Am I supposed to break the laws of my country and just shitcan people willy nilly?

>As a manager, everything is your fault

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.

> Avoid back and forth

> Processes are expectations made explicit

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.

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.

This is gold. Concise and to the point. A lot of self-reflection must be put into this.

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.

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.

>> Expect more from managers that report from you

>> * 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.

He makes it sound as if you can just fire people at will.

If I had a personal API both as an IC and as a manager, it would look something like this. Thank you, this is magnificent.

20% of the job that applies 80% of the time.

> Don't load your work onto others in the company.

I've seen this at companies small and large, especially where you might have a "politically" appointed manager, rather than someone a bit more useful.

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!

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.

Yes, most states are "at-will", which means you can be fired for any non-illegal reason at any time, barring any existing contracts.

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".

Nope. It happens but not so easy. Its the mindset of most managers especially managers with non coding background.

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

You have any suggested reading or links related to Marxism, especially as it relates to work?

Very well said. This has indeed helped me too.

How do you feel about labor unions in tech or corporate environments? The labor move seems to have its roots in Marxism.