We have super standards. Our systems are more complicated. We’re not like everyone else. We have the most intense channel. If we go down, we are in trouble. You can come up with as many lines as you want but at the end of the day it still boils down to this – “Leading teams and delivering Code” – and if you aren’t doing those things, yes you are different, but the bigger question is…
The #1 problem with Code Reviews isn’t whether the standard is followed, what syntax is used or when you start doing them with your team. Whatever you pick (and when) will work – it will. The problem is the follow through. We start with lofty expectations of all that we’ll accomplish, we turn on all the switches and for a time things start to go well – code starts to get reviewed – questions are…
But it’s all up to you. It’s up to you how you show up. It’s up to you how you conduct yourself. It’s up to you how much effort you put in during the day. It’s up to you how much effort you put in during the night. It’s up to you how successful you want to me. Not them, the choice is yours, it always has been.
Because you’re asking the wrong questions. Your team isn’t late because they all don’t use the same tools. Your team is late because no one is helping coordinate the different tools. The reason you missed that delivery deadline wasn’t because the bug count was too high. It was because the feature load was preposterous and was never going to be met. We shy from asking the wrong questions because the answers that come aren’t immediate…
If you’ve never asked them, you can start there. That’s really all there is. There is no complicated mumbo jumbo or fancy leadership style books to read or culture decks to download. Just ask them what they need and start there. The plan, the strategy, the direction? You can figure that out later, but not until you talk to your team.