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.
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.
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.
Honestly one of the worst blogs I've ever seen from a readability perspective.
Since you challenge the post here instead of flat-out ignoring it, I believe you think at least some of it may be true, and you want to know more.
To me, the bullet points read as titles in a Zettelkasten or personal wiki, or maybe chapter headlines in a book.
I'm conviced that there's depth to these points, and the author could write a lot more about everything. (Please do!)
Even though the article seems very superficial, I took away at least four points in my personal notes, for further reflection and whatnot:
* Trust through transparency
* Processes are expectations made explicit
* Make true what is real
* people x context = output
YMMV.
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
I don't agree with that train of thought at all.
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.
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.
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 words only get used when something isn't going well and the managers don't want to look bad.
In many organizations, taking ownership and responsibilities are indicators of individual contributors stepping up, and are pathways to greater success, promotions, and results.
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).
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).
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".
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.
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.
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.
So many managers get this wrong that just fixing this one thing probably gets most startups 60% of the way there.
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.
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
Very one-sided and superficial, for sure.
> 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.
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.
Right, what if I didn't hire them? Am I supposed to break the laws of my country and just shitcan people willy nilly?
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.
> 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.
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.)
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.
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
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 :)
allocate/re-allocate
assign/reassign
delegate/replace
on-boarded/off-boarded
hired/let go
*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.
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.
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.
>> * 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.
Still, the moment you are the boss, it really is your show.
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.
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!
So as manager don't delegate work?
Some of those points are written like a horoscope: You can understand them whichever way fits your own experiences best.
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.
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.