14 ms·

> Effective teams need trust. That’s not to say that frameworks for decision making or metrics tracking are not useful, they are critical — but replacing trust

> Effective teams need trust. That’s not to say that frameworks for decision making or metrics tracking are not useful, they are critical — but replacing trust with process is called bureaucracy. A thousand times this. Highly effective teams have super high levels of trust and mutual accountability. The moment you lose trust, you now have to replace trust with some other type of mechanism. This leads to process/bureaucracy. Trivial example for those that don’t “get it”: think about why do we need code reviews? If we knew people would write perfect code every time, they would never be needed. However, we hold them because we know that even in our own “best code” we may miss something/forget some detail. However, think about your own process, at least for me, depending on a feature/the engineer, my code review might be cursory rather than super line by line. The difference? How much I trust that engineers ability in that specific type of code. But that was a digression, my main point is that hight trust means high speed, low trust causes slow speeds. The more you can build up trust and eliminate/prevent process, the better your organization will be. For anyone that wants more details on this, I highly recommend the book “The speed of trust” by Stephen Covey.

Hex-3-En 7y ago
THIS is basically what I feel is the reason why most german software companies are lacking success in international competition... Disclaimer: I'm german, have software engineering degree and hate german conservative company structures not adapting to the 21st century...
- pca2 7y ago
  can you explain a bit more about "German conservative company structures" for us non-Germans?
  - juangacovas 7y ago
    Here in Mallorca island some call germans "cap quadrats" (being "square heads") for a reason. I'm sure they also call us names...
  - mr_overalls 7y ago
    In a nutshell: Germans seem to love bureaucracy, process, and red tape. https://www.dw.com/en/germans-and-bureaucracy/a-16446787 https://www.dw.com/en/germans-and-bureaucracy/a-16446787
    - jacobolus 7y ago
      There is a trade-off. German society (compared to some others) seems to do much more enforcement of industry-wide and society-wide standardization (e.g. of measurement systems, part compatibility, common procedures, ...), with an expectation that everyone should “follow the rules”. This has the advantage of increasing interoperability and compatibility and making many things more predictable and easier to assess/audit, at the expense of sometimes fixing poor choices and forcing them into contexts where they should be discarded. * * * As one example, most of the design features of computer keyboards sold worldwide from the 1980s–1990s were forced to conform to a (not especially well considered, in my opinion) German standard, which was adopted by IBM and then copied by everyone else, and later became the basis of an ISO standard. Beige or gray color with matte surface texture and dark labels (no colors allowed), cylindrical keytops with primary symbols in one corner to make room for standard German labels, low keyboard height (which did not fit many of the keyswitches from the 1970s), a shape precisely accommodating the standard German key layout, ... At some point companies started ignoring this standard (e.g. producing black keyboards), and I don’t think there was ever enforcement. But we are still stuck with many of those design choices now, a dramatic difference from the extreme diversity of designs from the 1960s and 1970s. Arguably many of the keyboards of the 1970s were better than almost anything produced at mass scale since.
  - close04 7y ago
    It's basically procedural rigidity. Everything is formalized and has to work in a specific way. This may be an asset sometimes when reproducibility or accountability are key. But the crippling lack of flexibility is a serious downside many other times.
- ImprovedSilence 7y ago
  I’m sure this is a big part of large entrenched US companies that aren’t a part of the SV “move fast and break things” culture.
- davinic 7y ago
  I use a lot of music software and DAWs created by German companies. Any idea why Germany has been so successful in that specific market?
  - aasasd 7y ago
    Maybe a DAW has lotsa moving parts and the author(s) need patience to implement them all, har har.
- mayankkaizen 7y ago
  I am ignorant about this. Can you or someone else explain why this is the case with german s/w companies? What is the reasoning here?
- 0xdeadbeefbabe 7y ago
  Usually comments about Germany are more positive. What is going on with progressive HN? Won't a German boss think you are incompetent for working six nines? For reference ukigumo says, "In countries like Germany or Holland, if you consistently stay over-time in the office you might be surprised to find that you will be called upon justifying your behavior since the local belief is that you are either incompetent..." https://news.ycombinator.com/item?id=9456190 https://news.ycombinator.com/item?id=9456190
  - Confusion 7y ago
    People generalize personal experience and anecdotes they have heard. People may also generalize to cultures they think are similar without evidence.
    - 0xdeadbeefbabe 7y ago
      Three anecdotes and I wouldn't be treated this way.
rficcaglia 7y ago
Ok but serious question...what do you do with highly ineffective teams that you inherit, and/or are contractors, and/or are the only engineers available, and/or are only motivated by a paycheck, and/or would rather be working on their five side projects, etc..... in many cases who have demonstrated repeatedly that they make lots of mistakes and get sloppy and will fully refuse to cooperate. Yet your job is to somehow produce high quality software. This is the not uncommon outside elite startups in my experience. In those cases I will take slow vs hazardous.
- deleted 7y ago
  [deleted]
- aerophilic 7y ago
  Assuming this is a serious question: You/Your group needs some serious help. What you do about it depends on your role/level of influence in your organization. Regardless of your level, I highly recommend reading Speed of Trust (like I recommended above). However, two example roles: If you are the CEO/key leader, there is no excuse for creating/fostering this mess. You have to address the culture you have fostered heads on. Your complaint: “But it will cost too much!”. If that is your mentality, you are missing the point. Don’t look at absolute costs, look at value, that is what good CEOs do. If you can realize $2 for $1 cost, or $5 for $2 of cost, which should you choose? The $2 for $1 is what you realize by creating/fostering a low trust environment. When you hire folks, find the best people you can, and then enable them. If you aren’t getting good people, it is either because a) they think your environment is toxic or b) you aren’t offering “enough” to compensate them. Note: compensation is NOT just dollars. It could be flexibility, it could be the ability to work on their side projects, it can be ability to learn new skills, or can be shared vision. Take your pick. In general, after some number of x $$$, money becomes secondary. Foster a culture of trust, mutual respect, and you will get dividends. If you are at the “lower” on the totem pole, the answer is more simple. Ask yourself: can this org be saved? If you brought this up to leadership, would they work to change the culture? If not, then it is time to pack your bags/look for a better org. If they will listen, You have to decide if you WANT to save the org. If so, you have a long road ahead, but if you can pull it off, you will gain lots of experience and will rapidly increase your marketability. Edit: In case it wasn’t made clear, let me make this final point for the ceo/leader: Spend the money/create the perks that allow you to attract the people you can trust, then once you get them, TRUST them. Yes, verify, but if you don’t do this, you are doomed to fail. Also, either find a way to trust the people you have, or get rid of them. It is a disservice to both you and them to keep around people you can’t trust. One big caveat: make sure you are someone THEY can trust too. Additional edit for spelling/grammar
billfruit 7y ago
My opinion is that in the absence of a process framework, the advantage lies with people who try to build trust rather than doing the right or optimal thing. It also makes people a less fungible resource.
elpakal 7y ago
code review can also be a great way to share knowledge though
habosa 7y ago
Agree 100%. I work at a big slow place (Google) which has many processes that evolved from a lack of trust. But my local team has pretty high trust levels. I try to explicitly say things like "I don't think we need that process here, I trust you" to speed things up and it often works. But some people don't want trust, they want the safety of the process.
carapace 7y ago
It's a general rule: Systems of elements that can trust each other are more efficient than systems of elements that cannot. (Corollary: By the time you have written laws it's already too late.) This ties in to why I think ubiquitous surveillance systems will actually work, provided they're self-reflexive to prevent their own abuse. Secrecy is becoming exponentially more expensive. Economics and technology ensure that the surveillance systems only get better and more pervasive. So the cost/benefit ratio of "cooperation vs. defection" will be skewed towards being a "good citizen", eh? What if the Total Information Awareness systems are their own cure?
WalterSear 7y ago
> However, think about your own process, at least for me, depending on a feature/the engineer, my code review might be cursory rather than super line by line. The difference? How much I trust that engineers ability in that specific type of code. The difference is that you can't review your own code, for the same reason that writers work with editors: The reviewer is leveraging their unfamiliarity with the code along with their familiarity with the code's intent and the codebase, as a critical tool. If it was feasible to get someone else familiar enough with the project that they could review it, I would do that, but at that point, I wouldn't be working on my own.
tomp 7y ago
How can organizations deal with the problem of too much trust, e.g. freeloaders (lazy workers who get little done) or even those who actually abuse trust (e.g. spend too much money on their own needs, or undermine coworkers, or take credit for their work, or lying about their skills during hiring process, or secretly work for competitors, or otherwise damage the company)? Ideal is "trust but verify" which sounds good but (1) it's hard to verify (except in annoying and ineffective ways like "face time"), and (2) signaling you don't trust your employees can make people more likely to abuse your trust ("the company thinks we're spending money on ourselves anyways, might as well spend it, we're already guilty"). I think trust issues are one big factor in why nepotism (and other "hiring by connection") remains so popular.
ownagefool 7y ago
Code reivews can have other uses. - Protection against insider threat. - Protection against leaked credentials. - Protection against knowledge gaps. - The psycology of giving a reasonble account of yourself when being judged. - Assurances that standards are being followed. Trust is all fine and well, but what happens when one of you're colleagues is having a bad time at home? What happens when their wife is held hostage until they insert some code? What happens when a laptop is hacked? A cursory glance might just be enough, but you also might want to internalise just why we do these things. Often people won't mind if you set expectations and write the reasons for doing things down. Also keep in mind all the big breaches that have happened lately. I wouldn't be suprised if they were high trust environments, still got hacked though.
yojo 7y ago
I agree with your premise, but not with your digression. I still read the code reviews of my team’s experts closely because: 1) I might learn something. If they are experts in the domain, they almost certainly know things I don’t. 2) Even experts have blind spots and make mistakes. If I trust my teammate I default to “accept to unblock” and leave some questions in comments. If my concerns are valid, they can fix it before landing. I also trust them to request a fresh review if that leads to major changes. If I misunderstood, they can educate me in their reply and land it without further delay.
agumonkey 7y ago
Serions question : how much of work is a deep feeling of taking care of others. Trust is a Mark of caring imo.

Hex-3-En 7y ago

THIS is basically what I feel is the reason why most german software companies are lacking success in international competition... Disclaimer: I'm german, have software engineering degree and hate german conservative company structures not adapting to the 21st century...

pca2 7y ago
can you explain a bit more about "German conservative company structures" for us non-Germans?
- juangacovas 7y ago
  Here in Mallorca island some call germans "cap quadrats" (being "square heads") for a reason. I'm sure they also call us names...
- mr_overalls 7y ago
  In a nutshell: Germans seem to love bureaucracy, process, and red tape. https://www.dw.com/en/germans-and-bureaucracy/a-16446787 https://www.dw.com/en/germans-and-bureaucracy/a-16446787
  - jacobolus 7y ago
    There is a trade-off. German society (compared to some others) seems to do much more enforcement of industry-wide and society-wide standardization (e.g. of measurement systems, part compatibility, common procedures, ...), with an expectation that everyone should “follow the rules”. This has the advantage of increasing interoperability and compatibility and making many things more predictable and easier to assess/audit, at the expense of sometimes fixing poor choices and forcing them into contexts where they should be discarded. * * * As one example, most of the design features of computer keyboards sold worldwide from the 1980s–1990s were forced to conform to a (not especially well considered, in my opinion) German standard, which was adopted by IBM and then copied by everyone else, and later became the basis of an ISO standard. Beige or gray color with matte surface texture and dark labels (no colors allowed), cylindrical keytops with primary symbols in one corner to make room for standard German labels, low keyboard height (which did not fit many of the keyswitches from the 1970s), a shape precisely accommodating the standard German key layout, ... At some point companies started ignoring this standard (e.g. producing black keyboards), and I don’t think there was ever enforcement. But we are still stuck with many of those design choices now, a dramatic difference from the extreme diversity of designs from the 1960s and 1970s. Arguably many of the keyboards of the 1970s were better than almost anything produced at mass scale since.
- close04 7y ago
  It's basically procedural rigidity. Everything is formalized and has to work in a specific way. This may be an asset sometimes when reproducibility or accountability are key. But the crippling lack of flexibility is a serious downside many other times.
ImprovedSilence 7y ago
I’m sure this is a big part of large entrenched US companies that aren’t a part of the SV “move fast and break things” culture.
davinic 7y ago
I use a lot of music software and DAWs created by German companies. Any idea why Germany has been so successful in that specific market?
- aasasd 7y ago
  Maybe a DAW has lotsa moving parts and the author(s) need patience to implement them all, har har.
mayankkaizen 7y ago
I am ignorant about this. Can you or someone else explain why this is the case with german s/w companies? What is the reasoning here?
0xdeadbeefbabe 7y ago
Usually comments about Germany are more positive. What is going on with progressive HN? Won't a German boss think you are incompetent for working six nines? For reference ukigumo says, "In countries like Germany or Holland, if you consistently stay over-time in the office you might be surprised to find that you will be called upon justifying your behavior since the local belief is that you are either incompetent..." https://news.ycombinator.com/item?id=9456190 https://news.ycombinator.com/item?id=9456190
- Confusion 7y ago
  People generalize personal experience and anecdotes they have heard. People may also generalize to cultures they think are similar without evidence.
  - 0xdeadbeefbabe 7y ago
    Three anecdotes and I wouldn't be treated this way.

rficcaglia 7y ago

Ok but serious question...what do you do with highly ineffective teams that you inherit, and/or are contractors, and/or are the only engineers available, and/or are only motivated by a paycheck, and/or would rather be working on their five side projects, etc..... in many cases who have demonstrated repeatedly that they make lots of mistakes and get sloppy and will fully refuse to cooperate. Yet your job is to somehow produce high quality software. This is the not uncommon outside elite startups in my experience. In those cases I will take slow vs hazardous.

deleted 7y ago
[deleted]
aerophilic 7y ago
Assuming this is a serious question: You/Your group needs some serious help. What you do about it depends on your role/level of influence in your organization. Regardless of your level, I highly recommend reading Speed of Trust (like I recommended above). However, two example roles: If you are the CEO/key leader, there is no excuse for creating/fostering this mess. You have to address the culture you have fostered heads on. Your complaint: “But it will cost too much!”. If that is your mentality, you are missing the point. Don’t look at absolute costs, look at value, that is what good CEOs do. If you can realize $2 for $1 cost, or $5 for $2 of cost, which should you choose? The $2 for $1 is what you realize by creating/fostering a low trust environment. When you hire folks, find the best people you can, and then enable them. If you aren’t getting good people, it is either because a) they think your environment is toxic or b) you aren’t offering “enough” to compensate them. Note: compensation is NOT just dollars. It could be flexibility, it could be the ability to work on their side projects, it can be ability to learn new skills, or can be shared vision. Take your pick. In general, after some number of x $$$, money becomes secondary. Foster a culture of trust, mutual respect, and you will get dividends. If you are at the “lower” on the totem pole, the answer is more simple. Ask yourself: can this org be saved? If you brought this up to leadership, would they work to change the culture? If not, then it is time to pack your bags/look for a better org. If they will listen, You have to decide if you WANT to save the org. If so, you have a long road ahead, but if you can pull it off, you will gain lots of experience and will rapidly increase your marketability. Edit: In case it wasn’t made clear, let me make this final point for the ceo/leader: Spend the money/create the perks that allow you to attract the people you can trust, then once you get them, TRUST them. Yes, verify, but if you don’t do this, you are doomed to fail. Also, either find a way to trust the people you have, or get rid of them. It is a disservice to both you and them to keep around people you can’t trust. One big caveat: make sure you are someone THEY can trust too. Additional edit for spelling/grammar

billfruit 7y ago

My opinion is that in the absence of a process framework, the advantage lies with people who try to build trust rather than doing the right or optimal thing. It also makes people a less fungible resource.

elpakal 7y ago

code review can also be a great way to share knowledge though

habosa 7y ago

Agree 100%. I work at a big slow place (Google) which has many processes that evolved from a lack of trust. But my local team has pretty high trust levels. I try to explicitly say things like "I don't think we need that process here, I trust you" to speed things up and it often works. But some people don't want trust, they want the safety of the process.

carapace 7y ago

It's a general rule: Systems of elements that can trust each other are more efficient than systems of elements that cannot. (Corollary: By the time you have written laws it's already too late.) This ties in to why I think ubiquitous surveillance systems will actually work, provided they're self-reflexive to prevent their own abuse. Secrecy is becoming exponentially more expensive. Economics and technology ensure that the surveillance systems only get better and more pervasive. So the cost/benefit ratio of "cooperation vs. defection" will be skewed towards being a "good citizen", eh? What if the Total Information Awareness systems are their own cure?

WalterSear 7y ago

> However, think about your own process, at least for me, depending on a feature/the engineer, my code review might be cursory rather than super line by line. The difference? How much I trust that engineers ability in that specific type of code. The difference is that you can't review your own code, for the same reason that writers work with editors: The reviewer is leveraging their unfamiliarity with the code along with their familiarity with the code's intent and the codebase, as a critical tool. If it was feasible to get someone else familiar enough with the project that they could review it, I would do that, but at that point, I wouldn't be working on my own.

tomp 7y ago

How can organizations deal with the problem of too much trust, e.g. freeloaders (lazy workers who get little done) or even those who actually abuse trust (e.g. spend too much money on their own needs, or undermine coworkers, or take credit for their work, or lying about their skills during hiring process, or secretly work for competitors, or otherwise damage the company)? Ideal is "trust but verify" which sounds good but (1) it's hard to verify (except in annoying and ineffective ways like "face time"), and (2) signaling you don't trust your employees can make people more likely to abuse your trust ("the company thinks we're spending money on ourselves anyways, might as well spend it, we're already guilty"). I think trust issues are one big factor in why nepotism (and other "hiring by connection") remains so popular.

ownagefool 7y ago

Code reivews can have other uses. - Protection against insider threat. - Protection against leaked credentials. - Protection against knowledge gaps. - The psycology of giving a reasonble account of yourself when being judged. - Assurances that standards are being followed. Trust is all fine and well, but what happens when one of you're colleagues is having a bad time at home? What happens when their wife is held hostage until they insert some code? What happens when a laptop is hacked? A cursory glance might just be enough, but you also might want to internalise just why we do these things. Often people won't mind if you set expectations and write the reasons for doing things down. Also keep in mind all the big breaches that have happened lately. I wouldn't be suprised if they were high trust environments, still got hacked though.

yojo 7y ago

I agree with your premise, but not with your digression. I still read the code reviews of my team’s experts closely because: 1) I might learn something. If they are experts in the domain, they almost certainly know things I don’t. 2) Even experts have blind spots and make mistakes. If I trust my teammate I default to “accept to unblock” and leave some questions in comments. If my concerns are valid, they can fix it before landing. I also trust them to request a fresh review if that leads to major changes. If I misunderstood, they can educate me in their reply and land it without further delay.

agumonkey 7y ago

Serions question : how much of work is a deep feeling of taking care of others. Trust is a Mark of caring imo.