Why public chats are better than direct messages(teamplify.com) |
Why public chats are better than direct messages(teamplify.com) |
I stopped reading there -- maybe it's prejudice, but it's also my spam filter.
The result is here:
https://community.intercoin.org
https://youtube.com/c/intercoin
Anyone coming by is able to see what we are working on. We’re gradually moving to self-hosting everything open source, with no reliance on Big Tech at all. We do want to rely increasingly on decentralized networks, though.
Even our clients are encouraged to come on the show to discuss their challenges and their needs, rather than “requirements gathering” in private. They sign a release that we can use clips in our marketing. We explain to them that they get exposure for their community and fundraising, as the clips get shared in the subsequent months. A few clients insist on an NDA - we put them on a waitlist at the back of the line. We prioritize clients who are willing to openly discuss their community and needs. As a result, we also have an endless supply of “reality TV” case studies from beginning to end of testimonials about how they needed our service, and then how we helped them.
By creating a culture of openness and collaboration, we make sure people know what is happening. Our roadmap is public. Our customers are public. I personally interviewed some well known people this past year:
Noam Chomsky, political commentator
Sara Hanks, author of Regulation S at SEC
Ian Clarke, founder of Freenet, the first truly decentralized hosting network
Thomas Greco, community currency economist
And much more. Now in the show’s second season, I plan to organize panels where we have multiple well-known people and have them discuss stuff for 1-2 hours. Sometimes we may use a famous person as a reason to reach out to other famous people to be on the same show.
I used to wonder why I accomplish so much and yet get so little interest. It’s because you have to be public with your successes and grow a snowball around your project, to attract people with clout, reach, resources, and other forms of capital. To build a movement, it’s better to have every member to bring 1 new person a week, than spend $ on marketing on FAMGA in a zero-sum game to strangers. Virality wins in the end, and us far more sustainable.
The goal is about more cross pollination of ideas. We don’t have a big audience (yet). But we will be selling this software and this system, to celebrities, conferences and other projects - including tech startups. If you’re interested, comment below.
But here's the thing: every group is different, has different needs, and will respond differently to different styles of communication. Some people (especially people not using their first language) can find working in public stressful; some people get very stressed by the intensity of 1:1s. It takes all types, and as a manager, understanding how to get the best out of everyone is part of the job.
There is no single, correct way, and we know this because, if there was, then we wouldn't keep hearing about these interminable "solutions".
Which is fine coming in, but the culture should be one that reassures these folks that public forums in the company are safe regardless of their proficiency with the main language.
Half of the people I work with speak English as a 2nd language (most are very proficient since they're mostly French-Canadian but there are plenty that make a bunch of grammar/spelling mistakes). That's never been the reason why folks try to use private channels to discuss work. The main reason I've seen is because people think it's more efficient to reach out directly to people. I've seen it a bunch with product managers and engineering managers that are new to the company and not used to a culture of trying to work out in the open.
So you know, both cases happen.
But there is room in the world for more than one way of doing work. There are drawbacks to doing everything in public just as there are drawbacks to doing everything in private. If you care about getting the most out of the individuals in your team then finding the right balance is hard, and there is no one solution that will work in all cases.
Also worked at a company that encouraged people into public channels for inter-team communication and into team channels for anything useful to your team, but didn't have obnoxious rules around it. Also allowed private team channels. Worked perfectly, everyone felt comfortable talking to just their team in the private channels, and everyone searched Slack for old technical answers all the time because they were actually there, which is about as close to proof it worked as you can get.
Also there should be a buddy for all new hires and you should get a month or 3 of DMs with them because asking every dumb new-person question in public is tough for introverts.
From the home page,
> Teamplify | Hey @anna.austin, we haven't seen updates for PROJ-716 since Thursday, July 19. Could you please add a comment there summarizing your progress as of today.
Yes, this is very true, and it varies not only by person but by situation. But most people have a default that they respond best to.
- Some prefer IM
- Some prefer email and will respond to a group discussion with an email (sigh)
- Some prefer direct phone calls and will completely ignore your IMs
- Some prefer group chat
- Some prefer more formal group chats (MS Teams calls these "channels")
- Some want you to walk right up to them and start talking
The truth is you probably need a mishmash:
- There's a time and place for group emails, most notably when you need to include an outsider, or if you want a better paper trail of the conversation
- If your team is accepting of it, some form of group chat really is super effective at greasing the wheels, but I find it's inappropriate for lengthy, detailed conversations. Then it truly does become noise.
- Direct IMs, direct emails, phone calls, and foot traffic are all extremely easy to abuse and should always be used judiciously. None of these should be the default unless you know this is someone's preference; it's just rude.
The other side of the coin is that if a team member chooses not to be adaptable they are limiting their own ability to contribute. If you want to be a finicky communicator don't be surprised if you get the dull work or get overlooked when promotions come around.
Presuming that information asymmetry will hold over time is a bad assumption, regardless of cost of information security controls.
Why have these new collaborative innovative services succeeded where NNTP and > > indented, text-wrapped email forwards for new onboards have not?
Instead of Chat or IM, hopefully working on Issues with checkbox Tasks and Edges; and Pull Requests composed of Commits, Comments, and Code Reviews; with conditional Branch modification rules; will produce Products: deliverables of value to the customer, per the schema:Organization's Mission.
What style of communication is appropriate for a team in which phase of development, regardless of communications channel?
The new tools we have at our disposal are amazing. Of course they are better. But they are just tools. They don’t solve any problems relating to interpersonal communication any more than a hammer solves building a house.
> What style of communication is appropriate for a team in which phase of development, regardless of communications channel?
It’s the job of a manager to work that out. There is no formula. It’s not even possible to write one down. That’s the point.
YUP!!
Especially when some parts of the group are working with Controlled Unclassified Information (even more so for classified); it's a legal requirement that people access it only on a need-to-know basis. Even without that, companies that rely on trade secret protection (Apple, SpaceX come to mind) must also compartmentalize their information both to prevent leaks and to protect it's legal status as a secret (you must treat a secret as exactly that, or risk it being declared public domain)
It’s like having drinks at a bar solo, talking to people next to you (a bit more reserved, avoiding specific topics) vs. having drinks with a close friend. I don’t mind if someone listens to my private conversations with my friend, but the direct audience is different.
Closed channels for teams are good but not everything is a democracy. I let my team make decisions but I can veto any of them, if needed.
So, you are saying that yours is the only way? And that being flexible and working out what’s right for your team… is wrong?
Some people get it. But overall in the cultures I've done it in, it mostly gets me branded as difficult.
If you are interested in learning more on it here are a few resources!
1. Project Aristotle - A study from Google https://rework.withgoogle.com/print/guides/5721312655835136/
2. Good to Great had a couple chapters touching on safety, but also making company information easy to access.
http://www.squeezedbooks.com/articles/good-to-great-why-some...
3. A more sciencey approach https://www.ncbi.nlm.nih.gov/books/NBK310384/
I couldn't find the second study I wanted to link to. I recall reading a study on team composition that focused on impact of different types of leaders. Teams that had a leader which got everyone to talk in a group were consistently successful. That was the one constant over time, even beating out visionary/charisma types that weren't inclusive.
Their company size is only 25 people. I doubt they will be giving the same advice if their company grows to 200+ people.
At some point you should trust your team to be adults, and to make the best choice for the situation.
I’ve worked at FAANG where I was reprimanded by HR equivalent for raising an issue in chat rather than email because of who was in the channel. I wasn’t rude in my report, I just explained the issue, the impact it had and the likely resolution.
Maybe a VP was having a bad day, but I’ve since learned to keep my mouth shut working for large organisations as an IC.
It’s something I expected from shitty workplaces like Big4, consultancies or FinTechBroCorps but it’s everywhere.
Use something that can be searched, and doesn't require one to have an account to read the messages and/or search.
And setting up search on the chat is not difficult, we had search on chat 25 years ago.
Chat is ephemeral, treat it as such and everyone's life will be better.
For starters, he's talking about communications within a team, not the whole company. Should all work conversation happen in a single #general channel on slack (or whatever the equivalent is wherever)? Absolutely not.
For a long time my boss was a big proponent of this, and I was against it. However, I'm personally tired of having the same conversation over and over as we realize we need to add more people to it. Or half the team decides on an approach in private, and then someone in the other half sees in the PR immediately that they didn't consider some huge thing and now it's back to the drawing board.
So now, everything should happen in the team's open channel.
The real crazy thing is how slow our nontechnical progress is.
As a more real-world example, in Slack, you can decide to use more channels instead of having a big channel with lots of threads. But this tends to need a lot of discipline on channel management. Places devise naming conventions, etc. Or maybe they integrate with some other tool to manage the conversations.
So, a lot of my DMs tend to just be me and a "tiger team" on a particular subject. Which is really just a workaround to not having to figure out channel management. It's not a carefully thought through system, it's a workaround to our current crop of chat tools.
Personally, I've found older "discussion forum" systems do a better job of threading instead of a chat-style tool. But maybe I'm just getting to be an old person.
They DM me or publicly message me depending on what's most convenient for their public image.
It can also lead to issues when members of the chat have varying degrees of context. Shared understanding is ideal, but it's impractical for everyone to be aware of everything so there's a balance to strike.
Public chats are somewhere between the extreme of broadcasting everything to everyone and talking only in private chats. There's definitely a lot of middle ground.
"I don't think it's good for nonsense to come out of a one-to-one message and be on a channel."
I have no idea what you tried to convey there (did auto-correct mangle the words?).
1. Concern that certain specific people could hijack conversations or take them the wrong way
2. Ability to candidly express frustrations with partners and stakeholders not doing their part
I don't think we are unkind or impolite, but any negativity we express, even for the purposes of effective internal problem solving, can be used against us.
When I know who I'm talking to, I can tailor my message for them. If I talk to another embedded C++ coder about memory management, I can make my request short and concise by assuming that the recipient already knows what the placement new operator is, how it works, and what using it implies. That means I send a quick 10s chat message to ask for one thing.
If I had to include all that background information to make the discussion accessible to people who have different strengths, for example to the front-end Ruby developers, then my 10s one-liner would likely turn into a 30 minute 2 pages email. But the contained information for my target recipient is still the same. So I have just wasted my time and his/her time.
Also, there's the increasing issue of people taking internal work discussions and sharing them publicly. I wouldn't want some of the new hires in the social media team to read our internal discussions about CLV and CAQ, because discussing clients in a purely financial and/or mathematical way would rub more emotionally skilled people the wrong way. There was a huge scandal when word got out that some companies called their Dallas office the "discount" location, even though it had been blatantly obvious to everyone before that SF employees earned much more.
So the simple act of sharing a chat message to a wider audience requires:
1. additional explanations, thereby making things longer and slower
2. additional safety checks, thereby making things slower
It does not scale.
I also think it shows a fundamental misunderstanding in what code review is - half the time I’m basically not invested at all in the outcome of the particular review, I am just giving my time and knowledge to help make sure that we produce good code. When people start these sync chats I have to context switch a lot and people often think I’m super opinionated on the outcome (so ask me lots of open ended questions I’m not prepared to answer), which is not what I intend to convey when I say you need to test something or document some particularly confusing part because it seems pretty likely to break.
"Hey, sure I can answer your questions, but I often find it helps to do that in public so we have a track record... etc. etc. And I'm not immediately available, so I'll get to it soon..."
It's tough to fight habit and culture. As the article points out, it's *all* about comms. That's a 101 statement. Having to explain the value of comms (and documentation) isn't something you should have to do. So if you are, chances are good they won't get it.
Sorry to hear that. Getting the right balance of sync and async, and knowing when to use one or the other makes a big difference. In my current team we went through multiple iterations to come to a mix that works for us. If it's too much sync, the constant sync conversations drain you; if it's too much async, coming to a concensus becomes grindingly slow.
When it's just async written messages, I'm constantly only able to say 1/10th of what's on my mind only for it to be misunderstood by the other person hours later. Sure you can blame it on me for being poor at written communication but I'd argue the other person is always just as bad too. They just think it's the other person and not them.
It’s also, not necessarily disrespectful, but a very inefficient use of my time to spend 20 minutes chatting with someone about why you need to add a test in XYZ and make sure you check A - when I can do that in just a few minutes exactly when I’m ready otherwise. Because I am reviewing 5+ peoples’ code and have my own things to do as well. The asyncness is necessary for me to manage my time. I can also read much faster than I can listen, and it takes me longer to explain something with words than to find a couple links and write out a few sentences about something.
If these things were written down there might be less of them. Might. It might just be part and parcel of working in a more enterprisey setting again.
Being new-ish I felt like I could ask the obvious question.
“Where do we find this process?”
Leader: “Oh don’t worry, I’m not blaming you. I sent out the process in email before you joined.”
“I joined nine months ago.”
Leader: “Yup.”
In the end this person was actually pretty great to work with but man having a ton of wonky communication methods and etc just constantly causes problems.
But people get lazy because Slack is there and it's "easier" (really, more immediate) than looking at the PR.
Opened a feature request: https://github.com/integrations/slack/issues/1433
"Discussed A, B, C with <@person> and we agreed on <plan of action>"
I think a lot of the effort that people perceive has to go towards async discussions is actually just resistance effort, too. When multiple people embrace it it can be surprisingly easy.
And a lot of times people push the async method because the environment is already difficult -- for them. Sometimes certain team members get bogged down in focus work and want to get that done as much as others want to have a discussion. How to have good conversations in the ideal workplace is one thing; how to have them in more dysfunctional situations is another.
> if I'm trying to land a change, having a synchronous conversation (ideally in person) will resolve any misunderstandings between us on the order of minutes.
That does not match with my experience.
Imagine I wrote a comment on Steve's PR in foo.py line 31 that said "I see what you are doing here. Do you think this would be more readable if you used the itertools from the standard library instead of implementing this yourself?".
Now Steve asks me if he can have a call with me about my comments. I join the call and he opens the PR. He reads my comment aloud, then he says "OK" and opens up the documentation for itertools and reads it silently. I'm still in the call.
This goes on for every comment.
I see what you mean and wish that that was how it worked - and I've made good experiences doing this after 90% of comments in the "written comments" stage are worked on by the author. But just skipping it sounds like insanity to me.
I can remember many times, specially on new teams that I just joined, that by reading PRs, specially following https://conventionalcomments.org/, I get much faster the motto and the spirit of the team.
You have the context and the focused discussions on the same place. You can also check how much time it took to deliver and even connect easier to the outcomes of the deliverables.
If the discussion gets too subjective, use the team private chat, with threaded comms, then a direct call.
I know it depends on the urgency as well, but we should strive for general efficiency, not efficiency only during rush / at the end of sprint.
That's why also I prefer to open WIP PRs with incomplete code. Open discussions beforehand.
Also, repeated questions and similar problems can be retrieved from the chat / comments history.
Now, for early designs, spikes, initial research on an epic/hard tasks, needs some sync comms, followed by some asynchronous comments and questions.
Even things like "yesterday we discussed during a call x, y and z, and we agreed on w. it still holds up? In this case, I will use the strategy N to develop the solution, please comment back if you changed your mind".
It helps me a lot, and the people that I asked about this kind of message are heavily positive on it, because it's neutral enough and consolidates the agreement.
Then after a few weeks working close to someone (same team, for instance), I can make that phrase shorter, because we established a protocol.
Now that said, under my new contract, the entire team is almost silent on chat and everything is a direct call with 4 people on avg. I'm wrecked today because of 5 consecutive 30min~1h meetings to sync information yesterday.
This is the price we pay for not knowing what's going to be important in the future. If we knew that, we could mark the messages immediately and have them pushed into the FAQ or the wiki or whatever.
By obvious corollary, message archives need good full-text searching or else they are useless.
There is a place for everything - PR comments, public slack channels, private DMs, in-person meetings, video calls, 1:1s - even phone calls! - but what’s critical is to use the tool that best gets the job done. And most of the time the job is not “teach everyone all the time”.
Public vs DM just means (to me at least) “put all comms in the relevant channel, never in a DM”.
I’d go so far as to advocate temporary channels for individual projects but not everyone buys into that. At least have team and working-group/functional channels.
Basically it’s analogous to email (point-to-point) vs. archived mailing lists (which anyone can subscribe or view after the fact). Mailing lists and public slack still have threads/channels.
Before this, the devs would make a private channel without product and management people, to discuss technical things openly or just to complain. But product/management was unhappy to be left out of this communication channel.
Eventually we, devs, decided on our own to end the private channel and "banalize" the main team channel, by that I mean that we were going to try to make the main channel less "official" looking and more casual, like sending memes, talking outside of threads and so on. With the intention of making people mor comfortable in using it.
This had mixed to low effectiveness, some people were more comfortable speaking entirely on the main channel, some other people pretty much just started only using private conversations and never used the main channel.
So my solution was to create a temporary project channel, open, but only with devs explicitly invited (but communicated at the main channel that the channel existed). This channel is implied to be a dev channel, but whoever wants to join in can, or they can also just peek in without joining, being a public channel.
So far this has been working well, as long as you are in a reasonably long running project. I have archived more then one of these channels as the projects ended, and I'm thinking of maybe not even achieving the current one and just rename it after the project, let's see.
So, keep of trying to make this fly with your team, it did worked somewhat with mine.
If we can agree that not all conversations in a company happen inside of one big channel, we've already agreed to subdivide the company's conversations into smaller subgroups (teams). Why then do we dismiss the idea of subdividing a team's conversation into smaller subgroups? Why is a team the smallest unit?
Is there not also times where you share information to your entire team, but then realize you need to add in other people from not in your team? How is this different from the example where half the team had a discussion? Why is the entire concept of subdividing conversation lower discarded in an attempt to fix an issue that doesn't even end up fixed?
Start the discussion at the level you want, make it clear who it’s for, and others can read along if they want. They may learn something, they may ask a question or two (and it’s good to answer for knowledge sharing), but also they may decide they don’t need to understand and not bother asking, and you can encourage this subtly if you get too many questions.
It’s also great for reducing comms later as rather than explain a decision or design or something later to each person who asks you can just point them at the original discussion.
As for repeating to external - I don't see that as a problem - well it fixes itself quickly the leaker would get fired pretty quickly.
This is a strawman scenario. Nobody expects you to make your directed C++ discussion accessible to the front-end Ruby developers.
The point is that a team needs to move team-specific discussions into shared team spaces where the relevant team members can observe and be informed or involved as necessary, as well as understand now and where things are decided.
The point isn’t to inform the entire company of every detail of every step.
"Traits of good remote leaders" (2019) https://news.ycombinator.com/item?id=24432088 :
"From Comfort Zone to Performance Management" (2009) https://scholar.google.com/scholar?hl=en&as_sdt=0%2C43&q=%E2... :
> "Table 4 – Correlation of Development Phases, Coping Stages and Comfort Zone transitions and the Performance Model" in "From Comfort Zone to Performance Management" White (2008) tabularly correlates the Tuckman group development phases (Forming, Storming, Norming, Performing, Adjourning) with the Carnall coping cycle (Denial, Defense, Discarding, Adaptation, Internalization) and Comfort Zone Theory (First Performance Level, Transition Zone, Second Performance Level), and the White-Fairhurst TPR model (Transforming, Performing, Reforming). The ScholarlyArticle also suggests management styles for each stage (Commanding, Cooperative, Motivational, Directive, Collaborative); and suggests that team performance is described by chained power curves of re-progression through these stages.
But how do you get the information first. You have to look at the chat transcript - and in an international company and a problem requiring thought or research the information could be spread over a couple of weeks SO you still need to scan the transcripts.
Yes Chat is ephemeral and I can't think of cases that involved looking back a year but weeks definitely.
Chat id part of the process - if an issue is raised then the solution will be a permanent change, in my case software code changes, or an email summarising the solution for non computer issues, or chnages to documentation (if you are lucky enough to have documentation)
Another example is if you go on vacation for a few weeks the a quick scan of chat is often useful.
If forcing all communication to be done in public makes the goal harder to achieve, then ffs do something else. Don't just force people to be inefficient because of some dogma.
The goal is not "make all communication public". The goal is to get the job done.
Just adding that "get the job done" shouldn't be confused with personal productivity. Many younger/inexperienced devs that are highly motivated go through a phase (some get stuck here) that optimizes their personal productivity above the team's productivity. You end up with pockets of people that share knowledge (or hoard knowledge) with others left behind. You also end up with different subsets of people making different decisions, younger devs clinging to each other for feedback/guidance (yikes), and way more thrash that needed.
I was thinking that the OP for this comment thread was claiming that there are situations where public comments/knowledge sharing isn't needed for teams, which makes no sense to me.
For example: While working with text written by non-native speaker, had to explain often to some members of the team t hat the text was just awful and needed a complete rewrite. But I didn't want to type this in public so that the "culprit" wouldn't feel like I was out to get him or something.
At least in my culture, it is extremely rude to berate people in public, so I extended this to also considering rude to "blame" people in public when explaining why work is late.
It was based on my real-life experience working with a colleague from another team.
> If it were possible to use itertools, wouldn't they just research that, update the PR, and say OK in a comment?
Time spent on a call is time you are publicly perceived as working. Time you spend researching itertools is time during which someone can interrupt you by pinging you in Slack. In that employee's shoes, it seems clear which one of those gives you less of a headache at the end of the day.
Politics aside: Exactly what you describe - the capability to research a library, respond to a PR comment concisely and appropriately - are skills that no one learns during a CS degree, nor doing code monkey work. Ideally, this is the sort of thing a junior engineer gets taught during their first years on the job if supported by a capable mentor. But if they don't have one? Tough.
I think you have a very strange view of development work. At least in my experience, a vast majority of work involves going off on your own and implementing things, which often involves reading documentation. Meeting with a colleague is also considered work, but I wouldn't say meeting with a colleague is somehow considered "more work like" than solo development or that many developers prefer one form of work over the other.
Do you send the idiosyncratic team member home and forgo what they’d otherwise bring, or do you adapt your process to make the most of the team you have?
It’s great to have ideals to reference, but you miss a lot when you hold onto them as rules.
That’s is such a great way of describing my frustration with this stuff.
Your counter-point is "there are a miniscule contigent of people who can't function at all in a team". Weak.
Do you force them? Sack them? Threaten them?
Or just send them for reprogramming?
Honestly, this is just cargo cult stuff.
Being uncomfortable isn't a veto.
All your criticism is just framing. It presupposes pathological work practices are actually just personal quirks. If you can't type a question in a slack with 20 members you are basically useless.
I did not present my view of development work - I presented that employee's view of development work.
> At least in my experience, a vast majority of work involves going off on your own and implementing things, which often involves reading documentation. Meeting with a colleague is also considered work, but I wouldn't say meeting with a colleague is somehow considered "more work like" than solo development or that many developers prefer one form of work over the other.
In my experience, every single developer wishes they could spend less time in meetings and more time "doing real work" (their perspective, not mine). Everyone with the opposite view is promoted out of being an Individual Contributor.
Also with private criticism, any decision tends to gravitate toward the opinion of the highest paid person. If the debate happens in public, everyone has more of an equal chance to be heard.
----
Edit: almost forgot! Private criticism also leads to an air of suspicion, in my experience. When everything public is upbeat and positive you start to wonder what terriblenesses people are hiding. It might be nothing, but that's the thing -- you just don't know.
Being able to publically discuss both the good and the bad is a prerequisite for a smooth operation, and the hallmark of a mature organisation.
This. When I get criticized in private on an technical matter by someone more senior than me and disagree with them there isn't much I can do. Maybe I already have a good relationship with them and we can talk it out but if not I just have to suck it up. I can maybe escalate to higher up but that is also very risky and might more harm than good.
There isn't much I can do to defend myself.
In public there is a chance of other people offering their opinion. Senior people might get kept in check if their critic seems too unreasonable to the rest of the team.
I think a good rule is to criticize technical stuff in public and personal stuff in private.
Interesting, that's the opposite of what I've experienced. Also a problem with group dicussions is that it's too easy for participants to drift into group think and conformism. I thought these are general principles, but maybe they are predicated on the group.
I can't stand people that are always-positive and nice all the time. I know they are lying and holding stuff back --- but what? I'd rather be friends with someone honest than nice. At least I know what they are thinking, and thus actually know them. Some people would rather just go through life in a mask and insist everyone else wear one too -- something I generally refuse to do.
If and when you have that trust, criticism also needs to be more structured and question oriented. E.g.
- I think the main problem we're trying to solve is X. Is that right?
- if we do this, we'll solve Y but we'll also have a new issue Z. Do we think we would rather have Z than Y?
The whole team should be able to look at and learn from code reviews, and the best way to do that is if it's in the open for the whole team or company to see. I'm not sure if truly "public" is possible for most companies, so I'm not talking about that.
I would say that you're right about other kinds of feedback, like criticism about (mis)conduct, attitude, etc. That should for sure be done in private.
It's hard - but a wonderful soft skill - to do this in semipublic envs and be gentle.
"enhancement: Extracting the lines below into a separate function. As far as I understood it's only calculating x, you can call 'x_calculation'. Fell free to use a better name than my suggestion".
shorter, for a team that you are already know for some time:
"enh: extract into a new function. It's calculating x, maybe it's 'x_calculation'. You can name it better than me."
During retros then, I usually recall everyone that I'm open to be criticized in good terms, and send me a message if I'm out of touch. Or even be open during the retro.
“The problems in your team can be solved with this ONE STUPID TRICK”
A team is a bunch of individuals, and working out how best to motivate everyone on your team is the manager's job. And not everyone is going to be optimally motivated by being told they have to do everything in public.