If you have visited Battlefy’s office, you probably have observed our engineers in their natural habitat: headphones on, being alone, and solving logic puzzles in our own parallel universes. But if you look closely, you can probably identify a few wild engineers in product brainstorm sessions, design feedback meetings, feature health retrospectives, lunch and learns, and so on. Why are they in those meetings?! VOLUNTARILY?! Isn’t that just biologically impossible? Won’t that make their weekday less efficient solving engineering problems? Yes and no. We have those meetings scattered around the week that break our alone time thinking about solutions. But those meetings habitually remind us of who we are serving, why we are fighting, and what we are fighting for.
At Battlefy we grow the esports community by making participating and organizing esports extremely easy. This is what our users need. This is the problem our product managers, our designers, and our engineers come together to solve. Different roles contribute to the solutions in their own ways. In this regard, are those meetings wasting of time? No. They align us engineers on what problems we are solving today, and how the solution fits into the bigger picture.
We used to provide our engineers with as little interruption as possible. We indulged ourselves exploring the solution space without anchoring us to the problem at hand. Lines of code were poured out like they were free during those fun times. We’ve built an in-house Object-relational mapping library (ORM) as a centrepiece of our dependencies only to realize that there was no way we have the resources to maintain it (And community driven ORMs quickly caught up and provided all the features we needed in the first place). We’ve built yet another chat application with state of the art stack, full on spamming control and filters, and no user nor spammer cared to use it.
What we learned is that the first step of solving our users’ problem is to recognize the problem. That’s what startups do. And that requires team effort and countless experiments. Today, we leverage third party services and libraries as much as we can, so that we can iterate fast and focus on delivering to our users. When we build features to test product-market fit, we talk with PMs and designers about hacky shortcuts and tech debts, and decide together whether the risks are worth taking. Once the market fit is found, we do revisit and iterate and make the feature scale proof, still in the simplest ways we can find.
We probably wont be the best engineering team building ORMs, or search engines, or MMORPGs. But we strive to be the best engineering team to deliver a killer esports competition experience. We are the most knowledgable engineers about esports on this planet.
Isn’t being domain experts the job of product managers? Engineers should just engineer. Here’s a secret… Being knowledgeable about the problem actually makes us better engineers. We all know sorting in theory has a lower bound of O(n log n), so no algorithms can achieve better sorting performance. Or is it? If you get to know what you are sorting a bit more, so that you can properly design the buckets, you can use Bucket Sort to achieve linear time sorting performance. Today Java uses Timsort as the default sorting algorithm. From years of generalized domain knowledge we know most inputs are already partially sorted, and Timsort takes advantage of that knowledge.
At Battlefy we design applications and systems that are performant in the esport context. We research, design, and implement algorithms to generate the most fair double elimination bracket progression, or Swiss match pairings. Some of our systems talk to users’ browsers in realtime, while other systems are outside of HTTP request/response cycle providing less time sensitive but higher reliable services. Our systems are architected for our particular domain.
Vancouver is a relatively safe city if you disregard all the earthquake predictions. What I mean here is that we have created a psychological safe environment intra and inter our teams. We are comfortable being vulnerable in front of our peers. We speak up when and wherever. We talk as if we are designers or product managers, and we listen without batting an eye when some designers or community managers talk about how to best engineer things. We schooled or got schooled during those conversations and there’s not a single day past without some TILs.
Some of the most important lessons I have learned in my life are when I shipped blocker bugs into production. During those times the team always acts together swiftly and focused unblocking and fixing. We also improve our practices from those lessons. The pain of letting our users down is unbearable enough. But, if shipping bugs to production is inevitable, our team probably is one of the lowest stress places for that to happen.
It might be pure luck to get hired into a team that has this psychological safety perk. But maintaining that safety requires everyone’s effort. I don’t have the magic recipe. But being eager to listen, being humble and respectful, and being curious seems to be the skills all of us put many of our skill points to when we level up at Battlefy.
Our engineering team spends most of our time understanding our users’ problems. From our office arrangement to our organizational structure to our culture, everything is configured to help us do that. We all feel what we have is a pretty sweet setup here and we’re proud of it! Let us know what you think!
If you would like to know more, come join us for some free dinners (unlimited beers), gaming, and chitchats every Friday evening year around, or maybe just try it out in first person perspective!
Battlefy is hiring! We value passion and drive but we also believe that diversity is the key to success for every high growth technology startup. We welcome people from all walks of life.
We take care of the people, the products, the profits — in that order.
