Horizon 3 Development

The following post is not that directly concentrating on software development, but more in the early stage business development in B2B field. The learnings here seem to apply to domains that are a bit slow moving, like maritime and telecommunication. Maybe they can be applied more widely, but I have no first hand experience from others. Would be interesting to hear your thoughts if you have similar experiences from other business fields.

 McKinsey's three horizons is a framework for categorising businesses that are in different stages. 

Three Horizons

Horizon 1 (later H1) is a steady running mature business. One that is no longer growing much, but generates revenue steadily. Aim in this business is to maximize profitability. 

Horizon 2 (later H2) is growth business. It is not yet necessarily profitable, but the engine of growth has been found and there's a good product-market fit. Aim is to maximize the growth while there's still market left. At the later stage the goal is to make the business profitable a.k.a become H1 business.

Horizon 3 (later H3) is new business. Usually far from profitable, maybe even no customers at all. In this category useful metrics can be found from Lean Startup. In theory companies would like to minimize the time spent in H3 and skip this part with as little effort as possible and become an H2 business.

One can see similarities in the three horizons model and Technology adoption lifecycle model. The early adopters are willing to try new things and are willing to accept some 'children's deceases' in the products partially for the possible edge they can gain from the new innovation, partially for the sheer value of being seen as pioneers or forerunners.

The Problem in H3

The problem is that one cannot advance from H3 to H2 without really having a solid, scalable solution. H3 customers might be willing to have a proof of concepts, co-develop or co-create a solution together with the solution provider, but usually customers at later stages are expecting more maturity. And there are two options: you build the basis for scalability while you are still seeking the product market fit with your H3 business or you are late and will have huge delivery pains at the beginning of your H2 journey.

Needless to say, the problem is not that trivial to solve. H3 businesses are usually startups or internal startups with limited resources and budgets. Time is their biggest enemy, because time equals salaries and other operational expences and with a long time to market you probably lose the opportunity window and some competitor gets the customers. The time constraint is the reason companies do sub-optimal design choices that result in non-scalable architectures. Instead of taking the extra time to do things properly, companies take technical debt. And when you reach the growth phase it might be really difficult to find the time to pay the debt back.

What to Measure

In my experience (B2B software development in telecommunication field), the biggest bottleneck is not software, it's customer access. The metric I propose to follow in H3 phase is how deep customer relationship you have been able to develop.

• How many meetings you have had with different people in the customer organisation?
• What are the roles and ranks of persons you have been interacting with?
• How precise questions they have asked?
• How well have you been able to understand the customer's business and identify the customer's painpoints and problems?
• Are you able to provide them with something that helps them
  a) save money
  b) get more money
  c) help them do something they couldn't before

Deepening the customer relationship takes a lot of time. So does finding new customers. That's why testing your ideas might be really slow compared to working in B2C where you can more easily reach many customers (although I'm aware that it is nowadays really difficult to get consumers attention). Keep track of your progress and you are able to make decisions based on data!

Story about Software Lifecycle

This is a tale of a software lifecycle. It's fiction, but into what extent - I won't tell. It has been inspired by real events.

The Beginning 

About seven years ago a big consumer company wanted to renew their customer web portal. They didn't have own software development department, so they hired a team of external consultants for the task. Consultants came from two different companies. One was a smaller company with senior specialists. They did the architectural design. The other company was bigger. Already from the beginning the plan was that the bigger company would maintain the portal. Their developers were less senior, but the plan was that they would learn during the building phase.

The portal was a big success. It even won prices. When the intensive building period was over, the smaller consultancy company went to do other things and the other company began to maintain the portal. From now on I'll call them supplier (or team A).

For quite a few years everything went well. there was one person on the customer's side who was in close contact with the supplier. Supplier had a dedicated team and an architect/scrum master. New features were being built and things worked smoothly.

Maturity

Time passed. The customer relationship was so intense that at one point the architect needed to blow the whistle and take some time off. The person was replaced by another architect. The developers who were involved in the early phase were also in the early phase of their careers. And it is quite understandable that after a few years they wanted to do something else. Some changed roles, some went to work in other companies. If you are familiar with the job market in software industry today, you know that there are plenty of opportunities for skilled developers. People can easily vote with their feet. From maintenance point of view this is a real pain.

New people, who weren't familiar with the codebase, had a big struggle getting into productive mode. Without really rigorous attention to architectural quality, software tends to get more complex and more difficult to maintain. And when this is combined with staff turnover, the overall architectural picture gets lost.

Unfortunately, when there are no senior members in the technical staff, the balance between business and technological needs gets disturbed. Business grieves features and visible things. For the business, development speed (how many new features you get with x amount of money) and performance (how quickly things happen when you click) are relevant. What happens behind the scenes is not. The development team should speak out for the technological needs.

There's a dependency between development speed and codebase complexity. With low automated test coverage and high coupling, introducing new changes is always a potential source of unwanted regression. But for a person observing the development from the outside, this simply appears as slow and costly development that produces poor quality.

Back to the story. The customer didn't want to spend so much on the maintenance and so the supplier scaled down the size of the development team. Or the team size was kept about the same, but they were working for another customer. Organizational changes happened on both sides, with the customer and with the supplier.

The customer was unhappy with the development results and felt that they needed to take a tighter control. Team was heavily micromanaged. Daily scrum meetings turned into reporting and command and control sessions. The development team didn't like this and it accelerated the staff turnover even more.

The Renewal

The supplier had seen that it was getting very difficult to find people who were familiar with the technology. Without consulting the customer, they made a plan how to renew the portal to current technology. The benefit would be that there was much more skillful labor available in the job market and that the development speed would increase dramatically. The software architecture had deteriorated into a big ball of mud, but by applying certain changes, the user interface could be separated.

Due to the understandable lack of trust, the customer had hired an external consultant to aid them in technological decisions. Actually this person was also one of the people who originally participated in making of the original portal. Thus he knew it well and didn't see a need for changes. The supplier was trying to push the idea, but things got postponed. After six months, the supplier had hired a technology guru who could fluently demonstrate how the changes could be implemented. It changed the customer's mind. The plans were the same, they were just presented smoothly by a charismatic person.

When the renewal project finally got green light, the customer insisted that there would be a "dream team" working on it. There would be team members from the supplier (let's call them team A) and team members from the other smaller company (let's call them team B). Architect and scrum master were appointed from the smaller company and the customer acted as the project manager. Customer strongly demanded that the development should take place on site, in team B's premises. 

Before the actual development started, there were planning meetings where the plan was discussed, argued and fought over. Architect from team B questioned all design decisions that came from team A. During this period both the technology guru and the most senior developer in this new technology resigned. They had made their decisions about how fruitful the co-operation between the companies would be and didn't want to live in continuous argument.

Team A had had a team lead who was the main contact between the customer and the supplier. But for this project the customer said that they didn't need his services, since the customer's own representative was managing the project. Team A also had an architect, but he was stripped of his power, since the achitect was appointed from team B. During all this time, team A was still contractually responsible for the portal.

Teams didn't collaborate that well and the project fell into crisis. Even though there had been numerous planning sessions before the project started (that were mostly used for arguing), the plan regarding the user interface was still rather abstract. Stories had not been refined and for example the styleguide for the whole site was only one story. The work estimates were too small, since they were given by more senior people than who were left in the team.

The End

The team lead, who wasn't needed for guiding the project, resigned. This wasn't communicated with the customer. Soon the whole renewal project was cancelled. The customer made a decision that they would end their contract with team A and team B would maintain the portal in the future.

Learnings

There are probably quite a few things to learn from this and mistakes were made in many occasions. But here are at least some takeaways:

• Pay attention to technical quality. Feature development is important, but without proper code and architectural caretaking software will rot over time.
• Technologies have lifecycle too. I dare you: try to find COBOL or Smalltalk developers. Make a plan for renewal early enough.
• You catch more flies with honey. If you want people (your own employees or suppliers) to walk the extra mile, treat them properly. Collaborate rather than command.
• Or from the supplier perspective: if you are faced with a challenging customer relationship, add a buffer role into the interface. Some people might even enjoy the challenge.
• Don't pit suppliers against each other. Rather insist that they collaborate.

End note: Hopefully the story made you think. If you see events around you that resemble this story, be careful. It's never too late to change the direction ...until it's too late.

Photos by Ariel Besagar, chuttersnap, frank mckenna, Matt Botsford & Filip Mroz on Unsplash

Reaching the Next Level

When a new programmer starts writing code, s/he requires detailed specifications and clear requirements. The understanding is on a level "I need to get this piece of code working". There's not very much thought given on what happens outside this routine or how things are connected.

On the next level, the coder understands that the piece of code s/he's writing is a piece of a larger system. This system exists for some purpose, but the purpose isn't necessarily clear for the person. But generally s/he understands the system is important for the company and probably generates financial benefits (i.e. is sold).

Reaching the next level is already quite challenging. At this point the developer starts to think about the customers' business. How do the customers make their money? (...that can be then invested. Maybe in software. Maybe even on the solution you are developing...) And when you understand how the customers make money, you understand their priorities and needs. What is important for them and critical for their business.

There might be intermediate levels between the ones I mentioned, but I think this covers the basic steps. I'd encourage all developers to try to advance on these steps. The higher you are, the better you can fill your customers' needs and thus the more valuable you become. I'm not saying that code writing is easy. I'm simply saying that being able to write code AND understand the business is a tad harder and rare. Development on this path starts from understanding the user. 

(Sometimes the decision maker for software purchase is not the same as the user. Users might be only influencers in a complex network. But let's leave this out of scope for now. )