→ Confessions of an ex-developer

If you attend an iOS/Mac dev meetup and hang around long enough, you’ll start to hear the whispers and the nervous laughter. There are people making merry in the midst of plenty, but each of them occasionally steps away to the edge of the room, straining to listen over the music, trying to hear the barbarians at the gates. There’s something wrong with the world, Neo.

Great read from Matt Gemmell. I’ve been in this spot and gone back to development, I get where he is coming from.

There is something on the horizon, although I don’t know exactly what it is. There are so many changes afoot in the development world and in the industry that I don’t think anyone can see very far down the road anymore. Developers have become a recognized asset in the broader world, yet it seems like there are lots of people who don’t want to let that stand. The next decade will be fascinating.

→ DevOps and 'The Phoenix Project'

When a colleague handed me The Phoenix Project I was very skeptical. I’m a reader and a writer, and if I can be honest, I’m more snobby about it than I should be. I was skeptical of the book, but I read it.

I read it in one day. I really liked it.

It’s not great literature. The criticisms of the storytelling and writing in the reviews I’ve read are dead on. That’s okay by me though, that’s not the point of the book. Sure, in an ideal world the level of art would be higher and match the lofty ideals of IT presented here, but it didn’t, and I’m okay with that.

The book tells the story of an all-too-typical IT shop. Everyone is under pressure, well intended processes are ignored because they are too cumbersome, and IT can’t deliver critical features to the business. Our hero is thrown into a battlefield promotion, and must save the day. He learns DevOps from the ground up, by thinking it through (with a touch of help from an all-knowing operations zen master-type), without ever using the term.

If you want to learn about DevOps, and why everyone thinks it’s a big deal, read this. If you need to convince someone else that DevOps is a good idea, hand them this book. It’s not the best novel, but it gets its job done. Actually, all things considered, it does its job well.

Leaders want the ball

Leading a technical organization is dangerous work. Every week there are literally hundreds of small decisions that must be made without full comprehension of the associated risks or benefits. Each one of these decisions could lead your team down the path to success or failure. Oh, and everyone on your team has a different opinion. That makes decision making very hard, and if we are honest, scary.

Yet leadership is not about decisions. Trying to lead solely through decisions is a recipe for failure, no matter how good they are. Effective decision making is simply management, but leadership is so much more.

Leaders want the ball

In college I played intramurals for my fraternity in every sport I could. I spent a lot of time on the ‘B’ teams, and later leading on our executive council. I loved it all. In that fraternity I learned about leadership firsthand, and it started on the intramural fields.

In the sports I was confident in, I wanted the ball. I wanted to be the one who had the last shot, or who sparked the final goal. I wanted to lead the team, to influence victory. In those sports we saw good victories over the years, and I loved every one of them.

But in the sports I was not good at, I hung back. I passed the ball quickly, I looked to sub out at the end of a close game. It wasn’t cowardice exactly, but it was close. I knew the decisive moment was near, and I didn’t trust myself with it. Victory in those moments did not feel good, but instead, like relief.

As the years went on and my influence in the fraternity grew, I saw the same thing with my fellow officers. The good ones wanted to lead. They wanted the ball. As I got older and took on more serious positions, I started to want the ball, too.

When our biggest decisions came about, the same pattern emerged, and our best leaders stepped up. And in time, they helped others step up. When the biggest decision of my time in school came around, it was my best friend and I who stepped up and led our chapter to the right decision, one which has benefited us every year since.

When I left school the fraternity was in much better shape than when I arrived. It wasn’t me—it was those around me. We had great leaders, and they helped everyone grow. The stakes weren’t as big as they are for me now, and the current decisions are certainly more complex, but the truth remains: leaders want the ball.

Effective leaders build culture

In soccer, the jersey number 10 is sacred. Number 10 is the playmaker, he sparks the great plays. Number 10 is who you want on the ball when the clock goes past 90 minutes. Number 10 scores some goals himself, sure, but Number 10’s value is his ability to rack up the assists.

The technical leader should be the team’s Number 10. They should rack up the assists. They set the team up to win, and do it by building a winning culture.

If you reflect on your time on technical teams, both effective and otherwise, I bet you notice a simple pattern: teams evolve in the image of their leaders. The values and goals of the leader directly set the tone for the team. What the leader recognizes and rewards, the team produces more of. More importantly, the choices a leader makes, their team emulates.

Good leaders want to influence their teams. Good leaders want to model the right behaviors and set a winning tone for their team. Bad leaders simply want to manage the status quo, and eek out a little bit of a performance gain. Good leaders build culture, bad leaders make excuses why the culture can’t change.

Next time the big decision comes down the line, don’t just make a choice—lead. Bet on your team. Bet on your people. Have the courage to want the ball.

In the end, don’t manage. Lead.

Management presides over bureaucracy. Leadership empowers people.

Management dictates policy. Leadership expects cooperation and accountability.

Management enshrines standardization. Leadership models flexibility.

Management trusts process. Leadership trusts people.

Managers pass the buck. Leaders want the ball.

→ Using Swift and Cocoapods

This short post on medium is short and simple, but walks you through how to get Cocoapods working with your fancy new Xcode 6 Swift projects. It saved me quite a bit of time and experimentation.

Evolutionary change fuels revolutions

We commonly draw a distinction between revolutionary and evolutionary change. We categorize some changes like the invention of the PC as revolutionary, and others like a new development framework as evolutionary. I suppose there is something about that idea that makes sense. There are changes that have immediate and wide-ranging effects. But I’ve never seen this as a useful distinction when you are trying to effect change.

This distinction is commonly used to comment on big changes in an industry, product category or culture. Commentators see the big, evolutionary change leapfrogging over many smaller changes. They categorize changes into these categories as an either/or proposition. A given advance must fit into one bucket or the other. There is another group besides pundits that also commonly uses this paradigm to think about how change works: managers.

This kind of hard, binary distinction is something that only an observer and not a creator could come up with. Creators know that these kinds of changes are really two sides of the same coin. That’s not to say that we don’t need both managers and commentators, but their perspective is, for the most part, that of an outsider to the creative process. Creators know that there is a very fine, if even distinguishable, line between the evolutionary and the revolutionary.

A revolutionary change can only be sustainably made after many smaller changes lay a foundation. Wi-Fi was revolutionary, but it was built on the back of other technologies. The TCP/IP protocol, radio communication, low-power radio receivers, fast high-quality encryption and more led the way to making Wi-Fi possible. For the outside observer, this appears to be an evolutionary change out of the blue, but to anyone in the networking sphere it was the inevitable result of many smaller (from this perspective) innovations.

We must keep this in mind when we are responsible for changing systems, be they software, hardware or processes. Small evolutionary changes fuel the big, revolutionary change. New principles and ideas build on what came before them. To effect change in a large scale system, leaders and designers must emulate this evolutionary process.

I think the easiest example here is contemplating how a large development organization might make the move to an agile methodology. The leaders certainly can decide to just institute the process changes—daily stand-ups, backlogs, fast iterations and the like—and train the staff in how it should work. This is the way many companies do it. But it is usually not very effective. Because agile is not just a way of running projects, it’s a way of thinking about software, a very different way than many people were trained to think about it. Implementing the changes to the process without changing the way people think, without trying to change the culture, will not result in a meaningful change.

Small changes—like your team seeing the wisdom in the agile principles—is not always easy, and it does not occur overnight. A change like this is evolutionary by its very nature. By constantly fostering small changes you can build the foundation for the evolutionary change you want.

Big changes are possible—they happen every day—you just can’t skip building the foundation for them.