Long and UX Chapter
… a senior engineer working in a product squad but often sneaks off to run a UX chapter when the product manager is not looking.
Q: What is your name, and how long have you been at ServiceRocket?
I usually introduce myself by surname — Long, to keep it short and easy to pronounce. It has been 8 years since I first joined ServiceRocket.
Q: What is your current role in ServiceRocket and how did you transition into it?
I’m a senior engineer working in a product squad which build apps for Confluence Cloud but I often sneak off to run a UX chapter when the product manager is not looking.
As for how I transition into the role, I might need to go back to as far back as when I first joined, I was given a brief talk about Agile by my then-manager after my interview. I was then introduced to automated testing which was inspiring and eye-opening for me who had limited exposure to modern practices. Starting as one of the junior members, I was fortunate to work with more experienced colleagues and was given the opportunity to grow in a couple of teams working on a variety of technologies. Along the way, I found myself drawn to the then UX guild. With the encouragement from my mentor and manager, I took the role of a chapter lead. There is no doubt that these years in ServiceRocket are formative for my career and will be a memorable period of my life.
Q: What is a Chapter in ServiceRocket?
There is a bit of a journey from how we started what we now call a chapter in ServiceRocket. As you may have guessed from the terms used, we first explored the idea of a chapter based on the popular Spotify model. It looked promising as a framework for team formation. We formed tribes around product platforms, each tribe with multiple squads, and chapters that spanned across squads from different tribes. After some time, we realized that this created some overheads in reporting structure and source of work because chapter members had to juggle between squads and chapters. So we reformed chapters into something that resembled more of user groups with the primary goal to drive knowledge sharing and practices across squads, while still allowing engineers to specialize in a particular domain.
Q: What are the focus areas of UX Chapter?
UX Chapter focuses on areas that have direct impact on the overall user experience. We work closely with designers on implementations and keeping up with modern frontend development, plus an eye for design system components and standards. One of the main goals is to bridge the gaps between design and engineering by building a common understanding.
Q: Did you always want to specialize in UX?
I have always been interested in creating a good experience and have always regarded good user experience as a hallmark of great products. However, I didn’t know much about the domain or even knew the term “UX” until several years ago. Not that I’m an expert now but ever since I discovered what goes beyond UI design, I’ve been trying to learn more about the field and be the advocate of the human aspect of software development that often gets overlooked.
Q: What are the challenges that you have faced along the way and how did you overcome them? Any experience or lessons to share?
The roads were quite bumpy for me to lead a UX Chapter. For starters, UX design is relatively new compared to other disciplines like operation and security. It is less involved in terms of the technicality which most software engineers are interested in. As mentioned earlier, we were experimenting how to run chapters. It was difficult for the chapter to create significant direct impacts. Chapter members were struggling prioritizing responsibilities between squad and chapter. What helped, for me at least, is to be more intentional in energy management, and eventually the aforementioned reforming the expectations and purpose of chapters. It’s not all sunshine and rainbows now but it’s more manageable and we’re still learning.
As for experience or lessons, I used to answer these questions with something technical. However, as my experience grew and our engineering team expanded, I found out that there are other aspects of software engineering that are more challenging to scale. One of them is alignment and effective communication, especially when teams span across multiple platforms and timezones, more so when working remotely becomes common since the recent pandemic. Sharing best practices through influence and learning by proxy don’t work as well in these situations. I find taking a balanced approach between communicating through systemizing for scalability and empathizing through personal interactions for effectiveness depending on circumstances eases the gaps.
Q: Can you also talk about study groups that you have organized?
While Chapters meetings are useful for broad knowledge sharing and building influence for best practices, I have been organizing study groups as a more structured mechanism to help the chapter members to upskill in more specific topics. We’ve done one for browser networking and are currently going through one for React. What separates our study groups from available online courses is that we get to inject usage context around our own problem and solution domains. We have the flexibility to adjust the pace and scope to better suit the skill levels of attendees according to feedback received.
Q: What are your hobbies? Or what can we find you doing outside of work?
I tend to fill up my free time learning about technology in general, not confined to those in software engineering only and more often than not are related to consumer electronics. There is a sense of wonder in seeing them getting more advanced and how the reach of these technologies influences us at individual, community, or even societal level. But other than that, I’m not beyond the common hobbies of playing video games and reading books, maybe writing a couple blog posts or publishing podcasts with friends (who I came to know through ServiceRocket) when the stars align.
