Continuous Learning at Pricefx – 8 Lessons From Scaling Pricefx Engineering

Every software company that aims to excel on the market with their product and get a deserved market share, needs to scale up at some point, but also needs to shape their engineering culture. If you are curious enough to find out how we coped with the change, then this article is the right 5 minute reading for you.

As a leading provider of price optimization software, Pricefx is inevitably growing, and with that, our culture and priorities need to be reshaped a little bit.

After already been through the process of scaling Pricefx, we’ve gained invaluable experience that shaped the engineering culture we enjoy now. Though it’s difficult to list every lesson we’ve learned as we’re still growing and improving, here are the top 8 that have stood out to us the most. Maybe you’ve learned a few of these lessons yourself! 

Embrace Learning and Growth

On our expansion journey, we quickly realized how valuable it is that our software engineers be adaptable. We weren’t searching for experts who focused mostly on a single framework. Instead, we were on the lookout for people who had a hunger for knowledge and the ability to grow.  

For example, when we need Java proficiency on a project, we don’t mind hiring a C# developer with an excellent reputation. In our case, when we did just that, this developer quickly became an essential member of our Java team. Gradually, several of our Java engineers transitioned to JavaScript. And as Pricefx grew, our needs evolved. We started with Ember and shifted to React, where we found many more candidates. So why focus on doing the same, when encouraging growth helps everyone win? 

Find the ‘Sweet Spot’

In our experience, every engineer has their own ‘sweet spot’ where they feel the most productive and satisfied. Some people excel at defining the framework, concepts, and adopting new technologies, even if they’re not really enthusiastic about business features. Others are more maintainers than innovators—they get satisfaction from enhancing, tuning, and fixing existing parts of our applications, preferring stability over constant change.  

Then, we have our innovators. These are the people who are exhilarated by creating something new, innovating for a while before needing to move on to a new challenge to stay motivated. Recognizing and nurturing these individual strengths has been a major part of our culture. 

People Over Technology

At the end of the day, software development leadership is really about people. When you work with people, you need to balance the human factors like managing interpersonal issues, possible team tensions, egos, and personal problems. Technology is only one piece of the puzzle. But really, our success comes from understanding and addressing these human complexities. 

Cultivate Psychological Safety

We highly value psychological safety on our team. When things don’t turn out as expected, which we all experience at one point or another, we focus on intentions rather than blame. For instance, a regression bug following a low-level refactoring intended to improve performance is a setback on a project. But for us, it’s important to not discourage the engineer who took on the task. Instead, we help them fix the issue and learn from the experience so they can avoid similar mistakes in the future.  

Leadership Influence

We embrace the idea that a manager’s output is equal to the output of their organization, plus the output of the neighboring organizations under their influence. In our culture, leadership is about empowering others and facilitating collective success. 

Avoid the Cargo Cult

We actively discourage the ‘Cargo Cult’ mentality—the belief that following certain processes or ceremonies without understanding their purpose will magically solve problems. Instead, we emphasize the importance of understanding the why behind our processes, to foster a culture of intentionality and purpose.   

Adapt Team Structure with Growth

As more and more joined our team, we noticed that stand-ups were taking longer, communication was more challenging, and engagement was shrinking. To try and fx these growing pains, we drew inspiration from Spotify’s agile structure. We introduced sub-teams with specialized roles, each with a unique Pricefx name like Chilli, Tabasco, Pepper, Vanilla, and Mustard. This structure made our communication much smoother, and we can see our people feeling more engaged. 

Redefine and Contextualize Metrics

Another important lesson we’ve learned is that traditional metrics like Lines of Code (LOC), number of Merge Requests (MRs), and bugs closed don’t show a complete picture of productivity. We’ve found that we understand productivity better when we put more value on business outcomes like:

• active users 
• user engagement 
• time taken to adopt new features 
• time to onboard a new customer for a released feature.  

These metrics are better aligned with our business goals and give us a more holistic view of our productivity. We also recognize the value of supporting metrics, when used in the right context. These are things like:  

• test coverage 
• build pipeline durations 

• average peer code review duration 
• number of regression bugs per time period 
• number of reopens per ticket 
• resolution time for critical tickets 
• ratio of externally vs internally reported bugs. 

As you can see, the journey of scaling Pricefx has taught us a quite a bit. We now know that successful growth is about more than just technology—it’s about people, adaptability, and constant learning. And we’re looking forward to the next chapter of our scaling journey—we look forward to sharing it with you! I bet you cannot wait to see more, thus let me invite you to some scroll thru some more reading here at our Learning Center.