>> Thank you very much, Meri.
I'm an engineering manager, but, once upon a time, a very, very long time ago, I was
just a humble software tester.
And the way I process - the way our process worked went like this: so the developers would
write their features, they would poke a bit around the UI, write automated tests, make
sure they were green, and then they would declare it done.
Then I and another tester would pick up the stories, and have another little go at testing
them.
What a surprise, we would find issues.
In fact, we found so many issues that, out of nine months of development work, we generally
created another three months of rework to actually get that stuff shippable.
Yes, that's a very long release cycle, this was a very long time ago.
Now, testing is not really very glamorous profession, and so there were times when I
questioned my worth in the company.
When I did that, I would look at that three months of work that I created, knowing that
it was improving the customer experience in the end, and say, "That is the measure of
my worth to this company."
And I felt pretty proud about that.
So I'm here today to talk about overhead teams - I don't mean overhead, I mean financial
overhead.
The roles in a company that are really important, crucial, but they don't directly bring in
the cash.
If somebody wants to make more money, they're not going to say the first thing I will do
is high some more testers.
So, some overhead roles are at the timing overhead support, bug, maintenance, tech writing
and leadership.
And sensible companies try to reduce their overhead as much as is possible, and so it
often means that, when you're in an overhead role, it can feel like you get defensive or
you get victimised.
People are trying to cut us.
They don't understand the value that we add.
That can often happen because people in overhead roles can look at just the small picture and
not understand where they fit into the broader picture of the organisation.
So back in my testing days, that was definitely the case.
All I cared about was the quality of the product.
Don't get me wrong, it's pretty important, but it doesn't mean it said the only thing
that is important.
The work we were doing was adding an extra three-month delay to getting the software
out the door, and other people coming in looking at the broader picture were saying it takes
three months to get from code-complete to done?
That is atrocious.
I was looking at that in the meantime saying, "I created three months of work.
I'm awesome!"
[LAUGHTER].
Thankfully, I had a Q&A manager at the who had a broader view.
He held me and my colleague accountable not just for the quality of the software delivered,
but also for the speed of the development process.
So what do you do when given that kind of accountability, especially when it felt like
it conflicted?
Well, if you are like me, stubborn, the first thing you do is try to dig yourself deeper.
I said, "Well, the code that we are getting from upstream is really poor quality.
It takes three months to get that to production quality.
Quality is non-negotiable.
One of our company values is don't F the customer.
Therefore, there is nothing we can do to reduce that three months.
End of story."
Now, most of that is true.
It doesn't mean that it is helpful.
So, thankfully, my boss helped me to see it a different way, and so we started again with
that thought process.
Okay, it takes three months because upstream code quality is poor.
Why's that?
It is because the developers aren't testing very well.
Why is that?
First of all, they don't know how to, secondly, they don't really care very much, and thirdly,
they're not being held accountable for the quality of what they are shipping.
So now we're no longer at a dead end, we have three problems that we need so solve.
So that's what we did.
We changed our role entirely.
We stopped being a testing team, and we became what we called a quality assistance team.
And our full-time role was to educate developers in really good testing techniques, really
efficient testing techniques; secondly, to build the customer empathy in the team, help
the devs realise this isn't just a bug Android issue-tracker, this is something real that's
going to impact real people; thirdly, we worked with the dev team leads and dev managers - dev
- to hold them accountable for what is doing.
It worked.
I won't say it is easy - it took several years, but we went from 100% stories needing rework
to four per cent.
We got rid of that three-month rework process entirely.
In fact, these days, the team shifts multiple times a weeks to production.
But most importantly, the quality of the product actually increased because all that customer
empathy and care about what the customer was really doing was baked in at the start of
the process and not pushed into the chocolate chip cookie later on, to use Heidi's example.
So that's the benefit of looking at the broader picture: if we had only looked at quality,
quality, quality, we don't care about speed, then we would have continue to cost a lot
more to the company.
So it is all they nice when you're in an overhead team and you can address the root causes like
that.
But often you can't.
So let's take another example which is bug-fix.
So, earlier this year, I was working as a dev manager and I took on ownership of the
JIRA bug-fix team.
They don't fix new bugs but the legacy of old bugs signature there in our - sitting
there in our public issue tracker.
They're not serious, only affect a small proportion of customers, yet the total of the bugs adds
up to an amount of customer pain and an amount of support cost.
So when I took on this team, I spoke to the previous bug-if I can managers and asked them,
"What are the issues you have had with running this team?"
They all told me the same thing.
They said you will just end up in this endless battle with the Head of Engineering, trying
to get more developers, because you can never get through that bug-fix backlog enough really
to make a difference.
I said, "Hmm okay, it is a problem.
Bug-fix is an important quality thing, quality is non-negotiable, don't F the customer, et
cetera."
Let me see if I can put together a compelling business case to get more devs on bug-fix.
The way the system works is there is no-one permanently assigned to bug-fix.
Each iteration, a certain number of developers are taken off their feature teams and put
into the bug-fix team.
At the time I inherited it, it was four developers, each iteration.
I said, okay, quality's really important, but, first of all, let's look at the broader
view: a bug's really the aspect of quality that our customers care the most about.
I looked at a bunch of met Ricks we had that aggregated all the different customer feedback
we had coming in, and there were different types of met Ricks coming from - metrics,
end-users, cancelled evaluation, and people who cancelled their subscriptions, and they
all told me the same story.
Taking the cancellations as an example, of the people that cancelled their subscriptions,
ten per cent of them said that they did so because they found the user experience too
confusing, too complicated, and, to be fair, that can be true.
Eight Perseid that it was because they found the performance too slow; 0.4 Perseid it was
- bugfix doesn't seem like the best place to
achieve that, particularly since increasing bug-fix investment meant I was pulling those
devs off the feature teams that were rewriting the confusing UI and fixing the performance.
So, it no longer - I was no longer thinking, "How can I increase the size of this team?"
I was asking, "What is the right size of this team so we are working sustainably?"
So I had a chat with the support folks.
We came up with a way to measure the amount of bug debt we had in terms of customer impact.
Then I looked back through the history of the bug-fix teams and look how many devs we
had had on the team at each iteration and correlated how to change that metric.
The number that we came up with in the end was in order to keep that debt stable we needed
2.5 developers on bug-fix.
I think what is possibly the first time in history, I went to the head of engineering,
and I said, "I have too many developers, please take some back."
Because it is far more important to have those developers working on the things that customers
care about rather than being overhead in this bug-fix team.
So there are four lessons I would like you to get out of this: the first one is that
if you're in an overhead role, or you're leading an overhead team, please don't deny it as
but embrace it.
Recognise you're not the ones making the money and try to figure out how to redirect the
company's resources so they can be.
Secondly, broaden your view.
Don't just work towards your team's goals, work towards the company and the customer's
goals and you may end up finding then you find better ways to achieve your own goals.
There is an opportunity cost to everything you ask for for your team.
Understand what that is before you go out asking for more.
Thirdly, try not to mistake your costs for your value.
As a tester, the three months of working I was adding was not my value, my value was
the improved quality.
That was the cost that I was adding, that was my overhead.
Similarly, with managers, your value is not the number of people that report to you, it
is the amount of work that that team is able to produce.
If you can get the same work done with half the number of people, you're twice as valuable.
Finally, please remember that, yes, leaders are overhead, too.
Pretty much in this room is overhead.
So, look out, I'm coming for you next!
Thank you very much.
[APPLAUSE].
Going to take a selfie, if I may!
[LAUGHTER] Cool.
Thank you.
>> Great job.
One of the topics that we had requested a loot last year after the conference was to
have more about remote working.
We had a number of really cool and interesting submissions on that topic, and this is the
one that we chose out of those submissions.
So we have Laura coming to talk to us about how to deal with the culture divide and internal
advocacy in a distributed team.
She's a developing/community manager at Couchbase, and I'm really excited to hear her thoughts
on how to help our remote teams have a consistent culture and to work with well together.
Welcome to the stage, Laura.
[APPLAUSE].
>> Hello, everybody.
I hope you can hear me okay?
Yes.
You're not seeing what I'm seeing.
Shoot.
I'm sorry, this was working.
Best-laid plans, and all that.
>> I threatened to sing but none of us deserved that!
>> How is everybody today?
All awake after lunch?
No!
Come on!
Wakey, wakey!
[APPLAUSE].
Okay, we are going to do this.
Currently hating my operating system right now.
It is not a Mac.
It's not windows, either!
>> And I can't blame this on the TV trucks!
>> It did work.
It is because of the slide.
>> Right, everybody up.
Super hero poses!
[LAUGHTER].
Come on, like the middle row here are awesome, and the rest of you are just hanging out!
Turn to the person next to you and teach them the most weird word you've heard recently.
We all know the one word to remember to forget!
[General chatter].