Categories
Coaching Leadership

Fix Small Problems

It’s too easy to get caught up in the big issues, things that are intractable at first glance and that feel like they an never get better.

If you stop and look a little closer, you will find that there’s something that you can do to improve things. It might be a very small step, and it might not feel worth doing, but fixing something small is a great start.

It changes your mindset, you become powerful rather than powerless. It starts to build momentum, powering up the Flywheel of Change. It also marks you out as someone who “gets things done” rather than complaining about the way things are.

Even if you can’t find something that’s tied up to the big problems, there’s bound to be something that’s small but annoying to you and your teams. Set aside a few hours and get it sorted out. Cancel a recurring meeting if it no longer provides value. Fix some spelling mistakes in documentation. Make a template for a weekly update. Delete some tickets that you know will never get done.

Once you’ve started, it’s easier to keep going. You’ll be able to break down some of those tougher problems and make good progress, and each change you’ve made will improve the overall state of play for everyone, so each one is worth doing.

Don’t complain, don’t let overwhelm win, go out and fix those small problems!

Categories
Coaching Leadership

Dont Innovate to Hit the Date

When we’re building software, we’re creating something new. It’s exploratory, it’s uncertain and it might not work.

Often in the world beyond the tech teams, we think we’re just following a plan to build to a schedule.

The mismatch between the two causes approximately all of the conflict in a software focused organisation.

We use a lot of techniques to bridge the gap, all loosely badged under the Agile heading. Basically, we always endeavour to have working, shippable software that we can show to people, and we always complete the most important things first. That means we can launch the software on any given day, and it’ll have the most vital pieces.

Engineering have the power to solve problems, stakeholders have the power to decide if their problems are solved enough or not. So when we work in this way, everyone gets their key pain points addressed, and everyone is happy.

This works best when we’re working in an incremental problem space, building out a product that provides benefits with some features, and will provide more as those features are added to and refined.

Sometimes we’re not in that space. Instead we’ve got to hit a fixed date. We know what we need to and we know when we need to do it by. When the date is truly fixed, it’s usually due to some sort of regulation, so there’s the added spice of needing to be compliant with some law or face a penalty.

In this scenario, we need to strip back some of our exploratory instincts and move more towards the schedule model. Nevertheless, we must also keep in focus those agile principles of solving the most important problems with always shippable software.

Rather than innovating, we make sure we hit the date:

  • Pick known technologies
  • Extend solutions that work today rather than starting from scratch.
  • Choose the approach that has least work
  • Sequence your plan to get to done sooner
  • Allocate additional resources

When we know what we need to do, we are following a map along a known route rather than exploring the territory.

Measure your progress, correct your course when needed, and don’t innovate to hit the date.