How do you deal with work that is challenging, time-consuming, or risky?

If something is hard, the typical approach to reducing the pain is to do the activity at hand less often. The logic is, this thing should be done as little as possible so it consumes fewer resources or exposes us to less risk. I see this option being used often in software development.

However, I think that a generally more effective – but counter-intuitive – option is to do difficult things more often.

DevOps

One of my favorite practical examples of this is modern development and deployment of software products. In some organizations, deploys happen monthly, quarterly, or annually. The pain of manually testing for regressions and getting all of the pieces aligned and documentation updated just makes it too difficult to do often. We wouldn’t want to put out a product that is less than perfect, so let’s make sure that it works correctly before releasing. And who can get it to build and deploy correctly? We need three engineers to take three hours to deploy the changes and make sure that everything works as expected.

The costs, however, are high. Features are shipped in batches instead of when they are finished. Integration is done at the end, and manually tested. Customers wait months for bug fixes. When there is a major bug in the final release, instead of being constrained to a small set of changes to fix it, the technical team might need to stay up late looking through weeks worth of changes.

The problem might be solved another way. Instead of considering how long we can defer the pain, what if we try to take the pain early and as often as possible? What if we deploy all code that has been peer reviewed and accepted at the end of every week? What if we did the same every day? What if we did it after every merged pull request? What would need to change to make deploying multiple times per day possible?

With the weekly deployment example, the team would likely quickly document the deployment procedure to ensure that it could be done reliably each week by anyone on the team. They might invest resources to start automating small parts of the deployment process to reduce some of the need for documentation and to make the process less brittle. Maybe with several hours of effort, the team gets the deployment time down to one engineer taking two hours.

Then, they move on to the next challenge, deploying what is believed to be the best code available every day. I have certainly heard opposition to this strategy. Well, we need time to test out the code. We need to make sure it is ready for prime time. But I would ask: when are you more sure about something being right than when you just worked on it? When could you fix any issues quickly, now, or a week or month from now? If you delay today, how will you be more sure tomorrow?

When the team incrementally writes automated tests for the important software they write, we enable faster testing. Instead of manually testing the software weekly or monthly, we can run all of the tests every time we make a change. Then we immediately know whether we’ve changed something for the worse and revert the change. The more our tests are automatic, the higher quality our product and the more confidently we can deploy, which promotes our changes to customers faster.

Reviewing Code

Taking the pain early on reviewing code is another example. It is possible to batch up pull request review to try to make reviewing them more “efficient”, but that results in pull requests growing ever larger. Instead, by continuously quickly reviewing code, we actually save review time and encourage higher quality work.

Someone at a recent Indy.rb meetup mentioned that pairing can replace code review. I think this illustrates that increasing the feedback loop can actually replace or remove a part of the process that we previously considered time-consuming or difficult.

Giving Feedback

Giving performance feedback and guidance can be a struggle. One approach is to do it less often. Maybe move the monthly one-on-ones to quarterly, or our semi-annual evaluation to yearly.

But giving feedback less often just exacerbates the problem. Now we move from a less formal and more open process to one where people feel guarded. When we couple feedback with discussion of salary changes, this also results in fearful feelings.

Instead, by giving feedback more quickly, we encourage people to bring up problems when they encounter them and work through them together. It results in feeling more connection with each other. In the increasingly virtual world we live in, getting face-to-face time is an important investment.

One example that I can give is from our one-on-one process. We had a great policy of weekly tactical one-on-ones at Haven to talk about what was on our minds and how we can keep improving as individuals and as a company. This periodic check-in was really helpful to stay engaged.

We had an intern that was part-time because he is still in school. Initially I thought, “OK, half the time, so he and his mentor should do these every two weeks, right?” But then I thought of this principle, and thought: “if giving feedback and making sure people are happy is important to us, why not continue doing it weekly and then we can make sure that everyone is happy and learning as quickly as possible?” Twice as much “overhead”, but we get a much more engaging experience, give the intern the most learning, and give the company a good way to clarify direction. It seemed to be a good arrangement, and lined up with the rest of the company’s cadence as well.

Aside: daily or weekly for meetings works much better than every-other-day or bi-weekly, purely for psychological reasons. Further aside: the word “efficient” typically misleads people into suboptimization. It is extremely rare that having a quality conversation with someone about the work they are doing is “overhead” or non-value adding.

One idea we’ve had and would like to explore in the future are continuous feedback mechanisms. How can we automatically ask small questions on an ongoing basis to pull feedback rather than push it in large batches at feedback meeting time? Could this lead to leading indicators of issues instead of learning after the fact?

Other Categories

Is hiring a challenge? What if you were always in hiring mode? What would you need to change about your processes, perspectives, or prospects to make continuous hiring feasible? Would the result be a competitive advantage for your organization?

Exercise hard? What if you did it every day instead of every week? What about continuous exercise, where your computer randomly shouts “do 10 push-ups!” a few times per week? :)

Hate dancing? What if you took classes and got pretty good at one style of dancing? There is certainly something to be said for doing a lot to get past the suck threshold and then you actually enjoy it more. Any skill is like this. By doing it more, you get better at it and will enjoy it, which will make you want to do it more, so you continue to get better at it. Taking 10 classes in a month is more effective than ten classes in a year.

Take a minute right now to think about the things you most dread, are least fun, or generally are very time-consuming in work and life and think about how you might actually do some of them more often to make your life better.

Hedging

“More” or “less” is an oversimplification of the options and the trade-offs (did you spot the dichotomy?) Sometimes it does make sense to do things with less frequency. If you are in heavily regulated environment or releasing an app in an ecosystem with long review cycles, there may not be a way to do something more often. But the thought remains the same, how can we possibly it more often, and will that reduce the overall pain?

Hat tip to Kyle Shipley for bringing up this concept in past conversations. And apparently a bunch of other people also internalize this concept, based on the comments on the Twitter post of this article:

New on my blog! If Something Is Hard, Do It More Often http://t.co/CUbMug1oF6

— Anthony Panozzo (@panozzaj) September 1, 2015