LogicGate Career Growth & Development

Tell us about your recent promotion or role change. 

I recently transitioned from a role in professional services to solutions engineering at LogicGate. In my previous role, I led projects to implement, update and scale applications for our existing customers. Now, I focus on demonstrating our platform’s capabilities to prospective customers to help win deals and drive expansion. Leveraging my hands-on experience in the platform, I now provide tailored recommendations and act as a trusted advisor to those exploring our solution.

What will this new role or skill let you do? 

This role change has given me a new perspective by shifting my focus to the pre-sales component of the customer journey. I’ve gained valuable insights into what motivates customers to invest in our solution and how we can best demonstrate its value to meet their needs. Being in a sales role has been both exciting and challenging, and I’ve enjoyed seeing the direct impact of my work on our company’s growth.

How would you describe the culture of internal mobility and upskilling? 

LogicGate fosters a culture of internal mobility by providing employees with the tools and support they need to grow and transition into new roles. One of our core values, “embrace curiosity,” has always been a personal favorite because it encourages employees to continuously learn and explore new opportunities.

LogicGate also provides formal development opportunities such as our internal mentorship program. My involvement in this program allowed me to connect with a mentor on the solutions engineering team after I expressed interest in transitioning into that role. This early exposure helped me gain insights and first-hand knowledge before a position even became available. When an opportunity on the team eventually opened up, I felt well prepared to step into the role of associate solutions engineer this past fall.

How does your team cultivate a culture of learning, whether that’s through hackathons, lunch and learns, access to online courses or other resources?

On our team, we focus on making learning both visible and safe. We’ve built regular practices into our week, including “story time,” where we discuss possible implementations and debate trade-offs, and “office hours,” where anyone can bring their work for feedback. We also hold “chaos time,” which is essentially red-teaming: We explore how our systems might break or how we’d react to different outages or attacks. And because security is a significant part of our work, we run weekly “security spelunking” sessions, where we review findings, remediate issues together and ensure we’re staying on top of compliance. 

What ties these practices together is psychological safety. We encourage engineers to ask questions in the open rather than in direct messages, even if that feels a little vulnerable. Asking questions publicly can be a double-edged sword; it sometimes exposes that you’re still wrestling with a concept or not retaining as much as you’d like. But on balance, it’s a net positive. Every question asked out loud is a chance for learning for the whole team, not just one person.

How does this culture positively impact the work your team produces?

The impact is tangible. When engineers are encouraged to ask questions publicly and share their thinking, problems get solved faster and knowledge spreads naturally. Instead of just one person leveling up, the whole team benefits.

Because we pressure-test ideas together in story time and office hours, the work we roll out is better vetted, which means there are fewer surprises in production. Our chaos time exercises have improved our incident response; we’ve identified gaps in our runbooks that could have harmed us during a real outage. Our security spelunking efforts have consistently kept us within the security service level agreement for security findings while also raising the baseline security awareness across the team.

Everyone knows failure is inevitable — even senior engineers make them — but on our team, failure is treated as a learning experience. We joke that it’s almost a rite of passage to “take down the stack” at some point in your career. It sounds scary, but what it means is that we don’t treat failure as the end of the world; we treat it as the start of real learning. That mindset makes people more willing to experiment, take ownership and improve their craft.

What advice would you give to other engineers or engineering leaders interested in creating a culture of learning on their own team?

Start with psychological safety. If people don’t feel comfortable admitting they don’t know something, no tool or program will fix that. Encourage questions to be asked openly, and model transparency by being open about your own learning and mistakes.

Then, make learning part of the team’s operating rhythm. That could mean dedicated time for hack days, chaos testing or office hours. The format matters less than consistency; if learning is optional or ad hoc, it will always get deprioritized.

Finally, think, “teach to fish.” It’s tempting just to hand out answers, but if you invest the time to walk someone through how to solve a problem, they’ll be able to do it themselves next time. That builds not just skills but confidence.

If you can get those three things right — safety, consistency and empowerment — you’ll see both the team’s output and their sense of ownership grow.