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.

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.

For software, stasis equals death

“Stasis equals death.” I picked up this phrase from a really good book on screenwriting, and found that it absolutely applies to the software development world. It applies because it is utterly true. For developers of modern software, products are either under active development or they are dying.

This dynamic was clear in Apple’s transition last year to iOS 7. Within a few weeks of the update, most of the top apps were updated to the new look, and those developers that didn’t felt heavy pressure from their users. Look at anyone’s iPhone home screen months later and there are likely no iOS 6 apps on it.

The apps that were not updated now feel old. They still work as intended, but they no longer meet the expectations of their users, and as a result, they might as well not exist.

In the world of traditional enterprise software we see the same issues. Projects to develop or enhance an application finish, the operations team is (hopefully) trained, and the development team moves on to the next project. Sometimes on the same application, sometimes not. Either way, the project in production might as well not exist to the developers unless it breaks. After all, they have the next big project to worry about. The application enters stasis.

This leaves the users out in the cold. If they have changes for the application or issues that they need fixed, they must submit their issues to the ops team and feature requests to the product manager, or the roadmap committee, or whatever bureaucratic madness the governance folks can cook up. The timeline on addressing those requests then tend to run in months, not days. Even good software at this point starts to feel old, and broken.

It’s not just the users who are left out, either. As requests for work on the app stack up, and the next big project holds all the attention, a technical debt stacks up on the application in production. The issues may not be visible to the project team, or they may be known but “de-prioritized” in favor of the existing roadmap. Either way, this team runs a very real risk of launching a new iteration of the product that is even further away from what the users actually want and need. Even scarier is this simple fact: the longer these projects take to complete, the farther away they can stray from the users’ actual needs.

I know, right now you’re shaking your head and thinking, “It’s a good thing I don’t have this problem, because we are Agile.” Well, you might be right. Maybe.

Agile as a idea is a good one, maybe even the right one. But ‘Agile’ as sold by consultants and book publishers is not always the answer. There are a lot of people who will disagree with this, but it’s usually because they are selling Some Agile Way™.

Agile is nothing more than a set of ideas, ideas that build a culture. Merlin Mann talks about this concept in the latest episode of Back to Work, but the culture you create will define every aspect of your organization. Adopting Agile methodologies can help, but only if you are committed to building a culture that really believes in the idea of agile. Either way, and agile approach will not solve our problem by default.

So our problem remains. How do you avoid software stasis? By focusing your work on the product and not the project. This idea is not new, but it should be reconsidered by most of the software development world. Your primary concern should not be the project, but it should be the application.

There are many implications of these ideas, but product ownership can be implemented through a few simple concepts:

  • Organizing development teams by product. Each application or service has it’s own dedicated team
  • Tracking and scoping requirements by product, not project. For strategic initiatives you certainly need to have some mapping of the initiative’s requirements to the product requirements, but the system of record should be at the product level
  • Projects will come and go, but the product teams endure, as does the product feature and fix backlog
  • The product team must really own the product, and be in a direct relationship with it’s users.
  • The development process must trust the team with ownership of the product

This breaks applications out of stasis. In this model, the product is never “done,” it evolves. With the team and work focused around the product the developer and his users can really own and drive the product forward together, without the long lag times of the project focused timeline. It puts the software and its use at the center of development activities.

This idea does not solve all the problems of a dev team. Like all things in life there is no silver bullet. But by viewing products as the key organizing factor, an organization can focus on the constant changes required to keep up with users evolving needs and demands. Isn’t that, after all, the key mission of a development team?

Simple is hard work

When solving any problem, we tend to look to the simple answers first. This is a good response, and one that should be nurtured. But can easily be misled by that simplicity. This typically happens in two ways. First, we think the simple answer means less time than other answers. We tend to equate simple with fast. Second, we assume that a simple answer is easy to implement. We assume that what is easily understood can be easily done. We equate simple with easy. As a result, we often misunderstand the impact of a simple answer to a hard problem. Because, truthfully, simplicity is hard work.

Let me make this more concrete. Take the idea of a microservices architecture, something I have been thinking about a lot lately. The microservices architecture is “an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.”

This is a simple idea. In fact, most laymen will be able to grasp it with about 10 minutes of explanation, and IT professional should be able to grok it in a matter of minutes. The idea is straight-forward and elegant. Break a single system down into multiple, small systems. Put application logic into the services, not the data or transport layers—”smart endpoints and dumb pipes” as Martin Fowler puts it. Call the services asynchronously, and run each of them independently. The concept is not complicated.

But implementing this idea is hard work. How do you deal with decentralized data stores? How do you coordinate operations between services without tightly coupling them? What about managing API documentation? Automated testing and deployments on multiple frameworks or platforms? All of these questions sit squarely in the middle of the microservices concept and must be answered.

With all of those questions in mind, is the idea still a simple one? I’d say so. The idea is still clear and easy to understand. But it doesn’t look easy now, does it?

One of the best lessons a good developer or architect should learn is how to continually ask the question, “then what?” Always push to the next question, to the next decision. Consider each one fully in turn, and then in light of the whole. You cannot be satisfied with the simple, obvious answer if you cannot work through all of its consequences. Don’t be fooled, in the software world simple is never easy. It’s hard work.