I’ve completed one year as a software engineering manager at RegScale and thought it would be worthwhile to share some reflections on my journey so far. As employee number 12, I’ve worn many hats, juggling both leadership responsibilities and technical challenges in the R&D department.
In this post, I’ll cover the highlights — from the company culture and our team dynamics to management and leadership insights, key accomplishments, challenges faced and overcome, as well as my personal growth and outlook. I hope my experiences can offer some valuable insights, whether you’re in a similar role or are curious about RegScale’s journey from my perspective.
The Startup Culture
It’s been insightful to see our engineering culture mature – going from one with a small team and very little overhead process, to one where nearly 30 people can work efficiently and transparently. The theme we kept was autonomy with alignment. We’re still small enough that each engineer has their own project/feature to work on from requirements gathering to deployment. However, when a project calls for it, we join forces and collaborate closely.
It’s not uncommon in startups for there to be periods with longer hours to meet a deadline. RegScale offers unlimited PTO to help offset the extra pushes. Managers encourage their employees to take at least one week off each quarter. I’m proud that when our cloud architect was out of the country with minimal contact, we continued to function and demonstrate resiliency during deployments.
When I first joined RegScale, I was somewhat skeptical about having our R&D team mostly based in one location—Knoxville, TN. However, over time we’ve evolved a blended work model that really hits the mark. While most of our engineers are in or near Knoxville, we also have team members spread across different states.
What’s been great about this setup is that it allows for flexibility. RegScale encourages everyone to work where they’re most productive. Some team members prefer to come into the office every day, while others only come in as needed. Regardless of location, we’re all tightly connected through remote work tools, and we make it a point to be considerate of each other’s time zones and schedules.
Having most of the team in one location does offer one distinct advantage: it makes it much simpler to organize on-site working sessions and social events. For instance, we set up a “war room” event to build features to meet a firm deadline. It was a hybrid event—both in-person and virtual—and the energy and engagement levels were exactly what was called for.
Management and Leadership
Being a manager in a startup is like navigating through a constantly changing maze—the roles are fluid and responsibilities often overlap. As we grow, things stabilize, but just until the next curveball comes our way. Reflecting on the theme of autonomy with alignment, my manager has been hands-off for the most part, allowing me the freedom to identify gaps and take on new leadership roles as I see fit.
One philosophy I’ve found particularly effective is a blend of top-down alignment with bottom-up buy-in. For instance, when we transitioned from using GitHub Projects to Jira for tracking our work, the decision was initially made at the leadership level. However, we made sure to engage those who would actually be using the tool day-to-day, addressing their concerns and highlighting the benefits. This collaborative approach made for a smooth transition.
I’m fortunate to be part of a diverse R&D leadership team, where members come from varied industry backgrounds. This diversity enriches our discussions and decision-making processes. Our strong peer relationships serve as a support network for brainstorming, conflict resolution, and mutual growth.
Projects and Accomplishments
Understanding the Governance, Risk Management, and Compliance (GRC) space is no simple feat—it’s complex and often hard to grasp quickly. Several of my developers have commented in meetings that they have a better understanding of how all the pieces fit together. I’m proud to see people advance their technical skills while incorporating industry knowledge to make their next feature even stronger and better suited to our customers’ needs.
RegScale’s core tenet is compliance automation. We use several tools to ensure our code quality meets standards and that the frameworks and tools we use have minimal vulnerabilities. RegScale is also the first company I’ve worked for that drinks its own champagne – that is, uses the tool it produces. We’re finding ways to “shift-left” on compliance within the company; making our own jobs easier translates into making our customers’ lives less stressful.
In terms of initiatives, I’ve had my hand in various pots. I’ve been instrumental in developing RegScale’s performance management system and advocating using Confluence as a centralized repository for our internal processes. I’ve also introduced greater rigor into our code reviews and initiated the adoption of unit testing for our web app project.
No company is perfect, and I’d like to share a few areas that have been challenging.
It’s fun to move fast and have few guardrails when the team is small, and opportunities seem endless. A mission I’ve had at every place I’ve worked since I was 17 is to get tribal knowledge written down. This is key for bringing on new people: If those tricky instructions for getting an app to work aren’t written down, or worse, out of date, people can’t work independently. Over the past year, we’ve done a fantastic job of creating Confluence pages for crucial meeting notes and process descriptions. I would have no shame wearing a T-shirt that said, “Is there a Confluence page for that?”
Having us make better use of Microsoft Teams is something I’ve failed at. Repeatedly. Because meetings are also direct chat groups, people look for wherever they will likely find an answer rather than the area that’s most appropriate (e.g., channels). I can’t blame them; it’s the path of least resistance. A solution I provided that has mostly worked is writing up our communication protocol – what goes where, when to use DMs versus channels, and examples of what not to do and what to do instead (and why).
Leading a team at RegScale has offered a wealth of personal growth opportunities. At one point, I found myself managing a team of eleven individual contributors—too large a number to maintain the quality of care I strive for, alongside my own workload. I’ve since scaled it down to a more manageable team size of seven, but that experience of discomfort was instructive.
Although I’ve had leadership roles before, many of the difficult leadership tasks were ultimately someone else’s concern. Here, I’ve been pushed to level up my skills in new ways. For instance, handling underperforming team members has been a challenging but vital experience, forcing me to find the right balance between empathy and firmness. There have also been situations where I needed to adopt a more directive leadership style, something that’s not my default approach. These experiences have been incredibly educational.
RegScale has given me an opportunity to engage fully with my work, help people grow, and leave the camp better than I found it. At times it feels overwhelming because there are more projects that I want to do than I have time for. Reflecting on this past year reminds me of how far I’ve come, both technically and as a leader. As I look forward to the coming year, I’m excited to see how both my team and I will continue to grow and adapt.