Why optimize problems that shouldn’t exist?

If you repeatedly punch yourself in the face, you’d probably start thinking about taking something to manage the pain. What if instead you stopped punching yourself in the face?

If you have 56 open pull requests, you may implore your developers to review them sooner, or you may pick designated developers to review PRs all day on certain days. What if instead you didn’t push peer review off to an after-the-fact activity?

Your feature work may require hopping between teams to get done, and so you may reach for multi-team planning meetings and complicated processes like SAFe to manage those dependencies. What if instead you reorganized so that everyone needed to accomplish the work was on the same team and didn’t have competing interests and schedules?

Look, I’m not saying any of this is easy (though there are ways), and I’m sure this email seems pretty glib. All I’m saying is that before you seek to optimize a problem, think about whether or not the problem need exist. You typically have to keep managing problems, and that’s effort you don’t get to spend doing value-add work.

It’s worth spending some time to see if the whole thing can be eliminated.

wip 

Like this message? I send out a short email each day to help software development leaders build organizations the deliver value. Join us!


Get the book!

Ready to learn how to build an autonomous, event-sourced microservices-based system? Practical Microservices is the hands-on guidance you've been looking for.

Roll up your sleeves and get ready to build Video Tutorials, the next-gen web-based learning platform. You'll build it as a collection of loosely-coupled autonomous services, developing a message store interface along the way.

When you're done, you'll be ready to contribute to microservices-based projects.

In ebook or in print.