How Chaos Kills Engineering Team Productivity

We chose technology as our career, and technology, with all its beauty, is complicated, messy, and changes with neck-breaking speed. We have hectic lives.

Many of us deal with this constant change by compartmentalizing our time and reducing number of interruptions to our workflows. This works extremely well, to a point.

As Engineers and Product Managers, we are passionate about products we are building. We want them to be useful, beautiful, fast and technologically sound. In broad strokes, engineers trust PMs to lead “useful and beautiful” efforts, while PMs trust engineers to take care of “fast and technologically sound” bits. And as we know, quality of this partnership can make or break any product, and single most assured way to ruin a product is to introduce chaos into this arrangement.

Chaos is not the same thing as change, changing requirements, or occasional fire fights with systems being down. Change is OK. Change is good. There are well-known methodologies that allow us to deal with change.

Too much chaos kills team productivity

Too much chaos is poisonous, it kills team productivity
Image by T0mek | Stock Free Images

Chaos is something different – it is activity that does not contribute to product goals. Some of it comes from not having clearly defined goals in the first place, and some of it comes from not having enough constraints, allowing us to lose focus and waste time on things that aren’t important. Trying to second-guess others and work around them is contributing to chaos. Not relying on data for insights is chaos. Scope creep and feature favoritism is chaos. Untidy task management practices are chaos. Breaking build all the time is chaos. Not looking at bugs every morning and missing a critical one is chaos. And chaos is poison.

As technologists, we can’t help it – we constantly think about how to make our products better. Even outside of the office. Even as we sleep. Engineers think about their code, PMs think of new ways to make users’ lives better. We think of a right time to bring back something that was discarded a while ago into “not the right time” bucket. We look at data and have heated discussions about what it represents and how to move forward. We argue about design and other things. That’s how we build beautiful, inspiring products that people love to use. But this is only possible when fundamentals are solid and we don’t have to constantly worry about small things or take care of constant “Sky is falling, let’s get moving” situations.

We still deal with small, everyday problems that come up from time to time, this is unavoidable.  However, when they are relentless and omnipresent with increasing volume, they begin to occupy our mind, and forward progress on the project is lost: death by thousand cuts. All because of chaos.

So, how can we deal with this problem? By introducing culture of autonomy and building cohesive teams that like working with each other. We need to hire best people and let them work their magic, welcome and give honest feedback, don’t hesitate to ask for help, and above all, trust our team mates to have our back. Here are some good things that I’ve seen and practiced in many places, and things we live by at Wetpaint:

  • Our PMs take time to look at the data and say “no” to their understandable desires to cram as many features as possible into the product.
  • Our PMs don’t dictate how to implement features, but they are technically savvy and of course have an opinion. So they ask engineers to educate them about why certain things are implemented this way and what were the alternatives.
  • Our engineers watch builds like hawks and everybody obsesses about automation, unit tests and code coverage.
  • Our Test Team can openly ask others to help verify and close down open tasks as soon as sprint begins. Our Dev and PM team members gladly volunteer their time to help out.  When Test Team feels that our new features lack quality, they speak up and we, slightly embarrassed, fix things.
  • Our technical team can openly request for a feature to be cut from current sprint because interruptions came in or other features were under-estimated. PMs are happy to discuss alternatives and move things around. In return, Dev team becomes accountable for screw-ups with estimates.
  • Our prior decisions are reevaluated and bad ideas are killed in cold blood given new evidence in the form of data.

Our single most precious gift to our project partners is shielding them from chaos and letting them think. And work. We bet our careers on each other, so we need to help make each other successful. And we don’t have much hope for an emergence effect to arise from chaos, because our team is not an ant colony.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s