Open Government Products, GovTech Singapore
Computer Software
11-50 Employees
4.8 (Glassdoor)
Claimed
Manages Culture Code and Employee Benefits
About Open Government Products, GovTech Singapore
Open Government Products is an in-house team of engineers, designers, and product managers who build technology for the public good. We proactively identify areas where technology can help, test our prototypes with actual users, and bring our best ones to launch. This includes everything from building better frontend applications for citizens, to automating the internal operations of public agencies. We use and release open source software, keep a flat hierarchy, and bypass bureaucracy to focus on delivery. We work on real problems, build for the user, and push for change.
Projects we have worked on include:
Data.gov.sg - An open repository of all the Singapore Government’s public data. It helps people understand the data using visualizations and articles, and provides real-time APIs for developers to use.
Isomer - An end-to-end informational site builder for the government.
Parking.sg - A mobile app alternative to parking coupons. It lets users pay, extend, and refund their parking sessions just using their phones.
Form.sg - A form builder tool for agencies to self-service and create online forms that capture classified data, with the goal of replacing paper forms.
We are a division in GovTech Singapore.
Projects we have worked on include:
Data.gov.sg - An open repository of all the Singapore Government’s public data. It helps people understand the data using visualizations and articles, and provides real-time APIs for developers to use.
Isomer - An end-to-end informational site builder for the government.
Parking.sg - A mobile app alternative to parking coupons. It lets users pay, extend, and refund their parking sessions just using their phones.
Form.sg - A form builder tool for agencies to self-service and create online forms that capture classified data, with the goal of replacing paper forms.
We are a division in GovTech Singapore.
Open Government Products, GovTech Singapore Culture Code
End-to-End Ownership
Top
Engineers at OGP are involved in everything from ideation, requirements gathering and implementation to QA, releasing, gathering feedback, monitoring, analyzing key metrics and iteration, maintenance (rolling out fixes and improvements), and refactoring. Engineers here often play cross-functional roles e.g. Wearing a product manager's hat and working in tandem with their designer and product manager colleagues to determine product roadmap and execution. In cases where the codebase is open-source, such as FormSG, they may also handle and review code contributions from members of the public.
Move Fast
Top
At OGP, teams believe in quick ideation and implementation. Here engineering teams are small and self-organized. We avoid bureaucratic processes to build and deliver impactful products faster. This has allowed us to rapidly respond to challenges of national significance at the behest of the Singapore Government, most notably taking two weeks to build the prototype for "Appointments for COVID-19 Vaccinations".
We favour decision velocity over accuracy. Engineers here correct course over iterations through feedback and break down the work into smaller chunks - Design, Develop, Test, Repeat.
Learning Oriented
Top
Learning & development serves to help you maximise your long-term impact at OGP and on the public good.
This is especially urgent in the software development industry, where technology and innovation progress rapidly, and failure to keep pace means our work will cease to be relevant and impactful. This holds regardless of function–from engineering to product management to organisation design.
Learning at OGP typically happens through a variety of events and mechanisms, namely: annual Hack For Public Good in January, our performance cycle, ad-hoc sharings, learning Fridays, and Learning Month in December.
This is especially urgent in the software development industry, where technology and innovation progress rapidly, and failure to keep pace means our work will cease to be relevant and impactful. This holds regardless of function–from engineering to product management to organisation design.
Learning at OGP typically happens through a variety of events and mechanisms, namely: annual Hack For Public Good in January, our performance cycle, ad-hoc sharings, learning Fridays, and Learning Month in December.
Open Communication
Top
The "Open" in Open Government Products refers not only to our transparent engagements with the public but also to how we interact with one another in the workplace.
This is not only done through the way we talk about incidents and setbacks through regular team syncs and sharing but also through actively encouraging open internal discussion. The transparency also goes as far as fully disclosing the salary point tied to each level for each role in OGP’s career ladders.
This is not only done through the way we talk about incidents and setbacks through regular team syncs and sharing but also through actively encouraging open internal discussion. The transparency also goes as far as fully disclosing the salary point tied to each level for each role in OGP’s career ladders.
Team Oriented
Top
The hypothesis is that small technical teams given direct ownership of public sector problems will solve them more effectively than the traditional top-down, inter-agency, or procurement approaches. This minimizes the overhead and allows the teams to focus on simple solutions to well-defined problems.
To that end, product teams start small, typically consisting of 2-3 engineers, a product manager, and some commitment from a product designer. As the product matures, the number of people involved may grow to about 10.
Engineers, designers, and product managers are all peers within a team. So while product managers still handle project management, management never trumps design or engineering.
To that end, product teams start small, typically consisting of 2-3 engineers, a product manager, and some commitment from a product designer. As the product matures, the number of people involved may grow to about 10.
Engineers, designers, and product managers are all peers within a team. So while product managers still handle project management, management never trumps design or engineering.
Innovation At Every Level
While new technology is the most visible part of digital transformation, the bigger value is how it enables better organizations through improved culture and practices. These include design thinking, data-driven decision-making, continuous testing, open communication, and honest feedback. Digital transformation requires not just building new applications but redesigning the entire experience of how the government operates and interacts with people’s needs.
Open Government Products, GovTech Singapore Culture Code QnA
<div>The code review is a critical part of our development process where the team discusses software design. By doing code reviews, we hope to achieve the following:</div><ul><li>Maintain high coding standards</li><li>Increase the familiarity of the codebase within the team.</li><li>Identify mistakes early. It is ok to make mistakes. </li></ul>
<div>We follow a systematic way to be contacted when monitoring systems detect something has gone wrong. This can be a full-fledged system like PagerDuty, or something as simple as a Slack integration. As long as alarms go off and people get notified when something goes wrong. We may not be able to resolve the situation immediately, but at least someone has to start looking into it and activate the rest of the team if necessary.<br><br>For more well-established systems, it makes sense to specifically come up with a duty roster to designate who is on-call every week. In even larger teams, you may even have a primary and secondary on-call. The idea is that someone is designated to be responsive in the event something goes wrong, and you do not risk everyone being unavailable at a critical moment.</div>
<div>The performance levels of people are based on three inputs:</div><ol><li>Record of work done over the last year (contribution and impact)</li><li>Peer assessment (done by all OGP staff and weighted based on exposure to the person assessed) based on technical career schemas</li><li>Manager’s assessment taking into account the two above-mentioned inputs</li></ol>
<div>At OGP, learning is primarily self-driven. This is in line with OGP’s culture - hire the best people, empower them, and give them the autonomy to make an impact. </div><div><br></div><div>You will be provided with the resources to learn, and your managers will do their best to create the time and space for you to do so, along with providing coaching and guidance. Beyond this, you alone are responsible for deciding whether you learn, what you learn, and how you learn best. </div><div><br></div><div>But how exactly does learning happen?</div><div><br></div><div>Generally, we expect about 70-80% of learning to happen on the job, while the remainder happens more intentionally in formalised workshops or through organisation-facilitated initiatives like peer mentoring, talks, etc. </div><div><br></div><div>This doesn’t mean we leave it purely to chance or personal initiative. At OGP, your learning environment is shaped by four key levers (not including events like HFPG): </div><ul><li>Learning on the job</li><li>Your manager </li><li>Performance cycle</li><li>People Ops</li></ul>
<div>In OGP, people are promoted based on their performance irrespective of staffing needs.<br><br>If the performance of the individuals is in line with the next level in the hierarchy, they get promoted. However, external interviews are done to expand the team and drive more impact.<br><br>We believe in bringing in great people and then giving them the autonomy to work on building tech for the public good.</div>
<div>Our main job is to design, evangelize, and implement software to serve the public good</div><ul><li>Design: Identify areas where technology can help and build prototypes to show it</li><li>Test: Present prototypes to stakeholders and persuade them to test the idea</li><li>Implement: Pilot ideas and build them out if successful</li></ul><div>The hypothesis is that small technical teams given direct ownership of public sector problems will solve them more effectively than the traditional top-down, inter-agency, or procurement approaches. This minimizes the overhead and allows the teams to focus on simple solutions to well-defined problems.</div>
