Engineering Manager, Product Engineering

You make strong engineers more effective.

You can manage people without turning engineering into a process factory.

You are technically credible enough to understand what your team is building, but you do not need to win every architecture debate.

You are comfortable resolving conflict, giving direct feedback, hiring excellent people and helping senior engineers grow.

If your first answer to an unpredictable team is more ceremonies, more status reporting and more Jira, this is probably not the role.

You will help run the teams building the user-facing and reasoning layers of Reflexivity.

Initially, your remit will span Reasoning and Build
:

• Reasoning generates the answers and artefacts behind Alfred;
• Build owns the persistent user experience where those artefacts are saved, refreshed, composed and used.

The teams already have strong technical people.

Your job is not to replace the Technical Leads
.

Your job is to build the people and organisational system around them so the teams can grow without losing speed, quality or accountability.

You will also be an important part of building Reflexivity's engineering organisation in New York.

• Manage, coach and develop engineers across one or more squads.
• Run high-quality 1:1s and maintain continuous follow-through, not just quarterly check-ins.
• Own performance management and career development.
• Give direct feedback early rather than letting issues compound.
• Resolve interpersonal and cross-functional conflict.
• Partner closely with each squad's Technical Lead and Product Manager.
• Recruit excellent engineers and help build the NYC engineering team.
• Understand team capacity and surface people/organisational constraints.
• Remove organisational blockers that prevent the team from executing.
• Own onboarding and the management basics that should not consume senior technical leaders.
• Use data and evidence to understand team performance rather than managing by anecdote.
• Help the VP Engineering build an engineering organisation that can scale toward 75+ people.
• Keep management lightweight enough that engineers can engineer.

The squad Technical Lead owns:

• architecture;
• solution design;
• technical decomposition;
• technical delivery;
• technical quality;
• technical release readiness.

The Product Manager owns:

• customer problem;
• priorities;
• product outcome;
• success metrics.

You should understand and challenge technical decisions when appropriate, but management authority does not make you the technical decision-maker.

• You understand Reasoning and Build well enough to manage the people building them.
• Engineers know what you expect from them.
• You have a clear view of team strengths, weaknesses and hiring needs.
• 1:1s, feedback and development plans have consistent follow-through.
• The CTO is receiving fewer routine people/coordination escalations.

• The teams are materially easier to scale.
• Performance issues are dealt with quickly and fairly.
• Strong engineers have visible development paths.
• Product/Engineering conflict is handled at the right level.
• NYC has a stronger engineering nucleus.
• Technical Leads are spending less time on management administration.

• You can run multiple high-performing teams without daily intervention from the VPE or CTO.
• You have hired and developed strong engineers.
• The teams have maintained a high technical bar without becoming process-heavy.
• Your management system scales with the team rather than becoming its bottleneck.

• Significant software engineering experience.
• Meaningful experience managing software engineers.
• Experience managing senior, opinionated technical people.
• Strong performance-management and coaching skills.
• Experience hiring engineers in a competitive market.
• Comfortable resolving conflict directly.
• Strong written and verbal communication.
• Technically credible across modern production software systems.
• Data-driven and evidence-oriented.
• Experience in a high-growth product organisation.
• Comfortable with ambiguity and changing product requirements.
• Low ego: you do not need to be the technical authority in the room.

• AI / LLM-enabled products.
• Agent or workflow systems.
• Fintech or institutional finance.
• Developer-heavy or technically complex products.
• Golang / distributed systems.
• Experience building an engineering hub from an early stage.
• Experience across frontend + backend teams.

• Engineers own systems end-to-end.
• Every squad has one…