MyCareersFuture: As Told By The Technical Team
You’ve heard about it, you’ve seen the advertisements. Now see what it’s like behind the scenes!
So we launched our latest offering about two months ago, a product targeted at helping local Professionals, Managers, Executives and Technicians (PMETs) find employment in the later stages of their careers.
Like how all good stories begin, we start with why.
Before Development Begins
Way before development starts – around 4 months prior – all products destined for the keyboards of engineers at Government Digital Services (GDS) undergo a phase called product conceptualisation.
During this stage where we’ve been tasked by the various ministries/agencies to solve a problem with technology, we take the time to talk to users about the ‘problem’ and find out whether it is a problem technology can solve.
This all happens before the creation of any prototypes begin and makes sense because the highest cost one can incur during product development is creating a product no one uses. Simple stuff.
For our particular product, the problem we were tasked with was:
How could we use technology to assist experienced local PMETs regain employment in the disruptive innovation economy?
User Research
During the first phase of validating the problem statement, we spoke to users who fit the demographics identified by the commissioning body. In our case, this was identified to be:
- Unemployed local PMETs (with a primary focus on those in their 40s and later)
- Human Resource departments
- Hiring managers
We visited these people at their homes, offices and at coffee places to gain insights into affairs such as the problems they faced, how they used/interacted with existing solutions such as LinkedIn and JobsBank, and how they expected to be assisted by the government.
Something different about how we do things at GDS is that regardless of one’s role, we are able (and even encouraged) to attend such sessions.
While seemingly inefficient (what do developers in caves know about humans anyway? 😉), this has resulted in our engineering teams being highly engaged and connected to the problems we solve. “The User” no longer becomes a faceless object we see in UML diagrams, but living, breathing humans that share in our ways of life.
This results in passionate discussions between engineering and business units about how we can best help through certain features, user experience and overall design.
Synthesis
After speaking to people on the ground, we would meet on a bi-weekly basis to share our observations and assessments on the interviews we sat in.
During this session, we come up with patterns we are seeing across the interviews and derive potential features we believe could best assist these people we had spoken to.
The best part about having engineers be part of this conversation is that technology does not get romanticised and solutions that emerge are usually technically feasible, sometimes even including novel uses of more obscure technologies that business development teams may not know of (nope, I’m not speaking of jobs on a blockchain).
Product Conceptualisation
Post-synthesis when the problems faced by our target users are fresh in our minds, we conceptualise micro-products which can solve the common problems we identified during synthesis.
This session is where majority of our features come from. Recurring micro-products eventually become features of the final minimum viable product (MVP) which would be a more wholistic product designed for an end-to-end experience by eventual users.
The Product
The pre-development phase concluded with a resolve to create a job search platform with a different focus than private-sector solutions and which addressed the issues that JobsBank faces. Our main value propositions:
- Skills-based matching to assist PMETs from traditional job roles in identifying jobs where their existing skills may be applicable
- Increase awareness about available government schemes for job seekers and employers alike and facilitate its uptake
- Nudge employers to give fair consideration towards local PMETs and to close the loop with job applicants
- Nudge job seekers to upgrade their skills
- Empower policymakers to adopt a data-driven approach towards assisting unemployed locals
- A mobile-first approach with a focus on an empathetic yet modern user experience
Engineering a Usable Product
After all’s been said and done during the design phase, it was off to actually creating something out of nothing (one of the wonders of engineering – but that’s another story for another time).
It was a Tuesday evening and we had just completed our first stakeholders meeting with our primary Product Owners. Our seed team had a total of five people:
Just like this, the technical development journey began.
Storification
With the big ideas in place, we started to break down these massive features into smaller, more digestible parts that would enable us to better estimate the time and effort required to complete an MVP.
This basically meant meeting after meeting on estimating technical efforts and striking a balance between business and quality engineering. While tiring for developers, it is necessary.
Since we adopt the Agile methodology for creating products, having smaller features means that at any time, should ongoing user research indicate a feature was not as useful as we thought it would be, we could scrap it in favour of other features that would be of better use.
These stories were then placed into what we call a Product Backlog, which is a massive list of user stories which can then be prioritised and re-prioritised as the product evolves.
Understanding the technical effort required also allowed the product owners to better prioritise stories based on which features were considered as low hanging fruits, enabling a high-impact low-effort focus on development.
Prototyping
Once stories have been set in place, it’s time for some visualisations to allow our stakeholders to have a better idea of what the product would actually look like. Here were some of the early prototypes which Alvin Leu, our UX designer, created:
In case you were wondering, yes, we prototyped with the name ‘Talent@SG’, but being Agile, usually nothing is fixed until it is done. Here’s one of our later prototypes would eventually serve as our development wireframe:
The colour scheme and choice of layout was not chosen arbitrarily. Each of our early prototypes were shown to and tested with users from our target demographics, to verify it’s emotional empathy as well as ease of use.
Upsizing our Engineering Capacity
Obviously a development team of five (with only 2 engineers) wouldn’t cut it for delivering a product at the scale of JobsBank. Our first move was thus to ramp up the engineering capacity. Since all of us came from other existing product teams at GDS, we also had to backfill our vacant positions, and what followed was intensive screenings to filter out who would excel in our team and product development.
One of our focuses when hiring was to have a team that wasn’t just technically proficient, but also believers of the product’s cause. When engineers believe in what they’re creating, another wonder of engineering will expose itself – a coordinated dance with business development that produces features which achieve business value beautifully.
The technical proficiency of a team only ensures a product gets up and running. But we didn’t want just another product did we? We needed our product to empathise with its target users. For that, we also required a final touch – a team identity and culture.
Seeding a Team Culture & Identity
No engaged team, technical or otherwise, is complete without a strong sense of identity. Since most of us in the seed team were kinda-sorta-ish Lord of the Rings fans, we based our product team’s identity on the classic novel.
And… We kinda took it a little too far. We present to you our early Continuous Integration/Delivery status board (turn up the volume to hear what happens when our pipeline fails 😅):
And here’s our team board late last year with half of our positions filled.
And oh yes, our team was christened Rivendell!
Rise of a New Tech Stack
Since the start of our tribe, Agile Consulting & Engineering, we’ve been using the highly capable Ruby on Rails (RoR) framework.
Since the start of our tribe, we’ve always been pushing the boundaries of open source technologies (we went from ERB to Angular to React in one of our more mature products – Business Grants Portal).
This time was no different.
Choosing a tech stack is kind of like naming a child – one doesn’t simply change it down the road without good reason to, but then again, what’s the point of having two children be exactly the same?
Considering the scale of this project and the differences in business utility between our other product based on RoR, we decided on using Node which in recent years has gained reliable momentum – establishing a credible technical committee, backward compatibility plans, long term support release plans and predictable release cycles.
We also considered other factors that affect the longevity and effectiveness of using an open source runtime, some of which were:
- Number of other organisations using Node
- Number of contributors to the Node project
- Availability of engineers locally who understood and applied JavaScript
- Node’s global developer ecosystem as assessable through GitHub project and Stack Overflow question tags
- Node’s package ecosystem, NPM (which turned out to be the largest ever seen)
Also considering that all internet services facing users require JavaScript (it’s the only language that runs in a browser after all), this choice was not difficult to make.
In addition to the development tech stack, we also had to consider our supporting services and their availability on the government network. A relational database was in order due to the many relations in the data we had to work with, and we went with MySQL.
Technical Architecture
Thankfully for us, our in-house developed container orchestration Platform-as-a-Service, Nectar, had recently been launched, enabling us to design our technical stack around containerization technologies such as Docker and Kubernetes.
Given these new capabilities, we decided our end-goal architecture would be comprised of microservices that could easily be replaced as technology evolved. Having multiple services working behind the scenes meant smaller codebases with higher levels of disposability, bound only by their contractual duties. This would allow us agility to change tech stacks easily or even develop our product using multiple technologies simultaneously.
“The best architectures, requirements, and designs emerge from self-organizing teams.” — Principle #11, Agile Manifesto
In agile, we take an evolutionary approach to architecture. We decided to start from Services Oriented Architecture (SOA) and allow the product to organically divide itself into smaller parts from there depending on how the business use cases evolved.
Fun fact: At the point of writing, we have four of such services, three in Node and one in Kotlin – the last is an exploration effort by some of our team members.
Towards Continuous Integration (CI)
Armed with our tech stack and an end-goal architecture plan, next up was deciding on how we would automate our quality checking process – our testing – and our production deployments.
We utilise an on-premise installation of GitLab which provides us with a single source of truth for our code. GitLab also has its own in-built CI agents that can be deployed and managed through the traditional virtual machine (VM) way, or through a Docker engine, allowing us to pretty easily scale our pipeline as our team grew.
Next was establishing the Definition of Done along with the various environments – QA for quality engineers to implement integration tests, UAT for product owners to review and approve features, a staging/canary environment for testing our deployment, and finally production.
We did our pre-production environments with Kubernetes which Nectar is based on so that potential problems could be raised early on in the delivery pipeline.
The Launch
After almost a year of technical development fraught with challenges of managing business expectations and integrating with existing government systems, we went live on 17th April 2018, a date that’s bound to be etched in our minds for a long time.
And… You can check us out at:
It’s definitely not perfect yet or as refined as more established products like LinkedIn, but hey, it’s a start! And moving forward…
Next Steps
Iterative Improvement
Our launch is just the beginning of our journey towards helping local experienced PMETs regain employment. This means that even as you use our platform, we’re constantly updating it (every two weeks or so) with new features that have been identified by our product owners as important-to-haves.
If you’d like to see a feature, you could click on the Survey link at the bottom of the page and enter your feedback on item 4. That goes straight to us, and if others like yourself have also requested for it, that makes a stronger case for us to implement it sooner.
Enabling Citizen Co-Creation
As user-centric product engineers, our primary goal is to make our product as useful and as usable as it can be to users. While the afore-mentioned survey is one way of getting to us directly, it’s also somewhat impersonal and we’re actively seeking out ways we can use technology to let users tell us what’s needed/what’s good/what’s not so good.
One way the technical team can think of is to open source our code so that should you want a feature, you could submit a pull request to us, we can review the code and confirm that it conforms to our standards, and there you have it, your very own shiny feature! But let’s see how that goes with government policies.
Keeping The Team Strong
Since there’s nothing as enabling as a strong and engaged development team, we’ll also be continuing with our team building efforts even as development moves along.
Here we are a week after our successful public launch catching The Avengers courtesy of our tribe lead, Steven Koh.
Tackling the Employers
In product development, we have a concept of ‘chicken-and-egg’ where we don’t know if it’s better to have the chicken first so we can get the eggs, or to have the eggs first, so that they can grow into chickens.
For our MVP, we identified that job seekers would come first, hence we have what you currently see. The next step to increase the value of our platform, would naturally be to get our ‘chickens’ – employers. While a part of our team is engaged in active development of the current web service, another half of us will be working towards an employers’ portal which has been slated for launch by the end of this year.
With the employer site in place, it is our hope that we can help our target groups of users, local experienced PMETs, in greater ways through nudging and gaining insights into the job application process, enabling data-driven policy making and eventually, more targeted and relevant help for all local job seekers in Singapore.
Credits Roll
So we’ve come to the end of our little short story which is really just the beginning for our product. Do give it a checkout at https://mycareersfuture.sg and let us know what you think(:
With that, here’s the complete list of people who have put any amount of effort into ensuring the smooth delivery of our product.
Product Owners
Jun Hao
Joe Tan (User Joe)
Jeremiah
Winnie
Daniel
Business Analysts
Alvin Eun
Scrum Masters
Venetia
Product Designers
Justin
Eugene
Software Engineers
Wei Jie
Rui Jie
Guo You
Raymond
Laurent
Andrian
Lizzie
Kang Ming
Zi Wei
Nadzir
Raphael
Leok Si
Gerard
Quality Engineers
Jin Jie
Vimala
DevOps/Ops Engineers
Yew Lee
Ryan
Joseph (yours truly)
Design Researchers
Special Thanks
Post Credits
Nope, there’s none. We’re not Marvel.
Or are we?
Here’s a nice visualisation created recently that shows how our code repository for the website frontend evolved from way before day 0 till today:
If you’re interested in creating high impact products in Singapore for Singaporeans, and you believe you have the technical chops, why not give us a ping? We’re hiring for future projects and you can ping me at joseph_goh@tech.gov.sg for a casual technical-human-to-technical-human chat(:
Cheers!
