Practical examples

A wrong example to customer first

October 29, 2017

I’ve already wrote briefly about how Brazil are still not used to think on customer first, and how different maturity-level companies face digital transformation. Now, one step beyond the theory, I’m sharing one WRONG example of customer first thinking.


Why we reached the problem

This specific and short example is a very technical one, since it’s an IT issue. But the software development team maturity is affecting directly the problems they are facing right now.

Just to start, I want to rewind a bit and present an infographic about software development maturity evolution. From “traditional” methods down to modern agile, where the customer first mindset is very strong. I can say the guys from this example are leaving waterfall and are reaching the SCRUM by the book as suggested on the infographic “Software development maturity evolution brief story“.


The problem
  1. It’s a company of investments advices. This is the most important system for the company. It gathers all the data to be processed sometime in the future. If this system stops working, the predictions stop being calculated and we have nothing to advice (information to sell).
  2. Right now there’s a huge load capacity issue, that makes it stop working from time to time and the company stops predicting. It makes them lose a┬álot of money almost weekly.
  3. It’s currently impossible to optimize databases and machine hardware for now. There’s a need for an architectural deep change.
  4. So, there’s not a short-term solution to the problem.

Then we have a crisis established. The company loses a lot of money weekly because it’s receiving more data that it can support. It’s a very clear IT planning problem. Nothing short-term can be done to solve it, and all the solutions are long-term. The first things to solve the problem needs 4~6 weeks to be done.


Why it happened and why the company is not thinking customer first

But why did it reach this point? It’s related to the development team maturity. They lack of practices of architecture, scalability, stability, resilience, failure prevention, failure tracking, log tracking, etc.

All of those listed above are just consequences. The real motivation is the lack of investment on the software production process. Like the example on the articles listed above, the mindset is defined to think about the product, which are the investments advices. The majority of the investments of the company go straight to people who look at the market, compare the data this system generates, and make the advices better and better. Cool uh?

But the real product here is the information this system processes and the insights it generates itself. There must be a half term of the company investment planning between the advices itself (business area) and the IT modernization (IT area). The bigger is the investment on the IT, in this case, the lower will be the need for investment on the business area, since the system already predicts that data the analysts are checking. If the development team maturity were located at the Lean/DevOps step, or at least XP, probably this problem wouldn’t have reachd this point.


What to do now

Of course, an express contract with a company to help them to make the architecture changes as fast as possible is the first thing to seek. But the long term solution is to fix the investment target. The money must have a better destination. The company board must stop seeing the IT area as a support and make it the area that holds the whole company.

You Might Also Like

No Comments

Leave a Reply