I've worked for a lot of unsympathetic people who didn't put themselves in my shoes, or who had their own personal issues that caused them to tonelessly say degrading things to me as a young coder. But I was lucky enough - or sympathetic enough - to get through to them as their employee with questions that made them see me as someone they could help and improve. This wasn't even their choice; it was mine, to tease those explanations out of them. I sure wish most employers and corporate structures had this sort of kindness in mind, but on an individual level it really comes down to forming a co-sympathetic relationship (as an employee). Now as a boss, I find myself extremely sympathetic to anyone who asks intelligent questions, but very short on the fuse with people who don't take the time to look things up for themselves. Is that me becoming more of an asshole with age? Or is it that I put myself through the process and I expect others to as well?
> ...it really comes down to forming a co-sympathetic relationship...
Trust?
Young me was told that trust was crucial to effective management, high performance teams. Ok. How to do that? What does that look or feel like?
I've had exactly one trustful peer relationship. People used to joke that we acted like a married couple. We have no idea why we just clicked. We accomplished so much, worked so hard, had so much fun. Sadly, once you experience authentic trust, any thing short of that just feels like a waste of time.
I've trusted maybe 2 of my many bosses.
You'd have to ask my direct reports if any of them trusted me. I hope some would say "yes".
--
Older me reflecting back on all this stuff...
I had hoped life would be more win-win, a la Robert Wright's book Nonzero. But it was mostly transactional relationships, power dynamics, zero sum games (win-lose), so much energy wasted on guarding my boundaries, and then getting exploited whenever I didn't.
My experience is the same. As a young engineer I got things to work on time and with minimal issues. My reward for being good at my job is to be loaded up with work from my boss and by my peers and even by those who were outside of my team. When I refused because I said I have my priorities. I was called out for not being a team player. I once even had a come to Jesus meeting by someone who was not my boss for refusing to work on his emergency ticket. This tech lead who was on another team was later forced to apologize to me.
Essentially there are two classes of people. Those who want to master their craft and develop their skills. And those who think their job is boss around others and that other people exist to make their life easier. I have noticed this sense of entitlement is especially common among younger engineers who think I owe it to them to mentor them. Hmm. I don’t owe you anything.
Could you say more about that trustful relationship? How did it start, did you have similar backgrounds, was it work-focused or get into personal stuff? Signs to look for/ aim towards for people who aspire to meaningful, trusting relationships.
I have noticed there are two kinds of trust relationships. The first is pure office politics. You have long term creditability, therefore everyone knows not to try their manipulative tactics on you, engage with you professionally, and therefore you have a trust relationship. This is akin to being a made man.
The second kind of trust relationship I have encountered are with very religious devout people who believe they are doing God’s will to help others and with people who have sense of humor that builds people up not take them down. They don’t take themselves too seriously and just want do a good job and get along with everyone.
Mid-90s. Mid-sized company. Very engineering driven. Founder President was unteachable, largely absent, prone to drive-by management (disruption). VP of Sales was a complete dink ("All I want is free, perfect, done yesterday. Is that too much to ask?"). "Visionary" VP of Engineering with goal of being Director or better at Microsoft, most of his time building a fiefdom, protected his power by encouraging infighting. Tech Support was very powerful and in open rebellion.
I got things done. Mostly by being a bulldozer. Not popular. Eventually promoted to Engineering Manager over a suite of products. I was very interested in empowerment, process, execution, shipping products customers wanted. Major influences were Luke Hohmann, Deming, Eli Goldratt, and so on.
I had a crazy notion: instead of engineering dominance, model team after quality circles (a la Ford Motors) and the US Constitution's balance of powers. So initially, Marketing role would own scope and price, Engineering would own cost and schedule, Quality Assurance would own releases. Eventually expanded to include Sales, Tech Support, Docs & I18N.
Through pure luck I got paired with a skilled Marketing person, who also had domain expertise, first time doing software. She wanted to learn "software" and I wanted to learn "marketing". So we taught each other, mostly by example and answering questions.
Empowering QA assurance was a lot more troubled. Wonderful person, we got along very well. But she struggled to balance my way of doing things with how her peers (and their teams) were doing SQA. In a nutshell, I wanted her to be in charge, whereas her peers were stuck in Kem Kaner's mentality of victimhood and self-disempowerment. For example, I insisted we have our own test lab, she balked when her peers insisted on a shared lab run by the test group. In other words, I wanted a product & team focused org chart, and the rest of the company wanted to keep functional silos.
[Per the E-Myth's advice, I served the role until I could hire someone. So I did my own thing. Think "The Joel Test" and Code Complete, back when that stuff was controversial. The lightest weight ticket tracking system. Automated builds and testing. Front loading as much work as possible (eg always have a shippable product instead of Big Bang integration at the end). I say to show I took SQA very seriously and walked the talk.]
--
So the way that it played out, my Marketing Manager and I were on the same page. Meaning she could speak on behalf of both of us. She could make decisions without my input. She was savvy enough to know when I'd want to be in the loop. And vice-versa. In turn I went to trade shows, met with dealers and customers, and interacted with Marketing and Sales (in her absence) as her ambassador. We prepped each other, took notes, then debriefed.
I didn't have that relationship with my QA Manager, much as we tried. And we tried. Despite a great personal relationship, work wise we just ground gears.
When I switched to another team, to bring another troubled product back from the dead, my team was eager for my replacement, who was "nice" and very well liked.
New guy promptly disempowered everyone, threw away all of the team's processes (eg speed triage), became the sole gatekeeper (aka control freak), morale tanked, releases stalled.
About 3 months later my former SQA manager took me to lunch, told me she finally grokked what I was trying to do, and that she'd rather work her ass off shipping product with an asshole like me than be a drone working for a nice guy.
Bittersweet.
As for the people who worked for me, my job was to protect them, do whatever it takes to help them succeed. Most did great. Some excelled. Others were total time sinks, causing endless heart ache. Like I said previously, you'd have to ask them if any of them trusted me.
The managers I trusted treated me the same way. Just tell me what needs to be done, remove any blockers, help me stay on track. That's happened only 2 or 3 times. Everyone else needed constant upward managing, or worse.
Most of the time when someone ask a question answering it isn't very easy. You have to look things up, go through the code, maybe run some test to figure out what the solution is. That is how you work with the code and that is what they need to do to work in the code.
The problem here is that they expect that answering would be easy for you, but it is not, so you tell them to go figure out themselves since you don't have the time to do all that work for them every time they get "stuck". Since in fact, you yourself are "stuck" like that every day, being "stuck" is a major part of being a software engineer, it never ever goes away and junior engineers often thinks that being "stuck" is bad. It really isn't, that is what your life will be from now on, you just got to learn how to handle being stuck and nobody can really teach you that.
Anyway, when you dragged the answer out of those other people you did the work to unstuck yourself. Those people couldn't just have told you the answer from the start since they didn't know until after the long discussion with you, that discussion was the work. Now that you are on the other side you get a lot of "unintelligent" questions, ie questions you can't easily answer, and therefore feel frustrated with these new engineers. It has nothing to do with kindness, its just that the junior engineers needs to understand that finding the answers to these questions is their job and not something that just juniors have to deal with.
Example with overly simple question:
Junior: How do I center a div in html?
Senior: Just look it up on Google.
Junior: Why can't you just tell me?
Senior: I just told you how to do it, that is what I do every time I need to center a div!
I've found the best way out of these kinds of questions, where the asker hasn't put in even the lowest level of effort is to say, "I don't know, but here's what I would do first to figure it out." Most people will be glad to find out there is a path forward and take it themselves. If they're not willing to pick it up there and do the thing you've suggested then you are dealing with someone who doesn't value your time and setting a boundary is the right thing to do. The kind way to respond at that point is simply, "I'm sorry I don't have time to figure this out right now. You can try [the thing I suggested] and come back if you still have questions."
The crux here is there is no kind way to just make people go away. If your role is mentoring, and any of us with experience should be in that role at least a little, then some of your time is going to be spent on this interaction. The most valuable thing you can do for yourself, the other person and the company is lead them toward finding the answer themselves. That's going to require a balance of helping and honestly and kindly saying no to doing their work for them. Not easy.
"I put myself through the process and I expect others to as well". Resonates with me. I expect people to at least process things to a degree on their own so that we can have an intelligible conversation.
> Or is it that I put myself through the process and I expect others to as well?
I have no answer for sure but I've seen this pattern in just about every aspect of life. Older people who did X are very very angry if younger guys refrain to do X
I think it's fine as long as both sides are aware of the expectations. But managing those expectations might be better suited to a manager position, rather than the senior/junior developers actually involved in it. The job of a manager is to enable people to do their job.
The job of any person whose output other people depend on is to enable those people to do their jobs.
A junior software developer's job is to enable customers to do their jobs (as customers). An architect's job is to enable developers, sysadmins, etc to do their jobs. We are all part of a team, and we all depend on each other.
> Is that me becoming more of an asshole with age?
Sort of, but I don't mean that in a bad way!
Many of us experience rough times coming to terms with how to function in an organization and how to develop professionally. In my opinion, after that experience becomes internalized we end up behaving in various different ways when the tables are turned and we become "part of the landscape" for newcomers.
Some people believe that others must face the same challenges they had, that suffering is not only inevitable but required as part of the path to mastery. It's very much like a Calvinistic way of thinking where people must prove themselves worthy before they are given consideration in the eyes of god (or in the case of a workplace, senior practitioners). I think of this as "the stackoverflow" approach. It helps people out because it forces the student to formulate valid questions and uses reward or punishment as incentives.
Others, seem to model their behavior in an opposite way. They remember the confusion they experienced and strive to help out the newcomer. They try to provide some measure of "guard rails" so the newcomer doesn't have to crash and burn as much as they did. These people tend to take the "answering" of questions more seriously, and often end up asking questions to the student instead of just answering, evaluating their responses, and then asking more questions. This is like a Socratic approach and it challenges the student to come up with their own answers. It ALSO works.
Which of these is correct? Neither (or both). They're just ways of responding and everyone has encountered both modes and probably behaves in either way depending on the situation. Some of us have personalities that naturally tend towards one or the other.
I think that whatever approach is taken, it is super important to not dismiss the student. People do need encouragement, not necessarily with every interaction, but they need to know it's OK to "not know" and that their suffering is something we all experience. This helps to create a sense of psychological safety.
It's an indicator of a lack of empathy, which can come from many places. You need to find empathy for those people who don't take the time, and barring that, compassionately help them reach an empathy for you and others they might be frustrating.
I have a short fuse any time I think people aren't helping their coworkers or don't put in the work so others can do their jobs, and it's making other people quite frustrated. For me it comes from a couple places (perfectionism, ego, self-criticism, differing priorities). I'm still struggling with it, and I'm very lucky my boss is very understanding.
I don’t agree. People are hired to do a job. If they can’t do a job because they don’t have the skills and must depend on someone else to help them, they should not have been hired in the first place. This has nothing to do with empathy. This is common sense. If you can’t do the job, why are you here?
Because you're the best the company could find and afford to get into the position to maybe fix the problem. Lamenting an unskilled workforce or not having the perfect developer for a given task is just professional entitlement.
Your job is to work with the team and the resources you have. Why are you daydreaming about things you don't?
There's often an issue where people do not make any progress towards becoming useful, and do not show any promise of being capable of becoming a net contributor.
At this point, you can fire them, silo them off the critical path, move them into other work, or just keep jamming a square peg in a round hole. But it wears on the people who have to take up the slack and do, or re-do, that person's work.
Common sense suggests that > 95% of companies don’t have access to the highest grade of engineers. If we work for companies like that, our job is to work within the system and get shit done. That often means being kind and mentoring.
The problem is, depending on the environment and personal positions, kindness isn't necessarily the most useful option, and even if everyone likes it, kindness doesn't necessarily sustain itself.
The most important new information about aggression I've got in years is from Prof. Robert Sapolsky's lectures on Human Behavioral Biology. Mind blowing, totally recommend you watch it on Youtube.
We have this general notion that if we are rational, if we are learned, if we are scholarly, if we respect thoughts and truth and all of that, we will make the world a better place.
All of us who are professorial have somewhere in there this totally ridiculous belief that if you're allowed to lecture at a subject long enough, it will give up and go away. And that will be the cure for the world aggression. If everybody could be lectured to about the frontal cortex, it will solve world violence. But the basic problem is that aggression is such a messy set of behaviors.
Schizophrenia - no question about it, bad news. Alzheimer's disease, childhood cancer, global warming, all of these unassailably bad news. But aggression is a whole lot more complicated, because of that point where we started with, which is, the same exact behaviors, and depending on the context, it could be something that would get a medal for someone, someone you will want to mate with, vote for, reward, cheer on, join in. And in another setting, it is the most frightening thing that can happen to us. And it's the same behaviors in all those cases.
And it's for that reason, that violence is going to be the hardest subject for us to understand biologically. And it's for that reason, that it's always going to be the one we have to try hardest to understand.
> depending on the environment and personal positions, kindness isn't necessarily the most useful option
That is why C-level is so important. It starts there the creation of an efficient well-managed company were collaboration, trust and kindness are nurtured and valued.
I have worked in both types, companies that value trues and companies that value internal-competition, distrust and "strongman". And kindness is way more effective at delivering, finding and correcting risks, and it is a pleasure to work there.
I'm not sure that I buy you're assertion that kindness is either necessarily or sufficiently described by a lack of aggression per se.
Kindness is maybe better described by keeping the the inner life of your fellow beings in the forefront of your mind and treating them with respect relative to that inner life and your own hopefully well though out ethical frame. I can certainly see how that would often limit the amount of aggression you would employ but I see that as a secondary effect.
Aggression is also important in certain scenario when it demands. The problem is when it's expected in everything you do. If aggression and obsessions are part of your everyday that's when it becomes problem and one starts feeling need for kindness.
I made it about 10 minutes through the video of someone telling me what I needed to do without telling me why. Basically it was all "be cheerfully compliant!"
It would be wonderful if "software engineers" just had some code of ethics like actual engineers instead of having to invent this self help dreck. But I suppose that wouldn't be "disruptive."
I often wonder what it is about the software profession that brings this stuff out. Is it that very sensitive people are more likely to be drawn to software? Or is it that software industry culture breeds this kind of thing?
I have friends across many different industries, from government housing to tourism to accounting to logistics to teaching to rubbish collection. None of them would dare talk about "kindness engineering", "psychological safety" or any of these kinds of topics at work. They come in at 8, do their work and go home at 5.
Every workplace has assholes, highly empathetic people, drones and whiners to varying ratios. That's just human beings.
Sometimes it feels to me like some corners of the software industry have been co-opted by self-help gurus (styled as "happiness engineers" or whatever title they conjure up) because frankly it's a lucrative industry and they've spotted a good target.
We're an expensive industry, where treating people like dirt turns out to cost a lot of money.
And so we're one of the few industries where treating people with respect is actually of interest to leadership. Due to a still-lingering belief in Taylorism and an educational environment that's suboptimal, we're still burdened with a lot of people who think fear-based management ("they wouldn't dare talk about X" is about the fear of speaking up) is useful, so we keep needing to teach people that this doesn't really work.
The idea that "all workplaces have assholes" assumes that somehow being an asshole is an immutable quality. For the vast majority of people, it isn't. They've been trained via fear and obedience, and they believe it's the way to results. Teaching them that it isn't helps both get them on a better path, and it makes the overall environment better. Maybe we can't get completely rid of people with negative traits, but we can shift ratios.
Yes, there are some people who revel in being an asshole, or just can't change. They're very few. It's worth helping the rest. (Because training somebody is much cheaper than replacing them)
One challenge I've seen in practice is that psychological safety is often used as an excuse for why someone is under performing instead of holding them accountable and helping them.
> psychological safety is often used as an excuse for why someone is under performing instead of holding them accountable and helping them
Not in my experience. If management is competent they can help to improve trust between teams and team-members, and create a safe environment for technical discussions.
I always recommend to avoid working for "paranoid" management that sees as "excuses" all complains. Lazy management blames downward their own lacking and creates stress, distrust and problems to the employees that do the work.
I can't bring myself to watch the video. "Kindness Engineering" just radiates Orwellian vibes. People aren't being "kind" enough, and so we're going to apply scientific processes to people to "engineer" "kindness".
What a sinister title.
Doing a quick jog through the video...
- "Be yourself, because who you are is brilliant..."
- Psychological safety
- No blame
What a load of toxic advice. Engineering is not an affirmation cult.
I have the feeling that we got to this place by putting the sum of our existence into our git commits. And if people criticize your git commits, they're criticizing your existence, and this is "harmful", so we need to engineer "psychological safety" into our engineering reviews.
The real psychologically unsafe practice is making your code the sum of your existence. Accept that you can fail as an engineer, and still have worth as a person. That's the solution, not "kindness engineering".
I read the deck not the videos, but their is a section on “nice” versus "kind" slice that is the complete opposite of your straw man. Direct feedback about your work that covers both the good and the bad is considered kind and encouraged.
In fact, psychological safety is what creates an environment where actions and decisions can be discussed and critiqued rationally rather than emotionally. The blameless part is shorthand for focusing on the system rather then the person. After all, if Alice took down production by modifying a config file she thought was on the dev environment it makes far less sense to focus on blaming Alice did versus discussing why someone was able to modify production without appropriate checks in place.
The "bring the whole person" and "be yourself" concepts need work though. There are fair number of people I know who I really would not want to just "be themselves" at work.
> I read the deck not the videos, but their is a section on “nice” versus "kind" slice that is the complete opposite of your straw man
Thanks for drawing attention to the existence of the slide deck, that was much more easier to read than the video.
I think I understand why OP is reacting to the word "kind", it is a bit of a misleading branding, and the content is also not exactly coherent about it. There is an extra emphasis on considering the other persons' reception of the communication, but then there is an inclusion of assertive communication as you've pointed out. A more realistic title would have been "how to work and communicate effectively".
> In fact, psychological safety is what creates an environment where actions and decisions can be discussed and critiqued rationally rather than emotionally.
Again I think the connotations of term is problematic, in comparison to your pretty good of an explanation of what it should be about. After all psychological safety depends on the other side's psychology, so for a narcissist that would mean actually not threatening their myth of personal superiority, and bringing rationality to discussion would not necessarily be comfortable for them.
I think a much better approach can be considered through virtue ethics. There is no being fair to the other people while not being fair to ourselves. So there is a golden mean between giving consideration to their point of view vs. requesting consideration for our own point of view and there is no algorithmic approach that can find that point for us. We can't get lost in emotional contagion with the other persons' feelings (think of a surgeon unable to operate a kid because they are empathizing too much), just like we can't get lost in our own feelings (every callous, bullying manager or lead we've encountered).
Also "engineering" kindness sounds very objectifying and manipulative. Please do not engineer me, I am a human. Tell me the good reasons to be kind, and let me decide for myself. If being kind is "good", people would naturally take it up.
Disclosure: I read the slides, but have not watched the video.
What the author is doing is disentangling accountability and support. The nice-kind distinction is reminiscent of the permissive-restorative distinction in the social discipline window[1]. This disentangling into a 2x2 sets the stage for analyzing feedback.
I've never considered a good code review to be "kind" -- and I don't think much will change that.
Helping an old lady cross the street. Buying a friend a coffee and listening to their troubles. That is kindness: an ethical consideration for others, and a pleasant disposition.
It's absolutely essential to have design reviews be rational, and to untangle complicated emotions. The reason flight travel is so safe today is because of these principles -- crash reviews are not about assigning blame, but finding the cause of the crash to prevent further loss of life. But "kindness" does not come into play here, and introducing it will create problems, not solve them.
I agree with you, that the "bring the whole person" and "be yourself" part is unrelated good engineering practices. But these are the grounding framework of "psychological safety", which puts the responsibility for my well being in your hands. That's a responsibility that no one can (or should) bear.
I think you're conflating kindness and niceness. People are nice to protect the feelings of others, whereas kindness has a more logical component, e.g. being honest when the truth can hurt. You can be kind without being nice. But I believe you're right that people need to take their emotions out of their work.
Most of what we do, including writing code, is not rational. We are emotional beings with heuristics. You make irrational decisions in your code all the time. Hell - the fact that your code doesn't come along with a formal proof is evidence of irrationality; do you think the code you hand-crafted doesn't have bugs?
Kindness is a tool we use to accomplish work with other emotional irrational beings. The NTSB crash investigations wouldn't work without kindness. You can't run around asking insensitive rude questions in an insanely important/sensitive situation and expect to get cooperation! We are all responsible for each other whether we like it or not, and our ability to work together we'll hinges upon good relationships, which among other things, depends on whether we're kind to each other.
> Most of what we do, including writing code, is not rational.
Wow. I knew I was pulling on an ugly root when I started writing against the inclusivity dogma, but this is a little more than I was expecting to unearth.
Humans do not need formal proofs for things they do to be considered rational. Full stop.
> You can't run around asking insensitive rude questions in an insanely important/sensitive situation and expect to get cooperation!
I mean... you did just say the majority of what I did is irrational :'D But. To say that kindness does not factor into NTSB investigations does not mean that the alternative is insensitivity and rudeness.
Dude, I don't care about your problems with minorities, you don't have to bring it up in every conversation. It's like you're fixated on it.
> To say that kindness does not factor into NTSB investigations does not mean that the alternative is insensitivity and rudeness.
That's exactly what it means. If you're not being kind, then you're being unkind. Lack of kindness is a property of unkindness, just like insensitivity and rudeness.
"unkind, adj. 1) Lacking kindness; inconsiderate or unsympathetic. 2) Harsh; severe. 3) Not natural; unnatural. 4) Not sympathetic; lacking in or not springing from or exhibiting kindness, benevolence, or affection; not kind; harsh; cruel. 5) Having no race or kindred; childless. 6) Not kind; contrary to nature, or the law of kind or kindred; unnatural. 7) Wanting in kindness, sympathy, benevolence, gratitude, or the like; cruel; harsh; unjust; ungrateful."
Without the properties of kindness, an NTSB investigation would not be able to gather as much evidence. Every hostage negotiator and interrogator knows that you can get a lot more practical information by being kind and trying to be someone's friend, even if they have reason to doubt your motives. Being kind is a great strategy.
But it's not just a strategy to fool someone. It's as practical as it is morally good. It fosters better collaboration and communication, it speeds up resolution of conflicts, it removes barriers. Kindness is an indespensible tool to facilitate work between humans. The fact that it's also the morally correct thing to do is a side benefit.
> It's absolutely essential to have design reviews be rational, and to untangle complicated emotions.
We should stop hiring humans then, but what is the alternative? I have seen too many engineers getting angry because people is not rational. Like, man, you are getting angry and hyper-emotional but you think that others are irrational.
You have built up a terrifying straw man based on a video you admit you didn't even watch.
You're right that we should put less emotional stake in our code--the video actually lays some healthy ways to do this.
More generally, it's important that we recognize that people have emotions, otherwise it makes it easy and convenient for us to treat them like shit. (hint hint)
I'm almost certain you have, at some point in your career, correctly implemented a feature, only for an operations or product counterpart to blame you for some piece of out of scope functionality not being there.
How did that make you feel? Did you alter your behavior to be less helpful in the future? Did you start recording meetings so that you had a source of truth on explicit scope?
If team members think or feel that they "need to cover their ass," that hurts the company's mission, and wastes resources. Worse, it can lead to managers pushing for excessive due diligence, which saps the motivation of ICs.
Blame is ultimately a waste of energy. Every team member is going to make mistakes if they are taking sufficient risks. You can fire people who have a negative contribution level or chronically underperform without leaning on blame.
