Hacker News Reader

Comment by mprovost | Hacker News Reader

One quick observation: you say that your new role focuses on Devops etc... That sounds like a tech lead to me. A manager focuses on their people, not a tech stack. One of the hardest parts of transitioning from an IC to a manager is letting go of control of technical decisions, and learning to trust your team. Of course you need to be able to set the general direction, but it's more about building a culture than it is about the exact implementation. If the team doesn't want to do devops, or testing, or write documentation, etc then it doesn't really matter which tech you choose. Getting people to work together and build consensus is the hard part.

View on HN

As a military officer I agree that trust is a huge amount of effective leadership. It’s something that is immediately visible when visiting a different team.

So what do you do, as a software manager, if you don’t trust your team? Do you set higher technical standards? Do you invest in training? Do you hold responsible for failure to deliver a certain level of quality?

It's not really about the manager trusting the team, it's the other way around, gaining the trust of your reports. If you don't trust your team to achieve their goals, then yes you do have a problem and you can address that in all kinds of ways. But by default you should trust the team. On the other hand, you don't deserve your team's trust until you've earned it.

From the military side you might be familiar with Auftragstaktik [0]. Basically, you set the goal and a timeframe and let the team figure out how to achieve it. You have to connect their work to some kind of success metric. Otherwise you're just saying something like "we have to implement Devops", as a goal in itself, not connected to anything else.

[0] https://en.wikipedia.org/wiki/Mission-type_tactics

Depends on the diagnosis!

Two blog posts: [1] from Rands on skill vs will.

And [2], from Roy Rapoport on a five-step process for dealing with problems.

In both cases, it’s not enough to say you “don’t trust” your team. You have to do the work to diagnose WHY things aren’t working the way you want - do they see there’s a problem? Do they want to fix it? Do they have the skills?

Trying to fix a problem you can’t diagnose is going to be very hard.

[1] https://randsinrepose.com/archives/avoiding-the-fez/

[2] https://medium.com/@royrapoport/the-five-conditions-for-impr...

Reply on news.ycombinator.com