[HN Gopher] Effective teams don't keep secrets
___________________________________________________________________
Effective teams don't keep secrets
Author : adrianhoward
Score : 104 points
Date : 2022-02-25 08:58 UTC (1 days ago)
(HTM) web link (www.theadamthomas.com)
(TXT) w3m dump (www.theadamthomas.com)
| sandGorgon wrote:
| This is basically psychological safety, worded in a different way
| - https://hbr.org/2017/08/high-performing-teams-need-psycholog...
|
| The best write up on psychological safety is from Google Rework -
| https://rework.withgoogle.com/guides/understanding-team-effe...
| davesque wrote:
| I remember working at an organization that essentially made the
| results of performance reviews open across the team. The rational
| was that it would help people make sense out of salary figures
| (which were also open). It did not improve team function and led
| to a lot of paranoia, fear, and resentment.
|
| People keep secrets on some level because they need privacy. If a
| person is struggling, they often react by withdrawing and don't
| always appreciate their struggles being brought to attention.
| Especially when their livelihood is on the line. Everyone's
| different, but increased openness is not always going to help.
| Everyone should have the right to privacy in both personal and
| professional settings.
|
| _Update:_ Actually, I think the author of the article must
| understand all of this because they do call out privacy as
| necessary and try to distinguish it from what they 're calling
| secrecy. And secrecy seems to basically mean willingly
| withholding information necessary to properly complete a job.
| They say this could happen if teams have an antagonistic working
| relationship. I think it's a useful distinction as I've also seen
| this happen at a company, more recently than the previous counter
| example that I gave.
| jka wrote:
| I hear what you say, but I'd like to add that as an employee,
| I'd like the _option_ to make my performance data, salary, etc
| public -- even if it that is not the organization-wide default.
|
| The reactions that people have to their own data being public
| are partly a result of the current hidden-by-default model.
|
| I'm not a great developer: I'm experienced, but I make the same
| mistakes that any junior would. I'd prefer to share the kind of
| feedback that I receive and how those discussions proceed, so
| that juniors can look ahead, learn, and avoid repeating the
| same mistakes (hopefully leading to a much more advanced cohort
| of future developers).
| jrapdx3 wrote:
| > "...if teams have an antagonistic working relationship"
|
| Yes of course a set of people constitute a _team_ if and only
| if it meets the requirement for _teamwork_. That is, cooperate
| via info sharing, work load distribution and other support to
| get jobs done. Obviously merely assigning random workers to
| contiguous cubicles in no way constructs a team. That remains
| true even if a manager is loudly chanting holy corporate verse
| while pronouncing teamhood upon the hapless crew.
|
| This is as it's always been, teamwork is essential for the
| survival of modern humans. Companies that foster teams, and
| teamwork among teams, are the ones likely to succeed in the
| marketplace.
| bob1029 wrote:
| Sometimes letting someone know about a piece of information too
| early can cause problems.
|
| I have some very anxious team members who will get on edge when
| the development team starts to use key words like "refactor" and
| "iterate". Our organization has a historical track record of
| certain technical efforts being a complete dumpster fire and the
| PTSD of that has stuck around with many of us.
|
| In order to make everyone's lives easier, I will sometimes work
| in secret on prototypes of more "controversial" ideas to bring
| before the team. I find starting the conversation with "Here's a
| new thing you can actually see and play with" eliminates 99% of
| the annoying bullshit you get out of non-technical folks.
|
| It takes some discipline to do this correctly (i.e. don't ferret
| away on a secret prototype for more than ~1 week). That said, I
| can't imagine how you would scale an organization if everyone had
| to know everything always.
|
| Also, none of this stuff is actually secret. It's more of a need-
| to-know basis. If someone explicitly asked me about one of these
| efforts, I would tell them everything they wanted to know and
| then some.
| hughrr wrote:
| Completely agree with this. On numerous occasions I let an idea
| out while it wasn't developed enough to go in the right
| direction on its own. It turned into a shit show.
|
| Many many ideas I write down and develop. Many I throw away.
| But I learned never to throw information on the table without
| analysing the consequences of doing so.
|
| This applies to teams as well.
| crispyambulance wrote:
| What you're talking about is sometimes referred to as
| "exercising covert agency" and IMHO it's absolutely essential
| for the well-being of creative folks in heavily project-managed
| corporate workplaces.
|
| "Not keeping secrets" effectively ends up meaning that you need
| "permission" or at least consent for everything you work on.
| Depending on how tight things are this can be a recipe for
| misery because it's common in managerial ranks for people to be
| change-averse to the point of absurdity.
| darkerside wrote:
| Google turns up nothing on that concept, but I agree that it
| is essential. You need a strong leader who can sense when
| stakeholders don't want to put up with that shit and when
| it's OK, and counterbalance that with how much of a dumpster
| fire the codebase is becoming.
| beckingz wrote:
| This. Sometimes holding information until things are ready is
| the kindest thing to do for anxious people.
| rubyn00bie wrote:
| > Our organization has a historical track record of certain
| technical efforts being a complete dumpster fire [...]
|
| I think your urge to hide things until ready is clearly a
| symptom of other (root) problems within the organization. I
| have never seen what you describe in a healthy organization,
| and many seemingly "healthy" places are not. It sounds like the
| organization fears failure and refuses to learn from mistakes
| or believes it's impossible. This is a cultural issue that
| needs to be fixed by senior leadership but, if I had to guess,
| is probably caused by senior leadership being unwilling to
| trust.
|
| I'd encourage you to look to solving roots and not symptoms or
| go somewhere else where you're allowed to. Good luck.
| bob1029 wrote:
| > I have never seen what you describe in a healthy
| organization, and many seemingly "healthy" places are not.
|
| You've never screwed something up and had to try it a
| different way?
| rubyn00bie wrote:
| I honestly do not know how that was your take away from
| what I wrote. Can you please elaborate on how what you
| quoted at all implies:
|
| 1.) I've never screwed up.
|
| 2.) (and never) Had to do something different.
|
| I'm saying the lack of transparency you've been forced into
| to accomplish things is the result of people who are
| incapable accepting mistakes or doing things differently.
| You must work in secret because people don't believe the
| technical team can or will learn from their mistakes. In a
| healthy organization you would not have this burden.
| travisjungroth wrote:
| "Sometimes I work on things for up to a week before showing
| people unless asked."
|
| "Your company isn't healthy. Either get senior leadership to
| change or leave."
|
| Internet advice is weird.
| darkerside wrote:
| It's easy to not have seen things in healthy workplaces if
| you don't have a lot of experience. This is why we have
| implicit bias against folks who look really young, fair or
| not.
| throwawaysleep wrote:
| > If I don't believe that other members of my culture have my
| best interests at heart, I may decide to keep as many secrets as
| possible to prevent information from being leveraged against me.
|
| The biggest challenge for me here is that I don't believe a team
| or company can have my best interest at heart, as they often
| conflict with the best interests of the company.
| drewcoo wrote:
| Is your main goal in life not to maximize stockholder profits?
| How strange!
| shoo wrote:
| In practice, the company is not an entity able to set
| objectives or make decisions, decisions are made and
| influenced by individuals, and often the incentives of
| individuals are _not_ aligned with maximising stockholder
| profits. In many cases companies do things that do not
| maximize stockholder profits. There are blatant examples of
| this where a company CEO or company president is able to
| plunder assets from the company for their own personal
| enrichment (e.g. through self-dealing where the company buys
| or sells assets to another entity controlled by the CEO).
| There are also many cases where a project pursued by the
| company may have zero or negative benefit to the firm and to
| its shareholders, but provide many benefits to the employees
| leading or participating in the project.
|
| William J. Bernstein's article Of Earnings, Dividends, and
| Agency [1] offers an educational and entertaining perspective
| on this: > in a taxless world a company's
| dividend policy should matter not at all to the shareholder.
| Inside academia, this is known as the "Modigliani-Miller
| theorem." In the taxable world, of course, shareholders
| prefer capital gains to dividends. So why do companies pay
| them? > Because, to put it bluntly, corporate
| officers are often scoundrels and theives. They lie. They
| cheat. They steal. They invest in projects more on the basis
| of turf, prestige, and politics than cash flow. They run
| around in Learjets and eat fois gras on your nickel.
| Shareholders intuitively know this and insist on spiriting
| their cash away from these bad actors as fast as they can.
| .... > "failure to disgorge cash leads to its
| diversion or waste, which is detrimental to outside
| shareholders' interest." .... > But what
| is most remarkable about [the paper by La Porter, Lopez-de-
| Silanes, Shleifer, Vishny][2] is its tone, which is almost
| Menckenesque in its description of modern corporate ethics.
| They describe a Hobbesian world in the kind of plain English
| rarely seen in academic finance; "Firms appear to pay out
| cash to investors because the opportunity to steal or
| misinvest it are in part limited by law, and because minority
| shareholders have enough power to extract it."
|
| If Bernstein were to update his 2000 article for 2022, he
| might need to briefly discuss share buybacks as an
| increasingly popular tax efficient alternative to dividends.
| Share buybacks, like dividends, allow cash to be extracted
| from company coffers and captured as gains for shareholders.
|
| [1] http://www.efficientfrontier.com/ef/700/agency.htm
|
| [2] the link given to the La Porter, Lopez-de-Silanes,
| Shleifer, Vishny paper from Bernstein's article is dead.
| There's a copy of the working paper at https://www.nber.org/s
| ystem/files/working_papers/w6594/w6594...
| TheDesolate0 wrote:
| trynewideas wrote:
| Reminded of a discussion where I had to call out that the company
| culture of "transparency" was really only openness - everyone was
| willing to offer valuable help and information, but nobody was
| willing to publish it, even internally. During a rash of clumsily
| handled (and opaque) M&As that were making people feel redundant
| and competing for roles they already held, it became useful to
| act oppositionally against co-workers, especially new ones being
| hired in the middle of this infighting. The lack of deeply rooted
| internal transparency made this possible.
|
| Everyone trusted each other _individually_ and could easily ask
| questions that they knew to ask, when they already knew who to
| ask. But to understand the shape of the company, or even who the
| internal stakeholders were in projects, or access to basics like
| repositories and documents, people faced a lack of trust coming
| from the organization itself.
| hitekker wrote:
| Privacy over secrecy is an alright goal, but the rest of it
| sounds like consultant double-talk.
|
| In theory, "eliminating secrets" means the manager listening to
| the report's reservations and addressing them effectively. In
| practice, it means rooting out dissent and silencing opposition.
| The manager has created an environment where their reports don't
| feel safe talking to them. Instead of asking hard questions like
| "how the hell did I, the manager, screw up so badly", the article
| suggests easy answers like Project Retros or 1:1s.
|
| The article is further undermined by author's inexperience in
| product management. Brand building as an "expert" with only a few
| years in industry is a red flag.
| dasil003 wrote:
| This part I felt was especially specious:
|
| > _Both backchanneling and micromanaging are easy to identify.
| When there are different answers to the same question, that's
| the result of backchanneling. When you see clones instead of
| people, it's a sign of micromanagement. The good news is that
| once you see these trends emerging in your team, there are some
| concrete steps you can take to roll them back._
|
| First of all, there are plenty reasons to have a private
| conversation, and backchanneling is not a priori a bad thing.
| And the part about micromanagement leading to people "being
| clones" is gobbledygook--what does that even mean? And then the
| suggestion that those things are magically fixed just by the
| most basic entry level management practice of 1:1s and retros.
|
| Frankly, it feels as though the author has tried to generalize
| some personal experience and completely lost the script. In
| reality, management is very hard and very contextual. For any
| given action there is a time and a place. Specifics matter.
| boh wrote:
| Unfortunately the effectiveness of a team doesn't necessarily
| support the individuals within it. If a worker feels expendable,
| which they typically are, they may keep "secrets" regarding the
| functioning of certain aspects of a process or maintain the
| exclusivity of some relevant relationship to make the team more
| dependent on them. A team needs to support the necessary
| incentives for the members of that team to feel the team's
| success translates to their own personal success.
| taeric wrote:
| The opposite of secrecy is not transparency, but safely trusting.
|
| That is, some things are hidden, but not actively so. I don't
| need to know how hard my peers are working. Or what they are
| thinking. Or if they think the project will succeed. Or when they
| work, for that matter.
|
| I trust that if they need or want help, they can ask. I also
| trust that if I offer help, it is in good faith and it can be
| turned down. I could be wrong that they need or want any help.
|
| Not all interactions have to be interventions.
|
| This is not that some things don't belong at work. It all depends
| on the trust in the group. I agree that more trust is generally
| better. But sometimes that is fostered by not forcing a spot
| light on everyone.
| ChrisMarshallNY wrote:
| _> Although many factors contribute to a secrecy culture, they
| all boil down to a lack of trust._
|
| In my experience, there are two reasons for internal secrecy:
|
| 1) Security. There are things that only certain people need to
| know.
|
| It may be trade secrets, or security. In any case, these can make
| life difficult, but are important and valid secrets.
|
| 2) Gatekeepers
|
| These are individuals or organizations that are hoarding
| influence and information; trying to leverage it for their own
| gain.
|
| In my opinion, #2 is much more common than #1, but they will
| often say that they are following the diktats of #1.
| darkerside wrote:
| Third reason is that since information is distracting. Say
| there is a 30% chance of layoffs in the next quarter. Should
| this be communicated down the chain when it's not actionable
| and will do nothing but probably effectuate itself?
| ChrisMarshallNY wrote:
| I'd say that's a #1 thing.
|
| Secrecy is an important part of running any organization.
|
| I worked for a company that was _seriously_ tinfoil. I
| thought, over the top, but they had certain policies, and I
| abided by them; whether or not I agreed with them.
| gedy wrote:
| While I agree in principle, the main issue I've seen many times
| is this usually rolls down to apply to engineering only. "Oh you
| devs can't fix that bug or refactor that without talking to 'the
| team'". "Why is that architect suggesting and interfering with
| 'the team'"? etc, but then UX and product have their own
| planning, initiatives, roadmaps, etc that are totally off the
| books and never discussed by this so called team.
| 0xbadcafebee wrote:
| We had a public channel for our team and invited people to join
| it to watch our work. And then we got a private channel as
| well... and all our work and conversations moved to the private
| channel. Now the public channel is crickets and the other teams
| don't know what we're doing. I can actually feel a sort of
| tension now, like the outside teams don't feel as connected to
| us. They don't have the opportunity to ask questions about what
| we're working on, see what our other tasks are, or start
| discussions on related subjects. It sucks. I don't want privacy
| or secrecy, I want us to all feel we can talk about anything
| together.
| Silhouette wrote:
| This kind of totally open, real-time flow of information is great
| until it's not. It can easily turn into an unstructured free-for-
| all on whichever channel everyone is on as a substitute for more
| effective communication, decision-making and documentation. It
| can also easily become a vehicle for one or more lurking manager
| types who simply have to know everything all the time, whether or
| not that brings any actual benefit to the team. Both of these
| scenarios tend to be toxic to productivity and eventually team
| morale. Unfortunately with the recent emphasis on remote working
| that a lot of organisations weren't used to and everyone adopting
| Teams/Slack/whatever both of these scenarios also seem to happen
| quite often.
| jka wrote:
| > It can also easily become a vehicle for one or more lurking
| manager types who simply have to know everything all the time,
| whether or not that brings any actual benefit to the team.
|
| Given that type of character within the working environment,
| I'd personally prefer that their communications were largely
| on-display to all the teams around them.
|
| Them knowing everything that is going on doesn't necessarily
| seem a problem in itself, but if they're using that to cause
| disruption or selectively push different parts of the
| organization in different directions, then -- unless there is
| some broader plan that they could share -- it seems like the
| teams could more easily encourage the person onto a healthier
| path by having visibility into those patterns.
| Silhouette wrote:
| _Given that type of character within the working environment,
| I 'd personally prefer that their communications were largely
| on-display to all the teams around them._
|
| But _their_ communications are often the last things to be
| shared, except when they are insisting that _everyone else_
| share everything. IME this is a bad idea for much the same
| reasons you don 't want managers in code reviews. You don't
| promote honest feedback and constructive criticism when those
| giving and receiving the comments feel like management are
| snooping on everything all the time.
|
| _Them knowing everything that is going on doesn 't
| necessarily seem a problem in itself, but if they're using
| that to cause disruption_
|
| Bingo. It's the disruption that causes the problem. But both
| micromanagement and chilling effects can be extremely
| disruptive.
| jka wrote:
| > But both micromanagement and chilling effects can be
| extremely disruptive.
|
| Completely agree.
|
| > You don't promote honest feedback and constructive
| criticism when those giving and receiving the comments feel
| like management are snooping on everything all the time.
|
| Also true.
|
| But management couldn't do much to coerce people --
| including plausibly-deniably intimidating, harassing and
| spooking staff -- even if they're watching everything they
| do -- without themselves entering into some risk.
|
| Add to that the fact that any kind of sophisticated
| employee-trolling would require co-ordination and research,
| and transparency becomes more and more attractive, as long
| as it's applied in both directions.
|
| (I'll add that part of the working theory here is that
| rank-and-file staff (non-management) are on equal footing;
| not always necessarily true, perhaps, but should be on
| aggregate for large enough populations)
| dasil003 wrote:
| This is a simplistic take. Of course trust is a pre-requisite to
| a healthy team, and people should feel comfortable speaking out,
| there's no debate about that. However, transparency is not a
| silver bullet. I've seen plenty of teams that trust each other
| but don't get very much done. And if what you are doing is large
| and involves more than a two-pizza team or challenging tradeoffs
| then effective communication becomes much harder. If everyone
| just speaks their unfiltered thoughts without thinking about how
| those words will be perceived there is a high likelihood of
| confusion and churn. There is also the matter of expertise, and
| the fact that many important truths may not be grokked by all
| stakeholders, so just blurting them out may lead to furrowed
| brows and unproductive lines of questioning--or worse--a bad
| decision fueled by misunderstanding.
| jka wrote:
| This makes sense, and it helps a lot when conversation is
| focused and concise (while also allowing for a small amount of
| redundancy: people may acknowledge and display their receipt of
| previous messages by repeating them in their own words).
|
| When you mentioned communication becoming harder: were you
| referring to audio/video discussions (in-person or otherwise)
| and/or also text-based messaging?
| lowwave wrote:
| > Of course trust is a pre-requisite to a healthy team it is
| hard to rust someone on the team with technical tasks when that
| person is not technically capable for a developer.
| Supermancho wrote:
| > However, transparency is not a silver bullet
|
| That isn't a claim. The claim is that a team with full
| transparency is more effective (in terms of work done) than one
| with a limited transparency.
|
| What's interesting is there's talk about one-on-ones like they
| are an acknowledged best practice, but nothing about
| established payscales (or open salaries).
___________________________________________________________________
(page generated 2022-02-26 23:00 UTC)