Product mindset vs service mindset in software engineering

Having worked in the industry for years, I often thought about why I'm on the same page with some people and never can find a common ground with the other bunch. And it doesn't depend on professionalism (which is crucial though), or experience (sometimes beginner engineers are capable of outstanding thoughts and decisions), or sense of humour (well, at least not directly), or any other emotional aspects of interpersonal relationships (friendships on a job are typically too brittle). What gets peers together, at least in my opinion, after peering with dozens of colleagues from all over the world, is their view of the results of their work.

In short, one cohort sees a final product as the North Star or their journey, and another one sees their service in itself as the main goal of their working life activities.

While putting stamps is not correct here, in most cases these patterns or work behaviour define everything: starting from day-to-day experiences in teams, and finishing with resulting output(s), both in short terms, and in a long run.

Why would my dachshund be a good product engineer? Because she has the product mindset, where the product (no matter how cynical it sounds) is me. You can teach those who are able to be loyal and believe in the goal how to build things. You cannot teach those who are able to build things to be loyal and believe in the goal. And it, in practice, crashes even solid projects.

Why enterprise development sucks the fun out of programming? Because it turns people from product-minded to service-minded, destroying any potential loyalty and goal-orientation. It turns people to golden-handcuffed 9-to-5 checkbox traversers instead of software craftsmen. Considered it creates the commoditised teamwork experience, and maybe it does. But it also creates the outlier feeling inside the most valuable team members — the ones with the product mindset. And that’s not good at all as those guys are probably the ones everybody (and everything) relies (and should rely) on. And outliers are usually pushed away from the existing majority groups.

Why most developer advocates, devrels, product evangelists, and other software missioners sound so hypocritical to the folks at the plow? Because you see them jumping jobs so often, you start to confuse the products they evangelise. Salesmen are much more honest in this regard. I truly think the only sincere advocate for a product is the founder of it, or a person attributing themselves to this role.

Why empathetic developers feel it so difficult to survive in the software development industry? Because the service mindset of the most of the peers makes it challenging to cope with the way product teams work in 90% of the situations. While the empathy for the child of your working efforts, the software you build, is typically suppressed as an atavism.

So what can (and should) we do with this situation? How can we use knowing the differences between the product mindset and the service mindset and their impact on software developer team productivity?

Software development team leaders should minimise the impact the service mindset has on their team work. Either by compiling the corresponding product-mindset culture, or by cultivating and nurturing it as much as it’s possible in each particular case. The only way to build a great product is to live this great product. Although it doesn’t mean literal dedication of ones’ lives to the work and its results, it implies mindfulness and caring, ownership and responsibility. It’s the only practical way team collaboration works because the service mindset is the weak link where everything breaks, crushing the construction of a product team and the results of its work.

All in all, building the team with the product mindset and eliminating the service mindset… I’m pretty sure it’s possible, and I saw it with my own eyes, both in huge corporate teams (too rarely though) and in small family-like shops (more often but with many exceptions unfortunately). It may or may not work well eventually because the personal role impact is too high, the smaller the team. But it definitely will improve the team spirit, allowing to reach the team’s end goal — building the great product. And earning an honest buck with that.

And that what even any corporate software scoundrel can relate to…

The cover photo by Koshu Kunii from Unsplash (the dachshund one is mine though)