Some find that handling bad news as a leader is tricky. Their first thoughts range from figuring out who to blame, how to hide the damage or even just how to make the problem go away. I like to look at it from a different perspective. I want to embrace bad news. Treat it as a learning experience for those involved. And ultimately use it as an opportunity to build trust.
Follow along as I give you a few tips on how to embrace bad news as a leader.
I’ve been spending a lot of time lately being self-reflective and this week I was thinking about building trust. The more I thought about trust, the more I wanted to write something about how to build trust with your team, lead or even boss. I’ve got a unique perspective having been a team member, team lead and lately the head of a department. Trust is something that takes time to build and an instant to destroy. But once you gain it, pairing it with influence and credibility is a powerful combination for you as a technologist. Let’s dig into building trust in a technology team.
Influence. I’ve been thinking about this often over-used word for a while and wanted to take a candid look at how to establish influence, increase influence and embrace that influence for the betterment of those around you.
Infrastructure as Code is an emerging practice that encourages the writing of cloud infrastructure as code instead of clicking your way to deployment. I feel like “ClickOps” is where we all started years ago when there weren’t any other options. The lessons learned from the inconsistency in human deployment were the genesis for the automation and power that comes from building your cloud stacks as code. Now, many start from IaC as the patterns and practices are well-defined. But instead of re-hashing those commentaries, I want to give you my opinions on why IaC decisions are more than about the tech. Infrastructure as Code is a shift of responsibilities that brings your teams closer together and will help establish a culture of accountability but it will come at a cost.
There is so much buzz in the Serverless world about scalability, reliability, and nano-sized functions with the ability to generate faster speeds to market. These points are no doubt true and there are many other things to consider when picking the tech for your next project. But I’d like to take a look at why choosing Serverless is about more than those attributes. It can be about the intersection of technology and people.
I can admit my bias upfront that I love and often choose Serverless first. And in my current role, my teams are heavily leveraging Lambdas, SQS, SNS, EventBridge, DynamoDB and many other AWS Serverless stalwarts. But what I want to leave you with below is that choosing serverless when building a product can elevate your solutions thinking and center your thoughts around problem-solving which leaves the undifferentiated heavy lifting to be the focus of your partner in AWS.
