- Leadership in Tech
- Posts
- Company, team, self
Company, team, self
#118 – December 05, 2022
Back when I was managing at Uber, I latched onto a thinking tool that I drilled into the teams I worked with: reach the right outcomes by prioritizing the company first, your team second, and yourself third.
Authentication and authorization are critical parts of any application. It's the front door to your app. But auth is also a security risk. If you are considering outsourcing your auth, check out this ebook, which includes how to evaluate an auth system, risks you might encounter and how to mitigate them, and migration implementation details.
A team without proven observability and on-call strategies will invariably suffer from reactive disruptions; mitigating outages will be painful, like finding a needle in a haystack while blindfolded. I know because I have stabilized teams going through chaotic times.
Combining service layer and business layer is a bad decision in a layered architecture. Mishandling layered architecture can be an expensive mistake.
Measuring software engineers and teams by metrics is fraught with controversy, and rightly so. There are many horror stories of individual developer productivity being measured by Lines of Code, number of commits and other activity-based metrics. This is usually ill-advised, but it doesn’t mean that metrics don’t have a place in software engineering.
Zero to a Hundred Deploys(sponsor)
An average software team deploys between once per week and once per month. But why stop there? What if you can deliver more value to your customer more frequently? Here’s a practical guide to show you how to go from deploying once a day to a hundred times a day. Learn what measurements, development practices, communication and cultural changes are needed to get there.
This article describes the simple language I use to describe product development: opportunity, output, outcome, and impact. But more importantly it describes the tensions and unexpected implications in the model.