After my last column was published I learned that writing about coffee machines is a controversial subject. One might see an expensive coffee machine as merely a random example of things that shouldn’t be the reason a candidate decides to work for a company. But to me, a coffee machine represents so much more… the inspiration for this very post!
You see, it was while having a discussion in our office kitchen, observing Xolo people filling cups with that bitter, caffeinated liquid that helps them function (I myself prefer peppermint tea) that I realized — there are so many things that make our engineering team the crème de la crème of engineering teams. So just in case you're interested, I thought I would take the time to share them with you, too.
What's in a name? (A lot, actually)
Recently I've gotten a lot of questions about what the role "Product Engineer" means here at Xolo. The internet is full of think-pieces about what the people who deal with code all day should be called, so I thought I would give my 5¢ on the subject and how it relates to our team.
There are a lot of different role names for people who do "the IT stuff." Developers. Geeks. Software Engineers. Programmers. Hackers. Techies. Computer Specialists. Heck, I remember a time when it was all the rage to create made-up names like "Code Guru" or "Software Ninja". (Our friend Elon has brought this trend back.)
Now I am sticking with the Product Engineer, and here's why:
We work on a product, not a project
Even though some of our initiatives might look like projects, they are far from project development. It may surprise you to learn that we don’t even have Project Managers on our team! Instead, we are constantly working toward understanding what we could build to create the most value. In other words, who is going to care if we build this new feature? This approach is not only important for Product Managers, but also for our engineers. Because who wants to invest their time, energy, and skills into building something that no one even wants?
Start with "Why?"
It is crucial for the whole team to understand *why* are we building whatever it is we're currently building. I believe it's only when engineers have the answer to this important question, that they can then create the most innovative (and effective) solution. Every team member has the possibility to be included in setting the goals and hypothesis, doing the research, and of course, deciding on how everything gets implemented. To make sure this approach isn't just theoretical, we set out to keep our teams as autonomous as possible and give them the authority to make decisions that have an impact.
Our engineers don’t want to mindlessly churn out code with no clue where it'll end up. Instead, they want to know how the software they built impacts both the company and our users. It's vital to understand how our Xolopreneurs feel about our products, so we continuously ask for feedback in the form of NPS and customer interviews. We test customer interest in various features within the product. We believe in analyzing data continuously to make smarter, better decisions. Our business intelligence information is available for everyone in the company. For engineers, this means there is always the possibility to analyze information straight from the source.
Even though we are a tech company, we also have an amazing service delivery team. To support them optimizing their work, our product engineers dove into the data. Based on their analysis, they saw that the most time in our back-office is spent processing our customers’ purchase invoices. There are tens of thousands of invoices every month that need to be reviewed by adding, for example, the correct expense category and taxation rules for accounting and tax reporting purposes. By automating this step, they freed up entire workweeks every month for the service delivery team and in doing so, made our product offering even more scalable.
We get it done with Agile methodology
Our team follows the Scrum framework. Every two weeks, we have a ceremony where we demo what we've built to the rest of the company. Our engineers take this opportunity to introduce the improvements they have built for our platform. Not only do they show how it works but, whenever possible, they share the actual value the change has brought. For example, how many of our customers have found that our product is now easier and more transparent to use or how many hours of manual work we've saved through automation (as described in the scenario above). This is not only to justify their work but more importantly, to give context and meaning to these improvements.
And as we have three to five releases a day, these meetings are always jam-packed with a lot of useful information and learnings. Which leads me to my next point…
Continuous learning is the key
Even though everybody on our team wants to create elegant code that creates value, sometimes our hypotheses don’t work out in real life. And often, they're not the sophisticated solutions we initially set out to build. But that doesn't mean we see them as mistakes. Instead, we see them as an opportunity to learn and improve. Typically a root cause analysis (RCA) is done after an escalation and contains performative phrases like “This is our highest priority to solve” or “Our team is committed to ensuring this never happens again.” We don’t have anyone requesting these RCA's from us. On the contrary, we decided we needed them for ourselves.
We have a regular RCA meeting for the whole team where we introduce to the rest of the team what someone has learned and how others could avoid the same mistakes. Using this input, we have initiated workshops or changed existing processes — sometimes both!
For example, there was a period of time when we had issues with larger changes to our platform. As we have multiple application nodes in our cluster that share a common database, then when a new release with data structure changes was rolled out across the cluster, different nodes (already updated vs. not updated) had different expectations for the data structures and this caused errors. We had to learn to release such data structure changes in multiple steps to keep backwards compatibility until all nodes were updated. In the end, our product is more stable for the users and the team feels more confident when bigger changes are made.
As life changes quickly around us, the way the world works must also evolve to keep up. Especially when working in a startup environment. In addition to all the new features we released last year, we also launched two new products — Xolo Teams and Xolo Spain. We launched our fifth product, Xolo Italy, at the end of January 2022.
As you can see, this year is off to a productive start. With that said, it's a top priority of mine to inspire everyone in our team to invest time in learning new skills and actually taking the time and setting the boundaries necessary to follow through. This could mean refining their technical skills in our tech stack or gaining new knowledge on machine learning. At other times, they dedicate time to developing softer skills like better time management or strategies for more effective communication. Deep passion for software is something to be valued and nurtured here at Xolo.
This is not a job ad
Except yeah, it kind of is. Job ads, unfortunately, are usually clouded in so many vague buzzwords that it's hard to understand what kind of environment you'll be working in — until you actually work there. As our company is growing and we're looking for new talent to join the team (and let's face it, talented developers always have options), I wanted to take this opportunity to showcase why working on the Xolo Engineering team is different from a lot of other teams you've worked with. We don't want you just for your skills, we want you for your mind. You will be encouraged to take ownership, to make decisions, to speak up and share your opinion, to build something that actually matters. Sound like a place you'd like to work? Awesome, we'd be thrilled to have you.
About Piret
Piret has been leading the Engineering Team at Xolo since 2019. As a leader, she's a firm believer in a people-first management style where a culture of autonomy and personal responsibility is prized above all else. Her background in communications has taught her the importance of transparency, clear expectations and creating a candid & kind feedback culture.
Piret writes a semi-monthly column for the Xolo Blog. Here she waxes poetic on the art and science of building high-performing autonomous teams (and why she thinks coffee machines are super overrated).
Follow Piret on LinkedIn
