A quick story

I am one of the lucky people to actually be able to work for a company that tries to create its own software solution and become a software publisher. We are a sufficiently big company with enough resources to achieve this, but without being too burdened by the heavy corporate organization that some other companies have. The original founder is still the CEO and his little brother is the CTO. Family business is the best business after all.

The software our company is trying to create is a banking solution that adds many quality of life modern features for the clients of our clients. You should think “One time passwords authentication”, “Instant payments”, “Virtual banking cards” etc. In other words it is a modern digital banking for older banks and our main target clientele is Africa and the Middle East. I have previously worked for 2 french banks, and I am familiar with the security and quality requirements of such projects, so I was appointed as a technical leader and architecture consultant for one of the teams involved in the project. It was to put it one word enriching experience !

It did not come without a handful of challenges and hassles, however. One of the main issues of our company was that prior to this software solution we were simply a consultant company that was either lending resources to clients, or creating software for clients based on provided specification. We were clearly lacking the required experience and most importantly the mindset of a software publisher. As it turns out experience is the easier part of the two to acquire.

Our organization was very project centric with project managers, tech leads and development teams revolving around the idea of a project being anything from one month to one year. People could, (and they often did) jump from one to another to fill in missing positions, lend a helpful hand when some team was being behind schedule and so on. As soon as a project got “lighter” the PMs would reduce the staff and focus on other more urgent clients to optimise costs. This all worked very well in our “basic consultant” firm, but it turned out that this multi-project and “freely exchangeable resources” did not quite work for an actual product at the scale of our banking solution. We needed to take a big leap outside our comfort zone as managers and also as engineers. We needed to go to the next level.

All of this got me thinking that:

To create a product, one has to have a vision and goal and inspire a team of competent people to believe in those.

Having a vision and a goal can motivate people and make them believe in the project and also give them a sense of accomplishment that comes when working on a meaningful and impactful endeavour. Drawing from my 14 years of experience I would much rather prefer working with 1 motivated person than to work with 5 apathetic ones.

A common goal acts like a strong magnet on a plane of metallic particles (representing your team members). It pushes and orients all the particles along the lines of its magnetic field. This common attraction force (the goal) is what will harmonize and sum up the forces of each individual and propel the work to new levels. A positive side effect of having a well-focused and motivated team is that it becomes very attractive for developers. Nobody wants ot work on a trash project that is constantly behind schedule and where we are stuck with Java 6 and have zero test coverage.

Going back to our banking software solution, I initially had a team of 4 skillful technicians that over the course of couple of months became more and more interested in the end goal. They increasingly gained more and more interest in the Banking domain in the business value it provided to the end users. The team’s motivation also grew thanks to the fact that we worked using Domain Driven Design and Test Driven Development which were both new concepts for the members

Another source of motivation was the way we managed responsibilities: Previously developers at my company participated in classic projects and were used to a very hierarchical structure where they seldom took any decisions and responsibilities upon themselves. In fact many times developers would just follow instructions or even copy badly written code without ever questioning if it is correct or not. The same lack of questioning and criticism was also observed on the business side of things. When a task required to create a “new screen” with “couple of fields” people rarely asked what those are for and if it is logical to put them there or to even have them.

Our product’s team was different, however. Each member was encouraged to become a responsible and critical contributor whose opinion is as valid as the project’s architect’s. We often had technical discussions, we modeled new features together using diagrams and visual tools. We did mob reviews in order to show good and bad practices to all members. Developers who were more skillful would pass on knowledge to their peers and so on. Business rules were discussed between technical members and often questions were addressed to the business analysts.

Basically culture was being planted and slowly growing all the while our technicians were turning into crafters.

The downfall

Everything seemed to be heading in the right direction until the summer vacation period hit us. Many of the team members (including me) took long and well deserved august leaves. I was shocked to find out after my return that my whole team has been dismantled and assigned to various different projects and tasks. We fell victim of the old “project” oriented mindset that treated my colleagues as mere resources and numbers that could just be freely transferred from one job to another.

The seeds we have planted have been trampled and the future of our product looks grim to me now. dfd

To summarize

Becoming a software product publisher requires a mindset that is based on vision for what we want to achieve and a team that will believe in the common goal and reach it.

Special focus has to be put on the team itself, since culture of hardworking and motivation comes from the individuals in the team itself. To motivate team members we need to give them new and interesting things to learn, we need to give them responsibilities and give them voice.

We need to nurture cooperation but also critical point of view. We need to give them a terrain to exercise and to make errors. We need to provide a safety net and a helping hand to bring them up when they need it. These are in my opinion the very minimum requirements for a true software publisher to adopt in order to create anything meaningful.