≡ Menu
Pawel Brodzinski on Software Project Management

Change and Consistency: A Balancing Act

For quite a few years already I’m lucky enough to have significant impact on a company, or a part of it, I work for. Being involved in strategy creation and then being a part of execution of this strategy gives pretty nice perspective – you know why some decisions are made and then you see what works, what doesn’t and what you do about that.

It’s no different now and since we’re pretty close to start-up-like organization there are way less strings attached than usual. If I had to point strongest drivers for what we do here it would be change and consistency. These two are always somewhere in a back of my head. And no, they aren’t mutually exclusive.

The funny thing is I’ve already pointed both of them (see links above) as critical factors of success.

Change is brought by the market itself. What you start with is wrong. Plan for it. Plan for change. It isn’t any different here. When our initial ideas appear to be flawed we either adjust them or abandon them. We look for opportunities which sometimes completely change our playground.

Consistency, on the other hand, is needed if you want to achieve any measurable success. It’s fine to switch business ideas two times a day. It’s a deadly threat to allow this approach to rule the development. Your builders can’t switch focus 3 times a week in order to satisfy another great idea which will end up in trash in a week or so. Priorities can change but with no consistency along the way you’ll end up with everything started and nothing completed, which is such a nice description of failure.

The key thing is to balance these two. On one hand you shall not allow to miss opportunities because of some code you actually work on, on the other you can’t kill you production cycle just because there are so many great ideas out there.

I believe we deal with this balancing act pretty well.

We discuss new ideas very often but almost none of them get instantly into production.
You can say it’s a kind of context switching, but at least it’s limited to design or architectural discussions. This builds confidence while we talk with customers because we understand how we’re going to build what we’re talking about. At the same time, hopefully, this approach limits unnecessary job being done as things tend to change several times more before a target design is ready.

We finish what we started.
There’s no excuse for job being started and not being finished. Even when something becomes less important because of late change of business priorities we bring the code to “shippable” quality and then move on to the next most important thing on the list. This limits the worst kind of work-in-progress, one which would never be finished because it has so crappy that even when you needed this code once more you’d start writing it from a scratch.

We carefully set coarse-grained development plans.
We incorporate as much features as possible into existing product instead of building quick-shot applications which are thrown away two months after creation. Specific features which are to be added changes a lot and backlog is rather capacious but in terms of product management we have no revolution – it’s a constant process of evolving to cover actual needs.

And yes, sometimes when we come back from one or another business meeting there’s a very strong incentive to call “hey, stop doing what you do now, here’s this great new idea which we earn zillions dollars on” but I’m happy we organized things in a way which basically doesn’t allow to do that.

in: software business

0 comments… add one

Leave a Comment