Hacker News Reader

Comment by aerophilic | Hacker News Reader

> 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.

View on HN

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.

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

Yes very serious question, and very real (multiple orgs). And most times the team manager has zero control over hiring or firing. Nor any access to C level decision makers, who are buffered by layers of HR.

The orgs I have seen this in are 100% safe - highly profitable, and often funded by government or at least heavily subsidized.

So, if I understand your assessment...managers who see this reality should simply leave, instead of using skill and tools to deliver value in a difficult setting? That seems overly pessimistic to me.

I think this is a great call out. This is infact the very moment that skill and professionalism in team management is called to the front. A really good manager can do something about this; but it's a gradual process and a hard one.

Fundamentally you need to change the culture of the team. The first step is to establish a team - in the situation you are describing there is no real team - just a bunch of people waiting for a cheque every month, a new job or being told that this job no longer exists. You need to figure out if there is a core purpose that some or ideally most of the people in the team will sign up to (with you - if you aren't "in" then they can't be), which will deliver for your stakeholders. Then you have to orientate the team to deliver this, some of them won't come along, some of them can't. You will have to do a lot of coaching with some of the ones that would like to.

The big question : what is the core purpose that your team will adopt and which will change how they work and what they will do?

Ask. Ask them.

In my book if you don't have authority, including to hire and fire and affect compensation decisions, then you aren't a manager. In that situation you're half glorified babysitter and half scapegoat. And I agree this is how most organizations are designed, and why they're so anemic. I very much like flat hierarchies and consensus decision-making, but at the end of the day someone is in charge or they aren't. If they aren't, their capacity to effect cultural change is severely diminished.

I think the bottom line is this: Where do you want to spend your time?

Yes, you can use process and tools to make a low trust team “work”. This is in fact how most government works.

This isn’t horrible per say, it is just very ineffective. You will spend 2-3X the amount of time/money to produce the same result as a highly effective team. The multiple gets better with good process and tools, the multiplier gets worse if you have bad processes on top of having low trust.

If you want to change things, and don’t have support/the ear of leadership above you, then the alternative is to do what you can that is in your control. This is where great leadership shines (and leadership is much different than management, more on that another time).

A great leader doesn’t need formal lines of authority. They gain influence indirectly by “casting a vision” and enrolling others to pursue it. If you can do that, you can (over time) shift a culture. It is just very slow, and not straightforward to do.

The one bright spot is that in general, the more something is resistant to change, the more readily it will adopt/embrace it once changed. If you can shift the culture, they will never want to go back to how it was before.

But once again, you need to decide you WANT to do this, and in particular do it for this particular org. For most folks, that isn’t what they want to do, therefore they have to either learn to live with an ineffective organization, or move on.

Not OP, but I agree with both your assessments of the situation. I agree with you that most companies work this way. I'd even go a step further and would say that most companies are highly dysfunctional. But I also agree with OP that the only thing you can do in situations like this is to leave. Unfortunately changing the company from the inside is extremely difficult and in most cases a futile effort.

What follows for me is that one should be very careful in how they choose their employer. Unfortunately, I've found it often quite hard to judge this before starting to work there. Would love if someone could give their insight in how to figure this ought before even applying.

> 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.

Life Principles by Ray Dalio has this exact same advice.

https://www.principles.com/

TL;DR if a person doesn't have the technical background to judge someones skills, which in a lot of cases they don't otherwise they wouldn't be hiring you, it's very hard for a person to know whether someone is good at what he does or just full of shit.

What you're saying is a lot of ideologically great stuff but that's a bit disconnected from how the real world of high growth tech works.

The reality is that people can talk about vision and passion all they want but the US is a place where everything is a sales transaction. In a place where everything is a business transaction whoever can sell their work best wins and whoever can make an impression on perceived impact always wins over the people that think their impact will eventually be recognized. In fact listening to advice like that is what gave me a quick severance package despite being one of the most impactful engineers in the company at the time.

In one place I improved their entire performance by 38% and saved them a couple millions on licensing fees. The 38% was claimed by my manager the very same day i got my severance package even though I had to make a gif to convince them of the impact and defied them by fixing this issue, which was deemed a failed project at the time.

Most managers in the SV late startups are early employees that kept getting promoted and at some point were sent to Berkeley for a weekend management certificate. Very few of them stop and think about the things that they do, how they would want to be treated themselves and what they can do to improve transparency of performance.

I was recently responsible for the hire of someone I initially intended as my replacement as an CTO for hire/architect. I got blinded by the resume and the vetting procedure/recruiter and his ability to smooth talk about things he knows nothing about. It didn't take me long to realize he was useless, but the problem was that the guy spending the money actually believed it for 6 months and poured money into it. He massively regretted it. I basically had to let him ruin a bunch of stuff, waiting in the background to clean up after him.

Bottom line is he was a better politician that he was an engineer. And for most people it doesn't matter.

The tough ones are people who aren't clearly bad enough to just let go, but lack enough in the skill department that trust is lower than it could be and slows things down.

i think you're getting the trust causality somewhat backwards. people don't simply fall into trustworthy or untrustworthy buckets, but rather it's mostly context dependent (with rare exception; e.g. sociopaths). a trusting environment can reveal the latent trust inherent in the team members.

and trust takes time to build, so it's often not something you can just hire for (unless maybe you hire a whole team at once).

teams also require a blend of skills blanketing the problem domain, diversity of thought and background, necessary resources, clear goals, and the autonomy to make decisions toward those goals.

> Spend the money/create the perks...

Oh right, spend the infinite piles of money we just have lying around. If we had that money, we would have already spent it to hire better people in the first place and wouldn't be in this position.

I was actually hoping for this response. This is something that I fundamentally feel like many startups/companies miss: You should not be pursing any activity that is not inherently profitable given your cost structure.

Let me say this a different way, if you can expect $10 of revenue, the absolute most you can spend is $10-your minimum profit margin (for normal businesses... for VC backed, it is more about “value/market share creation for eventual earnings).

If you can not do the above, while ensuring the value, you are in the wrong business.

Business 101 dictates you spend less than you earn. The question is can you really do it given your cost structure. I would go even further that if you cant afford to pay what the market dictates to achieve a specific business outcome, you should not be pursuing that business outcome in the first place.

Parent already made clear that there are other options besides raw money:

> Note: compensation is NOT just dollars.

One really simple option that I think a lot of programmers would love, and that doesn't cost any money directly, is just giving them on-the-clock time to do some hacking on whatever they want, instead of keeping their noses permanently affixed to the feature grindstone.

> 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

I don't know if this is the best approach, but I actually kind of like these teams, and like working with/leading them, because usually the description is not true. And careful rebuilding of trust can usually (but not always) demonstrate that.

Very few people are truly as ineffective as they might seem, and people are more impacted by situations they are in, or the process/role/authority they have, then anyone will care to admit.

> in many cases who have demonstrated repeatedly that they make lots of mistakes and get sloppy and will fully refuse to cooperate

Ok, sure. I agree, and have seen this happen too. But why? Very few people intentionally want to make mistakes. Very few people intentionally refuse to cooperate for no reason. Most people are not inherently bad.

Are they making mistakes because they don't know something? Are they making mistakes because they are used to working in a different way, or prefer a different way? (If so, why?) Are they making mistakes because they feel some sort of pressure (like a time crunch, budget crunch, some 'three strikes' hanging over their employment status, etc). Is "only motivated by a paycheck" even a bad thing? (People can still do good work, despite only being motivated by payment. That's how most other industries work already). Are they refusing to cooperate because they have an unresolved grievance (where they demoted, or docked pay? Are they working on something that is slow/bad, because they couldn't get buy-in to do it the proper way the first time?)

People can be kind of cloudy, we're not robots, and there's not necessarily one single right way to go about rebuilding trust and creating functionality out of teams. And yes, occasionally there really are some folks who need to specifically be dealt with. But I really bristle when whole groups of people get written off with labels like the above, because it feels fundamentally untrue for most people most of the time.

These are all the types of things that a good manager is supposed to be solving. A good manager can make a "highly ineffective team" effective, even if they might never have been before.

I am not confounding good work with good people. I very often see great people deliver poor work. I rarely see bad people. I can be a great person and want to succeed at something I am I’ll equipped to do professionally, or for whatever reason am not fully engaged in.

Personally, yes, I feel working for a paycheck only is a sure sign of a bad fit/attitude. Maybe I have an unrealistic view, but I think people should work for more than that, or else find a more rewarding and engaging profession...life is too short to punch the clock (ymmv).

While very few intentionally make mistakes, I find it takes extraordinary effort to maintain the discipline to intentionally not make mistakes. A mistake is not always an erroneous action, it can be the omission of careful attentive proactive action.

My thesis (and practical experience) is that you can deliver good software with ineffective teams, contrary to the myth of 10x rock star hire-only-the-best mantras. But my question is how others use tools and techniques to reliably do this vs. gut feel and trial and error. I know it can be done, just as I know you can hire 10x coders and still fail a project.

Edit/postscript: you can also have (and often do) great people who as individuals can be highly effective, but fail to communicate or collaborate as a team. This is probably more common in larger orgs or in my specific cases, teams that span multiple orgs. You often have to manage great people who are poor communicators via nudges without direct hiring/firing or performance review leverage...aka “dotted lines”.

If you are offering your employees a paycheck, that is all they will work for. If you give them your companies assets, capital, and control over the org structure, then that is what they will work for. If you're offering them the opportunity to work on interesting problems, then maybe guarantee it in an employment contract. There is no reason to blame anyone for working to acquire the only things you're actually offering.

This is not universally true in my experience. People who take pride in their work will often go the extra mile, without being asked. I don’t “blame”, I just correlate.

Maybe this is the answer: if someone needs a guarantee then they are probably a bad fit for a highly effective team. Highly effective people look for opportunities instead of guarantees perhaps.

If I knew, I would be writing articles, not asking questions...

The guarantee is not a need, it is an opportunity that your potential effective employees are looking for. If you deny them that opportunity, they will look elsewhere and be highly effective for someone else.

> life is too short to punch the clock

If I only took work that I enjoyed, life would be a lot shorter. Uninteresting but better-compensated work allows for free time outside of work to do things I enjoy, and the theoretical possibility of saving enough for an eventual sabbatical or early retirement.

If people only worked jobs they liked, absolutely critical work nobody likes would never get done.

In my experience this is not true. I know lots of grunt work that gets done in both paid and open source projects that no one likes, by volunteers with nothing extra to gain. Those mundane tasks are necessary for the larger good, and folks can see past their short term motivations.

Those that respond and raise their hands to do the icky work everyone else tries to avoid seem highly correlated with leadership skills and better communication skills.

>...and/or are only motivated by a paycheck...

Are you really suggesting that people motivated by a paycheck are ineffective and can't be trusted? For that matter, that contractors can't be trusted? Or people who would rather be doing other things?

No, I never said anything about trust. They are in my experience less effective than those that are highly engaged by the work itself.

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...

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?

Maybe a DAW has lotsa moving parts and the author(s) need patience to implement them all, har har.

can you explain a bit more about "German conservative company structures" for us non-Germans?

In a nutshell: Germans seem to love bureaucracy, process, and red tape.

https://www.dw.com/en/germans-and-bureaucracy/a-16446787

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.

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.

Here in Mallorca island some call germans "cap quadrats" (being "square heads") for a reason. I'm sure they also call us names...

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.

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

People generalize personal experience and anecdotes they have heard. People may also generalize to cultures they think are similar without evidence.

Three anecdotes and I wouldn't be treated this way.

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?

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.

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.

> 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.

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.

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.

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?

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.

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

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

Reply on news.ycombinator.com