I have talked to organizations that haven’t yet moved into the cloud because of security concerns. They stay locked in their own data centers because they have a fear of exposing their systems and information to the outside world. This may sound counterintuitive to those that haven’t moved to the cloud yet, but you’re more secure in the cloud than you are in your own data center.
I’ve witnessed a lot of heroics over my professional career. I’ve been a part of some of those situations requiring heroics (mostly MUCH earlier in my career when I could actually “do” things). If I’m honest with myself, I liked the recognition and the sense of accomplishment. They were also memorable and dramatic and made for great stories. Later stepping into various leadership roles, I’ve also praised the heroes in other situations, believing I’m doing good by expressing gratitude and providing valued recognition for a job well done. It’s only been relatively recently that I’ve realized the harmful effects of heroics that often go unacknowledged in light of the back-slapping, award-giving, and praise-heaping “you’re awesome” celebrations. And once the celebration has died down, we move on… in a worse position than we were before the situation that required the heroics.
If you’re prone to heroics or celebrating heroics, you’re hurting yourself and your organization. Here’s how.
I’m a big believer in the old adage, “Those who do not learn from history are doomed to repeat it.” You need to examine your mistakes, figure out why and how you made them, and then use those lessons so you can do better the next time. In addition, I would prefer to learn from other people’s mistakes rather than committing them myself — it’s gain without the pain. So I asked myself the question, “What are the biggest IT fails in history?” And then the more important follow-up, “What can I learn from them?”
I wanted to find the failures that were significant and spectacular. They had to be impactful and memorable. There are plenty of stories about failed IT projects that “just” wasted a lot of money like this one from the Air Force (there’s a lot to be learned from them, too). But I wanted the projects that culminated in a momentous, go-out-in-a-blaze-of-glory, end-up-on-the-evening-news kind of failure.
Here’s my short list along with the lessons I took away from each.
I’ve been thinking a lot over the last several months about how my team and I work. This is somewhat about the actual work we do, but more about how we do it. My thinking was prompted by several factors. First, we felt like we were always maxed out on capacity. The metaphorical CPU was always pegged at 100%. As a consequence, we had long cycle times and lots of context switching. Second, much of the time we felt like we were struggling against the system to get work done. It felt harder than it should have been, was draining our energy, and hurting morale. Finally, we didn’t feel like we were collaborating as a team as much as we would like. We were operating in our own silos.
We needed a change.
Becoming a better leader has become a lifelong journey and passion for me. Regardless of what my official role description or title says, I’ve realized being a leader is what my real job is. Leadership is an awesome privilege and responsibility so I want to be the best leader I can. I’ve also realized I’m far from perfect as a leader (just ask my team). But I’m a better leader now than I was last year and hopefully I’ll be a better leader next year than I am now. For me, getting better starts with getting clear on what I’m all about. And getting clear starts with writing stuff down, so here you are.
I love spreadsheets, charts, graphs, and numbers. Tracking quantifiable metrics gives me comfort and a sense of control (those two feelings go together for me). Metrics help me understand what’s going on and give me insights to take action. In that respect, I’ve often felt I would fit right in at Etsy. In my experience, I’ve also discovered that clearly identifying who is accountable for something and establishing the metrics you’ll use to evaluate success for that something are powerful clarifying tools in actually achieving the outcomes you want. The “how” and “when” usually fall into place after establishing the “who” and the “what”.
I’ve also discovered some pitfalls with metrics. I’ve recently challenged my thinking about metrics and their value. Here are some of my insights.