Miles Davis and the Interwebs

Miles Davis and the Interwebs

In 1959, Miles Davis invited his band to a small recording studio on 30th Street in Manhattan. As each musician walked into the church-turned-studio, he handed them a single sheet of paper. On it, he had quickly sketched a modal scale. The musicians had no idea what they’d play that day. They had little more instruction than that paper.

Now at that time, jazz was embracing a style called hard bop. In this style, a group of musicians would get together with a set intro and outro, but improvise the rest. Typically, in the middle of the song, they’d find a repeating bed of chords, and one artist would step forward and improvise over the chords.

Listen to this track, “Freddie Freeloader,” from that 1959 album, “Kind of Blue.” (Feel free to keep listening; it will make my piece sound classy.)

In the beginning of the song, you can hear the hesitation. The musicians are getting their grounding, taking cues from each other to see where the song should go. But at 0:45, we hear something magical begin. As they continue to play, there’s a spark of an idea. Pianist Bill Evans steps forward and begins to improvise over the track. Little by little, the other musicians follow his lead and fall into the music. The band has found its groove.

It’s astonishing to think that something as incredible as “Kind of Blue” had no direction other than an intro and outro. This track, “Freddie Freeloader,” arguably the most iconic of Davis recordings, was entirely improvised. But this is what happens when a team meshes – they can seamlessly communicate and improvise to create something beautiful.

Collaboration is King

While specialization might imply efficiency, it often leads to flack.

Consider this scenario: a client approaches a project manager with an idea. The project manager discusses it with a designer, who mocks it up in Photoshop. The designer then passes it to a front-end developer, who complains that the designer hasn’t considered how difficult it is to create without major JavaScript hacking. After days of work, she hands it to a backend developer, who is infuriated because the front-end developer hasn’t considered how it is going to work within the company’s CMS.

Sound familiar?

The Problem with Specialization

When each team member works independently on their task, they become isolated from the group, leading to fragmentation. In his A List Apart article, developer Garin Evans cautions, “Creating narrow groups of specialists divides teams and restricts the way we work together.”

Instead, teams should function like jazz bands, taking cues from one another. “It’s like a jazz band,” describes Henrik Kniberg, a well-known agile consultant for Spotify, describes “although each musician is autonomous and plays their own instrument, they listen to each other.”

Teams at Perficient work like this. Before each project, we have a group jam sesh. In these meetings, we have a broad range of specialists – a designer, a copywriter, a project manager, a front-end developer, an information architect – all people whose skills alone couldn’t create anything impressive, but together, create something spectacular.

Just like Miles and his band, we have a set intro and outro – we know what the goals of the project are and have a rough idea of what we’re out to create – but that’s it. We play our repeating bed of chords, mocking designs we’ve used before – a horizontal timeline, an image based questionnaire – until someone steps forward to improvise.

Following the rhythm of the team, the single specialist presents her idea. Little by little, the other musicians fall in. We catch the tempo and improvise, throwing an orchestra behind the solo.

I recall one idea that came about like this. For a product recommender feature, we needed to create a question that would ask a customer’s budget. The client didn’t want any prices revealed on the site, so we had to figure out how to gauge a price level without using any numbers.

In our team meeting, we struggled to think of a practical solution. One colleague suggested we ask how this product ranks in their overall home improvement budget. While still a vague, indirect question, the ball was rolling. Just as in the first 45 seconds of “Freddie Freeloader,” our team was still finding its rhythm.

Then, just like Bill Evans on keys, we saw the first spark of an idea. I asked, “What if we ask ‘how flexible is your budget?’” The team caught onto my idea and followed it. “We could use images to illustrate the levels!” one designer excitedly shouted. Following this thread, we created a clean, sleek deliverable. And while we weren’t creating the most iconic jazz record of our careers, the collaboration was what led us to our great idea.

So how do you get a team to function like ours or the Miles Davis sextet?

Generalization Leads to Collaboration

Lately, I’ve been learning to code. Nothing too tricky, just some HTML, CSS, maybe even a little JavaScript when I’m feeling ambitious. I have no intention of being a developer. I don’t want to code for a living. Rather, I want to understand how code works so I can communicate better. Instead of saying, “How do we change that box-thingy to become less dark when the mouse is over it?” I can say, “Can we add anchor links to that div and create a hover event in the CSS?”

We call this the “T” model, the point where specialization and generalization converge. “Your aim is to have a moderate amount of skill in a broad range of areas (the top of the “T”),” explains blogger Scott H. Young, “and to have a lot of skill in a select few fields (the column of the “T”).”

Generalization increases communication. It gives everyone on the team the vocabulary to properly articulate their problems, and to understand – if just at an elementary level – what a solution might involve.

Generalization Leads to High-Level Planning

I can’t tell you how many times we’ve begun a project only to realize we missed a crucial step in the beginning. Assumptions were made with limited knowledge of what it would take to implement them. With a generalist, you avoid these problems. “Generalists learn how each component works with the others,” Evans writes. “They develop an understanding and appreciation of the whole process.”

Having a basic knowledge of your coworker’s field leads to better planning. If you know how difficult it is to develop a section of the site, you’ll allot more time for your developers. This will ensure that deliverables are finished on schedule, leaving happy clients and happy workers.

Promote Knowledge Sharing

We all know the old saying, “Those who can’t do, teach.” As a current student with deep admiration for my wonderful teachers, I don’t like that. The saying instead should be, “Those who can’t do, learn.”

You can never be too old to learn something new. Team members shouldn’t just collaborate, they should learn from one another.

Many companies host brown bag days, where everyone brings a brown bag lunch to work and a team member gives a TED-style talk during lunch.

But with the advent of the internet, you don’t need to wait for someone to teach you. You can go out (albeit, without leaving your couch) and find a wealth of resources on any topic. Tuts+, Codeacademy, and Lynda are just a few.

Follow my lead: I wanted to understand how my copy was formatted so I took the time to learn code.

Go Out and Collaborate!

Collaboration is crucial to a successful team – and it can only be fostered by breaking down ignorance. When you enter a meeting or a new project, put your preconceived feelings aside. Be prepared to learn something new, to feed off the energy of the group and to create, create, create. As Miles Davis put it, “That was my gift . . . having the ability to put certain guys together that would create a chemistry and then letting them go; letting them play what they knew, and above it.”

Find your rhythm. Embrace the jazz.