Shop Talk logo

I’m sure you’ve heard it said many times before: technology is constantly changing. One of the ways I attempt to stay up to date is to listen to podcasts on my daily commute. I try to listen to a mixture of podcasts; some are very technical, some are designed for a general audience, and some are just for fun. This way I stay interested and engaged throughout my week.

Strangely though, listening to podcasts tends to be a solitary activity, and I’ve only been able to discuss it with people when I’ve started a conversation. When I eventually do get talking to people about podcasts, I’ve been given great suggestions or have shared my favourites with others, and it’s a really good way to get the word out.

Since this has been so useful for me, I wanted to list of a few of my favourites as a recommendation for others – and I also want to welcome any additional recommendations, too. Don’t let it be a solitary activity: if you listen to podcasts that aren’t mentioned here, please let us know below. 

Technical podcasts

Listening to podcasts that are related to work is a great way to keep up with the technical community. Personally, I also read newsletters and blog posts but find that these are far too easy to skim-read, and I only really absorb the knowledge when I hear it on a podcast.

I also find that technical people tend to make technology easily understandable when they talk (rather than write) about it. I don’t know why this is, but a simple side-note on a podcast can give me a much better high-level understanding of something compared to a little paragraph in an email.

My top three technical podcasts are listed below with a little summary – please give us your own suggestions on Twitter or in the comments!


The ShopTalk show podcast is hosted by Dave Rupert and Chris Coyier (creator of CSS Tricks) and is a podcast all about web development. They cover a huge range of topics with a wide variety of guests and is a good way to pick up the general lingo of the technical industry.


Hanselminutes is a podcast hosted by Scott Hanselman, a Microsoft employee who enjoys programming, teaching and speaking about technology. The podcast covers a wide range of technical and less technical concepts, such as Lean Customer Development and WebVR. It’s a really approachable podcast that skims over high-level concepts really well, although rarely goes into technical detail.

My JS Stories on JavaScript Jabber

The podcast JavaScript Jabber covers a lot of information on JavaScript, frameworks and front end development. However, they have recently started a subsection of JavaScript Jabber called My JS Story, hosted by Charles Max Wood. My JS Story is a series of podcasts with various open source collaborators and JS programmers across the world that are asked to share their stories of how they got into programming in the first place, and then how they moved into JS from there.

Non-technical podcasts, but still work-related

There are also some podcasts that I listen to for fun, but which actually teach me things that I end up using at work. These are particularly interesting because things you never think will be useful pop up in a conversation and save the day.

My top three non-technical but work-related podcasts are below. Do you have any that you listen to for fun but find they’re actually useful too?

Note to Self

Note to Self is a podcast hosted by Manoush Zomorodi, and it covers the ethical and difficult questions about technology. It covers a huge variety of topics from new technologies, politics, mental health and others, and it always gives a brutally honest opinion on whether technology is helping or hindering us.

Science in Action

Science in Action is a BBC World Service weekly podcast that talks about new and interesting scientific discoveries and what they could mean for the future. It is rarely work-related, admittedly, but it does give you a host of interesting “Did you know…” facts you can spout to your teammates.

Happier with Gretchen Rubin

Happier is a weekly podcast from Gretchen Rubin and her sister Elizabeth Craft. Gretchen dedicates her time to researching and evangelising a happier life, and her podcast is full of easily accessible tips and tricks (and Happiness Hacks) for how you can improve your everyday life. These are not always life altering tips but they have helped me a lot over time, and help you to reflect on your own life and how you can help yourself be happier.

A bit of fun

Sometimes after a long day (or week) you really need a funny or interesting podcast that is 100% not going to be related to work. This helps me wind down and clear my mind after a day of coding, and makes me laugh after a difficult day.

My top fun podcasts are below. Please feel free to offer other recommendations on Twitter, I’m sure there are lots of fun ones going around!

No Such Thing As A Fish

No Such Thing As A Fish is the podcast from the QI Elves (the researchers behind the TV show) and hosts a panel of regulars that find an amusing fact from the week and explain it. This usually dissolves into a group discussion of something entirely irrelevant but hilarious, and you learn something along the way.

The Infinite Monkey Cage

The Infinite Monkey Cage is a BBC Radio 4 panel show hosted by Professor Brian Cox and Robin Ince. The panel usually consists of a couple of leading scientists in their field and a comedian or two to mix it up. They pick interesting and diverse topics and discuss the science behind the ideas. Although it sounds very factual (which it is) it is also hilarious and, refreshingly, British humour!

So, that’s it – all of my podcast recommendations. If you want to give a podcast a try, but aren’t sure how to get started, there is plenty of information available online on how to get set up. For example, I use the Stitcher app on my Android phone to listen to the podcasts above, but you can also find podcasts on iTunes and other apps.

Louise Formby, Software Engineer

May 24th, 2017

Posted In: Blog

Tags: , ,

Leave a Comment

Ocado van

The story of how to quickly check your team’s practices while having a lot of fun.

How do firefighters assess their readiness for an emergency situation? How do they ensure that everyone knows what to do in case of a fire?

The best way to check this is to organise maneuvers similar to a real life situation.

Firefighters train regularly to check and improve their procedures. They are inducting new members, they are testing new equipment, and they are building trust to each other.
Nothing can teach you more than real practice.

Like firefighters, data scientists need to perform as a team. This means introducing ways of working to new joiners, making use of the best tools and techniques they have at their disposal, and knowing each other’s skills and personalities.


In this article we would like to describe how we organised an internal Kaggle-like competition to test and assess our data science procedures.

Our small data science competition

Recently, we organised a machine learning competition at Ocado Technology to check how well equipped our data science teams were to solve real problems under pressure. We invited data scientists from our five offices (i.e. Kraków, Wrocław, Sofia, Barcelona, and Hatfield) to our headquarters in the UK. We ordered some pizzas and started a hackday.

We formed into teams and adopted only one rule: if two data scientists are working on the same team in real life, they cannot work with each other during the hackday. We wanted to encourage people to get to know each other.

We decided to use a Kaggle style competition. For people who are not familiar with Kaggle, it’s a competition where business problems, data, and evaluation metrics are defined by the organisers. Participants then have to build ‘only’ the corresponding machine learning models.

Our problem

The goal of the competition was to predict the total time-at-door for Ocado delivery vans.  

We wanted to know how much time it would take to deliver groceries to a particular address. Ocado is using these delivery times to plan the van routes with more certainty and thereby open up more one-hour time slots for customers to choose from.

Ocado vans

Similar to Kaggle, we prepared some baselines and a leaderboard where we showed the best solutions; this gave participants additional motivation to build something better than everyone else. At the end of the competition, the teams presented their findings and models. We learned a lot about our data, our practices, and ourselves.

It was a great day so we wrapped things up with the customary pint in the pub.

Five lessons learned after the Kaggle competition at Ocado

You can easily apply these lessons in your data science team or data department:


    1. Hackdays are a great chance to socialise

There’s nothing like a competition to get people from different offices working together and therefore getting to know each other. People can learn about their strengths and weaknesses. We found problem-solving to be a great team-building exercise. After the event, we created a survey which confirmed that people indeed had a lot of fun.

    2. Machine learning models are only the tip of the iceberg

As an organiser, you need to choose the problem wisely: it cannot be too difficult to solve in one day but still should be challenging. You have to define the evaluation metrics, gather data, split it into training and test sets, write down the rules etc. During his presentation at NIPS 2016, Ben Hamner (CTO of Kaggle) confirmed that his employees invest hundreds of hours in properly setting up the competitions behind the scenes. In all data science projects, only 5-10% of the time is spent on modeling.

    3. Data science is all about iterations

During the competition, some teams over-complicated their models: they tried to check too many things at the same time and overestimated what is feasible to do during one day. At the end of the day, only working models really matter (all teams had plenty of ideas on what they would have liked to check but ran out of time).

It works pretty similarly in real life. We’ve written about this here as well.

Practice and contests like this can show your team the benefit of iterative work.

    4. Domain knowledge can make all the difference

Rather than trying a more complicated model, it’s better to first invest energy into understanding the metrics, analysing data, checking the distribution and outliers. The team that won the competition used their knowledge about Ocado’s business to improve their model. In real life, very often domain knowledge is essential.

    5. Improve your engineering practices

Python and R are two of the most popular programming languages for data scientists.

To work effectively, you need to know your tools very well, including programming languages and frameworks. If you want to rapidly check hypotheses or add new variables, you cannot be blocked by technologies.

This hackday showed us that we need to work harder on unifying our technology stack and adjusting the induction process to ensure that everyone can easily get the data, make the analysis or model and share their results with the rest of the team.


As we’ve seen, a one day hackday event can provide a very useful health check for your team. You can check how people organise their work, what tools they are using and how they are working to solve problems. But hackdays can be beneficial not only for data science or engineering teams; management teams can use them to decide training budgets, investment in tools and technology, or for forming new teams. We therefore strongly encourage you to involve your managers or team leaders in these events as much as possible.

Try to conduct similar competitions in your company. We assure you that you will learn much more than you’re expecting while having a lot of fun.

Lukas Innig, Marcin Druzkowski

May 18th, 2017

Posted In: Blog

Tags: , , , ,

In the game

Recently I took the difficult personal decision to move from the business domain where I had been for over six years since graduation – Supply Chain – and into the technology, systems and completely different domain of Payroll.

Everyone around me has been hugely supportive in this self-learning exercise and my new team leader put it best: throughout their career and all the way until retirement, a successful individual will go from being a small fish in a big pond to being a big fish in a small pond. It’s then you need to reset and get in a bigger pond again and this is the only way you can continue to grow.

Introducing yourself and your own style to a new team can be difficult – as can learning the nuances of others and integrating into what is already a performant group. One of my new colleagues – Felipe – introduced me to the Steam game called “Keep talking and nobody explodes”, a collaborative puzzle game aimed at rewarding good inter-team communication skills. We thought we would give it a go!

The game

The game features a bomb, obviously. But importantly only one person is allowed to see it. Each of the sections of the bomb is a different type of puzzle; for instance the bottom left module in this image is a vertical wire puzzle where some wires need to be cut and others definitely not cut to succeed.

The bomb

The bomb

The rest of your group gets the manual! For a simple puzzle it gives explanations such as:

If there is a single yellow wire, cut the third wire. Otherwise…

The manual

The manual

More complex puzzles may require you to remember previous steps you have undertaken as well as build up a virtual image of where you are currently based on what the defuser is telling you. We opted not to use any pens or paper to aid us since it would have removed a lot of the confusion that good group communication and building consensus can actually resolve.

Keep talking!

Communication is the number one key to this game. The defuser needs to constantly and articulately express what is on their screen. The group with the manual must gather consensus on the right course of action through speaking but also listen keenly to the information they are getting from the defuser and each other.

Get one of these things wrong and you get…


Team photo

Dan, Felipe and Laszlo posing after a successful defuse

No matter how good you are at this game eventually there will be explosions. Learning from failure is a key part of this game and seeing behaviour like blaming each other or getting frustrated would be an instant indicator of underlying problems.

Fortunately for us we saw none of that, and the session was filled with shared ‘oooooooooohs’ as we became unsure, claps when we finally solved a complex challenge, and admissions of ‘my bad, guys!’ when anyone inadvertently made the wrong call.

A circle… with a line through it…. with a T on top!

Bomb puzzle on a laptop

Laszlo pondering the names of the colloquially termed BT, Trident, right dotted C and smiley face icons

One of the puzzles involved four random symbols and the defuser has to select them in the correct order. Unless you’re a pro at greek alphabet knowing your lambdas from your phis from your dotted lunate sigmas – there is going to be an element of ‘I have like a circle with a line through it with a big T on top rotated at 45 degrees’. Oh you mean a washing line on a manhole cover!

This is a hidden gem of an opportunity where the team quickly build common language to describe complex situations whether you see a washing line in that icon or not. In technology, understanding what someone means when they say ‘visitor pattern’ is easy – you can read a book on it! Understanding what your fellow colleague precisely means when they say visitor pattern – in reference to the unique way in which it was implemented to solve a problem three months ago – that is something you’re going to have to learn by reading clues from those around you. This vital cross-knowledge is part and parcel of the ‘forming, storming, norming, performing’ cycle of team behaviour and practising the skills relevant to getting to ‘performing’ fast is vital.

Too big a room

Working as a team

Dan, Laszlo, and Dan trying to help Paul defuse the bomb

We conducted this experiment over 1.5 hours. For the first hour it was five people in a room designed for 12+. We thought this was perfect, each of us spread out the paperwork for our manuals and got down to picking up the relevant bit of the manual at the relevant time and working collaboratively to solve it. Quite often a leader would emerge – someone who had read a little faster or found the page a little earlier or perhaps just understood how to read a Venn diagram a bit quicker than the rest. There was a bit of consensus gathering but mostly we went with the first answer to get to the defuser.

In the last half hour we were in a room really designed for six. People couldn’t spread out as much and at one point three of us were gathered around a single set of manuals with much more consensus being driven and more people being able to keep up with where we were on a challenge.

It is very hard to not be heard or indeed to be timid with your ideas when you are all in an appropriately confined space. I contrast this with the often vast meeting rooms that we use for Sprint retrospectives or the likes that require everyone to turn their heads constantly 60+ degrees to see if people are in agreement or not and whether everyone has had their chance to get their points across and will have to consider more often in future to book much smaller rooms wherever possible.

Breaking the ice

By the end of today’s session it was very easy to feel an integrated part of the social structure that makes up a team. I had the opportunity to see a great deal of situations in which people could have gotten easily frustrated with one another but actually all were willing to correct or be corrected by their colleagues. Work is often as much a professional as social grouping of like minded individuals and I find I am already building my appreciation for the talents and articulate nature of those around me.

As team building events go, a meeting room for an hour or so, an £11 game on Steam, and a few black and white printouts is a pretty cheap and surprisingly successful way of integrating a new member into the team dynamic.

May 10th, 2017

Posted In: Blog

Tags: , , , , ,

Group of interns

In my team we conduct a retrospective every two weeks. On each occasion, we try to keep things fresh and stop the same format from killing our ability to spot and discuss a growing problem.

We were inspired by a paper on rotational cleaning and how regularly changing your cleaning process avoids bacteria strains resistant to your standard approach becoming common place. Although our usage is very different, the same theory can apply.

We begin each retrospective with a game to help mix things up, keep us energised, and make sure we’re alert and learning. Here are some you can try yourself.

The game: Trolling your team on the requirements

Dan wants a new car. Dan wants you to draw him his new car. All that he knows is he is looking forward to it and it’s going to satisfy all his dreams.

Take a whiteboard marker and design Dan’s new car for him.

Watch as the team make assumptions, draw incorrect conclusions, and only infrequently think to involve the original requester in the process. Maybe fast feedback and awesomeness come intuitively to you; I’ve a feeling for a lot of us this is something we have to remember to work at, hence this game!

The conversation:

How did the car end up? Was it exactly what the requester wanted? I suspect not, so highlight where assumptions were made and why they were incorrect. Ask the team what policies they could try out to make the next project a success.

For example, vague questions get vague answers. Try out a policy of deciding in the team exactly what is important to understand about the project, then be sure you get the answers you need to continue. A vague answer shouldn’t lead a team to decide (or assume) for themselves.

Did anyone ask if the requester liked the design before it was finished? Involve the requester in the design process.

Repeat the process. Now Dan wants a new house. Go!

The moral of the game:

We can all get a bit comfortable and complacent in our given domains, but it is important to remember that making assumptions about what a business user might want leads to a risk: the risk that the thing we build isn’t the right thing.

In my team, we found it did not come naturally to have an approach that restricted room for failure, so we decided it was a good idea for us to make feedback opportunities part of our standard process.

Car sketch

Definitely not the car of my dreams, despite the heart logo on the door which my team was sure I would love


Sketch of house

Not far off the modernist home I would love to have – but what is with that fountain I didn’t ask for?

The game: Trolling your team on the estimates

Whiteboard markers out again. The task is to draw up to five cogs such that the cogs’ spokes multiply together to make X.

There should be a phase for planning and estimating how long the task will take, and then someone has to complete the exercise while you time them.

Cogs of different sizes

These cogs would make 8 * 6 * 6 = 288


We played for various values of X: 128, 34, 71, 260, 437

The conversation:

So how did your team do at estimating the time it would take? Try to discuss how people did in each instance. For example:

  • What factors did the team take into account for their time estimate?
  • For the first attempt, how much of that estimate was safety margin given no prior experience drawing cogs?
  • Did they allow less time if they thought the number factored into a simpler equation?
  • Does the number of factors really make a big difference to the time it takes to draw the cog?

We found it interesting to time how long was spent in the deliberation + estimation part of the task as well. Surprisingly, for a 37 second implementation task, it could take three minutes of deliberation before anyone even picked up a pen.

The moral of the story:

Estimation is tough! And estimates via triangulation aren’t always sensible. For instance, if people consider X=71 to be in the same class of problem as X=437 then they will scale up the time estimate and fail with disastrous effects. When we drew 437 spokes on a cog it became hard to keep track of how many we’d got up to, and the drawing had to start afresh at one point. Eventually fatigue set in and this cost further vital time that had not been factored in or considered.

As our team continued we found that, for numbers which were simple to factor, the team got more and more accurate at estimating. For more complex numbers we seemed to get worse. Often, this was because a big chunk of the work for more complex numbers was drawing a cog with many spokes (a cog with 437 spokes, for instance, because we couldn’t think of any way to factor that into smaller numbers). Yet even realising this we continued flip-flopping between vastly under and overestimating this type of task.

Any other ideas for retro games?

We have built up a good portfolio of fun games to play, to fill everything from 30 seconds to 30 minutes, but we would love to improve this collection. Share your ideas with us on Facebook, Google+ or Twitter.

Daniel Stoner, Senior Software Engineer

May 2nd, 2017

Posted In: Blog

Tags: , , , ,

Leave a Comment

Team shot

One of our largest areas recently undertook a revolutionary self-selecting restructuring exercise, the goal being a complete split between teams working on two different propositions. The overall aim of this split is to achieve greater alignment, autonomy and purpose.

Following the principle that a collaborative and distributed approach is often the best way to solve a complex optimisation problem, we negotiated moves amongst the five new teams subject to a set of constraints around team size and experience levels.

The plan going into the event was shared well ahead of time to allow people to get their questions in (and added to the FAQ section) and the concepts clear going into the day. Alongside this, we ran multiple townhall sessions where people could air their concerns and ask their questions openly. There was a certain amount of ad-libbing and practical adjustments on the day, but on a whole it unfolded according to the plan.

Fuelled by 18 pizzas, we completed three exhausting rounds of moves and peer voting. At the end of each round, we (everyone, including POs) voted on the viability of each team. From this we measured two scores: an intra-team score, and an inter-team score. This lead to a few interesting dynamics, for example one of the teams gave themselves a high intra-team score, but scored low on the inter-team vote. They then gave a pitch justifying their viability as a team, and were able to dramatically increase their inter-team score in the next round.

Voting results

The first round was deliberately suboptimal, hence dramatically lower scores. This was to encourage a large amount of movement in the following rounds.

Essential to finding a viable solution was an appreciation from all of the ‘greater good’ of Ocado Technology. On the day, some people made some really big compromises in order to serve the greater good and allow us to form balanced teams that are all capable of smashing out quality software.

After the final round of voting we then took a quick anonymous happiness reading by each dropping a green, yellow or red lego piece into a box. Although they were not perfect, we were extremely pleased the results, considering that our original goals was “at least 50% happy”.

We will be keeping a close eye on the impact of the shuffle-up by measuring the things that matter most to us: throughput and team happiness.

In terms of the solution itself: I am delighted. Every team has a reasonable level of experience whilst a healthy number of people have chosen to change domain. It is a vastly better result than I could have hoped for had we chosen a top-down approach.

The very next morning we did a big-bang desk move:

UK teams

James Lohr, IT Head

November 26th, 2015

Posted In: Blog

Tags: , , , ,

Bulgarian flag

Ocado Technology employs over 650 software engineers in the UK and Poland. We are intending to continue to grow that number significantly in both Poland and the UK in 2016. Our need for talented software developers is driven, in part, by our ambitious project to rewrite, from scratch, our end-to-end software platform to run in the cloud, to refresh all our technology stacks, and to wipe out our accumulated technical debt.

No mean feat! To enable us to achieve this, we’ve recently opened a new development centre, in Sofia, Bulgaria, complementing our development centres in the UK and Poland. These sites will develop the cutting edge software which Ocado and future retailers will depend upon to deliver high quality customer service.

Every time we open in a new country or city it brings new developers with different experiences into the company, which is a great way for Ocado Technology to be challenged internally and for us not to stagnate.

Ocado has never stood still; what many companies would consider R&D we see as business as usual innovation. So this international expansion is just one more way we continue to improve our service.

The Sofia office will grow into a significant development centre over the next few years, anyone who is part of this will benefit from the significant opportunities it creates, to grow and develop a wide range of both technical and non technical skills.

If you’re interested in joining us at the Sofia office then the current opportunities can be found on Questers

Richard Haywood, Development Manager

November 17th, 2015

Posted In: Blog

Tags: , , , , ,

Chris Brett

My team researches, implements and analyses new automation mechanisms. We sit within the Simulation and Visualisation area and our focus is mainly on the company’s huge CFCs (Customer Fulfilment Centres – warehouses).

Essentially, we create simulations that we then use as sandboxes to test out different control algorithms.

This could be anything from really innovative new ways of automating, involving entirely new hardware that doesn’t even exist yet, to simple tweaks to existing systems. The impact this has on the business makes this really exciting.

In terms of scale, the KPIs produced by our simulations mean big money for the business.

They allow evidence based decisions to be made as to which algorithm to use, or even what to actually construct, based on how well we predict it will perform in production. We can make the company more profitable thanks to reduced hardware requirements, greater maximum throughput, higher reliability and resiliency etc.

The simulations that we create need to be highly true to life, to be confident that an algorithm that performs well in simulation will also perform well in the real world. This means modelling edge cases such as mechanical failures and time deviations, message loss and latency, and incorrect sensor reports.

When developing high level control systems, the simulations also need to be fairly far reaching. It’s not just the mechanics that must be simulated. Other systems – or even people – that interact with the system we’re developing also have to be modelled. Any event that might happen in the real world needs to be considered.

A lot of the problem spaces that we work in are extremely complex, which makes designing and implementing a highly optimal algorithm within that space similarly complex, and a lot of fun. Even if you can design an algorithm that can derive an optimal decision, can you make it run fast enough to keep up?

The research and development nature of our work means that our goals often change rapidly. A new hardware idea may come along that we then simulate, prototype the control of, analyse, and discard based on the results, moving on to the next challenge. Or the bottleneck of some system may be overcome, revealing the next bottleneck that can be optimised. I really enjoy this variety of work. There’s always a new puzzle to solve.

I work with a great team – they’re good fun, really smart, and we learn a lot from each other.

Some are experts in particular areas, but mostly we try to spread the knowledge and skills throughout the team so that everyone gets variety, new challenges, and the chance to work with different people.

If you’d like to join us, we’re currently recruiting for these roles and would love to hear from you:

Senior Java Software Engineer – Simulation

Java Software Engineer (SE2) – Simulation

Chris Brett, Simulation Algorithm Development Team Leader

September 22nd, 2015

Posted In: Blog

Tags: , , , , , , , ,

Ali Major

In my first blog post I illustrated the many factors to take into consideration when building a cohesive team. This time I want to explore the technology available.

Can you make do without technology in building an effective non-collocated team? For me the answer is yes. But would that team be as effective and could the quality of relationships be formed as quickly? I’m not convinced so.

What technologies I use and when

Working in the age of technology affords us the luxury of numerous online communication tools, both paid-for and free. So which to choose?

The ease of interaction and responsiveness is the ultimate measure. It shouldn’t feel like a hassle to keep in constant contact with the teams during the day, and this is crucial to being able to build that successful team.

In fact, online communication tools have become such an ingrained and easy way of working that I feel more put-out having to leave the comfort of my desk to walk to meetings in our other two adjacent buildings.

So here are the online tools I use and why.

Smile, you’re on camera

Don’t be shy, don’t be a voice from afar, and don’t try to hide in the back of the room.

I highly recommend conducting all meetings with an offshore team via video conference. People receive information better when they have more than one way in which the information is conveyed. Being able to see and hear is a vast improvement to staring out the window whilst on a phone call.

It may seem a little awkward to begin with, but you get the chance to pick up on visual queues: a smile, a frown, a blank stare. Remember to move once in a while – a nod will do – as on more than one occasion I’ve thought the connection was hanging when the team was sitting extremely still!

There are numerous free options such as Google Hangouts and Skype, and paid-for services such as GoToMeeting and Avaya Scopia®. I would recommend investing in any tool that permits screen share and the ability to have multiple parties on a call.


So far so obvious but, despite some arguments against relying on email, it remains wonderful for a record of conversation, lengthy discussions and non time-sensitive communications. (Of course, if an email chain is going back and forth, back and forth, consider whether a video call would be better to discuss the topic.)

What I will mention though is, when setting up folders, apply the ‘can I answer this in under one minute?’ rule to use your time most effectively.

Quick chat versus fluid conversation

Chat rooms or message services like the Google Hangout chat feature, which sync across devices, have worked well between stakeholders, my teams and myself.

My teams know that if you need a quick response to a question then Hangouts or Slack are best. Chat rooms address many of the shortfalls of online message services, especially where you can subscribe to groups. Until we started using Slack we tended to have many one-to-one chats using Hangouts. The downside was that the individual had to relay everything to the other team members.

Team chat rooms have provided a mechanism for fluid conversations, and I love that we can subscribe to specific topics of interest from within other areas of the business.

If you can find a chat service that allows you to search previous conversations I would highly recommend it, as it’s very useful in the age of information bombardment.

Keeping up to date

Our teams needs to know about changes, latest tools and processes, business objectives and so on. We rely on Google+ and recently Slack, in which users can subscribe to specific communities or channels.

Google Sites tends to be where we maintain product and/or team specific pages. Flipping this around, my teams and our Product Owner community can also leverage Google+ to create our own communities as a way to reach stakeholders within our business.

Managing requirements

I am a massive Atlassian fan (yes, I even have the t-shirt) and use Jira for backlog management and visualisation of our workflow.

There are many other great reasons to use Jira, for example tracking stories levied on other collocated or non-collocated teams, versioning, filtering, metrics and keeping stakeholders up to date at anytime during the day. We also use Jira as a tool to facilitate scrum ceremonies.

I would strongly suggest you display the team board on an additional monitor where the team sits. This way you still get the benefits (though likely on a smaller scale) of a physical board.

There are of course other online tools for managing backlogs such as Trello and Scrumwise. Still, personally, I like Jira more.

Last but crucial point

Technology is vital, but only as a means to achieve this goal: to become an effective team.

It does not remove the need for physical interaction and, as previously blogged, your intentions and resulting actions are more important.

And, dear reader, don’t forget the fallback position when that internet connection is slow or your company doesn’t support certain communication tools… pick up the telephone!

June 19th, 2015

Posted In: Blog

Tags: , , , ,

Ali Major

As a Product Owner working with a team across two different countries, there are lots of problems to tackle to make sure projects run smoothly. In this series of blog posts, I will explore how my team and I have overcome issues.

For a bit of background info, I’m based in Hatfield and my colleagues in Krakow. We use Agile. In this first blog, I’ll explain how we work cohesively even though we’re miles apart.

Is the structure You + Team, or are you part of the team?

Let’s not beat around the bush, you should be part of the team, so don’t treat your team as anything less. And to be frank, you cannot be part of the team when trust has not been established and you have not invested in building relationships! You’ll just be the PO who is nominally part of the team because Scrum says you are…

Building a solid relationship takes time and I have tried many different ways with varying success. What works for one team does not always work for the other so re-evaluating this continually is very important.

So what were some of the things that have worked?

Communicate regularly

Communication is a potential hazard, so I made a deliberate effort to ensure that we communicate regularly i.e. every 1-2 days either on a work or social level.

To begin with I focused heavily on communication with the team’s leads. As time passed I began to find ways to engage more and more with the team as a whole. It is easier to just keep going back to the one person, but this approach hinders your effectiveness in the long run.

Why? Well you end up relying on that one person and at some point they go on leave; also information is double-handled as they relay everything back to the team. Finally it reduces overall interaction with the team, which you need to build a solid working relationship.

Show positive attitude and willingness to build a cohesive team

Don’t underestimate how much your mood and choice of words are perceived via email and hangout. If you are strictly business every time you talk to your team and seemed rushed or disinterested, then it is only fair the team reciprocates.

Regular visits to Krakow

After numerous visits of varying length, we came to the conclusion that it is best to not nick off as soon as your agenda is done. Spread your agenda over an extra 1-2 days and mix your time there with meeting your agenda and with normal day-to-day business.

Just being there to be asked a simple question, to go for lunch with the team, to contribute to Agile ceremonies… ahh nothing beats the luxury of walking over to a teammate to ask a question once in a while! Also it challenges the perception that you are just flying in and out for your needs, and shows that you value time with the team.


I love games and I play them when I am in meetings in Krakow as well as from Hatfield on hangouts. Taboo, Pictionary, Charades, trivia, true & false, riddles…

Why? Games remove the perception ‘we only communicate about work content’. It can help a team to learn more about each other i.e. ‘I come from Australia so – true or false, dear reader – I have been bitten by a brown snake?’ Games makes meetings more fun and they can relieve tensions during heated and/or vigorous discussions.

Ali's team in Krakow

Agile ceremonies

I attend all the prescribed scrum ceremonies with the team bar the daily stand-up. The reason for not attending the daily stand-up is that, with daily interaction and the ability to track progress of tasks moving on the JIRA board, I have enough information on what is going on and any impediments. Also it’s easier for the teams to do their stand-up in Polish and this is meant to be a quick meeting.

Should I learn Polish?

English is the first language of our organisation. For my Polish to be at the same standard as the team’s English I would need many years of study. If you know me and have heard my attempt at Polish (or any language) you would probably come to the conclusion that I shouldn’t push it!…

I firmly believe making an attempt is appreciated, but in my situation investing time in developing my technical knowledge is time better spent.

Sometimes in our meetings it is easier for the team to discuss technical details in Polish. I would encourage this as being acceptable, but that this is not the norm and they need to re-summarise in English what the discussion was about.

April 17th, 2015

Posted In: Blog

Tags: , , , , , ,

Ryan Wong

A little bit of background about myself: I’m Ryan and I’m a graduate fresh from Imperial College London. This is the story of how I moved from intern to full-time at Ocado Technology. If you’re looking for placements or first jobs, I hope you’ll find it useful.

The preparation and interviews

I came across Ocado Technology when I was thinking about whether to apply to banks or technology companies for my placement. After researching, I found out that Ocado develops all their technology in-house. So I thought it would be somewhere interesting to learn and work for four months.

Having gone through an initial CV screening and an online coding test, I was invited for the assessment day which included a written test and two rounds of interviews. I was also shown round the warehouse, AKA the ‘CFC’ (Customer Fulfilment Centre). It was fascinating to see the huge automated system in action.

After a few days of waiting, I was offered the internship.

The team

Among a great number of technology teams, I was assigned to the CFC Simulation and Flow Analysis team. They’re responsible for developing discrete event simulation models of the CFCs.

CFC model


The purpose of the simulation models are: capacity prediction; constraint identification; design appraisal; return on investment calculation; as a test-bed to develop algorithms; and to conduct ad hoc studies.

In addition, the team has written a three-dimensional visualisation tool with animated totes, allowing simulation runs to be visually reviewed (which I personally found it really cool).

The projects

There were three projects that I worked on during my placement:

  • The first was to use Python and Django to build a light-weight web app that constantly reports the status of the simulation models.
  • The second was to build a routing implementation for the simulation models. The aim of this project was to create a graph-based routing implementation to analyse how the totes inside the warehouse can be routed in the most efficient way.
  • The third was to use the power of the Google Compute Engine to run multiple simulation models on numbers of virtual machine instances simultaneously. This meant a set of optimal constants for the cost function in the previous project could be found more efficiently by comparing the simulation model results.

At the end of the placement, all interns had a chance to show off their work to engineers at the interns’ fair. It was a really good opportunity to listen to professional comments and share our views on the projects.

Here’s what I learnt

First of all I consolidated my programming skills from university in Java, and I learnt Python which I had never used before.

Alongside the technical skills, I was also able to learn how the real technology industry does software engineering, how the software actually gets delivered in production, and how the teams collaborate.

Working with a team of professionals was a valuable opportunity for a university student. It was great to receive feedback and comments from engineers specialised in different areas.

From intern to full-time

So, how can you ensure an offer after your internship? I don’t have a definite answer but, in my opinion, there are a few points that are important:

Firstly, you must ask questions – the more questions you ask, the more you understand the task. And people here are extremely helpful and friendly. So don’t be shy to ask anybody.

Secondly, you mustn’t think you are not good enough for the role, because interning is all about learning. People don’t expect you to know everything. So always be positive and enthusiastic about what you are working on.

What now?

Now, here I am, working as a software engineer at Ocado Technology. I’m currently in the Back End Web Development team, where we develop and maintain the applications that are used for and internally.

To be a developer somewhere I interned is quite an advantage because I’m already familiar with the environment and culture, which has allowed me to get stuck in very easily.

I would definitely recommend Ocado Technology if you’re the kind of person who loves challenging yourself and would like to contribute to future web development. I believe you’d be fascinated if you knew what Ocado Technology is planning to do in the future…

Ryan, ex intern and current software engineer

March 3rd, 2015

Posted In: Blog

Tags: , , , , ,

Scroll Up