How I learned that what matters to me is using my skills to write meaningful software with good people - not what legal entity ultimately owns the product.
On 15th May 2019, 8 months ago as of this writing, I started in a new job as a software developer at Nitor, a Helsinki-based software consultant company with several customers in the capital area. The move ended my 12-year long stay at Napa, a company making software for ship design and operation. But more significantly, the move marked a change from my long career in product companies (LabSystems, Nokia and Napa) that develop and sell their own products to consultant world where Nitor is not developing any own products but we instead work on various customer-projects helping other companies to develop software.
"I would never work as a consultant"
When I transitioned in year 2000 from academic career in Molecular Physics to job in software industry, I thought I would never work in a consulting company. Consultant companies, at least in my mind, had a bad rap. I had heard that software consultants were considered second class citizens in the customer companies, looked down compared to the real in-house developers. I thought that consultants got the shitty jobs, working on gigantic never-ending death march projects with Cobol and Java 1.1 and were kicked out first when things took a turn for the worse.
Furthermore, I felt on an emotional level that I should work in a product company so that I can feel ownership of the product that we are making. As a passionate person, I wanted to feel I am working on my and our product instead of just helping in someone else's stuff.
During the years after 2000 my prejudices towards software consultant companies were slowly softening. I become to understand that not all consultant companies are alike, that alongside the traditional hierarchical dinosaurs like IBM, Accenture and Tieto, a new generation of agile, flat, modern companies with radically different culture was growing. Around 2015 I started to follow more closely and attend events arranged by the new nimble Helsinki companies like Reaktor, Futurice, Siili, Solita, Gofore, Houston - and Nitor. Some of my friends moved to work in these companies and seemed to be happy with that.
Eye-opening experiences
I am glad now that my attitudes had been warming up enough this spring that I was open-minded to get into discussions with Nitor about possible job there. But only in the months after joining Nitor I have been seeing how wrong it would be to apply my original prejudices to this company. While my experience as a consultant is still limited to few months and single customer project, there are already some clear findings to acknowledge.
First, the level of respect, I now see that consultants can be not only on the same level as their in-house counterparts, but often enjoy a higher level of respect. It turns out that developers of any origin are respected by their customers and peers when they do their job well: when they are productive, excel in tech and soft skills and write rapidly great code that implements great innovative applications that exceed customers expectations. One starts to wonder that perhaps the consultant-companies and consultants of the olden days got a bad rap partly because there were too many cases there they simply did not do such a good job? It now seems that company like Nitor that employs great developers and pursuits to keep them on the top in competence has possibility for continued respect both on individual and company level.
Regarding the level of job-security and propensity of being fired, my earlier assumptions have been even more overturned. I am now aware of several cases, including my current customer company, where a customer has been rather laying off their in-house people than their Nitor consultants. Part of the reason seems to be simply in the good experience the customer has had with the quality and productivity of Nitor-developers.
Another reason to prefer consultants seems to arise from the Finland's strict labour laws that make it more difficult for a company to fire their own employees. Paradoxically these laws that aim to prevent companies from firing their own employees makes the company as a precaution to do exactly that. By having more consultants rather than in-house developers work on their projects, they have later more flexibility if their needs change. And for a consultant, even if they are dismissed from a project, the result is much less drastic than a person fired from a product-company: far from becoming unemployed, the consultant simply moves to another customers project.
The business model of consultant companies also seems to be more stable, somewhat protecting them from layoffs. Because software duplication is free, a successful software product company can for a while make immense profits. But such companies can also quickly turn into red if the success of the product evaporates. In my earlier years at Nokia and Napa, both companies were first very profitable, but later experienced periods of financial losses leading to layoffs and general souring of atmosphere. Consultant company that is selling hours of work can never make immense profits but their bottom line is also not so vulnerable on the success of single products when they have multiple customers.
How about consultants having to work on the most shitty projects? I am sure this can also happen sometimes, but now it is clear that in these modern companies the norm is the exact opposite. Typically - as well as factually in my current project - a team of consultants is tasked with the most challenging (meaning most interesting, creative and fun) projects that produce novel software applications with the latest and greatest technologies. In my case we are working on a green-field project to create interactive self-service kiosk for finnish Post. We enjoy a great deal of responsibility and freedom in our choices of architecture and technologies and I was able to choose the immensely productive ClojureScript / Re-Frame combo for the front-end while we use AWS Lambdas for integrating to the existing backend-services of the customer. The in-house developer team of our customer, on the other hand, is tasked on average with less challenging and innovative work of maintaining and bug-fixing of their existing production applications using older technologies.
The impotance of good colleagues
Good colleagues matter. Not only in gaining the respect of customers through good performance, but also simply as enjoyable and interesting human beings to spend your days with. It seems to me now, that some of the best tech people tend to gravitate to these next-generation consulting companies. This "good" should not be taken too narrowly to mean knowledge, skills and intelligence - while those are also important, the real kick that comes with these people is their character: Great unique humans with charm, personality, passion and stories to tell. Perhaps it is not just a coincidence that highly skilled people tend to also be quirky and colourful in interesting and delightful ways.
With Nitor colleagues on our trip to Italy in September
Of course it is also relative question who are "good colleagues" for any particular person. So perhaps it is more accurate to talk of "culture match": that the best colleagues for someone are the ones that are like-minded with similar values and culture expectations. When a company succeeds in bringing together people who are compatible in this way, it forsters creation of valuable feeling of "coming home", of another family.
The more stable business model of consultant companies might also help bring out the best of a person. In all my past product companies, I have seen normally nice and friendly people turn to anxious and aggressive behavior and relationships sour when finances turned bad and consequently opinions about fixing the situation become too extreme.
The psychology of ownership
What about my biggest original hurdle, my feeling that I must be working for product company in order to have a feeling of ownership of my work? In this case it turned out I was just wrong. It turns out that it does not much matter what is the chain of organisations and their agreements through which one ends up contributing to some project and product. I found out that once I do contribute to a product, once I do innovate and use my skills and write the code and features and once customers see the product and use it and are delighted by it - then regardless of anything else it feels that it is mine and ours and that nothing can take that feeling and pride away.
Customers exploring the new Post self-service kiosk that
our Nitor team launched in the summer
And even if being one degree more remote from the product does sometimes slightly lower the ownership feeling, that's not an entirely bad thing either. Towards the end of my career at Napa I think many of us, including myself, become too attached to the product, starting to take the ups and downs of the product too personally. This resulted in inevitable bad feelings when the product was suffering with heavy technical debt that seemed impossible mountain to climb. Occasionally it can be advantageous to be able to take slight healthy distance to the product in order not to become too obsessed about it.
Is the Grass Greener?
Of course, life is not always sunshine anywhere. I have also experienced hard moments at Nitor, when three weeks into my first project the deadline for the first release was already close and we had zero use cases ready for launch. It was hard for the first project, but I have seen other hard things in my career too. What matters is that all my colleagues on all levels were very supportive in that difficult situation and in the end we got over it and I recovered to have very enjoyable project with good feelings both in the team and by our customers.
In terms of programming technologies, consulting companies might on average be more on the latest-and-greatest side of the curve than product companies with any length of history. So there might be a bit less need to compensate lack of learning in work by high-tech hobby projects like I have been doing during my years. Indeed it is remarkable that I am currently able to use in my main project the wonderful ClojureScript / Re-Frame combo that I had earlier used only in hobby projects.
Changing jobs can be a bit radical, even harsh. Especially for a nerd like me whose colleagues usually form my main circle of friends. With such social setting moving companies can be like a small divorce. Prospect of that has been at least in my case resulting in delaying leaving a company bit too long after things have already turned sour. And herein lies the final reason why I eventually warmed up to a possibility of life in consulting: I hope and expect to be able to "change jobs without changing jobs" - rotate to other customer projects when the need arises and still keep well-connected to my colleague-friends. Perhaps that is the sweet-spot between the possibility for social continuation on one hand and possibility for personal renewal and growth on the other. Only time will tell, but so far I am happy I opened my heart to a consulting company.