Making a Product Symphony

I have no memory of the first time I stepped on stage, but given I was a preschooler, that probably shouldn't be surprising. What followed during the first 20 or so years of my life was a regular occurence, of practice, both vocal and instrumental, and performance. The first half of my life was one of getting up in front of people and showing off. Some would say this also describes the second half of my life, and they are not entirely wrong in that belief.

Given so much of my life was taken up in persuit of the arts, it might come as a surprise to learn how much similarity there is with making war. Even I was a bit surprised at how the lessons of my young life came back as I read through Boyd, a book about one of the best fighter pilots and how his views reshaped how we thought about aerial combat.

What I learned from music and fighter jets also turned out to be relevant to my day job, software development, too. I'm not a big note taker when I read books, but this one had highlights all over it by the time I reached the last page. In the three and a half years since my dash through Boyd, I've been mulling over what this means to build great software development teams. What follows will be my learnings so far, built into a framework of nearly 20 years as a performer.

Assembling an Ensemble

Before you can perform, before you can practice, you need to assemble your performers. Your idea may be top notch, but it will not come to fruition without the talented people to bring it to life. But who are these people? Its not enough just to grab random people; they won't have the skills you need to make the dream a reality.

Even if you got the right people, you need to make sure that they are in the right places. You don't have your first chair violinist back playing percussion. They could probably figure out what to do and when, but they are not playing to their strengths when using someone else's instrument.

Even if everyone is using the right instrument, you need to get them in the right order. Imagine if you, as an orchestra conductor, told the members to sit wherever they like. You no longer have sections of similar instruments supporting one another, but massed chaos. Some chaos could potentially work, say if all the woodwinds were in the front left, strings somewhere in the middle, brass off stage (where they should be), yet you'd still find that trying to give cues on when to come in would be a nightmare when compared to a well organized ensemble.

With the seating chart filled, you still need to fill the seats. You need to answer the question of exactly what kind of group you're going to be. Hiring for an orchestra is far different than a stringed quartet. Different people are drawn to different types of organizations. If you're a start-up, you probably need generalists who learn many different skills, as they'll end up wearing many different hats. Large organizations tend to specialize to achieve focus and (hopefully) speed in specific areas. Some people do better in one type of area and other people do better elsewhere.

So what do I look for when I'm looking for people? Regardless of the role, there are some things that I consider to be fairly universal in my hires. These may seem to be somewhat unrelated or random, but I feel these embody the spirit of the type of team members I want. Not everyone needs to be experts in all these areas, and depending upon the role, some may be more important than others. Everyone working for me needs to at least show the ability to understand these and growing into first-hand knowledge of them all.

• Has started something new. Sometimes, you just have to make something from scratch. What exists won't work, either organizationally, technically or spiritually. You don't undertake a blank page lightly, but you can articulate why it needs to be blank and what you feel it will look like as you progress in the journey.
• Has shut down something old. Life is a cycle, with death a stop along the way. Sometimes, something that may have served us well for years, needs to end. We may not mourn its passing, but someone, likely the person who started it as new, will at least shed a tear as its lights go out. We need to be respectful of its passing, but not hesitate to put it down.
• Has fixed something broken. Bug fixing is rarely the glamorous part of the job, but its critical. All software has bugs and it can always be improved, even if it bores us to tears. It takes discipline and determination to weed through someone else's mistakes, to make the world just a small bit better.
• Has moved when others sat still. Its often easier to sit and wait for someone else to take a risk. Seeing opportunity, gauging the risk and deciding to do something bold at the right time is a skill all in its own.
• Has knowledge others (at their skill and experience level) do not. We're not looking for 10x developers or savants here. Those people can be helpful in rare situations, but team players who can point to the real-world results of their work should always float to the top of your list. Do they have a github account? Have they posted their own code, along with contributing to someone else's? Have they written documentation for someone else. Do they have that love and passion to do that when it isn't part of their day job? These are aromas, as opposed to bad smells, of someone you want to have on your team.
• Has been responsible for something critical (and learned through failure). If they don't understand what its like to have responsibility, of someone counting on them to come through, you need to take extra care to make sure that they'll be there when it really counts. They're going to make mistakes, you did as well, so they need to know how to recover and that you'll have their backs as you clean up the mess, together.
• Has helped someone different from them be great. Its not all about them and its not all about you. Both of you need to know how to make someone else great, but specifically someone that isn't like you. Being able to step outside yourself, your knowlege and your background, to relate to another person with different cultural baggage (and we all have baggage), shows that they know the job is just a thing; nowhere near the most important thing.

None of that fits in a resume or on a job description. Little of that can be quickly gauged during an hour-long interview. This is why I believe so strongly in having a talent pipeline, networking and referrals. Get involved with your local university, high-school and job training programs. Participate and lead in your local professional organizations. Liberally poach the best talent from your prior employers and the prior employers of your best team members. Don't discount the person who submits a resume on your website, but don't rely on that as your primary method of finding talent.

When you're putting the band together, you need a good balance of different voices and instruments, otherwise you end up music that is flat and bland. As much as I love the saxophone, an all alto sax band hurts my ears. Get a good mix of people, get them in the right seats, practice their skills, then let them make great music.

Making Great Music

You've got the band, but what do you play? How do you, as a leader, conduct? How do you know, before you get booed off the stage, if you're bad? Making great music isn't something that just happens. More bands break up every year than businesses fail. You may have the best musicians in the world, but your music can still suck.

One of the key things about making great music is your tempo. Its not only the speed you're playing at, but its how you change speed, slowing down and speeding up, to make great music. The audience you play to has a great deal of influence on how the musicians play. If the audience is sedate, the tempo tends to drag, but a rocking crowd can push the band's energy higher.

In a similar way, what's going on in your industry has an impact to the tempo of your team. If you're in a highly regulated market, like banking or health care, the months of security review may drag down your entire team. If you're working in a silicon valley start-up, the expectation may be that everyone on the team is working 80+ hours per week. (Side note, don't do this, it isn't healthy and you're worth more than what they're not paying you.)

That tempo dictates not only how you play, but how other groups play as well. A poorly chosen opening act can drag down an entire audience, no matter if the main attraction is high-energy. Having a competitor that is dragging you along in its wake is a never-ending game of catch-up.

How do you avoid being drug along? Its not about simply moving faster, its about adjusting your tempo so that the competition starts following you. Its about knowing when to sprint, when to go the distance and when to recover with a walk. Being able to nail your tempo transitions keeps your team together as you're maintaining the same beats. Your team needs fewer reminders from the conductor because they are locked in together.

Getting these tempo changes right saves your energy, storing it up for when its really needed. It also can cause confusion with your competitors, because they don't understand your strategy. They're spending more time trying to figure out what you're doing than they are just doing their thing.

There are lots of ways to work on your tempo, but the first should always be practice. Spending time working through your basic skills, knowing the playbook inside and out, and the team knowing and trusting one another, gives you all the building blocks of a great organization. But that's just how you start.

Invest in technologies that require less work to implement, learn and maintain. Look for ways to configure before you customize. Integrate the work of others before you recreate a wheel. Look for things that are easily disposable, so you can toss them out if they don't work or you outgrow them. These are the multipliers to tempo; they can speed you up dramatically, but picking the wrong ones can grind you to a halt, too.

Balance

Think back to whatever music you listed to as a child and teen. For most people, especially those who see music as only something to listen to when you're doing something else, probably think that's the best music ever made. Music from older than that sounds like an antique and newer music an abomination that they can't understand. This has been the case for much of humanity, streatching back to when the "beat rocks together" group shunned the new "beat sticks together" racket.

Its no different with our teams. There was a time when COBOL was the new, hot language that everyone wanted to write (for about 5 hot minutes, anyway). If we stay in the industry long enough, we'll live through many of these transitions, watching as the lessons from the old way of doing things are applied to something new. Often, what worked 10 (or sometimes even 1) years ago no longer does so as well or at all. Time moves on, and we have to move with it.

We must view ourselves as constant reformers. If we do not, we risk being irrelvant as the world moves on. Yes, there are still jobs for COBOL programmers, maintaining legacy systems. I don't discount those people are still doing great work, but it will never be the work that excites a new generation to join up. You'll find yourself fighting to keep a flame burning that should have been extinguished long ago.

When it comes time to create new systems, we need to do so along side the old, but not within the old. Our goal should be to encompas the relevant needs of the old, extend them into the new world, and then extinguish the elements that are no longer necessary. If our mindset is to protect the way things have always been done, never improvising and reinterpreting, we will find ourselves locked into a music that is no longer heard except by a small number of revivalists.

Along the way, we're going to run into rule enforcers, people who know how its supposed to be played and will work against any deviations. Don't befriend these people. Instead, work with rule makers. Enforcers gather their power from what was done in the past, but makers see the future and build towards that brighter day.

You're likely to find something that doesn't make sense or is ambiguous. What did the composer mean by this notation? Did they really mean for it to be this slow or has our notation changed since this was written? Finding places of ambiguity provides us an open space to improvise, to experiment and to build little monuments to chaos. We need to embrace these moments, not run from them.

Close enough for jazz

My older sister's high school bad instructor, when tuning the band before practice, was known to say, "Close enough for jazz." Perfect tune wasn't a priority for him. As I became a jazz musician in college, I began to understand that more and more. You want to be close to in tune, but new works are created when you bend that tuning just enough for things to get interesting.

I call this the concept of fluidity. Bruce Le talked about being fluid like water. It flows, it fills up whatever container you put it in, but when poured out, it loses that shape and bends itself again to wherever it comes to rest. In not being rigid, we give ourselves more capability to change as circumstances evolve. This is how a good jazz musician does their thing.

Musicians have for most of time been chronically underemployed. Humanity appreciates the arts, but almost never enough to pay for it. Why should we pay for something creative, especially something that is as intangible as a music performance? People's resources are finite, and paid-for music is often seen as a luxury, not a necessity.

In projects, even when backed by corporations with large pockets, we never have the resources to really do everything we want to do. It gets even worse when we're competing for scarce resources. Going head-to-head causes needless attrition, so think about ways to go around problems. Be fluid to obstacles in your way. Look for the gaps that are open, decide on which ones can get you to your goal, or at least close enough to it, then go that way.

Knowing your strengths, especially when you have fluidity as one of those strengths, allows you to bypass the obstacles instead of having to break through them. When you do this, you find that your competition will not find you where they expected you to be. They broke through the barrier you bypassed, so they'll be expecting you to have to fight through it as well. Don't do what they expect. Audiences who hear music that only does what they expect are not audiences for long.

The last thing to remember is sowing chaos everywhere but with your team. Your teammates should never be in the dark about what you're doing or where you're going. Improvisational jazz musicians sound like they're just making it up as they go along, but in reality, they're the most prepared people in the room. They know all the rules and exactly how they can break them to produce something great. Their band mates have heard them make those breaks hundreds of times before, even if the audience has no idea what's coming next.

Creshendo to the finale

This ended up talking a lot more about music than it did creating fighter jets, but I hope you end up reading Boyd, anyway. I happen to know a lot more about music, so the framing of this post made more sense this way than military matters I learned from one book. However, the principles behind both share more in common than you might have thought.

How will you frame this up? Will it be through gardening? Cooking? Woodworking? Motorcycle repair? I don't know, but I encourage you to think about what matters to you when it comes to running your projects and find a way to relate it to your team.