Senior Product Software Engineer

Group 1001 is a consumer-centric, technology-driven family of insurance companies on a mission to deliver outstanding value and operational performance by combining financial strength and stability with deep insurance expertise and a can-do culture. Group
1001’s culture emphasizes the importance of collaboration, communication, core business focus, risk management, and striving for outcomes. This goal extends to how we hire and onboard our most valuable assets – our employees.

As a Product Software Engineer at Group 1001, you own the distance between what our AI-assisted development capabilities can do and what teams actually get out of them. Our agentic ecosystem includes both the platform that engineering teams build on, and the managed development environments with integrated AI coding assistants that let engineers and business technologists alike build and deploy applications in a fast, safe, and consistent way.

This is a forward-deployed role where your customers are colleagues. You will frequently engage with application teams, platform and infrastructure teams, and business technologists adopting the agentic platforms we are consistently evolving. If and when you help these partners write code to better leverage these platforms, you then generalize and upstream the capability into our platform/ecosystem. You remain accountable to the platform product rather than becoming staff augmentation for whichever team asks loudest.

Adoption of our work and our offerings is always earned. Overselling costs more here than it would with an external customer; our internal relationship has no end date. Your customers can read your code and your backlog, and they will have opinions about both; this is a feature, not a bug.

The ideal candidate is a strong software engineer who would rather spend a week finding out why a team abandoned a tool than a week adding a feature nobody asked for. This is a senior individual-contributor role with product ownership.

• Deeply engage with teams to learn how they actually work, not how some guide says they work, then build something real that will truly work for them. The deliverable is their workflow running, not a recommendation that it could. Fix it locally, then upstream the pattern.
• Enable teams with local fixes to get people going; but leaving a local fix in place is an anti-pattern.
• Generalize bespoke fixes and features, then land them in our platform; delete the bespoke version. If something cannot be generalized, say so and articulate why.
• Translate between three audiences who describe the same problem differently - application engineers, central platform teams, and business technologists. Each has a vocabulary, a set of constraints, and a threshold for what counts as "working," and they rarely match.
• Build the golden paths and the reference implementations. Most adoption failures are not capability gaps; they are the absence of a worked example close enough to someone's real problem to start from.
• Carry actionable signal back to the roadmap. Anecdotes from one frustrated team vs. a pattern across six teams are different inputs and deserve different responses. Know which one you are holding and actioning on.
• Earn trust. Show up consistently, learn the domain, fix something small early, and be direct about what the tooling can and cannot do.
• Say no to work that belongs somewhere else. Some of what you are handed is a backlog item, another team's responsibility, or a problem the platform should not solve. Routing it correctly is more useful than absorbing it.
• Write the documentation you wished existed when you got there. What released, what is coming, how to use it, and what it will not do for you.