[aylmao]

Recently, I was thinking plenty about trust within organizations, and it resonated with me too.

I've worked at a few startups and have seen high-trust environments lead to a lot of productivity, comfort and success— and the opposite for low-trust startups. In general, I think startups tend to lean towards high-trust, especially when they're small and early, but I was part of a 15-person one that was quite the opposite, and it was terrible.

The hiring process wasn't great. Long take-home task, and that was the only technical interview. A lot of talking, but not much noteworthy signal on the rest. Very long wait times. Now I know this is a red flag for low-trust companies. If they're not building trust at the hiring-stage, it means even after joining the organization it'll take time to acutally "be part of the team".

Once at the company, I had no permission to poke around— everything was hidden by default. There was no space for discussion, I was expected to learn, not to comment. There was plenty of micro-management; after all, if they don't trust you, they need to keep an eye on you at all times. You're probably doing something wrong.

The chasms were deep too; the company was building a web team to spin a contractor's project into a full web product, and I was supposed to lead it. We were disjointed from the rest of the company though, and would only hear about requirements through the founders. The team had interest on being more involved with the main product, but management just wasn't interested in making it happen, and just had us loiter around for a few months until they gathered requirements, and then implement some rather disjoint features.

The project failed. I'm working somewhere else now.

tldr; low-trust environments kill projects

[spuds]

Yeah, I think there's almost always a point where a company decides they need to stop generally trusting their employees. Then all the trustworthy ones start getting more and more frustrated, or just start checking out. Agreed that most startups lean towards trust. Need to keep that going as long as possible, and stay away from hiring managers who think their primary job is "protecting" the company from anyone who might make a mistake.

[geophile]

Yes, and at the same time, companies start hiring employees that shouldn’t be trusted.

Neither one causes the other, both occur as companies mature. I’ve seen this as startups mature. One very vivid recollection: we had a very strong and tiny dev team. Each dev owned a huge piece of the product. Definitely not egoless. We brought in trusted junior devs to grow. That was fine.

Then the very talented VP Eng. wanted a promotion and brought in a hack to replace him, who hadn’t coded in years, and was obviously more concerned with his career than our product. A real mediocrity. But the VP wanted to move on, so this mediocrity was hired, over vigorous objections.

That was the end. This new VP brought in mediocre devs, rewarding loyalty and “being a team player” more than productivity, or competence. He brought in employees who couldn’t be trusted.

As this was happening, we were acquired, and our new bosses from the parent company were used to employees who couldn’t be trusted, and acted that way.

HR knew that to keep the good engineers they had to do something, so they showered us with bonuses. That worked for a while. I finally got so bored and fed up that I left (for another startup).

[aylmao]

> Need to keep that going as long as possible, and stay away from hiring managers who think their primary job is "protecting" the company from anyone who might make a mistake.

On that note, a quick shot-out because I've been lucky enough to see the opposite happen at a big company too. Performance cycles at the company very much disincentivized big bets. Some engineers really thought project "X" was important, but it was risky— if it didn't pay off by the end of the cycle, per the way the bureaucracy worked, it wouldn't be great.

The manager very much tried his best to protect them against this. In fact I don't think it paid that cycle, but the project remained active until it did eventually pay off. Shoutout to managers like this. The easy route is to act like a messenger for higher-ups, and never put your own skin in the game— but there's some out there that want to do what's best, not what's easy.

[RHSman2]

This. This is what ‘higher’ ups should be aiming for. I try and do it with all my attention. The good fight.

[kridsdale1]

> there's almost always a point where a company decides they need to stop generally trusting their employees

I recall exactly when this happened at Facebook.

[tbrownaw]

> Yeah, I think there's almost always a point where a company decides they need to stop generally trusting their employees. Then all the trustworthy ones start getting more and more frustrated, or just start checking out.

$employer has formal separation of duties between development and build/release for some things, which deal with other people's money. I'm pretty sure it's mandated by customer contracts.