June 29, 2017

Perish or Survive, or being Efficient vs being Effective


In IT we are not dealing with commodities, although it may seem to be that way, it isn't. Software development is a matter of engineering and not producing. Hence efficiency is not the focus you want to have as a business, instead you want to be more effective. Effectiveness is what is required to be adaptable to a market where changing one solution for another is becoming increasingly trivial. Open standards and the democratisation of IT resources because of the cloud ensure users that the risk of vendor lock-in is negligible. This requires an organisation to be able to adapt to the wishes and needs of its users, not being able to churn out loads and loads of software. Therefore in order not to perish in today's world, effectiveness is needed not efficiency. To thrive in such a world you'll need to be efficient at being effective.

Over the past couple of weeks I had some discussions with a colleague of mine. He's an architect as well and we're in similar situations where we are asked to coach teams and organisations to transition from a traditional setup into an agile setup.

Last week or I was asked by this colleague if I could co-review a report one of his clients wrote that was all about a transition from a legacy waterfall organised project into an agile project. What struck me, and fortunately my colleague concurred, is that the main motivation for this transition was to become a more efficient organisation. Which in fact is an ill-chosen motive.

Let's back-up a bit and consider two similar words that are fundamentally different in meaning: Efficient vs Effective. Traditionally, in process engineering we're striving to become more efficient. The whole idea is that by becoming more efficient, you can produce more and hence benefit from economies of scale and the likes. It's a process improvement adagio that's been around since long. It is also a motive for improvement that leads to silo's, specialised silo's. And here you already see the first sign of why efficiency is wrong when it comes to agile methods. In an agile world we want to get rid of silo's not create them.
So where's the effectiveness coming into play? Well, that's actually rather evident. In order to be agile, you need to be able to turn on a dime at a moment's notice. Which means that whatever you do, you need to be very effective when you do it.

The point here is, that Efficiency focuses on minimising cost by spending as little as possible on the creation of a product on a per product basis. By doing so, the cost of the product reduces and the profit margin per product increases. Typically this is achieved by leveraging specific capacity for specialised tasks. Effectiveness on the other hand focuses on maximising revenue, by spending as much time on value creation by doing what is needed. By doing so, the costs of the product increases but the relevance of the product for the consumer and therefore its value increases more and this has a positive effect on profit. Typically communication lines between dependent parties in a process are shortened by introducing multi-disciplinary teams.

It makes sense to focus on efficiency when you need to produce large quantities of some product, and you know that there's no to hardly any need for diversification. For example when you produce nuts and matching bolts, it makes sense to produce them at the lowest cost possible. Efficiency is for growing your market share with a commodity product. Instead, when you need to grow your business by growing your market instead of your market share. Or where your product is anything but a commodity, efficiency is killing. You'll perish, eventually.

Considering you're in IT, that's most likely why you're reading my blog, your product is anything but a commodity, even when it's a commodity. And growth, especially sustainable growth, is accomplished by growing your market, not your market share. So drop the urge to be more efficient and become more effective.

Point is that you need to be able to adapt to your market. Your user, not even your customer, will initially not have a clue what she needs. Hey, that's why you've adopted agile principles. But once she is up to speed on what her demands are, she'll be more and more demanding. Hence you need to be able to adapt, continuously. And no, it's not adaptation in the IT department either, but your business needs to be able to adapt. And there's the catch, or rather your answer. Because by becoming more efficient in your production line, i.e. your IT department, your business will become less agile. This is because you've optimised the production process and software development is an engineering process. And before you ask, software development is a case of engineering and not producing. That, by the way, is the reason why off-shoring and out-sourcing is so cumbersome.

So you want to be able to adapt your product, you being the Product Owner, as the one being accountable for the company's profit (or loss). Or at least partially. So you want to be able to adapt your product, so it complies with the wishes and definitely the needs of your users. This requires a team that's effective, not a team that's efficient. Meaning that you want a team that can do pretty much everything needed to adapt the product autonomously. Not a several teams that can do specific jobs very efficiently.

This is why you need to focus on effectiveness instead of efficiency when you want to make the move to agile. And I'm convinced that you need to make the move to agile ways in order to survive and not to perish in this world that is changing faster every day. Organisations that are lean, nimble and agile are the ones that will survive in the long run, where the length of long is becoming shorter every day.

So where does this leave the architect in all of this? At the centre of agility. The architect is the one that is perfectly positioned to define what kind of competencies, qualities and personalities are needed to make a team into an effective team. The architect is also the person that is in a position to ensure that a product is adaptable. A product's adaptability and therefore a business' agility is determined by its architecture and the product team's perfectly equipped to make it so. More importantly though, the architect is in a rather unique position to not only ensure that product teams are effective and business becomes agile, but also be very efficient at this. Only when you architecture is in order and your team is effective will you be ready to improve on your efficiency, allowing you to not only survive but actually thrive.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contact-list. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.