Hello, everybody.
I'm impressed with the amount of people here.
It's great to see you - if I could see you!
I'm Joanna.
I'm an engineering manager on DeepMind Health
team.
And I'm here today to talk to you about the
one hand of the rapid growth of the team and
what is important in this rapid growth.
When you are team lead, tech lead, manager,
maybe CTO of the company, but, on the second
aspect, your companies will be working in
more and more challenging areas in domains
on the projects that are actually impacting
lives of people, and not only in the metaphorical
sense but actually being able to touch their
life and change it.
So that is why I would want to start telling
you a bit about the project we are working
on, because I think it's very important to
understand the environment in which this rapid
growth of the team has happened.
And then both the technical aspects and the
people aspects, the things that I think we
learned, and I hope that you will be able
think about them early on to prepare yourself
and the teams for the rapid growth.
So, when we talk about health care, when we
talk about health care especially in the context
of DeepMind or the high tech companies, this
is what people usually think about.
Modern environment, a lot of equipment.
But the truth is it is more like this.
That still is reality in a lot of hospitals,
even if they have modern health record systems,
they would also have parts of the process
that are happening on paper.
They will have this mix happening.
A lot of the systems that they will have deployed
will be not necessarily operating well together.
So, even more importantly, like can you spot
a dashboard on this picture, right?
That's the real time updated dashboard.
Probably, you have better tools for monitoring
of the systems that you're running with than
the one in here.
And then we think about the communication.
Communication is another super important aspect.
The doctors make their decisions, and when
they make decisions, they use either the knowledge
they have, so they can make the decision individually,
but more often than not, they actually consult
someone, and when they want to consult someone,
they've to talk or communicate with them in
some way.
Another test: can you name the thing on the
picture?
That's a pager.
For all of you who have not interfaced with
such advanced technology, this is a primitive
version of mobile phone.
It can only display the number that it is
trying to reach you.
Imagine the doctor goes into the theatre,
the operating theatre, they perform the surgery,
they get out of that, and on this device they
see 20 pages.
There is no way for them at this point to
say who needs they will, why they need them,
what is the most urgent phone they should
reply to, and they will go one by one replaying.
There might be someone who is dying on the
other side of one of those pages.
Finally, even in the leading hospitals, technology
is not necessarily what it should be.
So, if you ask in a hospital in the NHS in
the advanced hospitals in the NHS if they
use mobile technology, they would say yes.
Because the thing you see here is actually
what is called Computer on Wheels.
And this literally is a computer on wheels,
so it's mobile!
In this environment, it's easy for me to joke,
and it's easy for you to laugh because most
of us are actually working in a fancy offices
with all the equipment we need.
Huge shout out to the people delivering the
medical care and dealing with the 50-year-old
technology on a daily basis actually trying
to save our lives.
Having said that, we can do better.
That is why in 2015, a team of a few people
started to look into whether it's possible
to deploy and create the mobile application
that would deliver important information to
clinicians to nurses, to doctors, straight
into their hands, and improve the delivery
of health care.
The good news is, yes, it's possible.
We are currently in live deployment in two
hospitals in London.
We are helping nurses and doctors to treat
patients.
What we are focusing on initially, it's another
thing.
It's the spectrum of what can be addressed
in technology in the health care set-up is
so broad that the first learning for us is
that we have to focus on something that is
small enough and traceable enough to know
if we are making a change.
The team has focused on the detection and
alerting with the acute kidney injury.
That's a condition that happens when you are
in a hospital and for some reason, your kidneys
shut down.
The problem with this condition is that it
is actually quite common.
It often happens as a second conditions that
you will develop whilst in the hospital, and
even if detected and you will not die ultimately,
you will end up on dialysis which severely
- 
reaction is easy.
Sometimes, it's enough to provide fluid for
the patients, it's enough to provide antibiotics
and coverage, so the treatment is easy.
We have developed the application that analyses
the blood samples and lets clinicians know,
and we see the impact of this application
in clinical deployment.
We will be publishing the results of actually
a year-long evaluation of the deployment of
the application soon.
So, it's definitely possible to focus and
deliver impact.
We also noticed that simple fact of giving
them the mobile application and give them
the information they need when they need it
to assess the patient, already saves them
time, so one of the anecdotal evidence of
the impact of our application is that they
actually say they have two more hours a day
to face-to-face conversations with patients
because they don't have to run to use their
mobile computer on wheels.
So this is the application that the thing
I'm showing you is what we actually developed
last three years in close collaboration with
clinicians, so we've spent long hours talking
with them, talking prototypes, iterating.
Across that time, the team has grown from
literally a few people at start to over 150
at the moment.
And if you think about it, this is a significant
growth.
From the start-up to quite established team
at the moment, what were the important aspects
that we have learned to pay attention to,
and I think will be applicable to other organisations
as well?
First of all, be super clear about the trade-offs
in technical design.
My background is I studied computer science
and the first ten years of my software career
I spent at Google.
Google's approach is often, you know, very
large-scale, so you join the team, and you
start working on a project that already has
millions of users.
When you create a new design, you create a
design with those numbers in your head.
You address hundreds of QPSs in your design,
but when you're a start-up, it's very different.
When you're a start-up, it's important for
you to move fast.
It's important for you to be able to evaluate
the concepts and ideas that are coming from
product, from founders, from users, and through
that fast evaluation to learn and find your
niche in the market.
And fast evaluation and large-scale robust
design do not go hand in hand.
If you are not thinking about it actively,
what will happen is that you will start accumulating
technical debt.
And this technical debt is not something that
will go away on its own.
This is something that actually has to be
tackled, and there are two traditional approaches.
One is to ignore technical debt early on,
push as far as you can for new features, and
then one day sit down and be like, okay, code
red.
Let's rewrite everything.
The other approach is to actually constantly
think about this technical debt that you're
accumulating and either through, like, sprints,
like, you know, fix-it weeks, or active effort
in having the core team that is addressing
the technical debt as you go, to make sure
that it never accumulates so that it paralyses
you, both approaches are good.
There is not like one size fits all, but,
what is important is to be intentional about
it.
It's important to know the domain you are
working in.
It's important to have this time either now
or in the future that you know you will spend
on improving the technical design of your
system.
It's also important not only for us as leaders
but it's important for us as leaders to make
sure that the team understands the trade-offs
we are making so that everyone is on the same
page and they're actually using the same strategy
to deal with technical debt.
Because ultimately, it is about being clear
to yourself about how risk-tolerant and how
error-tolerant you are.
In the complex projects that deal with regulated
environments, health care, banking, probably,
you cannot afford errors.
You cannot afford taking the risk of leaking
users' data.
At the same time, I used to work on the e-commerce
start-up, and from products the guideline
was we are totally fine to drop five per cent
of requests, and, for me, as a software, I'm
like what do you mean.
That's a valid trade-off they were ready for,
going for 95 per cent of users being happy
with the service, and that is fine.
Second thing: from day one, you have to think
about the quality, security, and privacy of
the system.
Don't put it for later.
Because it's not something that can be applied
as another layer on the systems that you are
building.
Security and privacy is something like you
build from ground up on, so you have to think
about how are you dealing with user data?
Who has access to those systems?
How important the security and privacy is
for your system.
And usually, if the answer is you are dealing
with user data end-user data, it's important.
It's not that we can ignore it because we
are writing messenger.
Messenger can actually, you know, include
a lot of personal information.
It can actually impact people's lives if the
information is leaked.
And even more importantly, if that is like,
again, financial, or medical information,
crucial opinion so, hire experts, even if
it is one person on the team who actually
knows what they're talking about when it comes
to security and privacy.
Have this person in-house.
Include them in conversations, and ensure
they're not like, you know, the person who
is asked just to sign off on the technical
design but use their expertise.
Hire external companies to black-box test
your system.
Show that you're interested in them finning
the vulnerabilities and that you're interested
in fixing those vulnerabilities.
If the error will happen and something happens
to the data that you're processing, you should
be able to show that you care and, for that,
that you have an evidence of all the actions
you have taken to ensure the safety of the
system.
Finally, the slide I will spend the most time
on: don't forget that, at the heart of everything
you do are the people, the team that is building
the system.
It's the most important asset of your company.
It doesn't matter what desks people are working
on, and it doesn't matter on what laptops
they're working on.
It matters on who is working and who is building
this team.
And I think that's the thing that is easiest
to forget in the time of the fast growth,
because you started as a small Italy, you
started from the place where everyone knows
everyone, and everyone trusts everyone to
do the right thing.
And you are just adding one person at a time.
One person here, and one person there.
And soon you realise that you don't know some
people on your team, and soon you realise
that what has been the shared intuition no
longer - a shared intention is no longer a
shared intention about the team.
Probably the first very important lesson is
to hire responsibly.
Whenever you are hiring a new person to your
team, make sure that you really, really need
that person.
Just don't hire because you can.
Don't hire because you have a next round of
funding, and we are sure with the next ten
engineers, we know what we will build.
You will, or you will lose focus and you will
start building things because you have more
hands.
Scrapiness actually forces us to be super,
super sharp-focused on what is the most important
thing.
Then never lower your hiring bar.
You're like we have the deadline, we committed
to something, we took the round of funding,
we need to show the progress on the project.
We really, really need to hire people and
there are no people who are meeting our hiring
bar, there are no people at the market at
the moment, and like this person is, like,
almost as good as we would want them to be.
You will always be paying the price of this
person being almost as good.
And be intentional about diversity.
I think this one is the hardest, because it's
very tempting to hire whatever is on the market,
but think about the team you are building,
and the team you will actually be living with
for another X years.
Who do you want to have on the team?
What is important for that team to deliver
on?
How can you ensure that you get the people
that you want to have?
Then there is the whole aspect of having this
team and working with that team, and not forgetting
about a few important aspects.
First of all, look out for the signs of the
team burn-out, because when people are working
on a super important mission, something they
are strongly attached to, it's very easy for
them to think just the next dead line.
I will go crazy because we have to deliver
that.
It is important.
Yes, it is important, but the months will
change into a quarter, and the quarter will
become a year.
We have to learn also in start-ups to work
in a sustainable way.
We have to learn so that people can deliver
and can live their live at the same time.
And in the same area, it's very important
to monitor for the team's psychological safety.
In the times of the fast growth when you're
adding more and more people to the team, and
when the core team members that have been
with you for a long period of time are extremely
business, because let's not forget, they're
core people and probably pooled in a lot of
decisions and a lot of delivery, it's very
easy to lose the sense of what is the culture
of the team we are hiring to?
Are people feeling actually safe?
Can they question decisions?
Because all that boils down to whether they
will be building this team the same way as
the previous team members have been building
it, whether they will be able to contribute
to their best or will they be afraid that
they may get fired toll.
Let's not forget about how important it is
for people to actually feel appreciated.
Yes, everyone is super busy.
Yes, everyone is running.
Yes, everyone is contributing to this next
big release, but at the same time, you have
done this job, and that was great, and the
other person has actually pulled their own
... pulled an all-nighter and contributed
to the team's success.
All-nighter is one example.
I'm not encouraging people to pull all-nighters.
We should not have a hero attitude on our
teams.
It should not happen regularly.
And then the last aspect I would say is around
the communication.
And it's not only about ensuring that communication
is open.
And intentional.
It's more about thinking how to scale your
communication as the team grows.
Because no longer it will be this 15 people
of the initial team who will know everything
and who will even, even if they don't know,
have enough self-confidence and that their
position on the team to actually ask where
does this decision come from?
So, when it comes to communication with the
growth of the team, it's important to build
mechanisms for teams to communicate across
and for the roles to communicate across, so,
for the products to have a way to easily communicate
with engineers and understand engineering
trade-offs, for programme managers to be able
to be perceived as the source of energy on
the Italy, not the ones who are like, you
know, when will this be ready, it's important
to have a proper communication top down, because
there's a understanding of the vision and
of the mission of the company, but is it the
same understanding across 50 people of the
team, on the team?
We definitely discovered that, at some point,
we had the understanding but that wasn't like,
you know, crisp clear, and because this understanding
was like, you know, slightly blurred, and
the priorities were slightly burden, people
were making decisions based on their understanding
and those decisions were sometimes pulling
in different directions.
Working with the team and the leaders and
working with the vision of the group is clear,
that the roles and responsibilities of team
members are clear.
It's really important.
And finally, ensure that the communication
bottom-up happens.
Ensure that you as a leader understand how
your team feels, how people perceive the decisions.
Do they have enough clarity?
What is the next thing that you can actually
improve on?
Because otherwise if this communication breaks
down, you will have no clue, your company
will be growing, and you will not know what
is actually happening on the ground.
So with all those thing, what I want to leave
you with is through all that time, be clear
on the goal.
Ensure that not only you and leadership know
what is happening, but ensure that all the
team knows what is happening.
Communicate openly, be transparent, be clear
about your intentions.
I think I have to call out here Monzo as an
example of brilliant open communication.
I assumed they not only communicate this inside
their team, they communicate like this outside
of the company, which is bold, it's brave,
it's putting them in a position of vulnerability,
because, you know, people can call them out
of whatever has been published, right?
But at the same time, for me, it builds amazing
trust in the company that can actually do
that.
I'm thinking it must be amazing to be on that
team and have this clarity of how they approach
things.
Hire responsibly.
Think about what you're miring for, why are
you hiring for, and think about it, and write
it down before you hire.
So you cannot change your mind and alter your
mind in the process because you faced some
difficulties.
And finally, care for people.
That's the only thing that will survive everything.
The company may change the name, it may get
acquired, it may get sold.
The project may change, and you may decide
to pivot from product A to product B, but
if you have a strong group of people who can
build things together, if you create the environment
in which every single person on this team
feels appreciated, feels a part of the group,
feels that they contributed to their shared
success, and most importantly, they feel they
grow with the company every day, that is the
biggest power that you have in your company.
With that, thank you.
