Trust as a bottleneck to growing teams quickly | Hacker News Reader

Trust as a bottleneck to growing teams quickly

benkuhn.net

49 pointssurprisetalk10 comments

The article doesn't seem to address the main reason I learn not to trust some people: They aren't trustworthy.

At my last job I was on a project with two other developers, two data scientists, and a project manager. At the outset of the project I mostly trusted people to do their jobs. I'd only worked closely with one of the developers, but I'd had enough incidental contact to have a good opinion of everyone else. We divided the work up and made a decent plan early on. Then things fell apart.

One of the developers had a single 3-point spike story open for the whole quarter. He made one boilerplate PR and left no comments in any other PR. He regularly missed meetings and didn't add to any discussions. He talked a big game and never delivered.

One of the data scientists took six months to make an extremely simple model. He made the only PR for it on the last day of the quarter before he got switched to another project. He wouldn't answer any questions whatsoever about how the model worked. It was inefficient and not ready for use. I had to rewrite the model.

The project manager never wrote anything except titles in Jira tickets. He repeatedly didn't follow up on questions, even when we had a clear issue needing feedback from the customer, whom only he could talk to. He was completely oblivious to the lack of progress above, despite never seeing a demo from those people.

Luckily, the other developer and the other data scientist were capable and accomplished part of what was needed. The project was still a disaster because we had the software equipment of a car without wheels. I spent half a year begging my manager to move me to another project when I realized it was going this way.

I love to trust people. It's how I work. I tell you what I'm going to accomplish and I do it, every time. I expect the same from others. I don't care about performance as much as I care about doing what you say you will. There isn't a model to build trust with untrustworthy people.

The article does touch on the two things that are realistically within your locus of control.

There's only so much you can do to change how trustworthy someone else is, but you can a) change how trustworthy you are to others, and b) identify how trustworthy someone else is. Those two points are what the article chooses to focus on.

I'd argue that trying to be most trustworthy to untrustworthy people is often a way to get screwed even harder. On that project, since I was the most productive people who showed regular progress meant that the project manager rode me to get more stuff done rather than fixing the broken parts of the team. I was forced to pick up dropped balls constantly.

Identifying the untrustworthy people is super easy and doesn't help. It takes a only a few weeks to see that someone isn't putting the effort in. If you're on a project with that person, you're often stuck with it with no recourse if the organization and managers aren't willing to do something.

A company can spend more money to hire trustworthy people or spend even more money to hire managers to micromanage untrustworthy employees.

Spending money doesn't solve the problem. I've worked at places that paid the most, more than google and facebook even. You only get mercenaries. I'm not sure what the answer is.

Propaganda. The two major deficits stopping otherwise qualified people from being individually effective are (1) money and (2) time. If those are taken care of, any persisting problems are organizational.

"Business moves at the speed of trust."

This is a good post exemplifying this axiom. It is one thing for a leader to be trustworthy. It's a different challenge to cultivate trust within an organization in the midst of rapid change. Enjoyed reading this account of Anthropic's adventures scaling trust.

Indeed trust is a human scale problem at the root of civilizations. Seems like a rediscovery of the wheel.

This is why it is important to cite previous work on a topic. If we don't we run in circles thinking we are discovering something new.

Trust as a term is a bit overloaded. For software teams, I find “trust” can often be a shared lingo, shared mental model, and shared expectations. The first two can be easier if the two sides both use the same programming language and internal libraries. The latter can be hard, especially if the two sides have different Product Managers.

The OP alludes to ‘what trust is’ mentioning the ‘Dario simulator’ issue. Trouble arises when ‘the Dario’ holds a vision that might conflict with the team or the outside world.

Most employees and definitely new employees are not good. Ask any military unit about the FNG. Same applies to our business, especially and when RSO's matter.

Reply on news.ycombinator.com