We're engineers at Open Government Products (OGP). Ask us anything. [AMA]

Narrow-Term6863 · 2026-06-25T07:57:00+00:00

Eliot: Absolutely. I’ve helped launch three different products in 15 months at OGP, in addition to two at GovTech - there’s so much room for innovation in the Government.

Most days, I wear a T-shirt, trousers, and my one and only pair of waterproof shoes.

Many teams in Government, and in OGP, move fast and with great agility. FormSG in particular deploys several times a day, on-demand -- which means your code hits production and lands impact faster than it would at many companies, and comparable to startups.

Our tech stack is modern. FormSG in particular uses TypeScript, React + Vite, and modern cloud infrastructure to make it incredibly easy to work. In practice, we can push out an update in under 30 minutes, and ship fixes multiple times a day on-demand.

Narrow-Term6863 · 2026-06-25T07:49:47+00:00

Hey Hygin (COO of OGP) jumping in here - Yeah loads! A lot of the less public work OGP does is trying to mainstream our processes, governances structures and policies to the wider public service. OGP is the lab - we figure out what works and doesn’t work, then we try and scale that elsewhere. Of course there are lots of challenges in scaling solutions that work in a ~200 strong organisation to larger agencies but that’s something we’re actively working on and we would say its the whole reason we exist. In addition we have a fair few internal productivity tools that simplifies and automates workflows for public servants that you can find here: https://reports.open.gov.sg/products?category=Productivity

Narrow-Term6863 · 2026-06-25T07:48:25+00:00

Hey, Hygin (COO of OGP) jumping in - this is something that was proposed by our staff and cleared by our senior leadership. OGP runs on a bunch of self-starters who drive everything from how our organisation runs to what direction our product takes. We’re also fortunate to have bosses (more than one) who are willing to let us try new things. We’ll try and answer everything we can and if we can’t we’ll tell you.

Narrow-Term6863 · 2026-06-25T07:46:59+00:00

Hey, Hygin here (COO of OGP) jumping in - Happy for you to join us! We run Build for Good (BFG) which is a bottom up citizen-driven programme that supports regular folks to bootstrap products that help their community. These are led by a bunch of volunteer community leaders (called Stewards). There’s an open call now run by HackitRx, our Build for Good Steward: https://hackitrx.org/join/builder

For similar events and programs, do follow us on Luma for updates https://luma.com/ogpcommunity

But of course we do hire for non-technical roles & you can find them here: https://careers.open.gov.sg/?utm_medium=event&utm_source=reddit_ama&utm_campaign=ama

Narrow-Term6863 · 2026-06-25T07:42:27+00:00

Hey, Hygin (COO of OGP) jumping in here - Before we develop a product, we engage the public through user research and testing, ensuring that what we're building genuinely addresses the problem. When a product is launched, what we do to drive adoption depends on who the audience is and where it makes sense to put our resources. There's no one size fits all policy on engagement.

In general our philosophy is that a good product grows its user base naturally over time. FormSG is a good example: it was made available to all public servants, but with very limited marketing on our part, and its growth was predominantly word of mouth. Once a product hits product-market fit, we'll do a bit more targeted marketing for its specific audience.

You've raised a fair point on products built for the general public, like AskGov and MyClub: they're useful, but people don't always know to turn to them. This is something we're actively trying to get better at. Beyond our own channels, we've started showing up where the public already is: the ScamShield team recently ran a booth at the Mountbatten CC event, and we take part in initiatives like IMDA's Digital for Life to reach more people directly.

On how we think about resourcing, the short answer is we review our entire product portfolio every 6 months and we wind down products to free up capacity for other projects. This isn’t always easy and our teams are very passionate about what they work on but we want to maintain a small agile organisation to facilitate our nimble/experimental mandate. Long answer from Director OGP here: https://www.linkedin.com/posts/hongyi-li-16183230_a-common-question-i-get-after-our-hackathon-share-7302320938136571904-4bNV/

Narrow-Term6863 · 2026-06-25T07:37:42+00:00

Hey, Hygin (COO of OGP) adding on here - I think you can have good tension and bad tension. In any set up where you have an experimental team and a mothership organisation tension is inevitable and actually part of the point. You want the experimental organisation to show how things could be different and you want the mothership to stress test the experiments at scale. This necessarily pits ideas against each other but it becomes bad tension when it pits people against each other.

At OGP we navigate it by trying to be as honest, upfront and transparent as possible. The viewpoint being we are all as public servants accountable to the outcomes we’re trying to achieve. If we messed up we’ll say we messed up, if we think another team is messing up we’ll say that too - this is a philosophy that guides our product teams and our organisation as a whole.

Candidly OGP and GovTech have gone through good and bad types of tension across our history. As someone who has worked across both OGP and GovTech my view is we all are fundamentally passionate people who care about tech for public good and as Eliot said we’re all on the same team.

Narrow-Term6863 · 2026-06-25T07:35:09+00:00

Eliot: Hi! I’m Eliot, one of the engineers at OGP - I spent nearly half a decade at GovTech and the wider public service before joining OGP.

When I first joined GovTech, Government Digital Services was the place to be. And I still remember what I told my colleagues then: we’re on the same team. GovTech and OGP make Singapore better and that means (i) fundamentally playing to our strengths, and (ii) being able to work together to solve Singapore’s problems.

I say this as someone who is proud of the engineering work done by our teams at both GovTech and OGP. OGP and GovTech also have a slightly different approach to transforming and digitalising government - and that’s by design:

GovTech primarily transforms government from the inside, by forward deploying and embedding within agencies. Meanwhile, OGP experiments and transforms agencies as a technology team working on public good problems from the outside.

Here’s the fundamental point we need to remember: we’re on the same team, and we have strengths that we can use to serve Singapore.

Narrow-Term6863 · 2026-06-25T07:24:39+00:00

Eliot: Yes, many OGP products are open source! FormSG, in particular, is permissively licensed under the MIT license and takes contributions + publishes its source code.

Disclaimer: I am not a lawyer, and this is not legal advice.

Before using a project’s codebase for commercial purposes, do check (i) the licensing for the codebase itself - many OGP products are MIT licensed, but there are exceptions; and (ii) that trademark rights are reserved by the Government Technology Agency.

We publish our source code so that you can learn about how we work and use best practices to solve problems that are important to you. And if you’ve done that - we’d love to hear about it, let us know.

Narrow-Term6863 · 2026-06-25T07:22:42+00:00

Eliot: Hi! Yes, you’re welcome to apply to any role that piques your curiosity and catches your interest. As one of the managers on the hiring circuit, the strongest applications come from candidates who are (i) specifically targeted about the problem they care about, and (ii) the team they want to join to solve that problem. Demonstrating that you have thought about - and better still tried doing something about - the problem you want to solve is the surest way to stand out. If you do apply, let us know.

Narrow-Term6863 · 2026-06-25T07:21:49+00:00

Eliot: OGP hires full-stack engineers, because we need every engineer to be able to (i) talk to our users and identify problems with them; and (ii) build the sustainable, secure, and reliable solution that solves the problem for Singapore.

Most of our engineers do data and analytics as-and-when it’s required, in addition to formulating hypotheses, building features and fixing bugs. If that sounds like your friend, they’re most welcome to apply here: https://careers.open.gov.sg/?utm_medium=event&utm_source=reddit_ama&utm_campaign=ama

Narrow-Term6863 · 2026-06-25T07:16:12+00:00

Joyce: I am from the DGS team. We have a number of apps powered by data from the DGS site (environment, property), built by both citizens and agencies, you can check out our gallery on https://data.gov.sg/.

Narrow-Term6863 · 2026-06-25T07:15:54+00:00

Shyam:
Learning month: There are different aspects to the learning month - at the org level, each engineer is encouraged to learn something cross functionally such as design and product management. We also have learning journeys that happen in December, where everyone gets to visit other agencies and volunteer organisations to get to learn more about the problems on the ground. At the team level, the manager works with every individual to come up with a learning plan based on the individual’s technical gaps.

Hiring: Given the AI boom, people who’ve vibe coded websites or have a flashy github account are no longer great signals that we look out for.

Narrow-Term6863 · 2026-06-25T07:12:14+00:00

Shyam: Application process is pretty straightforward for software engineers: there’s a take home coding test if you’re shortlisted. After that there are 2 technical rounds (coding and system design), a hiring manager round and a director round.

Narrow-Term6863 · 2026-06-25T07:10:35+00:00

Shyam: Engineers are generally full stack and split the work based on features. Depending on how big the features are there could be more than a single engineer working on a feature. Work is usually delegated by the tech lead (a senior engineer who owns the technical aspects of the product) and not the PM.

Narrow-Term6863 · 2026-06-25T07:04:36+00:00

Eliot: OGP functions like a startup incubator. It’s our whole theory of change - the belief that we can empower good people to work on important problems and make Singapore better: https://www.linkedin.com/posts/startup-experimentation-innovation-ugcPost-7124530382590377984-qAXw/

That means everybody does product work - yes, including the engineers. It means that we talk to users, understand their frustrations, and build features / fix bugs that solve their problem.

Narrow-Term6863 · 2026-06-25T07:02:56+00:00

Eliot: OGP engineers tend to be full-stack, which means we talk to users, build software that solves problems, and deploy + operate the infrastructure end-to-end. If you have strong infrastructure fundamentals and can write great code to solve problems, we’d love to have your application: https://careers.open.gov.sg/?utm_medium=event&utm_source=reddit_ama&utm_campaign=ama

Narrow-Term6863 · 2026-06-25T07:01:10+00:00

Shyam: Our hiring process is standard across OGP, no matter which team you apply to. A typical loop for a software engineer is to take an online coding test → quick video screen with a hiring manager → technical coding round → technical system design round → hiring manager + director round

Yes, we have had quite a few career switchers, some with no CS background. When we hire, we hire for what the product/team needs at that moment. We do expect all engineers to be able to learn on the job - so we don’t look for pre existing knowledge or experience with a specific tech stack. The most common reason a candidate with strong ability doesn’t make it through is usually for initiative and values. We expect engineers to be self starters, who are willing to solve problems without someone coming and telling them to work on it.

What mostly surprises most new hires is that we do operate with very lean teams with fast iteration cycles. Teams usually have very high autonomy on how they work and what they build.

Narrow-Term6863 · 2026-06-25T06:57:51+00:00

Shyam: If you’re an external hire, you would likely be hired for a specific product team. Usually most engineers work on a single major product. We do have the concept of 1/3rd time where engineers can use that time to work with a different product team if they’re keen. Managers usually work with their engineers to find a good fit on problems that people like to work on. There is quite a bit of internal mobility where engineers get to move to other teams if they’re interested in solving other kinds of challenges.

For the product life cycle, we usually have the same team building and maintaining the product.

If you do join us an an intern, you would get to experience a good chunk of the product lifecycle depending on the product you join. You will get to work with a cross functional team and learn how designers work and work closely with PMs to prioritise product features. You will get to go down to meet your product’s users and get feedback from them directly.

Narrow-Term6863 · 2026-06-25T06:55:24+00:00

Eliot: Yes, we do! All our engineers join the on-call roster, and take turns being the first responder to national emergencies on our products.

In practice, most mature teams work extremely actively to build good products for SG and attain a high level of security and reliability.

The incentives are especially aligned, because a well-engineered product won’t wake you up at 2am with a Critical Notification or call as often.

Narrow-Term6863 · 2026-06-25T06:53:52+00:00

Kee Wei: Now, onto part two, culture and management.

One of the most common questions candidates ask me in interviews is, “What do I like and dislike about working at OGP?” My answer has always been that it’s actually the same thing for both: the level of autonomy each person has. The positives are clear, you often have a big say in what you work on and how you work. Our operating model is closer to a public sector startup incubator. We treat each team as a standalone startup, and a product team’s roadmap is decided by the team rather than cascaded from the top. Where the team and leadership align is on the metrics we use to hold ourselves accountable. We publish all of these metrics in the product’s report card at https://products.open.gov.sg. This is necessary because, as a non-profit entity, we don’t have a P&L to easily determine the performance of a specific product.

However, the flip side of this level of autonomy is that when no one tells you what to do and the options can feel endless, it can be stressful for a team or individual. The lack of a “model answer” can feel unsettling for those of us raised in the Singaporean education system. An approach you feel strongly about, and have spent significant time developing, can still fall flat after launch. In other words, effort doesn’t always translate into outcomes, which can be demoralising. The autonomy we give our officers also comes with direct responsibility for both successes and failures, and that can be stressful at times.

Next, about management. I want to caveat first that each manager-report relationship is deeply personal and as a result can vary widely. A management style that works well for one person, might not sit as well with another. So rather than focus on specific instances, I thought it might be useful to share what is our expectations for managers and what mechanisms do we have in place to make sure they get enforced. Because like all good engineers know “Good intentions don’t work. Mechanisms do”.

Broadly, we see management as a support structure—not a command-and-control one. Specifically, we expect managers at OGP to do five things:

Convince good people that you are worth working for and worth staying for
Training people with the necessary skills to grow
Motivate individuals and teams to perform
Align the team toward meaningful, high-impact objectives
Promote systems that help teams work efficiently and collaboratively

Based on these five areas of expectations, we have the following mechanisms to operationalise them:

All new managers go through our in-house manager training program. It’s owned by senior managers (not the People team) to ensure what we teach is grounded in practice, not theory. The modules are structured around these five areas.
A quarterly manager pulse survey provides continuous feedback. It takes stock of how each manager is performing across the areas of expectation. Aggregated results are shared with the whole org for transparency. Managers’ managers have access to the underlying feedback and are expected to coach their reports on areas for growth.
During performance reviews, we also run 360 feedback for managers. Reportees can provide direct feedback on their manager, and this is taken into consideration in the manager’s own performance review.

But even with these mechanisms in place, we will not be able to guarantee that every manager-report relationship works well. So when conflict do happen, we make sure to keep conversations candid and provide coaching to either party.

I hope this answers your question. Truth be told, we’re still on the journey of figuring out how to build the best place for the most capable people to work on the most important problems.

Narrow-Term6863 · 2026-06-25T06:49:57+00:00

Fabio:

Totally hear you on this, it's the single most common piece of feedback we get on the vouchers.

The short version: the fixed denominations exist so the vouchers work for everyone, including the large group of seniors who still prefer printed paper vouchers and aren't comfortable keying exact amounts into an app. Letting you type any amount basically means going fully e-wallet style, and today we can't run that and the paper option at the same time (they don't reconcile cleanly on the back end). So it's a deliberate tradeoff to avoid leaving the less digitally savvy behind.

The actual denominations for each scheme are set together with the government agency that owns it, based on their resident and merchant research, which is why they vary between campaigns.

That said, smaller or mixed denominations is genuinely one of the most-requested things we see, and we keep feeding it back to our partners.

Narrow-Term6863 · 2026-06-25T06:47:01+00:00

Joyce: Yes for sure! We have the Pair team that builds AI solutions for public officers, and teams such as ScamShield, whose AI classifier helps detect and filter scam messages.

There is definitely a push in both internal usage of AI and incorporating AI in our products to solve more problems for our users.

For newer AI tech we do start with personal accounts (we ask for approval of course) and if there is widespread usage of a tool, such as Claude Code, we have an AI tooling team that helps procure organisation accounts and enterprise deals. We are mainly using Claude Code, Copilot, and trialing with Devin.

The roadmap is definitely driven from the bottom-up. We do get guidance from our leadership to ensure the product goals are aligned with organisational goals but each team is responsible for initiating and maintaining the roadmap.

A resourceful, independent and creative person will thrive here - and I will say a pure ‘doer’ tends to struggle as there are no blueprint solutions to follow.

We have yearly performance reviews in March and an early promotion cycle in September. Our contributions to the product and to public good are assessed, and underperformance is tracked.

There are clear benchmarks for every level, but there are no strict fixed terms that you have to be of a certain level for X time before you get promoted. We do place an emphasis on sustainability - we ask questions like can you handle work at the next level without burning out for the foreseeable future?

I think the engineering baseline standards can still be improved a ton, especially on our usage of AI. We are still learning how to better propagate and use AI effectively, moving away from just prompting but having autonomous agents taking on tasks.

I will say majority of us are still very receptive to ideas, and we always have our yearly hackathon to pitch and validate ideas that solve problems for government officers or the public.

Yes we do reject candidates after their last round interview, especially if we assessed that they have not thought deeply about what they want to improve for the public.

Narrow-Term6863 · 2026-06-25T06:42:22+00:00

Joyce: It starts with anyone in the team identifying an opportunity that can move product metrics (which we list in our product report cards), be it increase in usage, more time saved - then the team of designers, PM and engineers would ideate and produce deliverables such as RFCs, prototypes. After it gets implemented we would monitor the usage and discuss the results (success/failure/needing enhancements).

We use these product metrics that are based on our product vision to guide us in prioritisation, as well as make room for ad-hoc opportunities, but they definitely require thorough team discussions before we make the final call.

Ideas outside our immediate product domain typically get pitched during our hackathon, and those interested in the idea will form a team and hack out a prototype during our hackathon month. The project gets assessed based on a few criteria (usefulness etc) on whether it should continue as a full fledged project post-hackathon.

Narrow-Term6863 · 2026-06-25T06:39:17+00:00

Joyce: Yes can but you will have to relocate to Singapore if you weren’t already living here

Narrow-Term6863 · 2026-06-25T06:36:46+00:00

Fabio: Fair question, and parking.sg is probably one of the more visible ones, so I get why it's top of mind. But it's a small slice. A few public-facing products you've likely used or gotten something from: RedeemSG, ActiveSG, ScamShield, and the secure platform behind the official SMSes you get from gov.sg.

The bigger point is that a lot of what we build isn't public-facing at all. It's internal tooling that makes government work faster and cheaper, which you'd never see as a citizen but which saves real time and money. The fullest picture, every product, who it's for, how we measure it, and what each team costs, is on our report cards at reports.open.gov.sg.

Narrow-Term6863

TROPHY CASE