I’ve had the benefit of learning through trial by fire – that is, I became a manager early in my career without any formal management or leadership training. Being a reasonably smart individual, I figured I would be able to lead a team to success in projects in areas beyond the boundaries of my relatively small experience. Without any regard for my own significant technical gaps or inability to know everything in the technical realm, I charged ahead as a young and motivated manager.

Enthusiasm, compassion, intuition – I had everything going for me early in my professional career. Prior project successes lead the team and company to respect my work – I was so, so lucky. It wasn’t long before I discovered that what I said as a manager, went. I could give direction and someone would go off running in that direction. It was amazing!

I often don’t have the best solution.

I had a (dangerous) power and I didn’t have enough respect for it. I was finally wrong enough times and am lucky to be surrounded by a strong and skilled team to have learned to tell people what to do less. When you have a capable team – they need you to ask questions more often than you give direction. After all, it’s far more likely that they’re experts in areas that you aren’t. Describe a problem, and ask questions about the potential solution(s) including benefits, limitations, ideal future-state, alignment with 1-3 year technology strategy, unconscious biases, and more.

I am responsible for ensuring we choose the best solution.

Not only was I assuming that I knew the answers instead of the team, but I had a blind spot to my own technical ability. Being the decision-maker results in responsibility for the soundness of a solution With the longevity of systems and code, my past is still around to haunt me – and remind me to assess my current knowledge level before proceeding forward.

When I make the team do something stupid.

Friends, I must admit, I asked our developers to put WITH(NOLOCK) on every SELECT query. It was within my first year above helpdesk and it took at least another year to spend time studying for certs, practicing in a home lab, and learning from others to realize just how wrong I was.

I changed my mind.

On the ground level, I realized you probably don’t want to put that shit on everything (NOLOCK). Beyond the specific example shared here, I’ve come to understand how much I need to rely on consulting the experts, whether on our team or elsewhere, before making a decision. My former mindset of charging forward independently has vastly evolved to include more consultation and information-gathering.

Thanks for stopping by for T-SQL Tuesday!

This post in response to the T-SQL Tuesday #119 prompt: changing your mind

More info on NOLOCK

https://www.sentryone.com/blog/aaronbertrand/bad-habits-nolock-everywhere
https://www.mssqltips.com/sqlservertip/2470/understanding-the-sql-server-nolock-hint/
https://blogs.msdn.microsoft.com/davidlean/2009/04/05/sql-server-nolock-hint-other-poor-ideas/
https://sqlperformance.com/2015/04/t-sql-queries/the-read-uncommitted-isolation-level