Building Brikl was intended to be a showcase of our technology and culture to entice new recruits to the tech team. And despite meeting its objectives, it achieved so much more besides. Being a remote international business has a myriad of upsides. But naturally, it isn’t always possible to have our finger on the pulse of what our hyper-talented colleagues are innovating on either side of the world.
Building Brikl was as much a showcase of our culture internally as well as externally. As the engineers delivered their impassioned views of what Brikl means to them and their vision for the future, the ripple effect of excitement across the company was electric.
That’s why we just couldn’t resist catching up with the speakers to elaborate on some of their talking points. But first…
- Tobias Meixner, our CTO, and Michael Hansen, our Head of Engineering, outlined the company’s ambitious vision for the future in no uncertain terms, as well as its flourishing engineering culture, and tech stack.
- In his talk, 55 Bricks at Brikl, our now-not-so-new new starter, Peerarust Siriamphan (Gno), Brikl’s Software Engineer recounted his personal experience of the company. From his onboarding journey to today, giving a candid and objective insight into Brikl life.
- Phoomparin Mano(Poom) spoke about how we architect our frontend mono-repo with ~300,000 lines of code, 40 libraries, and ten sub-apps. He also shared his experiences of the architectural challenges the team faced as the scale got larger.
Personal question first! Our company supports diversity in personality as well as race, nationality, sexuality, background, beliefs, etc. As an introvert, how do you feel Brikl has supported your personal growth, and what advice would you give to future candidates who also lean towards introversion?
If you’re an introvert, I believe you’ll feel very comfortable here as you don’t have to be loud for the team to listen.
Since my first day, I’ve been surprised at how everyone is very open to feedback, experimentation, and learning outside of their usual expertise.
Even though I’m a software engineer at heart, I still have multiple areas I want to explore further. I got to dive into developer advocacy, frontend architecture, team management, and product management. Everyone is always supportive, no matter what I do, from organizing hackathons to building a feature. I always get to mentor and share techniques, use different combinations of skills and learn something new in return.
If you have an idea, everyone is always willing to take a step back, wait for you and take time to listen and give feedback, which I think is a sign of a healthy environment. You have an opportunity to develop your communication skills along the way, from mentoring engineers, organizing tech events to communicating with stakeholders to build the product.
You explained complexity really well and how bad performance amplifies at scale.
Can you recap and expand upon how Brikl engineers counter this?
One of the problems we realized, later on, was that a slight performance issue could spiral into huge architectural issues when left unnoticed.
We have one example of cross-domain circular dependencies, which causes the module bundler to load unnecessary code from other unrelated domains and slow down the app.
The issue propagated as we continued to scale our product surface and codebase, starting with slow iteration time for our developers, unit and integration tests being slow to complete, and the application itself being slow for our users.
We started by developing automation rules and using the Nx module graph to identify the issue. Then, we explored several techniques, such as creating an isolated sub-application to reduce dependencies with Netlify proxies and using optimization tools such as Webpack tree-shaking.
You talk about pain intuition and engaging proactively with dev challenges. How important is foresight in mitigating risk versus pain intuition? And what balance do you think devs need to strike in their approach?
I believe that architecting software should not be like building a house, where every minute detail must be planned upfront, and most issues have to be resolved before the construction. While having foresight and being aware of architectural challenges are important, product surface and business needs change unpredictably, and we have to adapt.
Instead, it’s like planning a city where your prior experiences will help you avoid common architectural mistakes. Then you can test your plan out with a small region, measure the results, and make adjustments to the rest of the city.
Even if we have a solid architecture from the beginning, having pain intuition, understanding the fundamental problem, and pivoting the architecture to changing needs is a very important skill for engineers.
Engineers should still try to mitigate the fundamental architectural issues upfront, but more important is being mindful of the changes, pain points and being proactive about solving issues.
Michael & Tobias
Michael, you speak about how developers are a scarce resource nowadays in your talk. What challenges are they experiencing, and how would Brikl create a frictionless environment for them?
There’s currently unprecedented demand for developers, making hiring and retaining talent a challenge. As a result, we have to maximize productivity and keep developers happy. A common source of frustration is slow, unreliable process automation, insufficient developer tooling, and “technical debt” due to always being stuck in crunch mode.
In Brikl, we have invested in preventing these issues by dedicating one day a week to improving our platform (we call it Platform Monday). In addition, we have an internal team working exclusively on continuously improving developer experience throughout Brikl’s Engineering department.
How important are mentorship, leadership, and autonomy, and how do you help your team strike a balance?
By encouraging autonomy, we aim to promote a naturally collaborative environment where decisions are openly discussed and validated – everyone’s opinion is heard. To support this approach, we practice servant leadership, where leaders focus on helping team members develop, grow, and perform as highly as possible but take a step back when it comes to execution and decision making.
In my opinion, this is critical to keeping engineers challenged and engaged.
Tobias, you touched on how our current capabilities are well suited to the Metaverse. Can you recap what you said for anyone who didn’t catch the talk and expand on how our 3D capabilities make us metaverse-ready?
A core part of the Metaverse is visualization, especially in 3D, including e-Commerce. Brikl has extensive experience building 3D for customization, which we could create or use in our technology in the Metaverse.
As we scale by 44 in ’22, what are you looking for from the next wave of talent?
For engineers, we mainly look at three things:
- Attitude and team
- Talent with emotional intelligence
- Intelligence, aptitude, bringing in new experience ideas, or high passion and willingness to learn.
What would you say was the most challenging aspect of joining Brikl, and how did you overcome the hurdle?
The most challenging thing I encountered was working remotely. Understanding one another is crucial, and knowing how each team works is vital to supporting one another.
Usually, this situation would not be so challenging – in the office, we’d all see each other, grabbed some lunch together, but with remote working, this disconnect was something I couldn’t ignore.
Lucky for me, the people at Brikl are so genuine and friendly. Many team-building activities such as Hackathons and seasonal celebrations (such as our Halloween event) continue to be great boosters to get to know each other.
How was it being onboarded remotely to meeting the team in person?
This was my first experience of being onboarded remotely, so I was both nervous and excited about what lay ahead, but luckily enough, Brikl’s people were very generous and friendly when it was my first day at the office. I didn’t feel awkward. Instead, I felt like I knew the team even though we’d only spoken through chat and video calls.
What helped me a lot were regular team meetings: backend meetings, biweekly engineer meetings, and general ad hoc team meetings. At the end of the meeting, we have a tradition called rounded feedback, where we ask for feedback from the past week.
This helps me know a lot about the people working with me, what makes them happy, and what they’ve struggled with recently. It also allows managers or anyone on the team to support and help counter issues.
How do you think our hackathons have brought teams together?
We focus on our work daily, and most of the time, the conversation we have with the teams will be related to work. Hackathons are different: We work with others to develop tools, do POC, or even try out new ideas or technologies. It’s really fun working together to work on something innovative.
The thing that I like the most about the Hackathon’s presentation session is celebrating each other’s amazing innovations and things that we’ve worked on during the past two days.
Some of the results from Hackathon will also be improved and implemented into our product.
What do you most enjoy about working at Brikl, beyond your 55 days, and what advice do you have for your future team members?
The things I enjoy most working at Brikl are how supportive the team is, my team, and everyone I have encountered so far. We accept feedback and try to improve every aspect that will help Brikl as a company. That doesn’t mean that we only work to improve our product, but we also enhance the development experience.
So all development teams can happily develop a product that will greatly impact our customers.
I want to advise all future Brikl members to have fun! Fun with coding, solving challenging problems, developing impact products, joining activities with people from around the world, and hanging out with colleagues. Enjoy working at Brikl! 🙂