Sometimes consolidation of tech stacks between teams is pushed for.  The reasons vary.  Here are a few that you hear often but that might not have super-clear payoffs.



## Easier to Switch Teams?

Some would say that consolidating techs makes it easier to switch teams.

But when someone switches teams, it's almost always a proactive thing.  That person _chooses_ to switch teams because of something he hopes to gain.  It's his choice.  It's not thrust upon him.  He'll go to the other team with eyes wide open.  He and his teammates will anticipate him to be less proficient until he learns the new skills.

Plus, when does this ever happen?  Relatively rarely.  Optimizing for this is like optimizing for other mythical creatures like the designer who writes code or the product owner who writes tests.

## Easier to Support?

Consolidation is sometimes motivated by the feeling that we have too much to support.

We can only support what we have capacity for, true.  But if we start consolidating, how much do we consolidate?  And to what?  And when do we then expand?  If we lock in our support to only a certain set of things, which is surely a subset of the universe of tech choices, what happens when that universe changes (tomorrow)?  

We need to make sure not to shut the door completely and permanently to tech in our zeal to consolidate.  We might even accidentally shut out some tech that makes our support easier by its _addition_.
,
## Easier to Learn?

Sometimes we want to consolidate because there's just so much to learn, and we're tired. 

We have been here before.  There's some new tech thing, and it promises great new results but looks vaguely like the generations of things before it.  We're skeptical.  And maybe we should be.  But we're also the technologists of the company.  We are likely _the most_ progressive people around when it comes to learning new tech.  It's our job to find the best tools for the job, and yesterday's best will likely not be best for long.

True, we can only learn [so much at a time](https://jaketrent.com/post/learning-thresholds-quotas/).  But we need to embrace change generally.  To avoid this is to fight against the nature of our field.

So, should we consolidate techs between teams?  Maybe. But maybe it's not going to be the total solution we imagine it to be.

Sometimes consolidation of tech stacks between teams is pushed for.  The reasons vary.  Here are a few that you hear often but that might not have super-clear payoffs.

Costs of Inter-team Tech Consolidation

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!_

The Need to Do It All

Some product managers may see devs as a roadblock to getting good product. Some devs may view product as arbitrary and authoritarian. Without communication, early and often, it's easy to see why these perceptions persist.  Perhaps we can have better conversations instead.



## The "No" People

Some product people may see developers as "no" people.  A product manager comes to a developer and says, "Here's what we have, here's what we've learned, and here's what we want to build."  Immediately, that poor product manager might be given a litany of reasons why this is hard, improbable, or will take a long time.  It's easy to see why a product manager might feel like his work is being attacked.  It's easy to see how developers can be seen as kill joys.  Engineers do have a way of picking things apart.  How can we use this eye for detail to our advantage?

## Arbitrary and Opaque

Some developers may see product people as fantastical dreamers with no grounding in reality.  A product manager comes to a developer at says, "Here's what we have, here's what we've learned, and here's what we want to build."  Immediately, those poor developers might feel like they've been given a list of honey-dos for the next 3 months.  And why?  Who knows, it's probably just what that product manager wants.  It's easy to see why a developer might feel put upon and unclear about his willingness to do this work.  It's easy to see how a product manager can be seen as opaque in his process, handing out essentially arbitrary requirements based on his own desires.  Product managers are good at getting a vision of the future and the impact of product features.  How can we get the whole team to share this vision?

## Better Together

These views of developers and product managers both contain truth.  Yes, engineers are good at seeing concrete steps needed for creation.  Yes, product managers are good at seeing product impact.  But used in the wrong way, these virtues can reinforce an essentially negative stereotype -- e.g., they just say "no", or they give arbitrary directives.  We can help one another be better.  First, we need to trust each other enough to collaborate.  We need to speak openly with one another and share what we know and how we know it.  We need to share when we don't know or are unsure.  We are vulnerable with each other in order to speak with clarity and honesty.

Developers need time to work through things, just like everyone.  If abruptly given an idea or a directive, how can it not feel arbitrary?  There is no context for the origin or development of this idea.  Share the discovery process together.  Have conversations earlier and more often.  Then things don't come as a surprise.  More, smaller conversations over time will mean less painful course adjustments.

Product managers need the team to dream with them.  They need devs to be able to listen to ideas, even [bad ones](/post/hearing-bad-ideas).  They need to feel safe sharing what they know and how they know it.  Sometimes intuition is an ok answer, but it will require pre-existing team trust.  Product managers need to know that the entire team is committed to the purpose of the product and to working to achieve it.  They need context and reason behind why developers sometimes say "no".

When we really come together, we become cross-functional in more than just name.  To come together, we need to collaborate in each others' spaces.  We need to communicate better.

What are some ways that your product development team has learned to better communicate?

Some product people may see devs as a roadblock to getting good product. Some devs may view product as authoritarian and arbitrary. Perhaps we can have better conversations instead.

When Product & Developers Talk

Devops is a mindset and a practice that asks a lot.  Engineers must learn a two worlds of ops and dev.  This encourages some good things, and needs to be tempered in order to be more realistict.



## Ownership is Awesome

Devops encourages ownership of the code, the product, and the environment in production all the time.  This ownership engenders a feeling of responsibility, craftsmanship of better quality code, and removes the tendency to make your problems someone else's.  This ownership is wonderful.

Where ownership starts to feel overly intense is when it feels like you're out of your element, and you're all on your own -- it's your responsibility after all.

## Modern Dev & Ops Fields

Our systems are becoming more and more complex.

In dev terms, gone are the days of starting a repo and writing a single app. Now your app is spread across multiple codebases.  You might span languages and paradigms.  You have to coordinate the implementation of these systems with a wide array of contributors and stakeholders.  You have a wide array of tests to exercise and verify your code. You are focused on long-term viability of your design in its clarity and refactorability.  In order to remain relevant in the marketplace, your product is always changing, as is your implementation to support it.  There is a lot here.

In ops terms, gone are the days of your app sitting behind a simple webserver.  Now a request will hit a load balancer and pinball across the network. A labyrinth of microservices await the request.  There are many deployables, performing independent tasks, yet intertwined in larger workflows.  They have central logging and monitoring requirements.  They are individually tuned for scale.  They are controlled through arcane infrastructure configuration.  There is a lot here.

## Doing it All

To do both dev and ops requires a wide breadth of knowledge. Having considered the state of both dev & ops on the web today, they seem to require a depth of expertise.  Now devops seems to be asking us to combine the fields into one.  To find such an engineer that embodies the breadth and depth of both fields is rare.  To train such an engineer will take time, experience, proper training, be expensive, and put a lot on her shoulders.

## Making it More Realistic

As a software creator, I like to say that anything is possible.  It usually comes down to how long you want to wait and pay.  Perhaps you're frustrated or intimidated by a devops expectation that you know and do all of dev and ops. Perhaps you're feeling that it *is* possible but that the price is quite high. To mitigate this cost and to encourage realistic devops mindsets and practices, perhaps we can do a few things to help.

We can give development time and space to write quality code.  So much depends on us creating stable systems so that dev time is not eaten in ongoing production runtime maintenance costs.  The only way to go fast is to go well.

We can welcome specialists into our teams.  These fields are deep.  We shouldn't be afraid to lean on the deeper understanding of a specialist, whether she be in dev or ops.  Likewise, interests are often broad, but they are sometimes focused.  We can make it ok to not be interested in one side or the other. This isn't a lack of interest in the principle of responsibility -- just in going deep on expertise.  We can form teams around varied strengths and not require people to cultivate interest and expertise in absolutely everything.  We can ask for help.

We can provide platform level help.  There are complex tasks that can be wrapped up and made more consumer ready.  Procurement, build, deployment, logging, and monitoring setup all have great potential to be simplified for users.

Surely these are just a few things that could help.  Let's encourage ownership through devops.  Let's make devops more workable for everyone.

Have you felt the pressure to know and do all in a devops world?  What are some things that you've done to keep your head above water in a sea of tools and practices in these two deep fields?  What are some steps that you have made or see we could make to make the good parts of devops shine without being overwhelming?

The devops mindset asks a lot.  They must learn a whole new world of ops, in addition to development.

Devops Asks a Lot

Perhaps non-intuitively, seeking praise doesn't bring a lot of it.  More actively giving praise may actually increase your admiration (and praise) in the end.



## Being an Expert

When you're an expert, your advice is sought.  When you're around, people defer to you.  You have built up loads of experience, so of course people should be magnetized to glean something from you.  

How cool is it, then, when the expert in the room starts deferring to others?

I was sitting in the audience for a tech talk recently, and the speaker indicated that he had learned what he was speaking about from someone in the audience.  When pressed for his opinion, that expert in the audience had some nice things to say about his apprentice and the work he had done.  He did admit that he had done a fair amount of what was being demonstrated on-screen.  But this only gave more credence to his next remarks, where he proceeded to give a couple very generous and concrete compliments to this speaker and held up the solution we were all seeing as something at the head of the pack and worth our attention.  I didn't know this expert very well, but my estimation of him went up because of this generous praise he gave another.

## Hog vs. Give

When we hog praise, we look like we need it.  We look needy and groveling.  If we take it when it comes, graciously, and otherwise just do our best at our thing, praise will follow true achievement.

When we give praise away, we generate it -- we create new praise, an environment of praise. In such an environment we may have the pleasure of having some praise reflected back on us.

The next time you're recognized as an expert in the room, thanked for all you've contributed, after you say "thank you", what will you say next?

Sharing praise, instead of hogging it, will bring you more admiration (and praise) in the end

Sharing Praise Brings Admiration

We can have a lot of fun at work.  A lot of fun comes from our team unity and togetherness.  Just fun and silly stuff can be in the service of that end.  Sad cyclops is no different.



## Profile Team

At Pluralsight, we have product dev teams that own a full product vertical.  One of those teams is the profile team, who owns the individual profile experience.

A prominent part of the UI for this experience is the profile icon.  As a user, if you have an individual avatar, that will be used in the UI.  But in the case your avatar doesn't exist, you get the default icon:

![default profile icon](https://i.imgur.com/4c47pTO.png)

At some point, someone saw this default profile icon as a "sad cyclops".  I've heard this quite a bit from this team, and I love that it's become a part of their team identity.  It's fun to hear about team lore like that.  I wanted to make it a little more epic and fun than the original profile icon -- you know, play it up a bit.  

## A New Face

I first drew an eye because that is what I first perceived in the picture.  After showing it to a few people, they said they liked it fine, but the way they saw the cyclops was with a frowny face, not a buckling-with-sorrow bottom eye lid as I had seen.  So I resketched the entire face.  Now it's got a bit of sad cyclops inception to it. I took it with me over holiday where I inked and painted it.  I got back and ordered some stickers excited to give them to the team. I gifted it to them this last week.  I hope they like it.

I also wear one proudly on my laptop.  I'm digging it.  It's fun.

![a laptop of stickers](https://i.imgur.com/qB4z1ka.jpg)

## Team Fun

Why are things like this fun?  Why is it good?  Well, making things for people feels nice.  Having them feel good about the gift was one major goal.  And it's fun because this team has something to call theirs.  When a team has something that's uniquely theirs, it's distinctive for them.  They can share it freely with others who have an association with their team.  It encourages others to find their own [identity](/post/in-favor-codenames/).  It provides great team comradery and joke material.  It's a common point of identity and jelling.  It adds [whimsy to work](/post/make-your-project-fun/).

What do you do to [have fun and bond with your team](/post/have-more-fun/)?

In an effor to add more fun to work, I made a logo for a team.

A Sad Cyclops Appears in the Wild

When we are exposed to a new thing, we might not at first see its full grandeur.  After a bit of context and perspective, our appreciation for that thing may increase substantially.



## Subjects are Deep and Broad 

There are so many fields of study in this world.  Many of them have been around for a long time (eg, any study of our natural world)!  When we are first exposed to a new field of study or a new idea, we see the surface.  We don't know what the expert of many dedicated years knows.  Similarly, subjects are broad.  We may not even know what another human being has discovered in this field of study during his cursory investigations of the same.  He may have found something new and foreign to us that we have not experienced ourselves.

## Code You Didn't Write

One of the most fascinating and fantastic things about software is the extreme malleability of the medium.  You can make something out of nothing.  The somethings that we make can take any shape.  Thus the method of problem solving varies much from craftsman to craftsman.

Given the size and lifespan of many software projects today, you'll see and get to work with code that you didn't originally write.  You may open a file, run through the code, and remark, "what was he thinking when he wrote this?!" -- as if he wasn't thinking what you're thinking.  And he wasn't.  But he was thinking.  In his implementation he had a perspective -- a context consisting of many things.  The combined forces of his knowledge, experience, the team, the timeline, the leadership, the company culture, company growth stage, tool availability, operational environment, customer expectations, clarity of requirements, evolutionary stage of the product, and on.  We don't see things now as that original craftsman did.  We have a new context through which we're interpreting things and making decisions.  Were we to see more clearly the context under which this software was created, our appreciation for the person and the product would likely grow.

## Crossing Disciplines 

In software teams, and any large endeavor, we employ the specialties of many people to make something larger and more interesting.  A cross functional team may consist of a software developer, ui/ux designer, product manager, operations engineer, data scientist, and more.   

The thing that we create together, we can generally all appreciate.  But do we see as clearly the expertise brought to the team from each of these disciplines?  Sometimes we may feel that one of these disciplines is lacking and letting the project down.  A bit more context into the depth and breadth of the subject may increase our appreciation of that discipline and the people attempting to perform it.  It's hard, it's deep, it has taken time, effort, and focus to get to the current level of performance -- just like your own discipline.  If performance is really lacking, help that person. But before judging too harshly, try to gain some context, and it might assist your own appreciation.

What is something that you once didn't have much appreciation for but after some investigation and added context grew in your appreciation?

When you have the background of context, you're able to better see the value of things.

Context Assists Appreciation

You work every day.  It's a part of life.  It's a good part of life, and you have the power to make it better.  Ever since you were  young child, you knew what the magic ingredient was: fun!



Making software is a creative endeavor.  It allows situations for lots of free thinking.  It comes with the satisfaction of creating something from nothing.  It allows stretching of your cognitive ability.  This is all made more enjoyable by having a mental affinity for fun.  

Fun people create fun work.  Fun people are fun to work with.  It's fun to look at fun people's work.  Fun, fun, fun.  [We can't keep doing this, Bob.]

So look for ways to make your project fun.  Here are a few ideas.

## 404 Page

I love the creative outlet that 404 pages have become.  There are blogs of the "Top 25 Funniest 404 Pages" and the like.  It is now common to have companies try to make the most uncommon of "page not found" pages.  You look up to the sites that take the time to make a witty 404 page.  Make one yourself.  If your brand isn't funny (maybe it should be!), at least flirt with funny and push the envelope on happy as much as you can -- and then one step more.

Here's a 404 page that our team made before the designers had come to a conclusion on a recent project.  It's still there.  It's one of my favorite additions to the site.  

![Doge 404](https://i.imgur.com/HobT77O.png)

You'll find that fun projects also present opportunities to do things that you wouldn't usually otherwise do.  For instance, I spent half an hour drawing vectorized Doge -- again, a favorite experience in my memory.

## Animate Things

I am drawn to almost any page that includes some sort of data visualization.  I love making those pages.  Part of the reason is that there's always room to add a bit of your own flair to the thing.  Designers rarely get to the point where they start defining animations, and I love animations, so I get to experiment with what I like and fill that in later.  And animation is usually impressive to users later, so the payoff is nice.  

Here is a fun animation of a gauge that I made for a project that was meant to evoke a car engine revving at startup:

<p data-height="279" data-theme-id="1749" data-slug-hash="eloGk" data-default-tab="result" data-user="jaketrent" data-preview="true" class="codepen">See the Pen <a href="http://codepen.io/jaketrent/pen/eloGk/">D3 Gauge</a> by Jake Trent (<a href="http://codepen.io/jaketrent">@jaketrent</a>) on <a href="http://codepen.io">CodePen</a>.</p>
<script async src="//assets.codepen.io/assets/embed/ei.js"></script>

## Don't Use the Prebuilt

At this point in the UI design timeline, there are many, many prebuilt widgets for today's current look that you can just slap on the page.  You might get done early, but it won't look original.  Your site will just look like many, many other sites.  In my opinion, this is an unwelcome trend in web and mobile app design today -- everything seems to be converging.  But this just makes original designs all the more special and appreciated.

In a recent project, I could have thrown in any of a host of prebuilt loading spinners, but I wanted to do something different and quirky.  We had charts that relied on async data coming from a server, so we had the UI show a chart loading state.  Here's what I came up with for the line chart:

![Line chart loading](https://i.imgur.com/5gCGnzk.gif)

It's meant to evoke a heart monitor.  And for the bar chart:

![Bar chart loading](https://i.imgur.com/7WetiZ8.gif)

I was going to speed it up to make it more equalizer-ish, but then slowed it down so-as to be less busy.  Feel free to [download and use it](https://github.com/jaketrent/react-chart-loading) yourself.

## Have Some Fun Team Spirit

I've previously already mentioned my love for team and project [codenames](http://jaketrent.com/post/in-favor-codenames/).  You should get one, and it should come from a universe of thought that's original or exciting and fun to you.  This is to please you and your team, not anyone else.  Make T-shirts.  I've thought about this often, but have never produced my own, so this suggestion is for me.  For one of my teams, I even picked a [theme song, Moliendo café,](https://www.youtube.com/watch?v=0gC7bmIDQjY) to go with our team code name, Ranchero.  Those are happy memories of good times.  

Make a logo.  Choose something that will be fun.  Imagine it as a sticker on the back of a laptop lid.  Will in be awesome there?  When measured in logos, the coolest frontend web framework available today is [Ember](http://emberjs.com/):

![Ember logo](https://i.imgur.com/dwho9tp.png)

When measured in logos, the coolest tech conference of the past year was [React Rally](http://www.reactrally.com/):

![React Rally logo](https://d13yacurqjgara.cloudfront.net/users/700730/screenshots/2171778/evilsquid_1x.png)

Who doesn't think a bespectacled (Tom) hamster or a nuclear-powered squid aren't the funnest logos one could plaster on his laptop?  We need more mascots.

In short, have fun.  Don't wait for your project to become fun.  Make it fun.  Make your project fun.

Don't wait to make your software project fun.

Make Your Project Fun

Some have surmised that working more will help their team.  It may.  It may not.  It depends.  Here's just one collection of thoughts on how working significantly _more_ than the _rest_ of our team might not help and may actually hinder.



## What is "More"?

Working "more" than the team may mean many things.  Perhaps it means *more time* -- more time in the office, more time in certain worthy activities.  Perhaps it means *more skill* -- more productive, better at the things I care about.  Perhaps it means *more quality* -- produce better work at better rates.  Perhaps it means *more commitment* -- more focus, more sense of purpose, more of an innate sense of urgency.

"More", for purposes of these thoughts also means _unevenly_ more -- as in one person or subset of the team doing significantly more than the rest of the team.  I won't address it further here, but I think that generally if the whole team can do *more together*, within their capabilities, teams will get more better [sic].

## Carrying the Burden of the Team

When we work significantly more than others, it can be easy to feel like we're carrying the brunt of the workload of the team.  The team has work to do, and we're doing the most of it.  We come in first.  We leave last.  Others on the team come and go in between.

If we were to work similar hours to the reset of the team, we'd be less likely to feel that we were unduly burdened.  If we looked less at when people were in their seats, we'd feel less like a bean-counting manager.  We'd allow others to make their own time management choices.  We'd allow ourselves to focus more on our purpose for being on the team.  

#### What Can We Do?

Each situation likely requires thought and consideration of the team and those involved.  But here are some ideas on how we might overcome issues of uneven team contribution.

- If we must count, count hours less, count contribution more.  Hard.
- Focus on ourselves.  Put expectations on ourselves.  We can control those things.
- Life's never fair.  Sometimes we _do_ carry more burden.  Sometimes we are carried.
- Share what we're doing on the team.  Transparency may help dispel myth.

## Rise Together

Part of our purpose for being on the team is to help the _entire_ team be better.  If the team completes the work together and we need every person on the team, sometimes we need to specifically focus on helping our team grow in capability, focus, happiness, quality, output, or whatever it is that we feel the team is lacking.  

We may not really be addressing the issue that needs addressed -- whether a real challenge of the team or something we have conjured in our mind -- by just hammering out more work.  If we take this course of just pressing on with greater speed, time commitment, and effort, we may actually make the problem worse, encouraging ourselves to believe more deeply that we are carrying the weight of the team.

#### What Can We Do?

- Consider how we might lift the total capability of the team.
- Be constructive and helpful to others.  In order to get here, we need to stop feeling sorry for ourselves.
- Sometimes we might slow down and invest in the team itself.

## False Heroism

Once we are working significantly more than the rest of the team, we can come to believe that the team relies on us above all others.  We may attract praise and be singled out.  This may lead us to do more of the thing -- the potentially unhealthy thing -- that we're doing in order to attract more praise.  

Soon, to keep up this pattern of addictive praise incoming, we may begin to create more situations where we can swoop in, do significantly more than others and hopefully be held up as an example of adoration for others to aspire to.  This is a cycle that makes things worse.  

Lifting ourselves above our teammates leads to rampant comparison.  We cultivate pride in ourselves.  We start to feel like we need to prove our continuing contribution.  We speak up about what we individually have done to save and push forward our projects.  We use a lot of "I..."-subject phrases.  We are quick to point out after-hours or extended contributions.  The focus becomes me instead of the team.  The product becomes my own personal activities instead of the team output.

#### What Can We Do?

- Make comparisons for the purpose of helping and filling the deficit of others.  
- See our strengths as opportunities to help others weak in those areas, not a chance to shine above them.
- Be judicious in public praise.  We get more of the thing we praise.  Praise can have side effects.

## Stories We Tell Ourselves

When we're so focused on ourselves, it's easy to be very out of touch with others.  We're often uncomfortable in approaching others about our shared contribution because, of course, we believe that we're doing so much than the rest of the group and are likely upset in some ways with the team.  

So we're left to ourselves.  We tell ourselves stories about why the rest of the team just can't or won't keep up.  We create reasons in our mind to explain the source of their lesser commitment.  Some of it actually might be true, but the story is left to us to tell, and it's likely embellished and unfair.  

#### What Can We Do?

- Notice when we're telling ourselves things in our mind that we don't actually know are true.  Practice distinguishing actual fact from yet-unproved fact.
- Give people the benefit of the doubt.  Trust in usually-good intentions.
- Talk with others.  Tell them our concerns.  Hear their perspective.  We'll probably be surprised with new appreciation.

## It is a "We" Problem

I use "we" in this article because I believe we all can suffer at different times and degrees from this malady.  We value what we bring to the table, and we should.  It's the comparison with our teammates that's the problem.  Pride is universal.  

I also use "we" because this problem and its children problems are issues that we, *as a team*, need to help one another overcome.  I also believe that every one of us has the ability, hopefully with the help of help of our concerned teammates, to overcome this and other problems that keep us from being better teams.

## Great Teams Aren't Perfect

I hope everyone has some number of opportunities to work with great teams.  It's an awesome feeling to feel united in a purpose.  It's awesome to feel supported by others around us.  It's awesome to see our efforts magnified in a greater whole.  

Even great teams have troubles.  It's never going to be perfect.  Don't lose heart.  Great teams will be able to have patience, see each other as human beings doing their best, and find a way to make it work and work well.  

I think some of this has felt familiar as we've read through it together.  We are all still growing on our teams.  What have you done to make your teams work better together and not make any one person feel overburdened?

Working significantly more than the rest of our team may harm more than it helps.

Working More Might Not Help Our Team

It seems to be a recurring discussion in the companies I have worked for: should we use a codename for this project or not?  These are software projects.  The codenames are used on things as basic as the repository name or slack channel.  Later, they might be used in many other project-related things like the build server configuration.  The alternative for a codename is calling the thing exactly what it is.  Where's the fun in that?



## The Argument Against Codenames
The argument is that if you call the project what it is, people will know what you're referring to when you talk about it or when you see it in your version control or on the build server or hear about it at lunch.

## It's Fun
I think codenames are fun.  They add identity and character to your project.  They contribute to team spirit.  You have marketing options in a codename via logos, mascots, and themes.  Most things you can do to increase the cohesiveness of a team around a shared identity, sense of belonging, and to increase their enthusiasm will be worth it.  Why not let codenames help you with this?

An environment where codenames are enjoyed is one that is *not* sterile and colorless.  There are people and product markets that specifically enjoy things and places that are not organized in clean, labelled boxes.  Bring some color to your environment, learn to stop worrying, and love having fun together.

## They Encourage Learning
When you hear a codename for the first time, you might not know what it means.  Is that an unusual or bad thing?  Not knowing what it means should encourage you to ask what it means or look it up.

After you do, you'll then have learned it.  You'll have connected with people that know about it.  You'll have found the documentation detailing what it *really* is, not just what you can fit into a name.  I like the idea of each project having a root readme file that describes the core 'What' and 'Why' of the project.

## They're Short
Codenames are usually shorter than any presumably more descriptive name.  This is great because we usually are talking about our projects or teams *all* the time.  Thus something long and descriptive, like a bloated government agency name, is likely to be shortened into an acronym instead (which is just a codename constrained by odd letter combinations).  Worse still, as people tire of saying the longer name, they start making up their own easier-to-get-out versions which will not be consistent.

## We Speak a Specialized Language With Each Other
Codenames are great for the usually-specialized teams that end up working together.  These teams speak a common language that they learn because of the domain they all work in together.  It's a specialized language.  This is common for other technical and specialized groups: For example, air traffic controllers speaking to pilots on the radio will use terse, specific terms that others outside the domain don't necessarily recognize but which the two parties have learned to use together.  If your teams are cross-functional, you should learn the lingo common to your domain.

## They Need Discoverability Help
Codenames do not help with discoverability.  In the age of search, however, this point is lessened.  We often put important domain-related keywords next to content.  I'm all for including bylines next to codenames as a one-line explanation of what it is.  Using a combo like this when it makes sense will give you the best of both words: exact consistency via the codename and some discoverable verbiage via an accompanying byline.

## Abstractions for Future Change
A codename a variable name.  It's an abstraction.  It represents a project, team, codebase, or something else.  It hides the internals.  It will outlive your company's pivot from the original project scope and meaning so you can keep your codename even as your mission changes.  It usually doesn't leak the internal implementation details.

Codenames are singletons within the universe of your company.  No one else will have the same team name, repo name, or slack channel.  Codenames are the keys in the dictionary of values.

After you learn a codename once, when it's mentioned, you'll know what it is.  Nbd.

## They're All Around Us
Codenames are all around us, thankfully.  Who really wants to call Kleenex, "facial tissue", anyway?

You've heard of Python, React, maybe even [Chaos Monkey](https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey) (and check it out, they even have a 'What' and 'Why' in their readme!).  You've probably also heard of Microsoft SQL Server.  Blegh.  Doesn't that fill your soul with the emptiness of corporate sterility.  Though, there are codenames in their too, right?  "Microsoft".  "SQL" (one of those weird descriptive-things-turned-acronym).

So, embrace codenames.  You use them anyway.  It'll be more fun for most.  It'll bring color to your world.  It'll bring life and character to your team identity and the discussions you have about what you do.

What are some of your favorite codenames, and what are some of your favorite reasons for using them?

In Favor of Codenames

An estuary is where the sea meets the river.  Here, there is a mix of fresh water and salt water, sediment from the rivers and marine life from the sea.  The effects of both sea and river are seen in many ways.  It's a swirl -- there's no upstream or downstream.  It's considered to be one of the most nutrient-rich, productive ecosystems on the planet.  So really, who *wouldn't* want to make software in an estuary?



## The Traditional Production Flow

Here's a software production flow with disciplines and responsibilities represented:

1. Company leadership - develops a strategy and business model
2. Product management - identifies customers and products that could realize the business model
3. Design - visualizes information, interfaces, and flows for the product
4. Project management - manages a team in execution of production
5. Engineering - implements the design for the product
6. Quality assurance - verifies the correctness of the implementation
7. Operations - release and maintains the finished product

This is a simplified, constricted view -- a bit on purpose.  More or less, the traditional production flow is there.  It's very structured.  It feels like a factory assembly line.  I can imagine a lot of wall-throwing.  There are lots silos.  There's a lot of specialization.  The streams do not cross.  It does not feel like an estuary.

## No More Strangers, Upstream and Downstream

In the traditional production flow, there are specific orders and directions.  Arrows flow between neat boxes.  It might feel like a spotless production facility, clean and robotic.  It may even be really efficient.  But you likely have some uneasiness considering such a creative endeavor as software production being made in such an environment.

I think we should not think of ourselves as being in an upstream or downstream position, sitting somewhere in this traditional flow.  Rather, we are a full participant at any and all points.  We shouldn't think of our contributions in terms of our titles.  We should think of what we can offer of substance and then offer it.  In the estuary, things are messy, and we like it because of what we trust will be a better experience in the end.

It might be worth asking yourself if you really believe in the power of collaboration.  As in, are you really ready to participate in such a mix of people, ideas, and varied contributions?  It might be worth considering:

#### When previously downstream...

- Did it ever feel like you were expected to just do what you were told, completing your well-defined job on the assembly line?
- Did you ever lack an understanding of why you were making what you were being asked to make?

#### When downstream comes to the estuary...

- Do you feel comfortable deviating from and adjusting the plan?
- Are you ready to feel uncomfortable and contribute outside your wheelhouse?
- Are you ready to have your work critiqued and changed?

#### When previously upstream...

- Did you ever feel like you were the one mainly responsible for the thinking on the project?
- Did you ever feel like those downstream from you weren't being responsive enough to your ideas or instructions?
- Did you ever feel like you were in command and control mode all the time?

#### When upstream comes to the estuary...

- Are you ready for others to contribute to or push back on ideas that you create?
- Are you ready to relinquish some control on "your ideas"?
- Are you ready to stay engaged for the entirety of the project and care about the production experience end-to-end?

## Good People Required

Collaboration in the estuary isn't easy.  Work done here is done at a different level than work done on a pristine factory production floor.  It's more engaging, creative, demanding, evolving, and innovative.

Good people are required.  Self esteem from all is required.  Courage to potentially look stupid is required when you ask fundamental questions, question why, or challenge the status quo.  Courage to get something wrong means that you're contributing even if there's someone who might be "better" at a particular activity than you most of the time.  Humility is required to allow space for others to influence your work and defer to those who don't share your title or field of expertise.  Trust is required when others want to take part in something that you see as very important.

## The Medici Effect

The Medici Effect is named for the family living in Italy in the 14th century who had a great effect on the area and history.  They invited many experts from diverse disciplines and had the effect of making Florence, Italy a center of advancement and innovation, catapulting forward the Italian Renaissance.  The same effect of new and more ideas can be seen by us as we bring many disciplines together in a common cause.  What can we do to encourage our cross-functional teams really cross functions?

People have different tastes and exposures.  Associative thinking is making connections between different ideas.  Naturally, people of different backgrounds and trainings will be more able to make more and varied associations.  New, fun, and unusual combinations will result.

Steve Jobs often expressed that his passions lived at the intersection of the arts and technology.  That sounds like a cool estuary.  Now think of the intersection of the passions, knowledge, and abilities of entire teams really working together.

So swim in the estuary.  It's a great way to make software.  Don't think of your roles in terms of upstream and downstream disciplines.  You can have a rich, productive team and a better product by truly working together, not just being on the same team in name, location, or project.  Pay the price of the messiness of collaboration.  It's challenging, of course.  But who doesn't want to do great work with people of courage, humility, and trust?

Make software in the estuary, in a mix of disciplines, training, and collaboration

Make Software in the Estuary

The Agile method of software creation contains many principles of development that will help create good software.  Some of my most successful projects have had as a key feature an agile designer.  As Jobs said, design *is* how it works, and that means that to really deliver well in an agile environment, design *and* development have to be on the agile train together.



## K-man Keeps it Alive

I work with a fantastic designer, the one and only [Kendall Chadwick](http://www.composition3.com/).  He has many great qualities of an agile designer:

1. **He's available** - He lives with the cross-functional team.  He is there to participate in discussions.  It's not hard to get a hold of him, so answers to questions flow more freely.
2. **He listens** - He asks a lot of questions.  He's not stuffy about his design sense.  He realizes that many needs are represented in a project and product.  He attends discussion meetings not necessarily focused on design but on the details of the product or process.
3. **He's fully engaged** - He knows his task doesn't end when he clicks save in Photoshop.  He owns his designs and ideas all the way through the project, helping evolve them as we go. One of the most important things a software team member can do is remain fully engaged right up until the product ships.

## Agile Experience Design

I just finished a book called "[Agile Experience Design](http://www.amazon.com/Agile-Experience-Design-Designers-Continuous/dp/0321804813)" by Lindsay Ratcliffe and Marc McNeill.  I've read a fair bit on agile methods and currently live in a quasi-agile (hehe, let's actually call it mini-waterfalls) shop.  This book was intriguing as its authors are speaking to designers as they try to integrate better in an agile environment.

Of note was their Agile Design Manifesto:

Agile experience design is
Inclusive rather than elitist
Emergent with direction rather than up front
Integrated and collborative rather than handed over the fence
Considerate of customer, business, and technology needs rather than biased toward a single factor.

As a passing review:  The book won't provide too much that is new to someone familiar with agile.  It speaks in terms that I suppose are probably more well related to by designers.  It's a somewhat lengthy and dense book.  At times, it was hard to maintain reading momentum.  The book is beautiful -- perhaps it had some real designers laying it out?

## The Power of Design

It's amazing how much depends on solid design.  The design will define the users' experience with the software.  It will never not matter.  To a great design in a software product is a difficult thing.  Good people in the design discipline who are fully engaged in adapting to the changing landscape of software creation are invaluable.  Agile designers rock.  Find one and figure out how to get him on your project.

What have your best designers done to make great software on your teams?