Senior Product Platform Engineer - Smartly at Datacom

Christchurch, Canterbury, New Zealand -

Full Time

Start Date

Immediate

Expiry Date

25 Aug, 26

Salary

0.0

Posted On

27 May, 26

Experience

5 year(s) or above

Remote Job

Yes

Telecommute

Yes

Sponsor Visa

Skills

C#, Dotnet, Python, Typescript, Identity and Access Management, CI/CD, Observability, Platform Engineering, System Design, Technical Leadership, Mentoring, Architectural Decision Records, Modular Monolith, Developer Experience, Cloud Technology, Database Management

Industry

IT Services and IT Consulting

Description

Senior Product Platform Engineer Remote in New Zealand, The Smartly Platforms and Architecture Team are looking for a Senior Product Platform Engineer to own a platform domain end-to-end and the engineers who depend on it. How might we build platform capabilities that other engineering teams actually want to adopt? How might we tie the work we do to measurable impact? How might we grow our platform engineers through the work itself? Our Why There's a particular kind of engineer who quietly carries a team. The one who picks up a domain nobody fully owns, makes it coherent, builds the tooling other engineers actually want to use, and raises the bar of everyone around them without making it about themselves. If that's you, we want to talk. Smartly is profitable and reinvesting heavily in engineering and AI. We process pay for 200,000+ payees across 20,000+ companies. The platform works, and we have the runway to make it modern, AI-native, and worth building a career on. We're building the team that does that, and we're looking for a Senior to own a domain on it. About the Role (your why) You own a platform domain. Which one depends on your strengths and what the team needs most when you join: Identity and Access Management, Developer Experience and CI/CD, Performance and Observability, or another that fits the moment. Owning the domain means you set direction inside it. You build the standards and tooling. You make the technical decisions. You're accountable for adoption and outcomes. Your customers are other engineers across the company, and the only honest measure of success is whether they actually use what you build. You contribute to architectural decisions alongside the Principals and me. What you'll do No two weeks are the same, but here's the rough shape. Design reviews — both the ones you run for your domain and the ones you sit in across the team. 1:1s with the engineers you mentor and with the Principals who mentor you. Pairing with engineers in product squads to co-design solutions and unblock the hard technical problems. Building! You will build a lot. On Monday that might be shipping a new self-service capability for product squads to consume. Tuesday might be a CI pipeline improvement that shortens everyone's feedback loop. Wednesday might see you pairing with a product squad to instrument their new feature with observability that actually pages the right person. Thursday you might be refactoring shared frameworks in the monolith and pulling more business logic out of stored procedures. Friday is for learning. Writing — design docs, ADRs, agentic prompts that the whole team will use. We write things down. Decisions, designs, tradeoffs, and post-incident learnings live on the page. It's how we think, how we align, and how we work async. It is vital that you believe in writing as we do. Writing is not a chore to be done at the end of your work in this team. Writing is a forcing function for thinking and for clarity. You will only succeed here if you love writing as we do. Focus time is non-negotiable. We protect the calendar for deep work. Meetings have a purpose or they don't happen. We tend to focus in the morning and meet in the afternoons. Async standups by default, 3 o'clock Smoko twice a week where work talk is banned and we connect as humans. What working with us is like I'm a hands-on manager and I believe that all managers should be hands on. It builds empathy in the same way that senior leaders who show up on incident response calls build empathy. I'm building a team that believes where feedback is concerned, kindness and empathy lead while directness and problem solving follow. We avoid ruinous empathy here. I believe strongly in learning and curiosity, and I'll work with you to invest deeply in your growth, and in your ability to grow others around you. Both Principals on the team are mentors. Mostly this will look like training and mentoring, but as your mana grows you'll sponsor promising staff yourself, in the same way I'll be sponsoring you. Our team are full of thoughtful people who want to help others. We believe in respecting focus time and acting with remote-first intentionality. We believe in strategic laziness - why would I keep doing this manual stuff when a machine can do it for me? The team are pragmatic and want to make choices that favour technical purity, AND we acknowledge that sometimes that's not the right thing for the business and for our colleagues. When you join this team, your standards become team standards. Your judgement, vision, taste, agency and ownership will make everyone around you faster. What you'll bring You've shipped real systems. You've owned a domain. You've designed it, built it, run it, and been on the hook when it broke. You know what good looks like because you've seen it from both sides. You're deeply comfortable in the demanding application engineering space. You're very familiar with C# and dotnet — you'll be in our codebase from day one and we don't have months to bring you up to speed on the language. You probably know enough python and typescript to be dangerous, and if we pick up another language or framework you'll be one of the people who helps the rest of us learn it. Our monolith works, and it's chocka block with decisions that made sense at the time — you need to be comfortable taking those decisions, applying taste and judgement, and engineering modern solutions. We're moving toward a modular monolith with a well-formed internal structure, pulling business logic out of stored procedures and into code, and making choices about database and cloud technology. You need to thrive in that space, and help others feel at home there too. You have judgement, taste, vision, and context. The four things AI can't replace. You can look at AI-generated output and tell the difference between work that's actually good and work that's just plausible-sounding. You know what "platform as product" means in practice. You can tell when a best practice is the wrong practice for this codebase, this domain, this moment. You own outcomes. You have agency. You find a way to get what you want without waiting for conditions to be perfect or blaming the circumstances. You're a Go-Getter, not a Frustrated Genius. You build things other engineers want to adopt because you actually listen to them, treat their friction as your defect, and care about developer experience as much as technical correctness. If this is you I'd love to hear from you. Please apply. If parts of this resonate but you're worried you don't tick every box — please apply anyway. The traits I'm looking for — judgement, taste, vision, context, agency, ownership — don't come from a particular degree, background, or career path. Smartly is committed to building a team that reflects Aotearoa New Zealand, and I'd particularly like to hear from women, Māori, Pasifika, takatāpui, disabled and neurodivergent engineers, and anyone who took a non-linear path into the work. If you need any adjustments to be at your best in the conversation or beyond, tell me. When you write, tell me about a domain you owned, a platform capability you built that other teams couldn't stop adopting, or a piece of AI-assisted work you're proud of.

Responsibilities

Own a platform domain end-to-end, setting the technical direction and building standards and tooling for other engineers. Responsibilities include running design reviews, mentoring engineers, and developing self-service capabilities to improve developer experience.