The most powerful teams come from the special combinations of members.



## Product of Teams

A great team is one that has a great time making a great product.

To have a great time, we must enjoy working with the others on the team.  We have a productive relationship.  We inspire and help one another.  We communicate well.  Our weaknesses and strengths fit together well and are complimented by one another.

A great product is going to be something exceptional, something that hasn't been done before.  It's noteworthy because of its special quality, timing, application, reception, subject treatment, or other aspect.

This kind of experience and product is the result of a special confluence of people -- people with special skills who came together and created something unexpectedly great.

This has happened before.  Here are a few powerful combinations that I can think of.

## The 2 Steves

Steve Wozniak grew up learning how things worked.  Soon he was designing complex circuitry on paper.  He had the special disposition of designing with the least number of parts possible.  His creations were ingeniously simple and cheap.

Paired with Steve Jobs, he had someone who could market his creations.  Jobs was someone who could find the sale.  He could see a potential application for the technology of his partner.  He brought Wozniak's great abilities out of the shadows and found widespread application for them in personal computers marketed to the masses.

They created the first personal computer to sell 1 million units.

## The 2 Johns

Both John Carmack and John Romero were writing games for small-time publishers by the time they left high school.  When they discovered one another, they found in the other someone who could really understand and appreciate them.  

Carmack focused on pushing advances in game engines.  Every time he heard of a new industry development in graphics, he was soon to have developed a ground-breaking implementation.  These advances were revolutionary in their time.  His partner, Romero, was the ultimate gamer and could see how these tech advances from Carmack could be applied in radically new gaming experiences.

They formed id Software and created titles that advanced gaming and brought it into the mainstream.

## The 2 Garriotts

Richard Garriott grew up playing Dungeons and Dragons.  He then learned how to program on primitive terminals during high school.  Soon he discovered he could combine these two skills of story telling and programming to create virtual worlds.  He would have been happy to do so forever, simply enthralled in his creations.

But his brother, Robert Garriott, suggested they form a new company. He found out he could avoid a "real job", instead continuing to create games.  Robert was business-minded and helped put Richard's creativity to use.

They formed Origin Systems and created many successful, long-running titles.

## Potential Combinations

There are groups of people around us that could form great partnerships.  

Each person has a special set of skills.  If we considered combinations of team members more carefully, we could see greater benefit in special combinations.

How do you try to create this magic on your teams?  What are some special combinations that you look for?

This inspired a meetup talk: 

<script async class="speakerdeck-embed" data-id="7f90d9681bd043f4b11057f372ab9590" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>

The most powerful teams come from the special combinations of members.

The Power of Team Combinations

Your knowledge of a field is deeper when you're focused on it.



## Your Surroundings 

Stop wherever you are and consider your surroundings.  Look around, making note of things you see.  Do this for 30 seconds.  Then close your eyes and list all the red items that you saw.  

Actors sometimes use this exercise to get into the zone and focus on their surroundings. 

Imagine your increased perception of the red things around you if instead of just making note of "things", you were asked to take note of "red things".

## Deeper Abstractions

When making a program, it's composed of functional units called abstractions.  Some are general and high level.  They might be composed of more specific, low-level abstractions.  

The higher-level abstractions might have cursory knowledge of some of the subjects handled by the deeper abstractions inside of them.  For instance, they have to know how to invoke them.  They know of public APIs.  But they don't know the implementation details, and this is on purpose, so that you only have to consider those details when you peek inside that deeper abstraction.  Otherwise, you can trust that it's doing its job well.

## Separation of Concern

Our brains are very good at categorization.  They have to be.  We encounter hoards of new information each day.  What do we do with it all?  We rarely can use it at the moment, but some things we take mental note of, considering their potential utility.  We slap a mental label on it and file it away for recall when we are more engrossed in that subject.

We do this to survive mentally.  As in the "red things" awareness exercise, how much more effective in filing would we be if we knew we could disregard more streams of data coming into our minds and focus on those that really mattered?

## Single Responsibility

When we create a boundary around an abstraction in code, we often strive to follow the single responsibility principle.  If this bit of code does _one_ thing, it'll do it well.  If it does one thing, when I examine it, I know what to expect.  If I change its inner content, I will effect that abstraction and it _only_.

Imagine if your own focus was deepened.  What would you go deeper in?  At what cost?  At what gain?

Your knowledge of a field is deeper when you're focused on it.

Deeper Focus

As developers, we sometimes feel the need to do it all.  Is this feeling realistic or even needful?



## An Entreprenuerial Need

If you're starting a gig all by yourself or if your company is small, growing, and you're just figuring things out, you may indeed need to "do it all".  You wear many hats.  You make it work.  If something's not working, you figure it out yourself. 

Even in these situations, however, you may not need to do it all.  Do you need to have your own hardware?  No, there's EC2.  Do you need to build your own payment processing?  No, there's Stripe.  It turns out there are always things we won't or cannot do -- sometimes chosen strategically, sometimes out of only necessity.

## Moar Fuller Stack

It seems lately that the prefix "Full Stack" on a resume is the only acceptable path to take.  Anything less is interpreted to be something like admitting "I have not work hard enough in enough areas to warrant this monicker that denotes my vast abilities" -- or something like that.  I too have highly valued the ability to contribute up and down the stack throughout my career.  But I don't think it's the only way to go. 

For instance, I know some developers who like frontend dev and are good at it, but feel that they need to do more on the server.  If this need is motivated by one's own interest or the desire to positively help one's team more ways, great.  If this need is motivated by the feeling of inferiority or the need to get on the full stack bandwagon, I think it's unhealthy.  Stay more true to what you like, what you're good at, and where you can play to your strengths in order to make a difference.

## Fear of Missing Out

We are bombarded with oodles of posts in our feeds every day, tell us that we've got to use the next new thing in order to be competent or successful.  This is usually not true, but it calls to us nonetheless.  I'm very much in favor of constantly learning and looking for a new adventure.  But again, the motivation for our learning and looking is important.

If we feel anxious about it, the net result is a tax on our happiness.  And we will *always* feel like we don't know enough -- not enough libraries, languages, patterns, trends, conferences, projects, and more.

## You Really Can't

We might have a sense that the development world is passing us by.  In some sense, that is true.  There are so many people doing so many interesting things around us that one person simply cannot keep up with the full range of global interesting activity. But this is not to say that the ability to do our job today or prep for our job tomorrow is impossible.

We cannot do it all.  We cannot learn it all.  We have physical and emotional limits.  We need to come to grips with that reality for our own welfare.  We should still engage in good, worthwhile development and push ourselves, and we also need to be able to let go and not do it all and still be satisfied with our performance.

How do you cope with this reality and let go of things you would like but cannot do?

_Thanks to April and Ilene for the collaborative drawing for this post.  Such fun!_

specialization