Maybe it’s just the mood I’m in, but I found this list/notes style basically impossible to parse.<p>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…<p>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.<p>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)<p>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.<p>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<p>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.<p>Managers (almost) always want people to take responsibility, but don't want to give up authority.
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".<p>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<p>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.<p>My team, on the other hand, has lots of information from the trenches that I might lack.<p>> In every discussion/project/problem/situation, it needs to be clear who makes decisions<p>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.<p>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.<p>Yes and:<p>> <i>You manage processes; you lead people</i><p>> <i>Processes are expectations made explicit</i><p>I way I learned it was "Structure + Processes = Outcomes".<p>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.<p>Journey of the Software Professional: The Sociology of Software Development, Luke Hohmann [1996]
<a href="https://www.amazon.com/Journey-Software-Professional-Sociology-Development/dp/0132366134" rel="nofollow">https://www.amazon.com/Journey-Software-Professional-Sociolo...</a><p>The other crucial bit of life advice I got from Luke, which may not be in the book, was:<p>"Sometimes you have to let people fail. Just have Plan B ready to deal with the aftermath."<p>But that's a much longer story.<p>--<p>Again, nice writeup.<p>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.)<p>--<p>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<p>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<p>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.<p>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<p>> Processes are expectations made explicit<p>Processes should avoid back-and-forth. They need to ensure that clear communication happens when work is handed off from one person to another.<p>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.<p>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.<p>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:<p>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.<p>This has honestly aided me greatly. Your mileage may vary.
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<p><pre><code> allocate/re-allocate
assign/reassign
delegate/replace
on-boarded/off-boarded
hired/let go
</code></pre>
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 ...<p>*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.<p>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.<p>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.<p>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<p>>> * By default, mistakes are not their team's fault but theirs<p>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.<p>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.
> Don't load your work onto others in the company.<p>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.<p>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!