LogicGate Career Growth & Development

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.