Category: Project Management

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.

Advertisements

Developer-Driven Is Not A Panacea

Idea of developer-driven or developer-centric organizations is being actively discuss lately thanks to the likes of Facebook. Some people, mostly developers, love it for its freedom and lack of heavy processes. I love it too – to a point. I believe in its usefulness while a product is being conceived, while it is in the prototype or even in a rapid growth stage, while creators of the product have neither rich user data nor significant market penetration. In these situations, product team does not have any data to guide their development direction, and therefore tries to probe with multiple features.  However, there are obvious downfalls even at this stage:

  • Developing cool new features before core functionality is in place is meaningless at best and distracting you from your mission at worst
  • Developers left to their own devices tend to over-engineer most of the features and create flexible frameworks for everything, even trivial things
  • Most developers suffer from NIH syndrome, which leads to everything being written at least twice if not more

Let’s assume now that the product is becoming successful. It is growing in size, gaining more and more fans and/or more and more revenue. At this stage blindly following Developer-Driven process can get you into even more trouble.

Business:

  • New features developers chose to implement may not be helping your product
  • New features developers chose to implement may not be what your users want most or want at all
  • New features developers chose to implement may be cannibalizing or hurting other important revenue-generating features
  • New features your developers chose to implement may not be the most profitable

Technical:

  • Duplicated code grows all over the place and when new features are being introduced, raging debates start about what to use and what to retire and why. There is no consensus, so different factions continue to use and improve their code of choice ignoring others.
  • Set of home-grown tools emerges that mostly work, but nobody is completely happy with them, so from time to time somebody creates new tools that do almost the same thing but “better”. Maintenance costs continue to grow…
  • Documentation becomes so far outdated that knowledge about overall system architecture is priceless and can only be found with people who have been on the team since its inception.
  • Build takes forever because of the amount of code. Configuration is mind-boggling because it is hard to configure dozens of “data-driven” frameworks to actually do what users want.

I could continue this list for a while, you know…

So what’s the solution? In my mind, it is very simple – provide a system of lightweight checks and balances that will keep the good and eliminate the bad:

  1. Get a good PM on the team. Give them broad authority to influence and little authority to dictate. Make them work together with Dev and Test teams. Good PMs hate process just as much as Developers, and they will provide an excellent balance against cowboy development and over-engineering problems. More importantly, this move will compliment technology focus of Dev-driven product with razor-sharp customer focus.
  2. Get architects to actually do their job. Architects who design how features should work should also be capable enough to quickly code up reusable and complicated components and provide actionable feedback and oversight to other team members. However, architects who sit in an ivory tower are just as bad for the product as no architecture at all. Therefore, getting seasoned developers to become architects (i.e. experts) on the product is a better way to go, I think.
  3. Use experimentation in addition to (or instead of) traditional marketing research. Once a product get beyond initial rollout stages and starts gaining steam, the only way to grow effectively is to use data, quickly try out new features, measure, and if ideas fail (most of them do, by the way) – fail early and get out.
  4. Watch over the buildavoid having dedicated build team, keep number of branches to a minimum, make developers responsible for integrating code. This will serve as a forcing function to have a reasonable component architecture and inject enough engineering discipline.
  5. Do not subscribe to “good developers write bug free code” myth, invest in test infrastructure, measure test coverage. Once again, placing test responsibility with Developers can be used as a forcing function to inject stability and reason into your code base.

In short, maintain user-centric focus, keep it simple as much as possible, use real data, trust but verify.

Symptoms of Sick Projects

I recently got a new project assignment at work and started thinking about levels of uncertainty that exists in every software project. It’s been in the back of my mind a lot lately as I am trying to figure out what is that we are trying to solve, how our new project is going to work, what do we need to do technically and organizationally and how can I make it bring value in the context of larger division and even the company.

First, I know that uncertainty is inevitable and it is basically good. Without uncertainty, there won’t be any room for initiative, innovation, and risk taking.  However, too much uncertainty typically results from other bad symptoms that bring enough distraction to make me worry and question the project’s validity.  I’ve been trying to classify these most telling symptoms, and find ways to treat them. I am purposely staying away from management styles, social dynamics, reporting hierarchies on a project or even the project architecture, though these can have plenty of problems as well.  I am thinking about basic, fundamental issues that interfere with way to approach all technology projects: find what the problem is and proceed to create a technology that will solve it.

Here is what I could come up with, and I’ve been:

The NASA Pen Project

This a project where everybody assumes that problem at hand can only be solved with a new technology and diligently and stubbornly tries to come up with such a solution. Anybody who dares to suggest that the problem can be solved by using an existing technology (potentially mixed with some skillful organization changes) is immediately dismissed because… Nobody can tell why.  This creates a situation when people who are actually doing the work can’t fathom why or how their work might be useful because they all know that existing technology is just as good or even better. This uncertainty over the project’s fate causes quality issues, not to mention the team morale, because people think that their time and their work is being wasted. The only effective way I found to resolve this is to bring data to compare the projected costs of developing and implementing new technology with likely much lower costs of using existing tools to solve the problem and to propose a set of organization changes that will remove existing barriers.

The New Bicycle Project

This is classic and rampant NIH symptom. Because of political pressure within an organization or because of artificial competition and meaningless disagreements between “big wigs” in multiple divisions, an emerging or even an existing technology is reinvented with various degrees of success over and over and over again. Everybody has fun working on the cool new thing on their own, but company resources needed to solve the same problem are doubled or tripled. Nothing or very little is shared, teams hate each other, team management tries to outsmart their peers in the eyes of executives, and in the end nobody achieves the level of success they could have achieved had they worked together. Two-pronged attack might help here, I think: relentless pressure from the bottom (people demanding increased reuse and sharing of products already under way) and smart management from the top (timely executive decisions to combine or eliminate duplicate efforts).

The Emperor’s New Clothes Project

This is hysterical to observe from the outside but it is very painful for the people involved. This is a project where everybody seems to know and understand what the real problem is, but instead of solving it directly, team seems to be busy creating technology to work around it. After a few of those, a technological monstrosity/hodge-podge emerges around the original problem at hand, and it is usually unmanageable, unmaintainable, does not make things better at all, and is very costly. Once again, this could be due to politics within an organization or due to entrenched and seemingly unsolvable nature of the main problem (which sometimes is not technological at all). But until somebody has the guts to become that child who yelled that the emperor is naked, things will continue to be very difficult and the original problem will become even more entrenched because now there is a large investment into this pseudo-solution.

Go I Know Not Whither and Fetch I Know Not What Project

This is uncertainty squared – nobody seems to know what the problem is or was to begin with, nobody seems to understand why an existing solution, if any, is inadequate, and nobody can describe in concrete terms their vision for the new solution. But the plans are already approved, money allocated, and your team is on the hook to deliver… something. The solution likely lies in peeling the onion and asking a lot of questions from a lot of people. Start challenging every assumption to see how sure people are that there is a problem. Find out its exact nature to avoid building a space pen. Make sure you reuse existing bicycles. Call the emperor naked if you have to. Do whatever you have to to define “whither” and “what”.  And if you can’t make any headway, be aware that there is a chance that you got this fairy tale project because somebody wanted to remove you from the picture for a while or permanently…

Am I being too negative? Well, I don’t think so – I am an optimist. This is why I am doing my very best to prevent my new project from becoming one of these and I am beginning to like this challenge more and more.

Happy New Year!