From product company to a consultant company
Feb 5, 2020, 11:50 AM
On 15th May 2019, I started in a new job as a software developer at Nitor. Nitor is a Helsinki-based software consultant company with several customers in Finland's Capital area. The move ended my 12-year long stay at Napa, a company making software for ship design and operation since 1979. But more significantly, the move marked a change from companies with their own products (LabSystems, Nokia and Napa) to the world of consultant-companies which don’t have their own products but instead work on helping other companies to develop software.
"I would never work as a consultant"
When I transitioned in the year 2000 from academic career in Molecular Physics to my first job in the 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 and disrespected compared to the real in-house developers. I thought that consultants were assigned the worst tasks, worked always on gigantic never-ending death-march projects with Cobol and Java 1.0 and were kicked out on the blink of an eye 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 I was making. As a passionate person, I wanted to feel I am working on my and our product instead of just helping with someone else's stuff.
During the years after 2000, my prejudices towards software consultant companies were slowly softening. I come to understand that not all consultant companies are alike – that alongside the traditional hierarchical dinosaurs, 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.
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 a 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 the world of modern software consulting in general and to Nitor in particular. While my experience as a consultant is still limited to few months and a single customer project, there are already some clear findings to acknowledge.
First, regarding 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 consequently write rapidly great code that implements great innovative applications delighting customers. One starts to wonder that perhaps the consultant-companies of the olden days got a bad rap partly because there were too many cases where they simply failed to do 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 the possibility of enjoying continued respect on both individual and company levels.
Regarding the level of job security and the propensity of being fired, my earlier assumptions have also been overturned. I am now aware of several cases 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’s developers.
My laptop. Unlike a product-company software-developer, consultants have culture of decorating their laptops with stickers advertising their interests and experiences.
Another reason arises from Finland's strict labour laws. While these laws aim to protect the company's own employees by making them more difficult to fire, they paradoxically often result in companies tightening the environment by doing exactly that. By having more consultants rather than in-house developers work on their projects, they have later more flexibility if the situation rapidly changes. And even when a consultant’s project in a company comes to an end, the result is much less drastic than a person fired from a product company: far from becoming unemployed, it’s just time to move to another customer project.
The different business model of consultant companies also seems to somewhat protect them from the need of layoffs. While successful software product companies can, for a while, make immense profits with their product, their profits can quickly turn to red when the success of the product eventually 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 the atmosphere. Consultant company that is selling hours of work can never make immense profits, but their bottom line is also less vulnerable to losses when they have multiple customers. One customer’s business turning sour is often compensated by another customer’s (old or new one) business soaring.
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 a team of consultants is tasked with the most fascinating, creative, and fun projects that produce novel software applications with the latest and greatest technologies. In my current project, our team enjoys a great deal of responsibility and freedom in our choices of architecture and technologies – I was able to choose the immensely productive ClojureScript / Re-Frame combo for the front-end while we use the latest AWS serverless tech for integrating to the customers backend-services. The in-house developer teams, on the other hand, seem to be sometimes tasked with less challenging and innovative work of maintaining and bug-fixing of their existing legacy production applications using older technologies.
The importance of 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. The meaning of "good" here should not be taken too narrowly to mean knowledge, skills, and intelligence – while those are of course important, the real kick that comes with these people is their character: great sparkling unique humans with charm, personality, passion, and stories to tell. Perhaps it is not just a coincidence that people of high ability tend to also be quirky and colourful in interesting and delightful ways.
Of course, it is also a relative question who are "good colleagues" for any particular person. I am sure that some people on this earth would consider this bunch of nerds and nerdettes simply weird. So perhaps it is more accurate to talk of "culture compatibility": that the best colleagues for someone are the ones that have compatible culture- and value-expectations. When a company succeeds in bringing together people who are compatible in this way, it fosters the creation of a valuable feeling of "coming home", the feeling 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. I’ve witnessed 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 a product company to have a feeling of ownership of my work? In this case, it turned out I was just plain wrong. It turns out that it doesn’t matter much what is the chain of organisations to 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 good feeling and pride away.
And even if being one degree more remote from the product does sometimes slightly lower the feeling of ownership, that's not an entirely bad thing either. Towards the end of my career at Napa I think many of us, including myself, became too attached to the product, starting to take the ups and downs too personally. This resulted in inevitable bad feelings when the product was suffering from heavy technical debt that seemed an impossible mountain to climb. Occasionally it can be advantageous to be able to take a 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 tough moments at Nitor when three weeks into my first project, the deadline for the first release rapidly approaching, and we had zero use cases ready for launch. It was an exceptionally hard beginning for a first project – jumping into the deep end of the pool – but I have seen other hard things during my 20-year career, so I knew it would pass. And it was significant that all my colleagues at all levels of the organisation were very supportive in that difficult situation. In the end, we got over it and I recovered to have a very enjoyable project with good feelings both in the team and by our customers.
I used to wonder earlier if consultants were different kind of developers with some kind of special “consulting skills”. But I do not feel any more that my background in product companies makes me lack anything at Nitor. Software development seems to work the same way everywhere: being a good programmer, good problem-solver, and a friendly human being is important while other requirements are less so. Of course, not everyone excels at all skills and all the time, but that's why there are companies and teams where skills combine to create total competence that is more than the sum of its parts. Perhaps, after all, there are not separate product company programmers and other consultant programmers, but just programmers.
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 for the lack of learning new things through 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.
Switching jobs can be a bit radical, even harsh. Especially for a nerd like me whose colleagues often form the main circle of friends. With such social setting moving companies can even feel like a small divorce. Prospect of that has been at least in my case, resulting in delaying moving on a bit too long after things have already turned sour in some company. 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 the one hand and the possibility for personal renewal and good environment on the other. Only time will tell, but so far, I am happy I opened my heart to a consulting company.
Robert J. Brotherus has been loving computer programming as work and hobby since his first lines of Basic on Commodore VIC-20 in 1982. Originally a researcher in Computational Molecular Physics at the University of Helsinki, Robert moved to the industry in the year 2000 and has been working in various companies as a software developer since then. His current interests include functional reactive programming with Clojure, serverless cloud computing and “Teal” self-managed organisations.