Almost two years ago, the team at Obvious got an opportunity to build Simple, an app that leverages technology to help busy clinicians manage hypertensive patients by tracking their blood pressure measurements and medications. The first project from India to ever win the top prize of the “Best in Show” category at the 2020 IxDA Awards, this free and open-source project is a fast and disruptive mobile based application that is currently deployed in more than 500 facilities in India and Bangladesh and manages 200,000+ patients with hypertension.

When we first commenced work on this project, one of our key goals was to protect patient data. And as a part of this, one of the decisions we made early on was to not require any government issued ID when registering a patient in the system, something that has not changed at all till now. 

However, this introduced a new problem around how to help users of the app efficiently find a patient when they return for a follow-up visit. Healthcare systems have always struggled with looking up patients and ensuring that they are matched to their own medical information across institutions and time accurately, especially on a greater scale. We therefore tested several existing methods, each with varying degrees of success.

Searching for a patient by name

  • We implemented a “fuzzy” searching mechanism built on top of Levenshtein distance, in order to account for variations in name spellings, typos, etc. 
  • While it seemed to work at the outset, we soon came across a hurdle when we discovered a number of patients with the same names. A particularly bad case was a certain district in Punjab where over 20,000 patients were registered in the span of a few months all of whom had the exact same name, making it impossible for the nurse to find the right patient

Searching for a patient by phone number

  • We (optionally) allow users to register a patient with their phone number. This lets users call or send reminders via SMS to the patients and remind them about their upcoming appointments
  • We then administered a search mechanism that allowed users to look up patients by their phone numbers
  • While this worked really well, it had its own limitations due to the fact that we do not mandate collection of phone numbers and don’t want to either. Moreover, patients sometimes do not have phone numbers, don’t remember them or  change their numbers periodically as well, not guaranteeing a 100% identification of the patients

The birth of BP Passport  

After much consideration, we decided to employ a physical patient ID card, called the “BP Passport”. This intended to not only solve the problem of finding return patients effortlessly and quickly and maintaining a longitudinal record but also ensure that the right patient gets the right care by avoiding duplication. 

Each BP Passport has a QR code printed on it, which encodes a full UUID that is the passport ID. Since patients tend to lose their cards quite often, we decided to have a card ID instead of a patient ID so that a patient can be associated with different QRs and can have multiple cards. The BP Passport also has a 7-digit number printed on it, called the “short code” that is nothing but the first 7 digits of the Passport ID.

Technical summary on creating BP Passports in this link

The nurse can scan a BP Passport and assign it to a patient during registration, which the patient then carries to all their appointments. We designed this in a manner that introduces as little friction as possible and integrates into the workflow of the nurse. The Simple application is then capable of scanning these BP Passports to look up a patient within seconds. 

Here’s a quick video of how it all works together:

Generating BP Passports at Scale  

The problem: 

The next step was to print and ship these BP Passports ahead of time to our users so that they could spend their time doing what was important: patient care. However, the high rate at which the patients were getting registered in the system entailed printing and shipping thousands of BP Passports at one go, to ensure that they would last the facility for a few months. The roadblock that we ran into hence was the problem of generating these BP Passports at scale. 

We initially used Adobe InDesign and specifically, the Data Merge feature. We would create UUIDs in a spreadsheet that had formulas to produce the short code from the UUID. This spreadsheet would then be imported into InDesign and used to generate the BP Passports. 

What we quickly found out however was that this only worked for generating a small number of passports, since InDesign froze when working with a large number of passports and took hours to process them. This meant that we would have to manually generate them in small batches and save the final PDFs to be printed manually, which definitely did not act as a long term, usable solution. 

The solution:

When we consider a BP Passport, there are two sections: A static section that does not change from one passport to another, and a dynamic section (the QR code and the short code) that could differ between passports.

The clear sections in the image above are the “static” sections of a BP Passport, i.e, the parts that do not change.

The clear sections in the image above are the “dynamic” sections of a BP Passport, i.e, the parts that change.

Therefore, what we needed was a tool that would accept a BP Passport which has the static section filled in and the dynamic sections left blank (which we call the Passport template) and would be able to generate passports of a given number to be then sent for printing.

What the BP Passport template looks like.

We settled on writing our own tool to solve this specific problem and chose to use Apache PDFBox and the JVM (partly because it was a platform that the team was already familiar with, and partly because PDFBox had support for generating PDFs with CMYK color space, which was essential for the print material) in the Kotlin programming language.

The tool was written specifically to take advantage of multi-core processors and generate large numbers of passports in parallel. On a modern Macbook Pro, we could now generate around 40,000 BP Passports in just around 30 seconds! 

This translated into us being able to print and ship over 450,000 BP Passports to five states – Punjab, Maharashtra, West Bengal, Andhra Pradesh and Karnataka in multiple languages such as Punjabi, Marathi, Bengali, Telugu, Kannada and Hindi – all between October 2019 and May 2020

150000 BP Passports we shipped to Maharashtra, motor vehicle for scale.

Being able to manufacture such a large number of BP Passports ensures our clinicians are empowered, and can focus their efforts on improving hypertension control and preventing heart attacks and strokes. 

As with all the software by, the source code of the tool is available at


Read more

As a self-taught Android developer and a product engineer, there has never been a better time to join forces with other like-minded community members and contribute towards the greater good. It’s almost been a month since I joined Obvious, but the journey so far has been nothing short of extraordinary.

While I was familiar with Obvious and their past work, it’s only when a friend introduced me to their official Twitter handle that I came across the ‘public by default’ playbook that outlines their distinctive hiring philosophy. Right from the beginning, they stressed on hiring for inclusivity and diversity, fighting the default of exclusion through ardent commitment to craft, value fit, openness and transparency as well as culture add as opposed to homogenous teams.

A prime factor that led me to believe that it’d be the right fit for what I was looking for was their refreshing interview process for engineers, one that left me pleasantly surprised. Rather than being quizzed on data structures, algorithms and whiteboard problem solving, they wanted to understand the depth and breadth of my knowledge about a platform of my choice, my drive for learning and honing programming skills and the ability to think of the entire product as a whole.

(Why we do not have data structures and problem solving rounds)

Abiding by the belief that engineers would be able to “know what they do not know” and research sufficiently to gain the necessary skills, Obvious employs a thorough three step hiring process that involves:

Understanding one’s opinions

To get a better sense of one’s thought processes and experiences and learn from everyone’s point of view, Obvious focuses on elaborate answers to several questions both on a personal and a professional front. 

Rather than testing my knowledge through an existing example, they asked about my preferred programming language and what I liked / disliked about it. While I love both Java and Kotlin, my unbiased answer was Kotlin, since it provides much better support for functional programming in my opinion. When inquired about a great technical essay, book or video that I abide by, I knew it had to be Living the Code by Enrique Lopez for obvious reasons! 

What stood out though as compared to other counterparts, was that while they wanted to understand my rationale behind wanting to join the organisation, they were also keen on what advice I’d give my younger self.  Probably why since day one, I was clear on choosing Obvious because of their shared enthusiasm to learn, explore and adapt. (See how well that worked out!)

Building an Application 

The second step involves building an application iteratively using publicly available resources and specific guidelines, to then later host the solution as a public repository on any service and help gauge the strengths and capabilities.

At the time when I was applying to Obvious and going through the second assignment, I was already working with my previous firm as a stand-alone developer on a time sensitive launch. When I couldn’t revert on time initially, the people team from Obvious politely reached out to me out of concern and helped figure an alternate date instead of rigidly focusing on deadlines. This proved to not only be a testament to their commitment towards people and product alike but also motivated me to go beyond and deliver. I ended up making a note application where users could cross-collaborate, create and view notes, for which I received highly constructive feedback. 

(Evaluating a take-home exercise)

Spending a day at Obvious

The last step in the hiring process involves spending a day at the office, writing code, meeting the team and understanding the work culture. 

Post a 1:1 conversation with the team lead, Vinay, I was invited to spend a day at the wonderful, sunny and cheery Obvious office. The day featured a thorough tour of the lush, green and positive space, an ice-breaker pairing exercise and an exciting team lunch followed by a personal meeting with Pratul. The conversation with him delved deeper into my goals and other future oriented questions that pushed me to look at the bigger picture, albeit with a little difficulty at first. One thing that I can definitely vouch for is unwavering support, at every step of the process and even after!

Within a week’s time, I had an email from Obvious in my mailbox offering a position and since then I’ve learnt more about myself, the community, new friends at work and the clients than ever before.

In the last three weeks, I’ve not only experienced a conducive atmosphere that encourages empathy, openness, and self-disclosure but also a hopeful and helpful team that has been built on a strong foundation for smooth operations, despite working remotely. The weekly ‘Resilience Sessions’ are endearing and feature people sharing their traumas and openly talking about situations that have challenged their mental health to ensure we know that we’re not alone in trying times such as these.

If the Obvious Way makes sense to you, please fill out this form. We’ll keep you posted, give you the lowdown on life at Obvious, and answer any questions that you might have about engineering or working here!

Read more

The Trunk Based Development website says “[…] a source-control branching model, where developers collaborate on code in a single branch called “trunk” and resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after.”

That sounds great… but what exactly is it, and why should you care about it? For a bit, let’s forget about code and branches and use an analogy that is easier to understand — the transit system of a city.


When is the next train?

Imagine a city with lots of different train stations. The network can run using lots of trains at different frequencies. Let’s consider three different scenarios:

  • A train passes through each station once every day
  • Trains pass through each station six times every day
  • Trains pass through each station a hundred times every day


An intra-city train network


What will be the effect of the three different possibilities on the people living in the city?

In the first case, if a person misses the train there is no other way to reach the destination until the next train, which unfortunately will arrive on the next day.

In the second case, if a person misses one train they can catch another train in a few hours and won’t have to wait for an entire day to reach their destination. This means people don’t care about the schedule of the trains as much as they do in the first case. It is possible to reach the destination in a few hours — late, but possible.

In the last case, if a person misses a train they can easily catch another train in a few minutes. It’s easy to imagine that people will stop caring about the train schedule altogether and focus on what they want to do at the destination. The transit system becomes an artifact that recedes in the background, letting people concentrate on what they actually want to do — living their lives and getting things done!

Now let’s go back to building and delivering software.


Feature-driven delivery a.k.a. Unpredictability

In a lot of teams, the frequency of releases is determined by “when this Important List of Features gets done”. That leads to unpredictable releases with large delays between deployments. Although such teams try to “fix” a release date and try to cut scope so that the Very Important Date can be met, it rarely works.

Engineers working on different feature branches rush to get their tasks done before The Date. Merging all of those feature branches becomes a painful ritual as people discover all sorts of changes that have happened in the repository over the past few weeks that they were working on their own branch. Merge meetings are scheduled and a War Room is created to tackle issues that stand in the way of meeting The Date. Inevitable, The Date starts to move. Seven “medium priority” bugs that customers have been complaining about need to be fixed. The CEO’s personal favourite feature request has to be part of this release even though the team heard of it a week ago.

Every little thing is important because who knows when the next release will go out? The entire team — nay the org — rallies around The Date even though it has changed three times and the original date has been forgotten.

There are some themes that emerge in this familiar scenario:

  • Merge hell, as discussed above, since multiple, long-running feature branches become part of the primary codebase very close to The Date.
  • Massive changesets to review, or what happens in reality, no code review at all. Reviewing a three-thousand line diff that has been worked on for two weeks is an exercise in frustration.
  • Favouring the Rockstar Programmer over the team, since it is considered acceptable and natural that a great engineer will disappear for a few days or weeks, and come back with all the work done in a branch far, far away from the rest of the codebase. Merging is the team’s collective problem, unfortunately.
  • Emotional turmoil and a high probability of burnout for everyone in the team especially as The Date inches closer.

So what is the solution to this problem? We need to increase the frequency of the trains, of course. Hundreds of them every day!


Timeline-driven Delivery a.k.a. Daily Success

For software engineering, that implies…

  • We increase the frequency of production releases to as frequent as possible — daily, or even hourly!
  • We drastically reduce the size of changes that are merged into the trunk. As each merge request becomes small, reviewing it becomes far easier.
  • Since each merge integrates only a small number of changes, the possibility of conflicts also rapidly goes down. When conflicts do happen, resolving them is fast and painless.
  • Changes arrive into the codebase on a daily basis, which means the team is aware of the state of work that is in progress. Any impact from the changes being done is felt very early in the process, giving the team ample time to reach a resolution.


All of this sounds great in theory and it makes sense. How about in practice?

  • TBD promotes short-lived feature branches and frequent merges with the trunk. A branch usually has only one developer, it doesn’t last more than a day or two before it gets merged into the trunk.
  • This automatically pushes teams towards Continuous Integration. Every commit that lands on the trunk goes through the CI pipeline, confirming that it is indeed ready for integration.
  • Once continuous integration is in place, it is natural to follow it up with Continuous Delivery. Since all commits that land on trunk have been marked “stable” by the CI pipeline, they can be deployed immediately.
  • Since an approved code review means the code will be available on trunk immediately, teams rally together to review code as fast and as many times as possible.
  • Not everything can be done within a day, and features can take a long time to build. In those cases, work-in-progress code is “hidden” behind a feature flag. Flags ensure that incomplete features can be reviewed and still land on the trunk.
  • Flags can also act as a remote control for making features available at a later time. Features can be fully developed and be part of the codebase, and then be remotely toggled on (or off). Once a feature has been “enabled”, the alternative code path and flags can be deleted from the codebase.


All of this comes together to ensure the codebase is releasable on demand. Bug fixes are deployed as soon as the fix is available on the trunk. Teams stop coordinating releases to figure out which commits are “safe” to release.

Developers go back to focusing on what is important — building features and eliminating bugs — rather than being burdened with a release date.


We’d love to help your team with continuous product growth and learning. Get in touch!


Read more

Over the last year, we’ve changed our career growth evaluation. We transitioned from a “levels system” to a more comprehensive multifaceted system. 

While the transition wasn’t smooth, it was more than worth it. We learnt to evaluate each other thoughtfully and acknowledge the role a team can play in the development of an individual. 

Here’s a quick overview of why we made this change, what we created and how we implement it.


We strongly believe that people produce great work when they are at their natural best. Forcefully reducing them to experts vs generalists, or individual contributors vs managers, hampers their growth instead of boosting it.

At Obvious, we look for multi-faceted, T-shaped individuals, who bring a lot to the table other than just their craft. To nurture and accelerate the growth of such people, over the years we’ve experimented with several different frameworks. We’ve finally resolved to the one that follows.


The Framework

The framework is divided into 3 parts – Creating, Executing and Supporting, each of which has 3-4 different skills. Each skill is further divided into 5 different milestones. As you go deeper, or take on more responsibilities, you cross a milestone.

In general, you must have demonstrated the 5Cs – “Conscious, Comfortable, Continuous, Consistent Competency” defined as follows:

  • Conscious: having devoted intentional effort to this endeavour,
  • Comfortable: without being overly stretched,
  • Continuous: for a reasonable period of time,
  • Consistent: reliably and evenly,
  • Competency: meeting the criteria.

We have a seperate Design Growth and Engineering Growth Framework that you can explore in detail. 

This framework is inspired by the fantastic work done by the folks at Medium.


A 360° process

Evaluations are done in a comprehensive and transparent manner, facilitated by the manager. 

  1. Each person self-evaluates themselves.
  2. Everyone in a project team evaluates each other.
    • To prevent bias, no one should be able to see someone else’s evaluation of a person!
  3. Each individual is evaluated by their manager.
  4. Managers collate all the evaluations and consolidate them.
  5. The consolidated feedback is shared by the manager in a 1:1 conversation with each individual. 

Assessment Cycles

We run formal assessments (using our growth frameworks as a basis) twice a year, once in February, and the next in August. Everyone at the company has to receive a completed assessment by the 1st of March, and the 1st of September respectively. If the assessment leads to a level change, then the impact of that level change (compensation etc) will take effect from the 1st of April or the 1st of October. 

Guidelines for Feedback

  • Specific examples everywhere are important! Use the situation-behaviour-impact framework to make your case.
  • To ensure that someone definitely lies on a specific milestone, remember the 5Cs.
  • In case you don’t have sufficient information about a facet, please talk to the person and your manager. A year is a long period of time, and it is good to get clarification in case you think you’re forgetting something.
  • Feedback provided in an evaluation cannot come as a surprise to the person. Such a data point will be disregarded. All comments — positive and negative — should be a summary of the feedback provided through the course of day to day work.

If you’re looking to work in a team that aims to grow together, you should know that we’re hiring. Join us!

Read more
By Monica Pillai

The on-point, offsite

In healthy, growing organisations, “culture” is an ever-morphing, evolving thing. Sometimes as companies evolve from close-knit groups of a dozen people the old bonds can evaporate, even if that growth is organic and not sudden. However, such a situation can be turned into an opportunity to bring colleagues even closer together, if there is an alertness to this need. A structured team-building effort like an offsite, designed to build connections can really be the ticket. Offsites can really work well… or completely bomb. It all depends on the awareness of the needs of the audience and depth of the offsite design. For our offsite, our wish was to have an experience where people could bond deeply with each other across teams; build mutual trust and respect and experience a sense of belonging; and experience openness and empathy, while holding each other accountable for shared goals.

The plan

For our first offsite of 2020, and the first with over 20 people in attendance, we went with a recommendation from colleagues, who had recently seen the value of experiential outbound learning for a client they accompanied. We decided to spend two days at Pegasus Learning for Excellence. The offsite was an exercise in experiential learning: teams play, interact, plan and execute a task, and then come together to dialogue, introspect and deepen their understanding of themselves and others. Using Kolb’s learning cycle, the program design had built in spaces for participants to question their own habits, challenge inhibitions, confront fears and express feelings non-judgmentally.

The plan was for us to go to Pegasus’s Bangalore campus, two hours drive from Bangalore, in Doddabalapur. The information received mixed reactions: there was curiosity and excitement about the experience and there were questions about the levels of physical difficulties – were we expected to rappel down cliff faces or do fireman’s lifts on colleagues? We thought the fears were allayed – but the day before the offsite, we were at 18 people attending, and a mounting cancellation count of 9 people. A third of the office was not coming! Factoring in illness, etc., we were still starting off on a worrying note.

The experience

We left from office, at the end of a day’s work on Thursday, 23rd January, piled into two buses, told stories, played games, and barreled towards the relative quiet of the outskirts. We were welcomed to the campus, shown our living quarters (four tents, each accommodating 4-5 people and dorm style bathrooms). Some stone benches in the middle made for a convenient spot for everyone to gather for natter, and admire the night sky. After a hearty meal around a bonfire, we were told to “report at the small gazebo at 8.29 am”. The quiet ones retreated to their respective tents after an hour of chatter, and the energetic ones went on till 1am.

On the first morning of the offsite, we walked into said small gazebo – not at 8.29 am. All of us, including those who walked in at 8.38am, were greeted with the same smile by our two facilitators – Sudatta and Deepak. Phew! We were told that we will wait for the last participant to come in, before commencing, no judgment and no pressure. What a great start.

The program design was a work of art in how our boundaries expanded slowly and gently. In the first activity, we felt very little discomfort. We split into two teams and stood on two carpets. The task needed people to switch from one to another, and as it got crowded, some of us propped up others. It was telling, when someone said, “I knew I was supported when I lost balance – but I don’t know who all supported me. Thanks everyone, for the support.”

In the second activity, people had to be moved from one space to the other with constraints. We realised that each person needed to be lifted by others off the ground, moved a few feet, passed on and be received by another set of people and gently set down on solid ground again. This 45 minute long task brought to the fore realities about trusting others, shouldering the responsibility of that implied trust, and letting go of fears of feeling like a burden to those doing the lifting. This created more discomfort at the start, but beyond that, it welcomed us into a space of heightened trust.

We spent the afternoon in a deceptively simple activity, which contained great depth. In groups of fours and fives, we told each other personal stories of adversity and resilience and appreciated each other. This automatically surfaced people’s vulnerabilities as strengths and not weaknesses. We also drew our vision of how we see Obvious now, what we’d like to see in three years and what stands in the way. We then shared this with the larger group to much applause and acceptance. The evening set the tone for more childhood stories, more conversations, more walks in groups of all sizes, and much laughter.

The evening set the tone for more childhood stories, more conversations, more walks in groups of all sizes, and much laughter.

The second day started off on an unexpectedly absurd but charming note, with the whole group singing ditties and warming up for the task at hand: To work with each other to race against time in a sophisticated version of “the floor is lava” Many opinions, a couple of misses, new folks taking the lead, and finally, #OneTeam succeeded in the task at hand.

The penultimate activity saw half the team blindfolded to play a game that tested the group’s ability to communicate, while the other half of the team watched on.In the reflective silences at the end of this activity, we did some introspection of our own work needs, perspectives, how we share these now, and what can we keep/ change in this mix.

To close the two days of work, we looked at the gap between how the organisation is currently and where we want to go. In two groups, we shared three poignant wishes each, with the other team. With a resolve to convert these wishes into goals and meet our facilitators in 45 days, we called the offsite to a close.

Looking back

What contributed to this offsite being memorable, fun, depth-filled and allowing for true bonding? Here are the top 3 reasons:

Groundwork: The Pegasus team did research on Obvious and experiences culled from their work with hundreds of organisations at different stages of being. The introductory conversation with People Ops helped too, where our needs were shared. The Pegasus team spent half a day at our office, interviewing 50% of the participants, understanding their needs in their own words. This went beyond corroborating what they heard from People Ops – this helped them build the foundation for the workshop.

During the workshop, the two facilitators talked to each other in between activities, gauged energy levels and planned for changes to the next activity to ensure maximum engagement.

Safe space:The way the facilitators set up the space was to constantly maintain a level of visible respect for all. It showed in the small things: always waiting for the last person, for instance. And it showed in the big things: always have an inviting smile for every response; asking for deeper reflection, but not necessarily, asking people to share the outcome of that reflection.

Allowing silences:The facilitators helped us surface our opinions into the safety of our circle, watched out for ideas to not be shot down, and ask deeper questions for reflections. There were many instances of very comfortable silence, which helped us to reflect on our own journeys, our own needs, and talk about them.

One of the implications of a successful project is that the bar has been set higher for the foreseeable future. For the next offsite, in addition to maintaining meaning, bonding, a great experience, the challenge of higher participation is now added. Challenge accepted.

Read more

The What

Feedback conversations are a chance to give your colleagues healthy, honest feedback about their work or interactions. When done properly, they offer an opportunity for regular, consistent growth as well as a chance to establish deep, credible relationships. These short conversations, let you show your team members you care by offering constructive criticism or praise.

The Why

The only way to help your team improve is by telling them what they are doing correctly and how they can do more of it. Or, by telling them what they are doing that is ineffective and how they can avoid or do less of it.

People often save this kind of feedback for one-on-ones, which does not help because the context is lost or it is too late to do anything about. It is important to provide praise or criticism as close to the event as possible. Holding back comments causes resentment to build up that often comes to a boiling point and explodes. Also, it’s nice to compliment team members. At Obvious, constructive feedback is a way of life!

Use the following four steps to ensure that feedback is both objective and constructive.

Step 1: Ask & Listen

Before providing feedback, verify that your understanding of the situation is correct by asking a question or two about what they were trying to accomplish. This ensures that the feedback is offered in the right context and that the person on the receiving end does not feel misunderstood. To do this effectively, use the Situation -> Behaviour -> Impact (SBI) model.

Example: When we met with the client this morning and she asked how our team would decide how we find candidates for the user studies (situation), you told her that we will not discuss that today and that it was not relevant to the conversation (behaviour). She stopped participating and cut short our proposal meeting (impact). She wanted a better understanding of our process, and she felt that her questions were not considered important. I would love to hear your take on the situation.

Now that you confirmed your evaluation, it’s time to let the other person talk. Genuinely listen to what they have to say.

Try the following tips to be successful in this step –

Focus on the Situation

When seeking clarification, ask unemotional and non-judgemental questions. They should be about the work or idea, not about the person, and stick to the facts. Find out what they were trying to accomplish.

Focus on Listening

Talk less, listen more. Instead of thinking of a rebuttal when someone else presents their idea, actively listen to the speaker. Give your colleague time to think and answer. Try being comfortable with pockets of silence; they often help create a safe space for the speaker.

Step 2: Guide

Once the context has been established and the other person has presented their take on the situation, now is the time to provide feedback. Think of guidance as a tool that helps, not a whip or a carrot. Offer genuine advice on how to continue the behaviour or make it better.

Try the following tips to be successful in this step –

Default to Good Faith

When providing constructive criticism, trust that the person receiving it tried their best. If you receive feedback, believe that the person giving it is trying to help you.

Criticize in Private, Praise in Public

Deliver critical feedback privately. Criticism can lose its constructive power when done publicly because some people become defensive, escalating the situation. On the other hand, appreciation gains exponential leverage when offered in public.

Start with Genuine Praise

Obvious is filled with smart people, and we can all learn something from each other. Nearly every situation has positive aspects, so start there. Beginning a conversation with praise opens people up for receiving criticism, but ensure that your comments are genuine because people will see through it.

Use Radical Candor

Radical Candor is a fantastic framework for providing honest and constructive feedback to colleagues. We recommend that you read the book or listen to the podcast. The framework relies on this simple idea: In order to provide clear and candid feedback to your colleagues that challenges them directly, you must first establish a deep sense of trust and show them that you care about them personally.

One-on-one meetings offer a solid opportunity to go up on the “Care Personally” axis with your colleagues. Once that is achieved, it’s easy to provide candid feedback because it helps people open up to being “Challenged Directly”.

Step 3: Discuss

After providing feedback, there is likely to be a discussion. For praise, the conversation will probably go smoothly and may simply be a “thank you”. Regarding constructive criticism, it is important to give the person time to absorb the information and ask for further clarification. Answer their questions with facts, not emotions.

Try the following tips to be successful in this step –

Be Mindful of Your Words

No matter how hard you try to depersonalise the feedback, it is personal for the person receiving it. Telling someone to “not take it personally” is similar to telling someone “not to be sad”. Using the words “works/doesn’t work” instead of “like/dislike” keeps the conversation focused on facts.

Distance Yourself From Your Work

If you’re the one receiving criticism, genuinely listen to the advice. Distance yourself from your work and critique yourself objectively. If you find fault in what you’ve done, then you can improve it. Receiving criticism without letting it hurt you is a true skill that takes practice.

Provide Direction, not Navigation

Telling people what to do, doesn’t work. Nobody likes to be told what to do. When giving feedback, only provide direction, not step-by-step navigation.

Play “Yes and…”

The premise of this common improv technique is to accept an idea as true and build on it. The goal is to refine ideas and gain clarity. Reserve judgement of others’ suggestions until you fully explore them. For example:

Person 1: I know this might sound crazy because we have an upcoming deadline, but running another user study before we make a final decision might provide the clarity we need.

Person 2: Yes, and then we can be sure that this feature is relevant for our users. Let’s talk to the product manager about pushing the deadline out a few days.

Step 4: Resolve

After a short but healthy discussion, the feedback could be complete, or you may decide to continue the conversation later. If you defer, set a clear time and commit to it. No matter how the conversation ends, leave on good terms. A simple “Thanks for listening!” goes a long way.

Try the following tips to be successful in this step –

Time Box

These informal feedback conversations should be relatively short. If the discussion becomes heated or lengthy, it’s best to postpone the talks and discuss it later.

Follow Up

If you deferred the discussion, don’t spend time trying to bolster your case. Go into the meeting to listen and clarify.

If you’re looking to work in a company that invests in you, you should know we’re always hiring. 

We’re looking for engineers, designers and researchers across all levels and would love for you to join the team.

Read more
The What

Team conversations provide an opportunity to reflect on the previous week’s work, share important updates, and discuss and debate decisions that may need course correction. These conversations also create alignment between team members and set the direction for internal and external projects for the upcoming week.

The Why

Communication is vital to every project, so it is important that we dedicate time to bring the team together. When everyone is aligned, projects run smoother and more efficiently and lead to exceptional products. Team Conversations confirm that the team has a common direction, and everyone’s efforts are geared towards the same larger goal. We recommend the use of the following framework to run team conversations effectively.

Step 1: Reflect

Recommended time: 20 minutes

At the beginning of the meeting, team members update the project board with short snippets of what happened last week. Everyone then reviews their colleagues’ reflections in the context of the project plan and key metrics, quickly making notes, and the discussion begins:

  • What went well last week? How can we do even better this week?

  • What did not go well last week? How can we make improvements this week?

Step 2: Update and Clarify

Recommended time: 20 minutes

Next, team members look at what is planned for the upcoming week. They update the project board with new tasks and remove redundant ones. They also add comments about issues that might directly or indirectly impact the project.

Direct Impact: “We need to run a user study to test an idea that we’re not confident about. This will require 3 additional days that had not been previously planned”.

Indirect Impact: “I will be out for a week because of a family emergency. I will be working, but available intermittently”.

Everyone takes a minute or two to ask questions and seek quick clarification on updates that are not obvious. The team votes on which updates to discuss further. The topics should be ones that need the alignment of the entire team. Anything that can be resolved without everyone’s involvement should be handled outside this meeting.

Step 3: Brainstorm

Recommended time: 30 to 60 minutes

The available time for brainstorming is divided into smaller periods according to the issues that need ideation. If the length is inadequate, the number of topics is reduced through a quick round of voting.

The team brainstorms on the topics so that everyone is aligned on the new ideas for the upcoming week. While it is difficult to completely solve every problem in a short brainstorming session, the goal is to set a direction for each topic. Deeper brainstorming can happen later between those directly responsible for each task.

Step 4: Plan

Recommended time: 20 minutes

Using inputs from the brainstorming activity, the plan for the upcoming week is adjusted. The discussion creates a rough estimate of how long it might take to accomplish the new tasks and how much can be completed before the next iteration begins. From this, the team has prioritised tasks with estimations. The project lead ensures that the plan is pragmatic, achievable and aligns with the team and business goals.


Use the following tips to make the most of your Team Conversations.

Keep Egos Out

Leave your ego outside the Team Conversation. Using the words “works/doesn’t work” instead of “like/dislike” keeps the conversation focused on facts instead of making it personal. Our team is united by the goal of creating the best solution for the end user. It’s not about one person’s idea winning or losing.

Focus on Quiet Listening

Talk less, listen more. Instead of thinking of a rebuttal when someone else presents their idea, actively listen to the speaker. Ask for clarification to fully understand the concept, and then listen intently. Paraphrase a team member if you disagree to ensure that you have an accurate understanding of their viewpoint.

Play “Yes and…”

The premise of this common improv technique is to accept an idea as true and build on it. The goal is to refine ideas and gain clarity. Reserve judgement of others’ suggestions until you fully explore them. For example:

Person 1: I know this might sound crazy because we have an upcoming deadline, but running another user study before we make a final decision might provide the clarity we need.

Person 2: Yes, and then we can be sure that this feature is relevant for our users. Let’s talk to the product manager about pushing the deadline out a few days.

Time Box

Cap each discussion by setting time limits in advance. If a decision is not reached, decide whether to continue the conversation later or vote to resolve the disagreement. Consider using a Time Timer so that everyone stays on track.

Make Evidence-Based Decisions

At Obvious, we make decisions based on evidence, not gut feelings. If your argument lacks evidence, we ask you to let it go and trust your colleagues’ idea.

We also try to reach a unanimous agreement with decisions, but that scenario is not always possible. Ultimately, someone has to decide, and that person is the Decision Maker. When the Decision Maker has to step in, feel free to disagree, but commit to the decision.

If you’re looking to work in a company that invests in you, you should know we’re always hiring. 

We’re looking for engineers, designers and researchers across all levels and would love for you to join the team.

Read more

We’ve been lucky with workspaces. Our first office was a beautiful, 100-year old building, crumbling at the edges. The rain would come in and monkeys would steal your lunch. Our next two offices were equally quintessential Bangalore – one just next to a sleepy railway station, and the other nestled off MG Road amidst the greenery that the city was once known for.


We built out our last office to accommodate  around 12 people. We were still there at 25, with people sharing desks, the dining area repurposed into a work space, and the triple-height lounge crammed with tables. It was time to move.

My role within Obvious has changed significantly over the last few years, from doing hands-on design work to growing a business. While I enjoy the challenges and the learnings that come as part of organisational building, I was extremely excited about diving back into design thinking, and applying it to physical space. Working with architect Elayaraja Mayavan and his team, I set out to build a workplace that we’d want to spend most of our day in.

The Plan

Community and Ritual

We oriented the office along a public-private axis – with a full half of the office reserved for what we think of as our Community space. It’s a large, almost cafe-style space, with massive amounts of light. It’s where we all gather to eat lunch together (one of the favourite parts of my day), we hold an irregular movie evening, and we’ve already hosted several talks and workshops where we’ve had upwards of 50 or 60 people join us.


Collaboration and Craft

As you move into the quieter, focused part of our office, there are a variety of work spaces that accomodate different work modes. We’ve got more open spaces, where teams can whiteboard together, large private rooms to run workshops (like our Design Sprints), as well as a large, library-silent space that allows everyone who wants to do focused work a place where they know they won’t be disturbed in. We even snuck a little audio/video-editing studio, and my favourite part – a light-drenched reading nook, that holds our (growing) library and large couches for those post-lunch power naps.


It was almost a given that I was going to be an architecture queen: the fact that I own the entire back-catalogue of Grand Designs is perhaps a leading indicator. Whether it was insisting that we use no colour apart from white (right down to our clocks), inspecting every sheet of birch ply to see whether the grain and variations matched, or spending hours on finding the perfect soft-finish cement epoxy for our floor, I probably spent a little bit too much time sweating the details. I drove our architects quite mad, making them redo the lighting several times and being rather indecisive about the shape of our air conditioning vents. I’d like to believe though, that this all contributed to a space that feels intentional.

Ergonomics: if you’re going to be in front of a computer for eight hours a day, make sure it’s set up for you. Everyone at Obvious gets sit-stand, height-adjustable desks plus massive monitors and mechanical keyboards, so that we can keep off injuries related to ergonomics.


Local Designers: where we splurged was in supporting local designers and craftspeople – we bought an original Sandeep Sangaru couch (“The Ring”) and some very nice, minimalist chairs from Spin.

Bathrooms: We reversed the colour scheme from bright and white – making them dramatically lit, dark and intimate spaces.

Plants: all of our balconies (and we have a lot of them), have themed plants–one is around colour, one around smell etc. We’ve chosen indoor plants which act as natural air purifiers.

The Future of Obvious

In every other aspect of our company – whether it’s hiring, whether it’s what our team looks like, whether it’s paying people doing the same work the same , we’re trying to reimagine how a group of people can come together and build things that are so radically better that these practices just become…obvious…to the rest of the world. I think that our physical environment is no different – it’s a part of how we take care of each other, and hopefully, a place to be inspired, everyday.

Read more

By Sasikanth Miriyampalli


You may be wondering, “why not use production code in tests?” Sometimes it might not be possible — like calling an Android framework class in unit tests — or sometimes we don’t want to. For example, if we want to test out a retrofit network call that transfers money from one account to another, we don’t want to transfer money every time the test is called. In those cases we replace the production code with alternative implementations for testing purposes and these are called ‘Test Doubles.’

There are various types of test doubles; in this article, we will take a look at 3 commonly used ones: FakesMocks, and Stubs.

Examples listed in this article are written in Kotlin, but the concepts are transferable. While it is possible to use our own implementation for providing the mocking and stubbing logic, in this article we’ll be using a mocking framework called mockito-kotlin to make generating test doubles easy.


Fakes have working implementation but have alternative code compared to the production; sometimes it might be much simpler compared to production code.

An example for this case is using a fake datasource instead of touching the actual database or network or performing disk operations. In the following example we are making a FakeContactsDao that can be used to replace the production version in tests. This implementation is simpler compared to the production version which would have to deal with database. This is especially useful in instrumented/integration tests where you might be testing the entire implementation of the datasource.


Mocks are objects that expect certain calls to be made. They will throw an assertion error when they don’t receive those calls that are expected or if they receive a call that is not expected.

We use mocks when we don’t want to invoke the production code but want to check if the action is called or check how many times a certain action is performed. This is especially useful when you cannot run the production code in tests or if you want to avoid running the production code in tests but still verify that the methods are invoked.

In the following example we have a UserPaymentsRepo that takes in PaymentsApi . When we send a payment to the user, we expect to call the PaymentsApi#payUser.

We verify that method is invoked and no other method from the PaymentsApi is called.


Stubs are objects that lets you control a methods behaviour in a test. They are usually placed at the top of the test.

An example for this case is returning predefined data whenever a database method is called. We are doing this to avoid calling the database in tests or testing various database cases.

Let’s say we are making a social networking app and we want to get list of starred contacts for the user.

Instead of making the database call, we provide a stub that returns a predefined list of starred contacts. Then we can assert that we received the same contacts when we are calling userViewModel.starredContacts

When to use

Here is how I decide when to use Fakes, Stubs, Mocks.

Fakes – To provide alternate implementation of the production code that is independent of the system and can be tested quickly.
Mocks – To mock the production code and also to verify all the actions are performed/not to be performed in the test case.
Stubs – To have a predefined response for the calls made during the test case.

Reading notes

TestDouble – Martin Fowler
Mocks Aren’t Stubs – Martin Fowler
Introduction to Test Doubles and Dependency Injection – Google Codelabs
Fundamentals of Testing – Android Developers

We’re Hiring!

If the Obvious Way makes sense to you, let us buy you breakfast. We’ll tell you more about the work that we do, give you the lowdown on life at Obvious, and answer any questions that you might have about engineering or working here. Or jump straight in, and apply to join our team!

Read more

Dedicated time with your manager, focused on what’s important to you.

The What

One-on-one meetings are an opportunity for you to meet with your manager and discuss anything you want, in private. This is your time! You set the agenda, format, and location. During this time, you can give feedback, build and enhance trust with your manager, discuss new ideas and problems, and brainstorm on ways to advance your career. We specifically devote this time to you.

The Why

At Obvious, our goal is to create an environment where everyone feels empowered, supported, and heard. To accomplish this objective, we must create a safe setting for you to discuss your ambitions, concerns, and suggestions. One-on-ones provide you with that opportunity


You, as the direct report, decide the agenda of your one-on-one with your manager. You create a format that works best for you, and it may change each time, depending on your priorities. We recommend focusing on topics that pertain only to you. In other words, things you are not ready to discuss in front of the entire team.

We suggest covering: positive work events, negative work events, manager feedback and outside life. Each one-on-one, though, does not need to cover all four areas. These proposed topics provide general guidance, but you have ultimate control.

Outside Life

We do not want to pry into your personal life, but sometimes, it is beneficial to share what goes on in your life outside of work. Perhaps you’re going through something personally that causes you to be distracted, or have a health issue that sometimes requires you to be away from work during normal business hours. Speak as freely as you want and know that your information will always remain confidential.

In addition, it is helpful for managers to know what motivates you. If your life’s goal is to open a design school, let’s talk about the skills necessary for that to become a reality and how we can develop those while you are at Obvious. We understand that people’s aspirations change. You may not want to be in your current job forever. If you want to do something else in life, we want to support you and see you succeed in that goal.

One-on-ones are the time for you to speak about whatever you want. Each meeting may focus on a different topic or could be a continuation of a previous conversation. You call the shots!

Positive Work Events

Discussing what drives you shows your manager what you enjoy and want to do. By conveying this information, it makes it easier for your manager to provide you with more of those opportunities.


What motivates you to come to work? When you are excited to come into the office, then you are likely to be more productive, and that energy is contagious. We want to do what we can to keep you motivated, so let us know what that is.

New Ideas

New ideas are like infants – innocent and fragile. They need care and nurturing before they stand on their own. Use this time to explain any new ideas you have, then brainstorm and ask for constructive guidance before rolling it out on a larger scale. These ideas could be small items like a new type of coffee, or larger suggestions such as a new way to work with a client. Creativity is crucial at Obvious, so use this time to strengthen your ideas at their inception.


Share your aspirations and areas where you are trying to improve and ask for guidance on what you can do to move in their direction. This discussion will not replace the bi-yearly Career Conversations or day-to-day feedback, but rather, it may serve as a midpoint check-in to ensure progress regarding your path.

Negative Work Events

We spend a lot of time at work, so let’s make the experience a pleasant one. To do that, your manager also needs to know what is not working for you. While we do not want these meetings to turn into gripe sessions, vent your frustrations and together we will find a solution.


What do you dread about coming into work? Let your manager know what that is. Odds are we can resolve the issue. Come with possible solutions, but we can brainstorm together.


If you experience roadblocks that impede doing your job or make you feel unproductive, let us know. We will look for answers or workarounds. It may take a few attempts, but we will continue to address the problem.


Bring up things that are in the back of your mind. Maybe you do not know exactly what it is, but you know something isn’t quite right or could be improved. Be as honest as you can. Or perhaps, you need extra support or advice.

Feedback for the Manager

Hopefully, you already provide your manager with immediate, personal one-on-one feedback regularly, whether after a meeting, privately, or through written communication. However, sometimes you might need more time. Use these meetings to give advice on how your manager can impact you directly. Also, use this time to follow up on previous advice you gave your manager to let them know how it is going.

We recommend using the Situation → Behaviour → Impact (SBI) model. Tell your manager what impact, both positive and negative, their behaviour had on you in the context of a particular situation.

What can the manager do more of?

What can your manager do to make you more productive and happy? When possible, use the SBI model and be as specific as you can.

What can the manager do less of?

Tell your manager what they could stop doing to make your job easier. Remember to use the SBI model and avoid talking about the personality of your manager.


Use the following tips to make the most of your one-on-ones:


Use one-on-ones as a time to release the pressure you might be under. We want these meetings to be collaborative and relaxed not something dreaded. Look at it as a time to reset yourself. So, choose a format that puts you at ease, such as having coffee or tea, taking a walk or going to lunch.


These meetings occur once a month for 60 minutes and are scheduled at roughly the same time. The one-on-ones can be rescheduled when necessary but not cancelled.

Resist Work Critique

We encourage specific feedback using the SBI model to occur in three to five-minute conversations right after the situation instead of in the one-on-ones. Instead of saving up that feedback, deliver it when it has the most impact.

Keep a List

Instead of preparing a list of things to talk about at the last minute, keep an on-going list. This could be a separate list from the one you share with your manager or not. When a thought pops into your head during the week, add it immediately instead of trying to remember it.

Shared Feedback Document

Keep a written account of your meetings so that you can look back and see progress. Share the document with your manager where s/he can make comments and track your growth. Either take notes during your one-on-one or add notes after the meeting. In addition, add notes throughout the week. This master list of your yearly progress will be helpful when the Career Conversation comes around!

Bullshit Meter

As in everything we do, it is important to measure how well the one-on-ones are working. The following are indications that the process is not going smoothly.

Only Good News

If you only talk about how positive everything is and how well you are doing, you limit the feedback your manager can provide. Bring issues up as soon as possible so that the two of you can plan a course of action.

Lack of Criticism for the Manager

Praise is great but constructive criticism and suggestions are crucial as well. It is how we grow as individuals and as a team. Managers make mistakes and want to know when it happens. In fact, we encourage it. If you feel uncomfortable critiquing, then talk it through at these one-on-ones.

No Agenda

While we encourage free-flowing meetings, the direct report, who sets the agenda, needs to have a general idea of what to talk about. We specifically carve out time for these meetings because we feel strongly that they will increase the effectiveness of everyone involved, on a personal and professional level.


If you have the same conversation with your manager month after month with no progress, then something is wrong. Use the guidance in this document and to mix it up a little bit.

Notes and Definitions

Situation → Behaviour → Impact Model

The best way to provide constructive feedback, both positive and negative, is by putting your comments in context instead of being vague. For maximum effect, state the situation, the behaviour you liked/disliked, and how it impacted you. We call this the SBI model. Use it to offer sincere praise, or seek clarification before delivering critical feedback. Let’s look at two examples:

Positive Feedback

Vague: You did an excellent job with that client this morning!

SBI: During the meeting this morning when the client suggested changing the home-screen (situation), the approach you took to walk him through how the modifications would negatively affect users (behaviour) saved us from creating a poor user experience and also helped him understand how important it is to keep users in mind at all times (impact). Thanks for taking the time to walk him through it.

Negative Feedback

Vague: That client will never hire us thanks to you!

SBI: When we met with the client this morning and she asked how our team would decide how we find candidates for the user studies (situation), you told her that we will not discuss that today and that it was not relevant to the conversation (behaviour). She stopped participating and cut short our proposal meeting (impact). She wanted a better understanding of our process, and she felt that her questions were not considered important. I would love to hear your take on the situation.

In both these conversations, the SBI approach provides the one receiving the feedback with concrete information that allows them to either change their behaviour in the future or receive the compliment knowing that it is sincere.

Read more

Achieving professional dreams, large and small, through clarity and mindful planning.


The What

Career conversations help individuals gain clarity about their professional lives as well as how that plays into their personal goals. These conversations occur every 6 months, starting 6 months after employment. Each conversation takes about 2 hours and focuses on the person’s growth trajectory by developing a custom-tailored growth plan based on their medium and long-term aspirations.

The Why

People choose different career paths and have varying professional goals. While some people seek constant growth and more responsibility, others want stability and time to master some skills. An overarching career framework helps, but it is not enough to ensure everyone’s success. While it is a good first step that presents general guidance and direction, we must supplement that by providing each individual clarity on how to achieve their specific goals by developing a personalised growth plan. Career conversations help managers understand the values, dreams and professional aspirations of their direct reports, which further helps create the right opportunities.

Here is how we conduct career conversations at Obvious: 

Step 1: Value System

Recommended time: 30 – 45 minutes

To offer an individual enjoyment and satisfaction at work, it is imperative that the organisation supports the person’s value system. Values are different than goals. In fact, values are what remain intact when goals change. They are what one practices daily without expecting short-term results. For instance, honesty, safety, and teamwork are examples of personal values.

To understand a person’s value system, you must first understand the individual. One-on-one conversations offer a solid opportunity to know your direct report’s personal life story, slowly building a rapport over time. Depending on how well you know your direct report, you may only spend a few minutes recapping your understanding and offering them a chance to tell you more. Or, you might concentrate on learning more about them, especially if they are new.

Once you break ground in knowing your direct report better, use that information to incorporate their value system into their personalised growth plan. For example, a person who enjoys playing team sports might have effective teamwork as a core value. So, part of their growth plan should ensure that they work on projects with collaborative teamwork instead of projects that rely heavily on deep individual contribution.

Step 2: Aspirations

Recommended time: 30 – 45 minutes

The only way to ensure people bring 100% of themselves to work is by making sure that they find their work interesting. A conversation about aspirations can help make this happen. This conversation can be broken down into 3 steps:

  1. Dreams: A good way to start the conversation on aspirations is to ask people to imagine what the pinnacle of their career looks like. Ask them to articulate the most important things they want to achieve when they are at the top of their game. This question can elicit interesting responses, such as “I want to deliver a TED talk”, “I want to be a community leader for women in tech” or “I want to be an expert in typography and create a series of typefaces that will last for decades.” Together, try to create a list of 3 to 5 such dreams with your direct report.
  2. Skills: Achieving dreams often requires one to gain new skills or improve existing ones. For each dream, write down a few necessary skills. For example, to become a community leader for women in tech, one might need deep technical skills, public speaking skills and people management skills. These are the competencies that will help the individual make their dreams a reality.
  3. Values Check: Sometimes, people’s dreams do not align with their skills and values. For example, a person might want to be an entrepreneur (dream) managing a large team working on complex problems (value), but at the same time she might want to contribute really high-quality code (skill) herself. It can be quite difficult to contribute deep technical work while fulfilling the entrepreneurial responsibilities of running a company with a large team. As a manager, your job is to work with your direct report to help them find their area of focus and be successful by aligning their values, dreams and skills.

Step 3: Growth Plan

Recommended time: 45 – 60 minutes

Now that there exists a list of skills that the individual needs to achieve their dreams, it is time to create a personalised growth plan that creates opportunities to hone them. For instance, if your direct report needs to enhance leadership and product direction skills, create a growth plan that allows that individual to work on a project where little or no product direction has been set. Provide an opportunity to lead a small team. If your direct report needs to develop a deep technical skill, offer an opportunity to work on a project filled with challenging technical problems.

A personalised growth plan helps one choose their own career trajectory at a pace they are comfortable with. Alongside helping the individual feel like they are moving towards achieving their dreams every single day, it helps the organisation align business priorities and expectations across the board.

Repeating the career conversation

At the next meeting in 6 months, we go through each step again but with a mindset to adjust and course correct. Shifts in values and aspirations occur constantly, so check in to see what changes have occurred. Update the growth plan to account for these new expectations. Healthy businesses are a function of happy individuals who bring 100% of themselves to work every single day. That only happens when individuals see a path to their ultimate success at their organisation.



If you’re looking to work in a company that invests in you, you should know we’re always hiring. 

We’re looking for engineers, designers and researchers across all levels and would love for you to join the team.

Read more

As a small team of digital product strategists, we’ve helped realise some world-changing ideas, both in the for-profit and not-for-profit space. But changing the world is not our calling. It is just a happy byproduct of what we really want to do – make this complex world of ours, exceedingly obvious.

We’ve dedicated our lives to this mission and have evolved methods and best practices that have helped us solve complex problems by delivering solutions that are dead obvious. 

Time and again, a lot of talented people have reached out to us, expressing interest in learning from our practice, and applying it to their work. To facilitate this learning, we’ve decided to launch, for the first time ever, the Obvious Residency Programme.

About the Residency

Our residency comes in 2 flavours: you can choose to either work on a passion project you’ve been wanting to bring to life as a Solo Explorer, or you can join our team for the duration of the residency and contribute to an exciting client project that we’re working on as a Co-Conspirator! Here’s more information about the residency programs: 

The Solo Explorer

Work on your own passion project

Do you have a project idea that you’re itching to start working on? Do you need funding and guidance to make it come to life? If yes, then this is the programme for you.

Here’s what you get: 

  1. 6 months of our time, energy and resources
  2. Inputs from our team of 15 designers
  3. Access to our network of creatives, entrepreneurs and VCs
  4. Healthy lunch at our sunny office
  5. Ergonomic furniture
  6. Funding for all project related needs + a stipend to cover the cost of living in Bangalore

The Co-Conspirator

Work with us on an exciting client project

Are you more excited about the process than the end result? Do you want to become better at your craft? If yes, then this is the programme for you.

Here’s what you get: 

  1. 6 months of our time, energy and resources
  2. Inputs from our team of 15 designers
  3. Access to our network of creatives, entrepreneurs and VCs
  4. Healthy lunch at our sunny office
  5. Ergonomic furniture
  6. A full salary commensurate with your work experience
Our Sunny Office Library

What Do We Expect From You?

If you’ve read this far, and haven’t lost interest, you’re probably wondering – “What are they looking for? What’s in it for them?”

At Obvious, we’re always looking to make our studio more interesting and diverse. We believe that by bringing in residents who are willing to take risks, are itching to build something exciting and can challenge our thinking, we will continue to grow into a more well rounded team. By helping you learn, we hope to become better ourselves.


If what we’ve outlined sounds exciting to you, then apply using the link below and we will get in touch with you soon! 

Apply to be a Co-Conspirator or a Solo Explorer.

Read more

Over the last ten years of writing software at scale, we’ve become quite opinionated about how we work. Here’s how we code, the Obvious Way.

Over the last ten years of writing software at scale, we’ve become rather opinionated about how we work. We’ve seen good teams, bad teams, and good teams hamstrung by a lack of best practices.

All of our work is “country-scale”, which means it goes out to millions of people every day. A lack of best practices, growing developer teams, regression-related bugs and so forth mean that engineering progress often grinds to a halt. Where orgs have been built themselves entirely around a mobile app (think ride-sharing, m-commerce, neobanks, food delivery), the cost of having apps crash or be locked in technical limbo can rapidly rise to millions of dollars.

With that preface, we’d like to talk about some of the ways we think about building healthy, high performance engineering teams.

Engineering Philosophy

Engineering teams often think of themselves disconnected from both the rest of the organisation, and even further from customers who actually use the products. At Obvious, we’ve found that by situating ourselves as “co-owners” of the product experience, by looking at the overall org goals, and by expending effort to understand the impact of what we’re building helps us to get a better insight into the product.

Engineering exists within a broader organisation, and understanding that larger goal helps the team to predict requirements and find ways to make our end users happier. The only way that this happens at scale is if we remain highly aligned with organisational goals, with other teams, and most importantly, with each other. This ensures that we have the autonomy to explore different approaches, normalises failures, and enables trust at scale.

The Obvious Way

Most teams only take direct “costs” into account which are easy to see — time to build a feature, design a screen, migrate a database, etc. However, they fail to take into account indirect costs that come in as a product becomes mature — fixing regressions, identifying and refactoring pain points, improving developer experience, onboarding new hires etc. A lot of what we do at Obvious keeps all costs in mind and follow practices to keep them in check.  

Having a common vocabulary allows us to be efficient and avoids bike-shedding. Here’s what it looks like:

  1. Iteration Planning Meetings (IPMs): Evaluate what was (or wasn’t) done in the previous iteration and ensure that we all know what we are doing over the next iteration.
  1. Daily Standup Meetings (DSMs): We run a daily quick (~10 min) meeting everyday, to surface blockers or issues and keep everyone aware of what’s going on (at a broad level).
  2. Resilient architecture: In the rapidly moving landscape within which we work, it’s very rare for us to have visibility into the scale and future complexity that may be required. We distinguish between essential complexity and accidental complexity — the second is to be avoided, while the first, inevitable.
  3. Technical debt: Inevitably, we put something out that’s not perfect: requirements change, we write something in a hurry. We actively work on reducing friction by removing technical debt, even if it means a difficult conversation with another team or a client.
  4. Release cycles: Having a repeatable, predictable release cycle gives the rest of the org confidence that they can build on top of. This helps other teams factor in consistent engineering timelines into their estimates (whether sales, product or even customer support).
  5. Developer Experience: Understanding and enabling continuous success is an important part of scaling an engineering team.
    1. Code reviews: At the team level, having regular code reviews ensure that standards and guidelines are followed and for feedback on ideas and approaches to be shared.
    2. Trunk-based development: Avoiding “merge-hell”, reducing distance between developers (which branch-based development does) and setting the stage for continuous review, integration and deployment are key reasons that we practice TBD.
    3. Regular, readable commits: We absolutely avoid massive code “dumps”, and do frequent (daily) commits, along with good commit messages. This speeds up code review, writing release notes and helps future maintainers (and you!) understand why you did whatever it is that you did.
    4. Project management: Pivotal Tracker is our current go-to for managing complex software projects. You’re welcome to look through the Pivotal board of one of our active open-source projects, which is representative of how we use it.


We’ve seen some encouraging results from this approach. Our small — 2-3 people — teams have consistently punched above their weight. We now regularly build products which reach populations in the mid-to-high tens of millions. At that scale, every single product and engineering iteration has the possibility of unlocking massive business value. Our clients now bring us in to help them set up these practices within their own teams, in addition to helping with mission-critical systems.

Like what you see? We’re hiring!

If the Obvious Way makes sense to you, let us buy you breakfast. We’ll tell you more about the work that we do, give you the lowdown on life at Obvious, and answer any questions that you might have about engineering or working here. Or jump straight in, and apply to join our team!

Read more

When I joined Obvious, Simple — an open-source app for clinicians to track patients with high blood pressure — was in beta, and since then has been at the heart of my work. I’ve been working on the app for more than a year now, and it has been quite a journey! The team has three Android engineers, and our work has found a sort of daily rhythm that we’ve figured out along the way, with some trial and error.


9:41 AM

My usual workday starts while I am in the cab and on my way to the office. I live quite a while away, and Bangalore traffic being what it is, this is an excellent opportunity to get some work done! I fire up the “Sandbox” app on my phone and update it. I quickly test a feature that was merged yesterday. The feature is for our target users who are nurses working in rural India, enabling them to follow up with patients quickly. Looks like it’s working well, which is my cue to post on the Slack #releases channel that the feature has landed on Sandbox so that the design team can test it out.


10:17 AM

Once I reach work, I grab a cup of coffee on my way to my desk, located in the “quiet zone” designed to help us get deep work done. After going over my Slack messages and responding to a few, one of my teammates’ asks me to discuss the code review feedback I left for them. So we go into a meeting room and collaborate on refactoring a piece of code that was increasing our code complexity. After a few minutes, we figure out a way using Kotlin’s beautifully designed APIs. LGTM!

I look at my open pull request from the day before, and it is still under review. Since we follow trunk-based development, I cut a new branch from the branch under review, and continue working on the feature. An iteration in this project is usually a week-long, spanning Monday to Friday. We cut stories for each feature and make sure that one story is never worth more than 3 points (points being a mark of effort and not complexity) because only so much can be estimated by an engineer!


11:55 AM

I start by writing a test to verify a small feature using the given-when-then representation. Ever since a senior engineer helped me start on Test-Driven Development (TDD), I have been pushing myself to write tests before I even think of implementation. After adopting this approach, it has allowed me to follow a more user-driven approach to building software. I run the test and it fails — of course! — because the code is missing. So I go ahead and write a small piece of code to make it work. I commit once the test passes and then refactor the implementation a bit and run the tests again. Make another commit. And this goes on for about an hour till lunch.

By 12:30, most of us are eagerly waiting for the Slack notification that food has arrived. Lunch is often a chatty affair, with discussions ranging from public transport to culture to street food. Since Obvious houses both design and front-end engineering teams, we also end up spending considerable amounts of time discussing one common critical aspect of our work — user experience.


2:10 PM

Lunch is over and one of the designers wants my opinion on something new that’s being added to the flow. They are trying to figure out a way to de-duplicate entries in the system by allowing users to identify and delete the duplicates. This is where the real advantage of having both designers and engineers working at Obvious comes to play. We are able to minimize our feedback loops immensely by collaborating more often. This helps designers translate their user-centric design to a final product and helps engineers be closer to the users, by doing more than just writing code.

One of our engineering philosophies is that “we review code before we write code”, so after lunch, I dedicate some time to reviewing assigned PRs. This also helps me contribute by doing work which does not require deep focus right after a good lunch. I also go over other PRs which gives me a sense of what’s happening around the project.

While we are on the topic of reviews I want to mention a cute habit which I have picked up recently from a teammate — we drop small positive comments or emojis in the open pull requests and especially on ones that are not assigned to us for review. It’s such a small thing in terms of effort but it goes a long way in building trust within our team.


3:49 PM

We don’t have stand-up today so I continue on the feature to introduce diabetes management into the app. It is a long-running epic so it will have multiple stories and PRs. All of this code is hidden behind a feature flag while in development. So the feature may not actually work right now but our CI workflow ensures that code compiles correctly. We can never break the master branch, and this enables continuous delivery.

I receive a Slack notification that my PR from yesterday has been reviewed and I need to address the feedback. So I pause working on the new feature and first close the requested review changes — remember, “Delivering code already written takes preference over writing new code”. I wrap up work until the end of the day and push today’s branch to raise another PR. And the cycle continues 🙂


6:06 PM

We have come a long way in just one year. Simple is now launching across India and in other countries, and lots of credit goes to our team processes, developer habits and work ethic. At the end of the day, I go home proud of what we’ve achieved and even a terribly long commute doesn’t look that bad!

We’re Hiring!

If the Obvious Way makes sense to you, let us buy you breakfast. We’ll tell you more about the work that we do, give you the lowdown on life at Obvious, and answer any questions that you might have about engineering or working here. Or jump straight in, and apply to join our team!

Read more

One year after launch, see how the Simple app helps nurses to save lives from heart attacks and strokes.




On this day last year, I was sitting in a car driving down a beautiful rural road in Punjab, India, through a long tunnel of trees with rice paddies on either side. We were headed towards a public hospital and my teammates and I were anxious and excited since it was the first time that the Simple app was going to be deployed for real in a clinic. Would the app perform well? Would the clinicians accept it?

This was not my first time arriving at a hospital on this project. During the early development phase of Simple, we visited clinics many times to test prototypes. This time, though, it felt different. We had a beta version of our new Android app and we planned to install it on clinicians’ smartphones. It was the very first time the Simple app would be used in a live clinical environment to record real patient data and our software was competing with the tools that our users were already super familiar with — pen and paper. Bear in mind that on a typical day at a public health facility in India, a clinician sees over a hundred patients (average consultation times are less than 5 minutes). If Simple was going to be successful, it not only had to be as intuitive as pen and paper, but also had to be a lot quicker, which is a huge challenge. That first deployment went really smoothly. The nurse and doctor picked up the concept quickly. The app performed well. We breathed a sigh of relief.

A doctor recording patient visits using Simple

During October, 2018, we deployed Simple in 20 more clinics. A WhatsApp group kept us in touch with our early users and helped us maintain a short feedback loop to uncover and fix issues. It was inspiring to see how quickly nurses and doctors got accustomed to using Simple to record patients and how the app could help them recover hours of their precious time. Before Simple, clinicians spent a couple of minutes just to find each patient’s paper treatment card from a stack of hundreds, but now users only had to enter a patient’s name into the app to look up their record. Simple reduced the time to record a patient from 4–5 minutes to about 45 seconds. Over the last year, we made frequent, iterative improvements. We prototyped and tested constantly. And, we released new versions about every two weeks. In May, we introduced a scannable user ID called a “BP Passport” which has reduced data entry time to 24 seconds on average. Clinicians can now spend more time actually treating and counseling patients, rather than recording data.

One year after launch, Simple is used in over 400 hospitals and clinics to manage over 145,000 patients. To celebrate this one-year milestone and to acknowledge the work of healthcare workers who are doing the hard work of treating patients, we created a short film that tells the story of a day in the life of Bhupinderjeet Kaur, a nurse at Sub-district Hospital Batala in Punjab. Nurse Kaur uses Simple to manage her patients with hypertension and she takes a lot of pride in playing her part in reducing deaths from heart attacks and strokes in her village. In 2020, we anticipate that Simple will be deployed in many more hospitals across other Indian states and we will start deployments in several other countries soon.





Thanks to:

  • Nurses Bhupinderjeet Kaur and Ranjit Kaur for letting us follow them around and shoot them for two days.
  • Harnanth Singh, for inspiring us with the story of his hypertension treatment and for allowing us to shoot at his beautiful farm.
  • , Assistant Director, Punjab Health Department.
  • Everyone who works as part of the India Hypertension Control InitiativeIHCI is a multi-partner, 5-year initiative between the , State Governments and  Country Office for India.  (an Initiative of ) is an international technical partner.
  • Daniel Burka for script writing and for editing this article.
  •  for tirelessly shooting and editing this film 🙌.


Read more
1 2 3