Summary
This blog post shares some lessons learnt from the process of building the JUSTOKRs priority and progress tracking web app and the process of rolling it out across JUST EAT’s large technology organisation.
Context
There are now just over two hundred people in the JUST EAT technology team, where technology includes development, testing, product management, UX, ICT etc. For perspective, six years ago we had seven people … so we’ve grown pretty quickly.
We now operate in thirteen countries, across a mix of group built and acquired technology platforms with many different cultural, marketing and legislative challenges.
In late 2014 the UK Engineering area was made up of ten teams working on a range of components, including:
- Customer facing desktop and mobile websites
- Customer facing Android and iOS apps
- Restaurant facing devices and apps
- Customer care tools
- Public and private APIs that provide data to the other components
Challenges
As we continued to grow our teams we identified some challenges:
Managing cross team dependencies
We’d seen a few cases of implicit dependencies between the API teams and the teams which consumed their APIs, which became apparent very late in development – meaning that a consumer team became blocked whilst an API team caught up.
Appropriate & timely communication
As the organisation grew we found it increasingly important to communicate what the teams were working on to a range of stakeholders at different levels of detail. For example communicating at a high level to country operational management and in depth within the technology organisation.
Downstream delivery horizon
As a technology organisation we have many downstream consumers who want to know roughly when we’ll deliver something we’re building e.g. a marketing team who may want to run a marketing campaign on a new feature or the customer care team who need training on a new tool we’re building for them.
JUST EAT had started using the OKR (Objective & Key Result) methodology popularised by Google, at a high level, a couple of months previously (see more here). The management team determined that we should adopt OKRs within technology to address these challenges and started by building the mother-of-all-spreadsheets to track team dependencies.
The spreadsheet approach worked well but many people found it unwieldy and it was difficult for stakeholders outside of technology to understand.
At this point I felt that a system was needed to track OKRs rather than a spreadsheet and carried out a review of systems available in the market. Nothing quite met the bill and therefore I started building a tool that would help us manage progress in the same way as the mother-of-all-spreadsheets but which would be much easier to use.
I’d previously built a project using node.js for the backend APIs and Ember.js for the frontend and really enjoyed the convention over configuration and (stability without stagnation) approaches of Ember and being able to code APIs and front end in the same language.
JUSTOKRs
We’ve made the JUSTOKRs available as open source here. It’s structured around a few concepts:
- High level Objectives such as “Ensure first time users come back”;
- Key Results such as “Apple Watch app available on launch date”
- Deliverables, which are the concrete things that teams might want to build to deliver against the key result including apps, APIs etc.
The tool offers a high level overview of OKRs for stakeholders, showing when key results are expected to deliver, to help downstream teams such as marketing and customer care to plan their campaigns and agent training:
[Summary view with pixelated text]
Plus views for individual teams to manage their priorities and understand dependencies on other teams:
[Team view with pixelated text]
A few learnings along the way
The asynchronous nature of node.js and callback hell
Node.js applications are single threaded and therefore it’s important to use the asynchronous model to keep them performant. However for someone needing to write APIs which often combine a number of steps that need to be completed in sequence, (eg authentication, database query and database update) writing pure asynchronous code can result in code which is really difficult to write and comprehend.
My solution, which I’m sure that node purists would eschew, has been to use the va_sync library to join steps together in a sequential flow. For this application at least, sacrificing a little speed for code readability is the right compromise.
Active Directory Authentication
Initially a basic tokenised authentication mechanism was used, but as tool started to be rolled out we adopted Active Directory for authentication in order to use the same mechanism as other internal tools and to reduce administrative load.
We went through a few different iterations along the way of trying to get node APIs and front end code to communicate to AD but the final solution was actually very straightforward and just involved a call out to AD with it calling back to a node API.
Multi tenanting for international and other parts of the business
The tool was originally built for the teams developing the platform for the UK, but as we started to show that it was useful there were requests from other parts of technology who wanted access to the tool.
I looked at how we could make the app multi tenanted so that different areas of technology (eg UK, International & Partner Product Development) could all build and maintain their own OKRs within the tool but could get visibility on what other areas are working on if wanted.
The tool has now been adopted by all areas of technology and we’re already finding that by using a shared tool we’re seeing opportunities to collaborate and share knowledge across different areas, in a way we may not have done when each area was using their own systems (aka unwieldy home-made brother-and-sisters-of-all-spreadsheets) to manage priorities and progress.
Timeline view
When I showed the tool to one of our international teams they said that they’d like to be able to show their in country stakeholders a more visual view of work in progress. I needed to do a couple of iterations to get to the right view but ended up with a Kanban style view to show progress, which makes it easy to understand at a glance how each team are doing.
[Timeline view with pixelated text]
It’s worth noting that we use this view in conjunction with JIRA – JIRA is used to manage detailed technical tasks, whilst the JUSTOKRs tool (and the timeline view specifically) provides a higher level view of progress in stakeholder friendly language.
Looking Forward
Getting to Ember 2.0 – as the tool has been developed the core Ember team have been moving toward Ember 2.0. This has been done by incremental changes in a point release every six weeks with a set of suggested changes, shown in the console and in Ember Inspector, the in-browser debugger. I kept up with many of these releases and made the changes needed to take advantage of simplified syntax, additional features and removed deprecated features.
However the release of 1.11 required a pretty substantial number of changes to JUSTOKRs app and coincided with me moving to another role within JUST EAT. Doing the work to get to 1.11 and beyond, including the dramatically faster Glimmer rendering engine, is a job for another day… or maybe another contributor (hint, hint)…
Summary
In general, making the decision to build a tool in house is something that should not be taken lightly. It can be time consuming in terms of getting it built and adopted.
However, building a tool in house means that you can tailor it to the exact needs of the organisation and get very quick feedback on new features implemented and turnaround changes very swiftly.
From an organisational perspective the tool is now used across all of technology and helps engineers, product managers and programme managers to plan and sequence their work and stakeholders around the business to understand progress. It contributes toward making dependencies explicit and toward our constant improvement in delivery pace – all helping to “enable our customers to love their takeaway experience”.
Thanks
Finally I’d like to thank firstly everyone within JUST EAT who has used the tool & given feedback and secondly the broader Ember community – without your support the tool couldn’t exist.