• Category Archives: blog

8% of pull requests are doomed

Today we’ll look at three terminal pull request outcomes and one way to increase velocity in
your engineering process.

Every pull request has one of three outcomes

Every pull request has costs: engineering labor, product management, and
opportunity cost, to name a few. Each also has an outcome: merged, closed
without merging, or abandoned due to inactivity.

Here’s a look at how pull requests fare across the industry:

If you group closed and inactive pull requests together (“Abandoned PRs”), you
can estimate that the average engineer abandons 8% of the pull requests they
create, which is equivalent to a loss of $24,000 per year1, or the cost of a
2018 Toyota Camry Hybrid
.

(We consider pull requests that have had zero activity for more than three days
to be abandoned because our data shows a very low likelihood that PRs that go
untouched for so long get merged later.)

Achieving zero abandoned pull requests is an anti-goal, as it would require being
extremely conservative when opening them. However, a high rate of abandoned PRs can
indicate inefficiency and opportunity for improvement within an engineering
process. Reducing PR loss by 20% on a team with 10 engineers could save $48,000
per year.

How does my team stack up?

Using an anonymized, aggregated analysis of thousands of engineering
contributors, we’re able to get an understanding of how an engineering
organization compares to others in the industry:

This density plot shows that the average pull request loss rate across our
dataset is 8% (with a median of 6%). A loss rate above 11% would be in the
bottom quartile, and a loss rate below 3% would be upper quartile performance.

Improving pull request outcomes

Abandoned pull requests are, of course, a lagging indicator. You can tell because it
would be ridiculous to go to an engineering team and say, “All those PRs that
you’re closing… merge them instead!”

Potential drivers lie upstream: late changing product requirements, shifting
business priorities, unclear architectural direction and good ole’ fashioned
technical debt. If you have an issue with abandoned pull requests, soliciting
qualitative feedback is a great next step. Talk to your team. Identify something
that is impacting them and talk about how you might avoid it next time. Then,
rather than focus on the absolute value of your starting point, you can monitor
that your abandonment rate is going down over time.

After all, you’d probably rather not send a brand new Camry to the scrap yard
every year.

1 Assumes a fully loaded annual cost of $300k per developer.

Read more at the source

Velocity is out of beta

Our mission at Code Climate is to help engineering organizations improve their processes, teams and code. We see a future where everyone from individual developers up to the CTO has access to a full picture of their engineering work in the form of clear, timely and actionable quantitative data.

In February, we opened our Velocity public beta. Over the past five months, we’ve spoken with hundreds of engineering leaders, processed a nearly-overwhelming amount of product feedback, and added dozens of top-requested features.

We’ve been floored by the excitement from engineering leaders:

“If you haven’t tried @codeclimate’s new Velocity product, and you’re interested in non-vanity measurements of productivity, and a baseline from which to measure process improvements, try it now. It’s very exciting.”

– Avi Flombaum, Dean and Chief Product Officer, Flatiron School

“Velocity is quickly becoming one of my favorite tools for engineering management.”

– Tomas Becklin, VP of Engineering, DroneBase

Today, Velocity is launching out of beta, and we’re ready to help your engineering organization turn on the lights.

Click here to book a Velocity demo today.

Everyone who books a demo before Thursday, July 26th will receive our introductory launch pricing of 20% off for life. This is a one-time offer that we won’t be repeating anytime soon.

Still on the fence? Keep reading.

Most engineering decisions are anecdote-driven

Today, engineering organizations are often forced to make decisions based solely on anecdotes, gut feel and incomplete information. We understand that qualitative information is highly valuable – there’s no substitute for experience and intuition. However, the lack of quantitative data within engineering processes is a missed opportunity, especially given how data has transformed DevOps.

Historically, engineering organizations looking to incorporate data into their processes have faced two problems.

First, unless they’re working within a behemoth like Google, there simply aren’t enough developer resources to spare to invest in such efforts. This is the problem of “The Cobbler’s children having no shoes,” as analytics has transformed so many departments like sales, marketing, and finance.

Second, even if metrics were available, they would be hard to interpret. After all, if someone told you that your team averages 1.9 review cycles per pull request, is that the best as you could reasonably aim for or an opportunity for improvement?

Get data-driven with Velocity

Velocity helps you unlock the full potential of your engineering organization with data-driven insights to manage risks, eliminate bottlenecks, and drive continuous improvement.

It’s built on one simple notion: The happiest developers work on the most productive teams, and vice versa. Applying these practices, which we call Data-Driven Engineering, puts you in the position to achieve both.

Velocity gives you:

  • Custom dashboards and trends – engineering metrics with full historical trends
  • Team insights – actionable data to level up your engineering teams
  • Industry benchmarks – high impact opportunities for improvement by comparing your metrics against other engineering teams
  • Real-time risk alerts – identify and resolve risks before they become problems.

As a software company ourselves, we’re committed to improving the process of engineering, for everyone involved: developers, product managers, executives, and more. Velocity is a core part of our foundation to pursue this goal. If you’re excited about this prospect as well, check out Velocity today:

Click here to book a Velocity demo today.Act by July 26th and get 20% off for life.

It takes 10 minutes to set up by connecting to your GitHub (or GitHub Enterprise) account, and soon you’ll have dozens of reports (with full historical data) to easily identify risks and opportunities.

Onward, to a data-driven future!

-Bryan, Noah and the entire Code Climate team

Read more at the source

Turning on the lights

Welcome to the first installment of Code Climate’s new “Data-Driven
Engineering” series. Since 2011, we’ve been helping thousands of engineering
organizations unlock their full potential. Recently, we’ve been distilling that
work into one unified theme: Data-Driven Engineering.

What’s Data-Driven Engineering?

Data-Driven Engineering applies quantitative data to improve processes, teams,
and code. Importantly, Data-Driven Engineering is not:

  • Ignoring qualitative data you don’t agree with
  • Replacing collaboration and conversations
  • Stack ranking or micromanaging developers

Why is this important?

Data-Driven Engineering offers significant advantages compared to
narrative-driven approaches. It allows you to get a full picture of your
engineering process, receive actionable feedback in real-time, and identify
opportunities for improvement through benchmarking. Most importantly,
quantitative data helps illuminate cognitive biases, of which there are many.

What can Data-Driven Engineering tell us?

After analyzing our anonymized, aggregated data set including thousands of
engineering organizations, the short answer is: a lot.

Over the coming weeks, we’ll explore unique and practical insights to help you
transform your organization. We’ll share industry benchmarks for critical
engineering velocity drivers to help our readers identify process improvement
opportunities. Here’s an example:

Pull requests merged per week (PR throughput) per contributor1

This plot shows that an average engineer merges 3.6 pull requests per week, and
a throughput above 5.2 PRs merged per week is in the upper quartile
of our
industry benchmark.

You might be thinking, “Why do some engineers merge almost 50% more than their
peers?”… and that’s exactly the type of questions Data-Driven Engineering can
help answer.

1 We included contributors who average 3+ coding days per week from
commit timestamps.

Read more at the source

Launching Today: Velocity

Data-driven insights to boost your engineering capacity

Today we’re sharing something big: Velocity by Code Climate, our first new product since 2011, is launching in open beta.

Velocity helps organizations increase their engineering capacity by identifying bottlenecks, improving day-to-day developer experience, and coaching teams with data-driven insights, not just anecdotes.

Velocity helps you answer questions like:

  • Which pull requests are high risk and why? (Find out right away, not days later.)
  • How does my team’s KPIs compare to industry averages? Where’s our biggest opportunity to improve?
  • Are our engineering process changes making a difference? (Looking at both quantity and quality of output.)
  • Where do our developers get held up? Do they spend more time waiting on code review or CI results?

Learn more about Velocity

Why launch a new product?

Velocity goes hand-in-hand with our code quality product to help us deliver on our ultimate mission: Superpowers for Engineering Teams. One of our early users noted:

“With Velocity, I’m able to take engineering conversations that previously hinged on gut feel and enrich them with concrete and quantifiable evidence. Now, when decisions are made, we can track their impact on the team based on agreed upon metrics.” – Andrew Fader, VP Engineering, Publicis

Get started today

We’d love to help you level up your engineering organization. Request a free trial and we’ll be in touch right away. As a special thank you for our early supporters, anyone who begins a free, 14-day trial before Friday, February 16th will get 20% off their first year.

Read more at the source

How Codecademy achieves rapid growth and maintainable code

We sat down with Jake Hiller, Head of Engineering at Codecademy, to find out how they use Code Climate to maintain their quality standards while rapidly growing their engineering team.

Codecademy Logo

Industry
Education
Employees
50+
Developers
20+
Location
Manhattan, NY
Languages
Ruby, JavaScript, SCSS
Customer
Since May 2013

Code Climate keeps our process for creating PRs really low-effort so we can quickly test ideas and ship sooner.

Why Code Climate

Like many rapidly developing teams, Codecademy was running into growing pains for both engineering onboarding and code review. They had tried using local analysis tools but found them cumbersome to integrate as development environments varied across the team.

With an engineering workflow centered around pull request reviews, and a desire to reduce friction in committing and testing code, they needed a solution that would optimize their pull request review process and enable new team members to quickly become productive.

Codecademy had been using Code Climate for their Ruby stack since 2013. When Head of Engineering, Jake Hiller, joined in early 2015, he saw an opportunity to alleviate their code review and onboarding issues by rolling it out to the whole team.

“We wanted to avoid anything that blocks engineers from committing and testing code. Other solutions that use pre-commit hooks are invasive to both experimentation and the creative process. Code Climate’s flexibility helps us maintain rules that are tailored to our team and codebase, while offering standard maintainability measurements. Plus it enables us to defer checks until code is ready to be reviewed, so we can quickly test ideas and ship sooner.”

“Code Climate helps us transfer knowledge to new engineers – like our coding standards, why we’ve made decisions over time, and why we’ve chosen certain structures and patterns.

Increased speed and quality

Since rolling out to the whole team, Hiller says Codecademy has seen an improvement in the quality of their code reviews and the ease with which new team members get up to speed.

“Code Climate helps us transfer knowledge to new engineers – like our coding standards, why we’ve made decisions over time, and why we’ve chosen certain structures and patterns. New engineers can look through the Code Climate issues in their PR, ask questions, and propose changes and suggestions to the team.

“It’s also increased the speed and quality of our pull request reviews. We’ve been able to spend more time discussing the important functional aspects of our code, and less time debating smaller issues. There are a lot of issues that can’t be fixed with an auto formatter, which is where Code Climate will always be really helpful for our team.”

About Codecademy

Codecademy was founded in 2011 as an immersive online platform for learning to code in a fun, interactive, and accessible way. They’ve helped 45 million people learn how to code, covering a wide variety of programming languages, frameworks, and larger topics like Data Analysis and Web Development. Their recently released Pro and Pro Intensive products provide users with more hands on support and practice material to help them learn the skills they need to find jobs.

Read more at the source

The role of being technical in technical leadership

In July, we hosted the first annual Code Climate Summit, a one-day
conference for leaders of engineering organizations who want to better
themselves, their processes, and their teams.

Today we’re sharing The Role of being Technical in Technical Leadership, by
Camille Fournier, Managing Director at Two
Sigma.

 

Transcript of talk

Camille Fournier: Hi everyone, I am excited to be here at this Code Climate
Summit. We were customers of Code Climate when I was at Rent the Runway, so
I’m a huge fan of the product and I was very honored to be invited to come
speak.

This is a talk about engineering management, which I think is pretty important
for building effective engineering teams and building good products. We’re
going to talk about what actually what it means to put the engineer in
engineering management.

Before I begin, of course, I must give a pitch to Two Sigma, so I am as of
about four months ago, the head of platform engineering at Two Sigma. Two Sigma
is a financial company here in New York. Our engineers and modelers harness
data at tremendous skill, use machine learning, distributed computing, and
other technologies to build powerful predictive models. If you are interested
in that world, twosigma.com/careers, check it out.

Okay. So. Let’s get this really started. “You either die an engineer or live
long enough to see yourself become the business person.” This something my
friend Cliff Moon at some point said or tweeted, probably both, and I like this
quote not just because it’s kind of funny, but also because I think it really
summarizes the struggle that many people have when they think about engineering
management. “Am I still an engineer, or have I suddenly become a
business person?”

I personally have struggled with this, so this is how I have a lot of empathy
with this. I started out my career as a hands-on engineer, I guess as most
people do. I was hands-on for a really long time, building lots of different
kinds of systems, mostly distributed systems.

I actually just got photographed for something called Faces of Open Source,
it’s facesofopensource.com, which is taking pictures of various people in the
open source community. It was a cool experience and this is the photo that came
out of that.

So, I’ve spent a long time as a hands-on engineer. At some point in my career I
was like, “Oh, I want to do more, I want more power, I want more authority.”
Lots of bad reasons, but I decided that I wanted to go into management, so I
joined a startup as a director of engineering, and I was still actually writing
a lot of code for the first year or so I was there.

As the startup grew – and that startup was, of course, Rent the Runway – as
that startup grew and was successful, and I was fortunate to be growing and be
successful along with it, I hit that dreaded cliff of no more coding, where I
really had to stop coding.

We tell managers that this will happen. Sometimes we tell them a little too
early in my opinion. I actually think it’s okay for you to write some code when
you have a small team, but there is certainly a point where if you are writing
code as a manager, you’re probably avoiding doing more important work, like
talking to people, and planning things, and other kinds of things that make
teams successful.

It’s still hard. It’s really hard if you’ve been a programmer for a long time,
if you’ve been a hands-on person for a long time, hitting that cliff of no
coding is really painful. I remember, it probably took me like a year of angst
before I finally got over it.

We say a lot of things about management, we call it a career change and now
that you’re a manager, you’re no longer an engineer anymore. I have probably
said this myself, and while I think it’s kind of true, I also really love the
language that we use when we say this, because it’s also kind of a negative way
to frame things.

I wrote a book and you all have copies of it, which is cool. I’m very flattered
that they decided to give my book as a giveaway here. This book is about being
an engineering manager. It’s about the various stages of engineering
management.

Part of the reason that I wrote this book was that I felt that there was not a
lot out there that really walked the path of being all the way from a mentor
and early career leader, but definitely still a hands-on engineer, all the way
through to being something like a CTO or a VP of engineering or a senior
executive.

I also wrote this book because I have a thesis that is, among other things,
while the people side of management is really important, managers also need to
be technical. I think that there is a reason that we tend to promote technical
people into management roles. It’s not just because we want to punish them.

Engineering management is the intersection of engineering and management.

It’s that, engineering management is the intersection of engineering and
management. It is not just managing a bunch of people who happen to be
engineers. It is important that you, to be a really successful engineering
manager, understand the way that people do their work. You are able to guide
their technical decisions.

This doesn’t mean you’re making decisions for them. In fact, most of the time,
I don’t really make all that many decisions. I try to ask good questions and
guide my teams, but I’m not actually making decisions for them. The hands-on
people who are doing the work are making the decisions, but I still need to
understand the context in which they are operating. That context includes what
it is like to be an engineer.

This talk is going to cover three traits that I believe are overlapping traits
that you tend to find in great senior engineers, and the way that these traits
translate into what makes good engineering managers. I’m going to talk about
debugging, I’m going to talk about empathy, and I’m going to talk about
judgment.

DEBUGGING

Let’s start with debugging. I love debugging. I don’t know about all of you,
I’m sure some of you do and some of you don’t. It’s definitely not the thing
that every single engineer loves to do, but it’s something we all have to do
because

I’m sure you’ve probably forgot a semi-colon the first time you wrote hello
world.

We’re always debugging all the time. Things are always breaking and you’re
always having to debug, and as you become more and more of a senior engineer,
you experience more, new, interesting ways that things can fail. You start to
sense the vast possibility of causes behind failures.

Part of the reason that I went into management is actually the same reason that
I love debugging. I wanted to understand why things were happening. I started
asking why a lot. Why is this happening? Why are we doing this? Why do we do
this process this way? Why didn’t we fix this? Why didn’t we make this choice?
Why, why, why, why?

Asking why too much, it turns out, is a not uncommon way that people end up
becoming managers, because they want to know. They want to know not just about
what is causing systems to behave in a certain way, but they also want to know
what’s causing us to make decisions this way in the first place.

At the end of the day, this skill set overlap is what a lot of people call
“systems thinking”. It’s not my favorite term, but I like the concept. People
that are good at seeing the interactions of different kinds of systems that you
may not have perfect information into. When you’re talking about looking at the
interactions of people, you can’t read people’s minds. You can only go by what
they tell you.

You don’t always have perfect insight even into the software systems you’re
developing. People who are good at seeing in systems, are good at debugging,
and they tend to become good managers for the same reason, because, guess what,
as a distributed systems engineer, the system is slow, it’s probably the
hardest problem you’ll ever have to debug, and as a manager, the team is slow.

“The team is slow” is the hardest problem you’ll ever debug.

It’s probably the hardest thing you’ll ever need to debug, especially if you
happen to be working at a startup for a CEO, especially if the CEO is not
technical. But e*ven if the CEO is technical, frankly, they always want to
know, “Why aren’t we getting it done faster. Why aren’t we moving faster. Why
isn’t this release done? Why haven’t we finished this?”

To figure this out, you have to look across a bunch of different elements. You
have to look at the people, sometimes as humans, we move slowly because people
are unmotivated for whatever reason. They’re burned out, they’re tired. They
don’t get along. The team hasn’t actually gelled all that well. You’ve got
somebody that’s very disruptive. They just can’t agree on the way to do
something.

Sometimes, of course, the challenge is a process problem. You’ve got this
product management team that thinks that they’re mini demi-gods over here,
throwing work over the wall to the engineering team and saying, “Behold my
brilliance, go implement it.” And most engineering teams don’t really like
that, it can be very demotivating, although some of them do. You’ve got to
understand what process, what’s the process contributing to the team’s
slowness.

And of course, sometimes it’s the systems. Sometimes you really are dealing
with really hairy, nasty technical problems that are going to take a long time
to figure out. They’re going to take a long time to solve.

You as an engineering manager, have moved beyond the world where you’re
thinking about the interactions of software systems all the time, but you’re
still looking at system interactions. You’re looking at the interactions of the
systems of the humans and the processes that the humans are using and the
technology that they’re having to deal with to get their job done every day.

EMPATHY

The second characteristic is empathy. We talk about empathy a lot. It was
already spoken of quite a bit in the last talk. I think it’s a very popular
thing to talk about in technical circles these days, which is probably pretty
good, because for a long time we had this very robotic approach to technology.
Programmers want to go and close the door and be in silence and just thinking
about computers. We do realize that to really build effective products, we need
to care about our customers and to build effective teams, we need to care about
our teammates, and as a manager, we want people who appreciate people. But,
there’s a little more to it than that.

There was a study done recently that showed that the number one contributor to
workplace happiness that they measured, was actually whether or not they
believed their boss was highly competent. Highly competent could mean a few
different things. Highly competent could mean the boss could do your job, but
highly competent could also mean a domain expert in the field.

It’s very clear though, that people really do want highly competent bosses, and
frankly I feel the same way. I get to work for this guy, his name is Alfred
Spector, he is the CTO at Two Sigma. He was a professor of computer science for
a long time, actually started a company, then became a lead scientist at IBM.
He ran Google Research for a very long time before coming to Two Sigma. He’s a
very interesting person. He has a really incredible technical computer science
background, he’s a good manager, which is amazing, and he’s entrepreneurial.
All of those things are awesome, and I’m really excited to get to work for
someone like that. I want to work for someone that I believe is highly
competent and has shown a track record of doing great things.

That doesn’t mean that I expect him to sit down next to me and pair program.
That actually doesn’t mean that you as a manager are going to be spending all
of your time actually in the weeds of the technology, coding with your team.

So what does it really mean to say that we want someone who possesses technical
empathy? What does this empathy element mean for managers beyond just, you can
see how people are feeling?

I think it really means that you want someone who appreciates the work, someone
who appreciates the details of the work and why work is good or bad. Your
manager is often the person who evaluates you, who is evaluating your work and
saying who’s doing well and who’s not doing well, maybe even who’s going to get
promoted. You want that person to actually be able to tell the difference
between somebody who does high quality work and someone who doesn’t.

You also just want that feeling of the expert appreciation. It means more when
you respect someone’s opinion that they have a high opinion of you. We want
someone who really appreciates why our work is hard, why our work is done well,
maybe even, sometimes is able to give us suggestions about how to do it better.
But certainly, we at least want that appreciation.

It’s also good as a manager, to be able to appreciate what your teams are going
to be excited about. Different people are excited about different things, but
engineering teams tend to get excited about slightly different kinds of
problems than marketing teams or sales teams. Engineering is a special
discipline with its own rules, with its own challenges and we want managers who
can appreciate and identify interesting problems and direct us towards those
interesting problems and make us feel like they understand what the wider tech
world is excited about and can actually help us get to do some of those
exciting things. Even more importantly of course, we want managers who
appreciate what frustrates engineers. It’s not obvious to a non-engineer, what
parts of the job are stressful. It just isn’t. It’s very hard to understand how
stressful it is to get distracted or pulled away from your code every 15
minutes because somebody keeps coming over to talk to you over your shoulder.

That can be a hard thing for people to understand. It’s much easier with a
technical manager, at least someone who appreciates what the work is like, to
be able to predict those frustrations and therefore cut them off before they
start happening.

TECHNICAL JUDGMENT

Last but not least, there’s the matter of technical judgment, which is of
course, very important in senior engineers. I said before that technical
management is often the art of guiding technical decision making. It’s not
making the decisions yourself, but even when you have a very strong tech lead
or architect or whatever and a great product manager, what you will often find
as an engineering manager is that you are the person sitting in the middle of
those two and trying to balance those differing viewpoints.

You need to make sure that you are actually taking into account the full
context of both the technical and the business side in order to help the team
prioritize their work. Because ultimately, the technical decisions that are
made will impact the effectiveness of the team, and the effectiveness of the
team as a manager is definitely your job.

A lot of the people in their first go round of engineering management try to
apply just the process to things. They say, “Oh, I know the process that will
solve it.” It can be anything from we’re going to do OKRs, we’re going to have
engineers vote on whatever project they want to work on, we’re going to do
agile, scrum, kanban, whatever style project management you want to do.

I actually think process is useful and different processes work well for
different teams, but there’s a lot of nuance. You have to understand what
process is going to work for your team. Moreover, you’ve got to remember that
process does not make decisions for you. The best thing process does is provide
the context, again, all of the information at your fingertips with the right
people in the room, to help you make decisions.

One quote I use in my book is that a good political idea is one that works well
in half-baked form, which I believe is from some kind of economics blog. I
believe the same is true for a process. Good processes are going to work well
in half-baked form. As an engineering manager, you’ve got to understand how to
get something that works well for your team, but it’s not going to be the
magical decider of all your difficult technical decisions.

Good senior engineers and good engineering managers have a good eye for detail.
They can be detail oriented when they need to be, because ultimately, building
good software systems is all about the details. It’s all about understanding
the details of the problem you’re solving and accounting for those details.

The same is true for making good decisions. Good decision making is all about
having the taste and understanding the nuance that makes two decisions that
seem about equivalent actually different, and one the right way to go, and one
the wrong way to go.

I talked about prioritizing. I’m going to reaffirm that point. You’re at the
end of the process, you’re trying to get something shipped. Prioritizing,
prioritizing, prioritizing, is the name of the game and good engineering
managers are good at being in that end stage and looking at the list of
technical features and looking at the list of product features and asking both
sides what’s really important here.

“What technical features can we absolutely not ship without. It would be bad
for us to ship without having any kind of alerting on this, because this is
actually pretty mission critical. But you know what? Actually, this is just an
MVP and it’s going out to five people, so maybe we can just ship it without
that feature.”

On the product side of course, it’s like, “Hey, product team, I know you love
all these features, but which of these do you love the most, because guess
what, this beautiful widget that you want the engineering team to build, we’ve
talked it over and this is going to be a three week project to get right. Does
this really have to be in the critical path of delivery?”

Being able to balance those two concerns and advocate for each side is one of
the important characteristics of good engineering management.

Last point here, you have to understand the problems that the team is solving
well enough to be able to communicate them with various people.

Manager telephone. Manager telephone happens when your manager goes and sits in
a meeting, takes a bunch of notes, comes back to the team, asks the questions
they have written down on their sheet that were the questions that were asked
in the meeting, writes down your responses, goes back to the other team, reads
those responses out and so forth. Zero value add. You want managers who can
understand at least well enough to focus and reframe the questions that are
being asked from people who aren’t familiar with the work of the team and who
are good at actually getting the right information out of the engineering team,
and making sense of it.

Nobody wants managers who are going to play telephone. That’s simply a zero
value add activity. We want people who are going to appreciate the work that’s
going on well enough to actually focus the discussions around it.

Debugging, empathy and judgment. These are pretty important. I think these are
important skills to build whether you decide to become a manager or whether you
simply want to be a really great hands-on engineer. What else?.

There is a little bit of a risk to this whole “rah rah managers should be
technical” and that risk is that you get managers who were once pretty good at
being technical, but who have gone hands-off for a long time and lost their
touch a little bit. They still think of themselves as really amazing, as one of
the people, as it were, but they don’t really remember what it’s like, and
frankly, they haven’t even kept up, so they don’t really know what it’s like to
write code in JavaScript. They’ve only ever written code in C++, and frankly,
that’s just a different world, right? Writing code for the browser’s super
different. They have not kept up. They don’t really appreciate what the actual
work looks and feels like.

Stay humble.

If you decide to go on this path, it’s very important that you stay humble with
your knowledge and your understanding. You can glue this in a bunch of
different ways. Some people advocate for going back and forth between big
companies and small companies where you can be a manager and then you can be
hands-on and that’s an awesome path to take.

Some ways you could do it – frankly, I sometimes write a little bit of code. I
work on a lot of open source projects, but realistically, you can keep reading
code, you can keep helping debugging. You’re going to get a little hands-off,
though.

My advice if you decide to follow this path is to, if nothing else, keep
learning, particularly about advances in the way software engineers do their
work. That’s things like, “What does it mean to build all your software based
on cloud services.”

That’s very different than building everything in house. What does it mean to
do a continuous deployment process? What are the major advances in the way
people actually do work and deliver software? That’s a really important thing
for you to keep in touch with as an engineering manager if you’re managing
software engineering.

Okay, so these traits, one more time. Debugging, seeing those symptoms,
technical empathy, that technical appreciation, and finally judgment,
prioritizing and understanding the problems at hand.

I still consider myself an engineer, even though I don’t write code all that
often. I personally hope to die an engineer someday, but whichever of those two
paths I end up following, I know that it’s going to require constant learning,
constant reading.

You can be like this guy. He used to work for Code Climate and he is the
quintessential renaissance man who manages to both be the business jerk and be
an engineer, all in one. So read more. You can start with my book, because you
all have a copy of it, and thank you all very much. I’m happy to take
questions.

Audience 1: Thank you for the talk, it’s great. Disclaimer, I’m not an
engineer, I’m a product manager. My question to you as the technology industry
veteran that you are today, you see these four engineers that either goes into
principal engineers or technical fellow or going to director of engineering, do
you see the same trend with product management? Do you have any advice for
managers of product manager?

Camille Fournier: Not as much, mostly because the product teams tend to be
so small that even as a manager of product managers, you’re not usually
managing a lot of people. There’s just a huge difference between … frankly, I
think you can be an “individual contributor style” engineer and still manage
three or four people, particularly if they’re very senior and they don’t
require a lot of mentorship or management.

I think that often product management, because there are just not that many
people to be managed, it’s not as much of a fork. I do think that what you see
happen with product management is that product managers who become more senior
or experienced, tend to be like general managers – perhaps of business lines -
and that is a bigger, more complex management job.

I could imagine that for product managers there is a little bit of a split
between, I’m going to go be a general manager for a pretty big company and run
a large business line and actually have a lot of management accountability or
I’m going to stay very focused on just product direction and strategy.

Audience 2: Great talk, thank you so much. In your experience, what is a
good management to engineer in ratio, so how many engineers per engineering
manager do you think is a right mix. I know it’s different for every company
and every field and all that, but just in general.

Camille Fournier: Okay. I do think it’s very hard to effectively be a
one-on-one manager for more than eight to ten people. If you’ve got a team of
more than ten people directly reporting to you, and frankly for many people
it’s less than that, you are probably not serving very well, some of those
people.

I know personally that if I have more than about six direct reports, at some
point, people are getting less of me than they otherwise might. That helps sort
of think about the ratios. I do still believe that you can effectively be
managing a small team and acting as an individual contributor. You’re not going
to be 100% as effective as you would be if you had no team. You can tweak
ratios that way, but I certainly don’t think that it’s a good ratio to have one
manager per 20 employees. It’s probably not a good ratio to have one manager
per two employees either. It’s going to be somewhere in that.

I would say probably one to six, one to eight is okay, especially if the line
managers are still expected to stay fairly technical even if they’re not
writing a lot of code there, they’re really thinking about a lot of technical
issues.

Audience 3: Hi. You said that team effectiveness is a manager’s primary
responsibility or one of them. What are the KPI’s that you use to determine
your team’s effectiveness?

Camille Fournier: Okay. A few KPIs that I would see, obviously, retention.
Are people quitting? That’s a big one. How are we doing on the deliveries that
we’ve committed to? If we’ve committed to deliver certain software or hit
certain goals, how effective are we at hitting those goals and are those goals
stretch goals? Do we think they’re not the level we would like them to be?

I think overall morale of a team is just generally important, so even if people
aren’t quitting, you can still find yourself in a situation where people aren’t
quitting, but they’re just not that excited about work. They’re not that
engaged and enthusiastic. A lot of team effectiveness, the output is what work
gets done, but the side pieces of it are really a lot about morale and
retention and engagement from the team.

Audience 4: You talked about show an appreciation for team members. Have
you ever been in a situation where you show appreciation of a team member and
it’s fostered envy from other members or there’s been resentment as a result?

Camille Fournier: Yeah, absolutely. I think was accused of playing
favorites at some point in my career, so I’ve tried to be very aware of that. I
think appreciation is one of those core management things that you want to try
to do a lot for everyone. It actually is not a bad thing to tell people they’re
doing a good job fairly regularly and try to tell everyone on the team.

The way you recognize people, particularly if you do public recognition, you’re
definitely shaping your culture when you do that. If you always publicly
recognize individuals, and you never publicly recognize teams, your company is
going to start to develop a culture of “individual accomplishments are the most
important thing and it’s better for me to get the win myself than to bring the
whole team along.”

You have to be very careful with thinking about how you recognize those things.
Honestly, I think a lot of this appreciation is just in that one on one. Do I
feel like my boss really understands the work I’m doing well enough to be like,
“Wow, that was a hard thing. That was a really cool set up you did to get that
migration to go so smoothly. I’m very impressed with the technical work that
you did. I’m impressed you thought through this process in that way.”

I think a lot of appreciation is very effective just in a one-on-one context,
not even worrying about big team appreciation.

Audience 5: You mentioned we all want to work on hard problems, fun problems,
and maybe direct our team towards those. Often we don’t necessarily have the
decision making in where the product goes, where a business wants to go, so
what are your strategies for maybe managing upward or convincing them of going
towards maybe a more difficult problem but more impactful?

Camille Fournier: I think it depends, so a lot of the times … hard problems is a
little bit of a, I don’t think I phrased that as well as I should have.
Engineers want to feel like they are having impact, so some engineers are very
much driven by solving the hardest problem. I think the best thing you can do
in that case is help identify where there are really hard problems and make
sure you’re keeping those engineers as close to those as possible.

A lot of the times what you do though as an engineering manager is you also
help people find some of the more purely technical problems to solve, and those
are not necessarily hard in the theoretical computer science hard way, but
they’re often hard in the, “Oh we really need to clean up this particular piece
of technical data or this particular system” and you as a manager, are actually
explaining the value of spending that technical focus to the rest of the
business and saying look, “This is what this is going to enable. This is how
this is going to speed us up, or not slow us down in the future.”

And that, I think it’s a matter of really being specific about what the goal in
that clean up work is and trying to find measurable things that you can do once
you have done that. Some of it’s also just about setting very hard guidelines
with “we always spend a certain amount of time on this kind of thing because
this is important and this is the way we run our engineering teams.” It’s a
combination of those things.

Audience 6: As you become more removed from the day to day delivery of code, do
you have any tips for ensuring code quality from your team members?

Camille Fournier: That’s hard. Well, perhaps you can use, a lovely product
like Code Climate, a word from our sponsors [laughs]. I do think that letting
go actually can be really hard. Some of it is setting standards and being as
clear as you can about the standards that you want the software to maintain.
That can be anything from someone like me, I’m very passionate about testing, I
think testing is really important and so I try to set basic standards like,
“Look, we should be very cautious about ever accepting pull requests or
whatever that don’t have tests with them. Why isn’t this code tested? Why
aren’t we writing tests for this stuff?” I think you can do things like that.

I think also some of it though is about, you hopefully have senior engineers on
your team that you’ve trained, that they understand what good code looks like.
You want them to be teaching everyone on the team what good code looks like.
That is really one of those areas where it’s not really your job as a manager,
although you probably still care, but you do want to make sure that senior
engineers feel like they have the ability to chime in and say, “Hey, we want to
improve the standards in this code. We want to improve the standards in this
software, and here’s what we’re going to do to help with that.”

Audience 7: When you first transitioned from coding full time to management, did
you experience imposter syndrome and how did you deal with that?

Camille Fournier: I wouldn’t say that it was imposter syndrome exactly. I
will say that part of becoming a, especially a senior manager, is developing a
certain level of presence and being able to, the body language and the way that
you present yourself, and the way that you talk, and the questions that you
ask, and the things that you do, are actually important. That’s actually a
pretty hard lesson to learn, and so I wouldn’t say that it was exactly imposter
syndrome, but there was certainly a level of “why am I not getting the respect
that I should get because of my title or whatever” and I think some of that was
just, “Oh yeah, I have to learn how to be in a room with my peers and be
productive and not undermine people and not be disruptive in certain ways, or
make my points in a way that people will hear them and they won’t react
negatively. I would say for me, that was the harder lesson than imposter
syndrome. I don’t feel like I had too much of that, that’s never been my
problem.

Audience 8: Hi. Thanks for speaking with us. Quick question on dealing with
promotions, especially as your team size starts to grow. You naturally have to
promote people within hopefully, but oftentimes you might find a couple of
candidates within your team that when one is a more natural leader, but they
both have the same aspirations, how do you generally deal with that? How do you
smooth that out?

Camille Fournier: Yeah. I think the best thing that you can do … I think you’re
lucky if you know the aspirations. I’ve certainly had people where we did a
round of making tech leads, for example, and someone got very upset because
they weren’t chosen and it was a shock to everyone involved because nobody had
any idea that this person was even interested. And so that was a little bit of
a mistake on our part of not actually spending the time to understand what
people wanted, to understand people’s aspirations. Part of what you need to do
is make sure you understand the aspirations.

Once you understand them, I think then if you think that you’ve got a person
who has, frankly, better skills right now, maybe because they just have a
natural skill set, that’s okay, but you want to give the other person coaching
and try to identify specific opportunities for them to develop some of those
skills and to learn some of those things.

Even though they’re not necessarily being promoted to manager, maybe they can
be running certain projects. Maybe you can work with the new manager and say,
“This person really does want to be in a management role and so we need to be
looking for opportunities for them to step up and take some leadership and push
themselves out of their comfort zone, maybe give presentations to the team”,
whatever those gaps that you think that they might have, giving them a chance
to actually practice the job and fill those gaps is a good way to prepare them
for when the next opportunity arises. Now they really have the skills and the
confidence to do it.

All right, I guess that’s it. Thank you.

Camille Fournier is a Managing Director and Head of Platform Engineering at
Two Sigma. She is the former Chief Technology Officer of Rent The Runway and a
former Vice President of Technology at Goldman Sachs.

Fournier earned an undergraduate degree from Carnegie Mellon University and a
Master’s degree in Computer Science from the University of Wisconsin–Madison.
She is a maintainer of the Apache ZooKeeper open source project, writes the Ask
The CTO column for O’Reilly Media, and is a regular public speaker and advocate
for greater diversity within technology and leadership. Her book, The
Manager’s Path
, was published by O’Reilly in early 2017.

Read more at the source

The Customer Gap

In July, we hosted the first annual Code Climate Summit, a one-day
conference for leaders of engineering organizations who want to better
themselves, their processes, and their teams.

Today we’re sharing The Customer Gap, presented by Code Climate’s Director
of Engineering, Gordon Diggs, and Code Climate’s Customer Support
Lead, Abby Armada. In this talk, you will hear about how we’ve fostered
a positive, productive relationship between customer support and engineering. By
creating processes, and encouraging cross-team collaboration, we can combine our
strengths to best focus on customers of current and future products.

 

Transcript of talk

Abby Armada: Before we get into this, I wanted to highlight this customer quote, and following exchange between our customer support and engineering teams. So: “Awesome dedication by the engineering and customer support team. Thanks, Jenna, Abby, and Ashley.” And there’s Jenna, who’s on customer support, saying, “You da best.” And Ashley saying, “No, you da best.” So, you can see this is the kind of vibe your team can have by closing the customer gap.

I’m Abby. I’m the customer support lead here at Code Climate. And including me our awesome team is three people, one being remote. I’ve been at Code Climate for over a year and in various customer-facing roles for about 13 years. I really like running and I really like eat tacos, but not at the same time.

Gordon Diggs: Hi, I’m Gordon. I’m a record collector and I like to cook lasagna. I do sometimes do those two things at the same time. I lead Code Climate’s engineering team and I’m responsible for growing the team in both size, in terms of hiring and, for lack of a better word, “mentality” in terms of our processes and the kinds of ways that we work on things.

Engineering at Code Climate takes up about 40% of the entire company. So, we’re a sizeable department. And Abby and I have actually been discussing and collaborating on the support and engineering relationship for over four years. So we’re really excited to sort of have this culmination of a lot of the stuff that we’ve talked about for so long and share some thoughts with you.

Many companies list customer focus as a core value, but few engineers spend time talking to their customers.

When you think of customer focused companies, you may think of companies like Amazon, where everyone trains in support center and answers calls, or Apple where the CEO regularly works on the support team. And so, many companies list customer focus as a core value. But few engineers spend time actually talking to their customers. So you have the big companies like Amazon and Apple, but many smaller companies that we found also list customer focus as a core value. A lot of people want to do this. They want to be a customer focused company, but it’s really hard and it’s time consuming.

The customer gap: The delta between a stated customer focus and the reality of how engineering spends its time.

And so we coined this term “the customer gap.” We define the customer gap as the delta between the stated customer focus and the reality of how engineering spends its time. Engineering tends to be very separated from our customers. But there are also gaps between your strictly customer-facing departments and your engineering team. If you can close the gap between engineering and those other departments, you can also work to close the customer gap.

Over the years we’ve talked extensively about the gap between customer support and engineering and we think that in order to close that gap, there are things engineering should do, things customer support can do, and things that we should do together.

As a little bit of a visual aid, I made this kind of cheesy chart. But you can sort of see the idea here. You have your customers on the left. You have a small gap between them and your strictly customer-facing departments. And then a wider gap between those departments and your engineering team. And so, one of the things that this shows is that your customer-facing departments are doing a better job of closing the customer gap than you are already, and that’s why they’re closer to the users. And then there’s this larger space between them and the engineering. So, if you can work on closing this gap on the right, then you can really work on closing the greater gap.

Abby Armada: Here’s a brief outline of what we’re going to cover in this talk. We’ll start by talking about ways to build customer empathy within your engineering team. And next, we’ll talk about some examples of processes customer support can implement to work more closely with engineering. And lastly, we’ll talk about closing gaps between engineering and other departments.

Building customer empathy within engineering

Gordon Diggs: Building customer empathy within engineering. This is a really important part of the formula because if your engineers don’t understand your users or their experience, or aren’t bought into this idea of customer empathy and focus, it’ll be a lot harder to close the gap. Ultimately, you really need to get them bought in.

And if I’m being honest, we at Code Climate have this kind of easy. Our customers are software engineers so it’s not a big gap for us, as engineers, to understand our users and their motivations. If we were some kind of printed product, a fashion company, or some kind of feminine care start up, we couldn’t be sure that 100% of our team has something in common with our users and understands them.

So, we can go to conferences, and we can go to meetups, and we can meet people who use our product or who want to use it or who we think should use it because it would really help their workflows. So, this is just a little bit easier for us. But it is also a little bit of a trap. Software engineers are a very diverse group of people and we need to make sure that we don’t project our own biases and assumptions when thinking about our users.

For a few examples: We at Code Climate are a team of Ruby engineers. We work at a small company. We have a good continuous deployment pipeline, and we generally have good coding practices as the nature of the work that we do. But people who buy and use Code Climate come from wildly different perspectives. A lot of them work on very, very large teams, and with tools that we don’t use and understand as well as our own. So while we can get pretty far working with our idea of software engineering, we need to be aware of where that ends and where our customer’s experience starts.

So, it’s really important that customer focus and empathy is a cultural driver. And you need to build that empathy into your engineering culture. It’s not enough to only think about focusing on your customers when things are broken or when your site is down. And so, what does that look like? What does it look like to build empathy into your engineering culture?

First, make your engineers talk to your customers on a regular basis. Include them in customer site visits. Put them on your sales calls. Make them work with support on debugging customer issues. And send them to conferences or meetups or if there’s some kind of trade show that’s relevant to your company, send them to that and put them at the table that you’re sponsoring.

Secondly, we put every mention of Code Climate on Twitter into a Slack channel. So, good and bad, engineers can see what people are saying about Code Climate online. If we ship something and it’s a poor user experience, or the CTA was a really weird color or something and people start complaining about that, we’re going to see it. And similarly, when an engineer ships something that really resonates with a group of users and they start talking about it online, there’s a nice boost there. So, you can kind of get both sides of the coin there.

We also put engineers on the frontline of responding to our community in both our community slack group and on our open source repositories. If you open an issue or a pull request on one of our repos, it doesn’t go to a member of our support team. It goes directly to an engineer who’s responsible for triaging that issue and finding the solution.

Our engineers also run our status page. If our site goes down or our service is in any way degraded, they’re the ones who are responsible for keeping our users up to date about what’s going on. Obviously, they collaborate with marketing and customer support on these updates to make sure that they are of the highest quality that they can be, but ultimately, the timing and the content is up to them.

And lastly, watch your users use the product. One issue that we have as engineers, particularly product engineers is that we know the code that goes into the site and we know that if a page is slow or a user experience is weird, it’s often because the code behind it is complicated. And we bring this bias into using our own product that, “Well, this page is slow because there’s all this nested logic in the templates and stuff.” But your users don’t understand that. They don’t have any of that. And watching them interact with your product, watching the way that they use it, and where they get frustrated, will really help eradicate some of that handwaviness.

So, as with most cultural efforts, building empathy is harder on bigger teams.

Panna actually touched on this a little bit earlier. So, if you can start when your team is small, that’s better. The bigger your team is, the more people you need to convince to buy in to this idea of customer focus and empathy. So, if you’re at a small company, that’s great. You’re in a really prime position to effect change across your team. If you’re at a larger company, all hope is not lost. You can start with a small subset of your team, find a pilot team, and have engineering managers of that team spread their success laterally throughout the organization.

And it’s really important, I really want to mention that it’s not enough to silo this empathy. You can do all you want to build customer focus within your engineering team, but it’s also important to work closely with your support team. And Abby’s going to talk a little bit about some of the ways to do that.

Helping each other

Abby Armada: So, you have to work together. There are a couple of solutions we created here at Code Climate to help both the engineering and support teams be successful at this. These solutions may seem obvious in some ways but the execution and upkeep is essential for it to work well and close the gap, which in turn closes the other gap that exists between engineering and your customers.

The first of these solutions on our side was addressing escalations, which is when a customer’s problem has gone past a scope of troubleshooting and knowledge of the support team and requires a solution from an engineer or someone else. I’m sure many of you here have had to deal with customer escalations in one way or another, and it might have been a thorn in your side. We did a lot of work to improve this process for both of our teams, which ultimately has made our customers way happier.

Our main channel of support is email, then it trickles through to Twitter, Slack, and sometimes GitHub Issues. This is where all of our escalations come from.

So, how did we address escalations before? Engineers worked on escalations on a weekly rotation. This wasn’t ideal for anyone. For the incoming engineer, there wasn’t a lot of context for existing open issues. Plus, it seemed like a giant chore that was an interruption to their regular work. On support’s side, it’s hard to ramp up someone for this work, and it’s especially difficult to form a good working relationship with your new engineer for only a one-week rotation.

We didn’t have a great way of tracking this work, or a consistent process for handing off open issues to the new engineer, or giving enough context for the problems. Prioritizing issues did not exist at all, and we kind of thought they would just figure it out. This led to everyone drowning in a sea of confusion and sadness.

To fix this we came up with a couple of solutions. Instead of a weekly rotation, we now have a dedicated support engineer for a quarter. This solved that problem of feeling like they’re interrupting other work and gives the engineer a chance to fully work and focus on escalations. It also builds a great rapport between engineering and support because we get to know each other for a quarter.

And we broke down our escalations by severity, which gives us an actual prioritization system that makes sense to both teams. There are now four levels of severity, one being the highest and four being the lowest. This isn’t a new concept by any means, but implementing something concrete was the most important part of the solution.

We also documented how to respond to each severity, both as a support person, and as an engineer, and holistically as an organization. This is written in our company handbook so everyone can see and have the knowledge. We also have concrete examples in the doc for easy reference. So, if someone is confused, they can look at the doc examples and know how to assign an issue a severity.

And lastly, we started using a GitHub repo and issues to track and update customer escalations. Everyone in the company already knows how to use GitHub, so implementing this part was the easiest.

This is an example of our severity documentation. You don’t need to read the whole thing – and the people in the back probably can’t anyway – but you can see the structure of how we define severities. In this case, this is a severity three, normal/minor impact. It’s something that’s like a moderate loss of application functionality that doesn’t really affect any of their other workflows. It matches the description. And then the examples live underneath. In this case, a customer reports a bug in an engine that’s kind of broken but doesn’t have any effect anything else that they’re doing. And then the response plan underneath details what both the customer support person and the engineers can do to sort of solve this issue.

Another change is that severity ones are treated differently than other severities within our organization. A severity one is a major issue. So, for example, if a customer’s instance of Code Climate Enterprise is down, we flag it as severity one and it requires all hands on deck to fix.

In past quarters, we found that the burden of solving these types of escalations is hard for a single escalations engineer. They often had to ask for extra help anyway. So we changed severity ones to be treated as production incidents. Support escalates directly to our engineering teams existing PagerDuty rotation. We have a fairly robust alerting pipeline for codeclimate.com, so most issues are caught by other alerts before they even get to support. It was pretty easy for us to integrate these other issues into that rotation. Distributing the work amongst those who are already on call helps solve severity ones more quickly and taps into existing expertise.

After adopting the aforementioned quarterly rotation, it helped highlight gaps in our own team’s knowledge about troubleshooting in other parts of the product. Thus, engineering has started leading proactive education workshops to teach concepts that will help us troubleshoot future issues. For instance, one of our support engineers noticed that we were pretty much escalating every single issue that had to do with our enterprise product. He set up a workshop to talk through troubleshooting concepts and how engineering looks at the same issues. This helped the support team work through more enterprise issues and lessen those types of escalations.

Engineers really benefit from this, too. Having them explain their work and their contributions to the product helps them grow and build empathy, and again, really strengthens that great rapport between your support and engineering teams. And informing the support team empowered us to troubleshoot and triage more effectively and even nipped future escalations in the bud.

Here’s our resolution time for escalations per month. So, after a slight rise due to those new processes, especially proactive education, we were able to have a fast mean time to resolution to customers than before and our customers, obviously, are really happy about that. And here are our escalations per month. You can see the tangible benefits of when we adopted these new processes and it’s because of that quarterly rotation, better processes around triaging, and proactive education. On average, our monthly escalations have gone down month to month, and that’s great.

Having worked on our escalation process, the next thing we did was take a look at the product engineering and support relationship. It’s a common problem that support doesn’t have the full picture of what’s being developed. I hear this all the time from other support professionals that I interact with every day, and this is a problem for everyone.

Even on a small team, communication is oversaturated. There are too many Slack posts and GitHub issues, and this is not sustainable at all. There’s just too much to keep up with. Last quarter, we established a weekly customer support and product meeting to sync up about work being done that week, as well as talk about things coming through the pipeline. Instead of trying to keep up with endless notifications, now we talk face-to-face and it’s much easier.

Personally, this is my favorite meeting I have every week because it’s really productive for my team and the product team, and it really gives my team great perspective on what’s happening in our organization. So, we talk about work in progress. What’s the progress on last week? What’s happening this week? We cover any upcoming releases. We get to answer the question of what exactly are we shipping and when? And how does it affect our customers? Then we talk about any customer-facing communications needed like updating docs, release notes, as well as inquiry response to incoming new customer questions. And lastly, we talk about feature requests. I’ll cover that in a little bit more detail in a bit.

This has helped our teams a lot. I share the most important knowledge back to my team since one of my people is remote, it’s good that we can be all on the same page about what’s happening that week. And it also helps us action any internal work that helps that product work. And it has also stopped confusion about what exactly is being released. We’re more confident and thus can help our customers better. And lastly, it fosters trust, again, between support and product. We know what’s going to be released and how to handle it.

Now that we have that open channel of communication with product and engineering, we decided to tackle the beast; feature requests. We all want to be the type of company that welcomes customer feedback, and feature requests, and actually actions on it. But I think this is the hardest gap to close but we’ve made a lot of steps here at Code Climate to do so.

Before, support had ways to catalog feature requests, but no way to surface them in a meaningful way for people to action them. So, we had a very bad GitHub repo, then a very bad Trello board, and – hey, Gordon, did you look at any of those ever?

Gordon Diggs: Ehhhhhhh…

Abby Armada: Yeah, me neither. There’s a limited process for both of the repos and the Trello board, which also housed bugs alongside feedback. Someone would make an issue, which would live on in perpetuity. And every time a request came up again, someone would comment on it and push it to the top. It sounds good in theory, but no one ever looked at them. Just having the tools isn’t enough. We thought that switching to Trello would solve the problem of stale, sad feature requests. But, in fact, you just needed a process.

The more you can get feedback into the eyeballs of your company, the better. You have to be loud to get this actioned.

We created a feedback repo on GitHub, again, which feeds into a Slack channel, then we talk about important feedback during that product meeting I mentioned before. The more you can get feedback into the eyeballs of your company, the better. You have to be loud to get this actioned.

This is what that GitHub repo looks like. You can see the different issues opened by the people on our team. And we use labels to easily identify the status of each feature request. You can see stuff that’s been actioned, what needs to be reviewed, and the different parts of the site that the feature request is about. And now these are pure feature requests. They are not bugs or anything pertaining to escalations. These are all nice to haves and legitimate product feedback from our customers.

Of note, this repo is completely internal. There’s no way for a customer to directly add feedback to this repo. Only people at Code Climate can do this. And then the feedback is curated by me. We have an issues template that asks a bunch of relevant questions. If the feedback doesn’t clearly answer why a customer is asking for a feature or isn’t detailed enough, it gets rejected. This curation process keeps the board fresh and keeps my finger on the pulse of what our customers want.

This is that Slack channel with that piped in feedback activity. It has all new issues and comments on old issues. And they all get fed into this channel that anyone in our company can join. So, in this screenshot, Jenna opened an issue, pinged Noah to get his thoughts, which he then shared to the issue itself. Loud is good.

As I mentioned, we also talk about the feedback issues in that weekly product and customer support meeting and see if they’re still relevant and see where they fit within our product roadmap. Sometimes feedback and feature requests can alter a product roadmap, giving us ideas for something we didn’t even consider before. And through all of this, we’ve seen an immense improvement in adoption of customer feedback within product development. In fact, after we adopted these processes, 25% of feature requests were actioned by our product team, which is a huge improvement from basically zero.

You’ve heard me talk a lot about what we did at Code Climate to close the gaps between engineering and support, but these solutions might not necessarily work for your specific teams or solve the types of problems you’re facing between your customers, support, and engineering team. As an engineering manager, it’s up to you to try and work in tandem with your support team to solve these problems. Collaboration, communication, and iterating on processes together are the key ways to do this and it leads to happier customers overall.

Closing the gap to other departments

Gordon Diggs: We’ve talked about how to build customer empathy and we’ve talked about some of the processes that support and engineering have worked on together. But what about the other customer-facing departments in our organizations? Your customers move through life cycles, and engineering should follow them.

Before your customers are even your customers, they interact with your marketing and with your marketing team’s efforts. At Code Climate, we dedicated an engineer for a whole quarter to help build automation for our marketing lead pipeline. He did this by supplementing leads with data from a variety of sources and piping it all into our CRM. He learned about what makes leads more qualified from a marketing perspective and our pipeline is fuller and faster than it’s ever been. He also learned a lot about our user personas and our segments. And this ties back to that idea of the diversity of our users from before. He came back from the marketing team with a better understanding of our users and where they come from. Dedicating a full-time engineer to this rather than hiring a contractor or farming out to buying some product, ensures that we built this in the right way and in a way that we can easily maintain and extend moving forward.

Sales is a really important part of most businesses, but particularly at a SaaS product we need to have a sales team. And sales people usually aren’t engineers and may not be able to articulate the same engineering concepts. But they are very good at learning and they can really learn from your engineers. And there are a few ways that engineers can get involved with your sales department.

The first and maybe most obvious of these is building features for customers who are in your sales pipeline. Putting engineers on your sales team means that you can more quickly action the high value projects that will sign customers right away. So, we identified three key features blocking sales and then we built them. And additionally, in just having the conversation about what features are the users that you’re talking to, what features do they really want? In just having that conversation, we clarified our product direction and have a clearer idea of where we need to go.

There’s a very, very important note and caveat to this. Some features will be too big for this setup and some will be in conflict with your existing product roadmap. I’m not suggesting that you give your sales people carte blanche to implement features in your product. But, working through the discussion of the features that they want to build and finding the compromises will really help grow your business. It’ll help clarify your roadmap, and it’ll sign customers, which is really good.

So, another sales engineering activity is reviewing leads technically. This is a little bit specific to Code Climate as a highly technical product, but we have an on-premise enterprise product and we want to be sure that we only deploy it to platforms and customers that will be successful. Doing this once a customer is about to sign a contract causes the sales process to lose momentum, but if you review the technical requirements – for us that’s things like virtualization platform, version control system, programming languages, that kind of stuff – if you review that earlier in the process, your leads will be more successful.

Pulling engineers in to do this on an ad hoc basis was something that we used to do like, “Oh, yeah, just go grab someone off of product to review one of these leads.” But it meant more prep, more interruption, and generally lower quality reviews. So having people on your sales team ready to do those reviews is a really big strength.

Similarly, installing and setting up the product with customers gives engineers a really good sense of what your onboarding experience is like. In many cases, it’s been years since one of your engineers signed up for your product and, most likely, they’ve never done that with money on the line. So, having them sit down and understand what the customer is going through helps them build it better in the future and it helps get the customers up to speed faster. This also ties back to that idea that I was talking about earlier of watching your users use the product. This will really help eradicate some of those unconscious biases that your engineers bring to your onboarding experience.

Lastly, putting customers in touch with your engineers directly build rapport. It’s rare that you can jump on a sales call with a company and there’s an engineer there to tell you about how they built the product, particular features that they really like, that kind of stuff. It’s also rare that you can be in the Slack group and DM an engineer directly to ask them a question about how do I configure this? How do I work with this? And so, having that engineer there really helps build this rapport.

Abby talked extensively about customer support and shared lots of really good thoughts, but I want to throw this department up here because escalations were where we started. Both Abby and I started talking about this customer support engineering thing, and it was the first place that we experimented with this quarterly rotation idea. I also want to mention that being on the support team doesn’t mean just answering escalations and providing technical knowledge to the support team. A successful setup of an engineer on a support team means also building the features that ensures that those customer issues don’t happen again.

So, in the same way that sales engineers build features for customers in the sales pipeline, your support engineers should collaborate with product and engineering to action the features that will really help prevent future issues. So, you can see that drop in escalations per month, and a lot of that is because we found the patterns and where users were running into trouble and where they were writing into support, and built better experiences for them.

What about once someone is a customer but their experience isn’t broken? So, they’re not writing into your support team. Customer success works with customers who are configuring the product, who are discovering how to use it, and who are using it in their workflows everyday. Your engineers can help train users on how to use your product. They can go do customer visits. They can sit down and eat lunch with your users and show off their work or talk about things that are coming up that they’re working on.

I really love training customers, and working with them, and seeing them get excited about a feature that someone on my team built, or seeing them understand a complex part of our system. And if your customers are engineers like ours are, that’s even better because they’re going to want to know what it’s like, what the special sauce behind Code Climate is.

So, in both customer success and sales, the engineers are both training you customers and your representatives about the product. Your representatives may not know about the newest features or what’s in development. And if they do, they may not know about all of the edge-cases or the best applications for these features.

And ultimately, working with customers and with other departments makes your engineers more well-rounded. They’re still going to be great product engineers. They’re not going to stop wanting to build features. It’s fine. But they’re also going to be better at sales. They’re going to be better at support. They’re going to be better at marketing. And this will set them up for success both in your company and in their careers at large. We’re lucky because our quarterly rotation lends itself well to putting engineers on other teams and working directly with other customers.

Engineers also remember their customer interactions. And it informs the way that they build things in the future. They remember seeing that customers missed a CTA or ran into an error because of a configuration problem. And this memory or this interaction lingers with them the next time they build a feature or talk to another customer. And it really informs the way that they go about their work in the future. So, we’ve seen that engineers who do a tour on the customer support team come back to product and have a new way of looking at building product because they’re thinking about customers and they’re focusing on them more. To restate that, more experience with customers leads to better features.

More experience with customers leads to better features.

Engineers don’t like to be interrupted. We’ve talked a lot about building processes to reduce this interruption. Getting into flow is a really important thing for engineers. All the engineers in the room are nodding their heads. And we, as managers, can’t pretend to change that. We’re not going to change flow. We’re not going to solve that problem. But understanding why your support team is bugging you to fix issues and understanding their motivations and that they’re advocating for your users will really help your engineers grow and will make your product more stable.

And I’ll also mention, we made these slides and we did a rehearsal of this talk. And one of my engineers is like, “I don’t like the word nagging on this slide because I think it’s a negative thing.” And it is. It’s only nagging if there’s a problem and if it’s something that they don’t really want to be doing. Talking to support more often, doing these weekly check-ins, having the people there for them to discuss escalations with, will prevent the unnecessary interruptions and it won’t be nagging. It’ll just be talking to you. Support will be talking to you for a reason.

Abby Armada: Support doesn’t like to be interrupted either. We’re doing work too. So having dedicated time to talk to engineers really helps everyone and your customers.

And here’s that visual we presented before except we’ve closed the gap significantly. And our engineers are close to our customers than ever before.

Let’s review some takeaways and what you can do.

Gordon Diggs: Build empathy within your engineering team to foster a focus on your customers. Know where the gaps are between your engineers experience and your customers, and then close them. And start small. If you have a small engineering team, that’s great. Get everyone onboard right away. But if your organization is larger, find a pilot team and then recruit your leaders within engineering to spread their success to others.

Abby Armada: Make sure your processes promote good collaboration between support and engineering. Don’t be afraid to experiment and try new things and talk to each other. You’ll learn a lot about the ways that you can work together and make your customers happier.

Gordon Diggs: Include engineers in every stage of your customers’ life cycle. Find a way. Go to those teams in the strictly customer-facing departments and say, “How can engineering help here?” From marketing to sales to support to customer success, find out where the engineers can help and then put them on the teams for a significant amount of time.

Abby Armada: At the end of the day, if you’re truly customer focused, then happy customers will mean a happy business.

Gordon Diggs: Thank you. Obviously, Abby and I have lots of thoughts on this and we’ve talked about this for a long time. If you have thoughts about any of this stuff, please come talk to us. If these sound like particularly interesting problems to you that you want to help us solve, Code Climate is hiring for both engineering and support roles. So, please come talk to us. And yeah, thank you for coming today.

Abby Armada: Thanks!

Gordon Diggs: Thank you for listening to us.

Gordon is the Director of Engineering at Code Climate. He spends his days managing and growing the engineering team. When he is not at work, he can usually be found at the nearest record store or at home cooking lasagna.

Abby is the Customer Support Lead at Code Climate, and is passionate about great customer experiences. She’s currently working on developing her team, scaling support infrastructure, and finding the perfect taco in New York City.

Read more at the source

Building a developer culture with InnerSource

In July, we hosted the first annual Code Climate Summit, a one-day
conference for leaders of engineering organizations who want to better
themselves, their processes, and their teams. Starting today, we’re excited to
start sharing videos and transcripts of the six great talks. First up is Panna
Pavangadkar
, Global Head of Engineering Developer Experience at
Bloomberg LP, with her keynote: Building a developer culture with
InnerSource
.

 

Transcript of talk

I’ll just start by introducing a little bit of my background, how I got here, and why I do what I do today.

I run something that we call Developer Experience at Bloomberg. How I got there is a slightly long-winded story so bear with me.

I started off in the ‘90s working as a late night lab assistant in India, which then led me to supporting the manufacturing sector and then the financial sector. When you joined as a consultant, you literally did everything. You were an app developer. You were a system administrator. You were a DBA. You were the person who wired up the cables and got into the machine room and did everything.

That then led me to deciding to follow databases. I became a database consultant and moved to Asia in the financial sector. Long story short: I landed up here in New York City, working in the financial sector again, focusing on application development and databases, and then system engineering, and performance engineering. This long-winded story comes back to why it puts me in this unique position for Developer Experience, as I discovered that – going through these various roles in these various countries, encountering different types of developers – the one thing that I developed a lot for was empathy.

I realized that every single personality type in computer science, varied system administrators, DBAs, app dev, web developers, have their own personality types. We all have our own quirks, our own religion, and do things in a very particular way that’s unique to us. So “it’s my way or the highway” and “I’m god’s gift to mankind”.

That made me develop a lot of empathy that led me to saying, well how can we make our developer experience across the spectrum of people different? Because we all actually want to work with each other. It’s not that we don’t want to work with each other. But we are so myopic in the way that we want to develop our piece of the puzzle, that we don’t see the other person’s point of view.

Two and a half years ago, I got approached by Bloomberg to try and explain how should we be developing software. I had been at Goldman Sach’s for 16 years and done various, various roles. And as a tech fellow at Goldman we were driving technology in a particular way. When I started talking to Bloomberg it was really about how can we continue to embrace change, and keep our developers excited, and continue to develop quality software, and be the product leader that we have been for so long. So we created this team called developer experience.

So basically, my team does anything and everything from owning the tools that are required by the developers, the process, the framework, the training, the documentation. I even got a, this is a real story, I even got asked if we were responsible and we would take care of having enough male bathrooms. But don’t quote me on that one.

INNERSOURCE: LEVERAGING OPEN SOURCE BEST PRACTICES IN THE ENTERPRISE

Let me make a one second pitch for Bloomberg: Since the majority of people here are from New York City, you’ve obviously heard of Mike Bloomberg. Anybody not heard of Bloomberg the product company? All right. Awesome. So just to make sure we’re all on the same page, we’re a product company based in New York City predominantly, and we’re in the business of providing information. 5,000 engineers across the globe who work on developing the platform on Bloomberg Terminal. You’ve heard of Business Week and you’ve heard of the Bloomberg media news outlets, etc., but our predominant product is the Terminal.

I said we were in the business of providing information. As you can imagine, it’s been 30 years of development that have gone into building the Terminal, to be able to provide very high touch individuals with specialized functions to get the information they need. Whether it’s news, trade related, analysis, portfolio management, to finding out the current events that are happening. So we have to really, really work to provide low latency information and also a broad variety of information.

You can imagine that everyone is working on different functions. Could be for the equities business or it could be for the news media or it could be for some of the back-end functions, just to develop this Terminal itself.

When I got in, what we discovered was that we collaborated a lot. There was a lot of collaboration, but we collaborated the old-fashioned way. Spoke to people. Put in tickets for other people to do things. We were transparent about the fact that your ticket is going to wait for me to finish what I’m working on, or it has to get prioritized by whichever product owner of whichever team I’m working in.

I started exploring the concept of how can we bring open source best practices in house, inside the enterprise. As we started exploring that, we called it “collaboratively sourced” or we called it “internal open source” and finally some of our active developers came up with the fact that hey, this thing already exists in the market. It’s called InnerSource.

Anybody hearing InnerSource for the first time? Cool. It wasn’t a well-known term. We hadn’t heard about it. We were just wanting to bring the best practices in house. After going through a few iterations, we settled on saying fine, we’ll call it InnerSource. Of course, having spent the past 20 years in the industry, my fear was InnerSource would get thought of as developers outside the company working on it. But in any case, supposedly O’Reilly had coined the term 17 years ago, so the term existed.

About 17 or 18 companies, decided to collaborate to see if we could make InnerSource a much more popular term. But more importantly for me, was really bringing those practices in house and sort of breaking down the barriers that exist within an enterprise.

What I discovered is: Most enterprises have grown up organically over the years. It’s very easy in a startup to start with a clean, fresh slate and work on things, and be open about it, be transparent about it, be able to look at each other’s code, etc. In an enterprise that’s evolved over 20 years, you’ve grown up in silos. Thing have got added on as they got added on, so people hold on to their little bit of the codebase. That’s how they’ve grown. What we needed to do was figure out a way of breaking down those barriers and really embracing some of the benefits.

I list out the benefits here – transparency, collaboration, innovation, community, reuse, mentorship, self help – but there are obviously more benefits to open source than these. What I was really focusing on for our developers is collaboration and a lot of the community and the camaraderie that can be built up, so that we have empathy for each other. We are able to work with each other without getting protective about it. That’s pretty much the theme that started it.

HOW

So how did we go about it? Initially, it was really just talking about the concept. Just like how I asked you, who has heard about InnerSource and a lot of you hadn’t. When I spoke about collaboratively sourced, it was met with of course, a lot of skepticism. There was a lot of critiques. It was like it’s just not going to work. Like, why the hell would we do this? We are already working within our teams. We have enough work to be done within our teams. So the first thing was really about introducing the concept and saying, at least just be open to the idea that I can go across an enterprise team, organizational, artificial boundary and look at somebody else’s code and add value or vice versa. Have somebody else who may have something to offer, may have some sort of expertise, or just be interested in that area, to come and look at my codebase.

Just sharing that idea and getting the excitement created within the development community was the first step that we went about. I did think about, and everybody asked me, what sponsorship do we have? Do we have management buy in? What I had done was just tested the waters, to say, if I go and ask for permission, will it get squashed down or should I push for this collaboration social experiment and beg for forgiveness later?

Fortunately, one of Mike Bloomberg’s business principles state that take the risks and beg for forgiveness if needed. So that’s how we decided to say let’s start getting the developers excited about the fact that hey if you are waiting on somebody to do something for you, you can offer to help them out. In the offering to help them out is where the whole drama lies, but the concept was well understood.

Identify early adopters

Once the concept got understood and a few of the developers started embracing the concept, that’s when we said, let’s identify early adopters. I was in this unique position to say, I own the tools. I own the tools that developers use, so let’s open up these tools and if the next person who asks me for a feature, we’re going to tell them that they can help us and contribute to our codebase and make that happen for themselves.

Two and a half years later it sounds way easier to say what I’m saying. Trust me, all my team leads hated me. Literally hated me. They were like, why is she bringing all this into this? We were functioning just fine, right? Because I mandated that we open up our own codebase.

So I identified early adopters. In your organizations it really is about finding out what’s that sweet spot, what’s the low hanging fruit, which of the less resistant applications, functions, codebases would be able to accept external contributions. Then, it really was about mobilizing people to actually start to engage and contribute.

Engage (at all levels)

This is where we were slightly unique because we already had a few years ago started off with engaging our development community a lot more. We have people who are called partners, we have people who are called champs, we have people who actually within their own areas, are responsible for being the people who engage with the other teams, continue to collaborate with the other teams, as well as pushing best practices. So it was really leveraging this champ/partner community. We have tech reps as well, really embracing and getting them to embrace it and then they started engaging with us to say, can they start contributing to these early repositories because it really was setting precedence.

Evangelize

Once we had the precedence set, because we had a few repositories where people from other teams could now contribute code, we could then start to evangelize a little bit more and even tell middle management, or our managers, or our senior management, that this concept can work. We just have to push the envelope a little bit. So really it was the engagement on all levels and the evangelization.

This is really about tooting your own horn for the project itself. So for InnerSourcing to be accepted, for people to start understanding the terminology, we created an internal function called sauc. It’s just a play on Innersource but it’s called sauc, so when you type in sauc it’s nothing but a list of repositories with pull request, books, help wanted tags, and it’s just a very, very simple gaming methodology. Not to call out people, but to call out projects that have lent themselves to being contributed to as well as extended.

Sponsorship

That’s a key, but in our case, we got sponsorship way later into the game when we had already sort of proved concept, to say this can actually work.

AFFECTING CHANGE

Organizational structure, culture and dynamics

So I mentioned change is hard. Tell me to walk on the left side of the road when I get out of Penn Station and I go berserk because I have a set pattern. I walk on the right side of the road to get from Penn Station to Park. That’s just a simple example. Try telling any one of you to change the way you write code or change the way you do certain things and you’re going to be questioning why it needs to change because it works for you. The way I develop software on my laptop works for me, why the hell should I change anything, right?

It was really, really hard to get people to accept the fact that now we are going to introduce the ability for other people can contribute to your codebase. You can contribute to other people’s codebase. Keep in mind, I’m talking about history. People at Bloomberg have been around for 20 years. So they have set patterns. They have ways of working. It’s not like we’re getting in or changing 5,000 people overnight. When new people come in, of course they want to be able to bring their new best practices with them. Being able to talk about the fact and getting them comfortable with this organizational structure should not be the barrier which holds you from going across organizational boundaries, which is something that we really had to work on. It was a lot of talking. A lot of sharing stories and convincing people that this is good for them.

There is a lot of pride in the work that we bring, the work that we have done. Sure, I took some short cuts at some point in time, but I had pride then and now, because I don’t want to feel exposed, I’m reluctant to open it up and allow people to critique it or comment on it.

So, code pride is one of the things that I found was the biggest road block because people have evolved over time and they have become better, they have embraced new things, so if you go back and open up something that somebody wrote 15 years ago, and start saying this person doesn’t know what the hell he was writing about. Yeah, maybe he didn’t. Maybe he or she had no clue what they were doing at that point in time, but they have evolved now.

What became really interesting is creating a culture where it was okay to talk about code that was written earlier, but it was not okay to say nasty things. It’s easier said than done.

We use IB, Instant Bloomberg, as our internal chat. I can’t police multiple chat rooms to say people shouldn’t say nasty things to each other. I’m guilty of saying, this is just ridiculous stuff, I’m not even going to bother commenting on it or they shouldn’t have done it this way, but we had to start creating cultural awareness that you cannot bite somebody else’s head off, you cannot be nasty, and creating the informal policing.

I talked about champs. I talked about tech reps, I talked about evangelists. Creating that culture where developers feel that they can hold accountable other people who may be getting vicious, or even slightly aggressive, on IB or mail or even comments in the codebase itself. Really embracing the fact that you’re coming from different places and you’re contributing at different times and therefore, passing a judgment is not acceptable, and we have to find more constructive ways of changing that codebase and making that change.

Accepting contributions is hard work

As soon as we started getting over that barrier, the next thing was, well, accepting contributions is hard work. And then taking ownership of somebody else’s contribution, because I may still own the product and I’m responsible for when the tool breaks. It then became the concept of saying, well we have to then define how am I going to discuss the feature request coming in, or how am I going to deal with the idea, the suggestion, the code contribution coming in, and what are the rules of engagement? What are my guidelines? Or, what’s my point of entry? And what are we willing to engage with and what are we not willing to engage with.

Now, in the whole Agile transformation, it’s tough because you need the product owners to buy in, you need the team to buy in, you need to be able to set aside the time to accept contributions that weren’t part of your regular stream of work coming in.

Trusted committers

This is where we started to talk about expanding our trusted committers beyond the organizational or product team. Could we grow our list of trusted committers beyond the organizational boundaries? This was really, really hard work. It of course meant that there was a lot more coaching involved. There is a lot more shadowing involved. A lot more people who are getting familiar with your codebase, before they can actually help out with code reviews, by being able to review your pull request, etc.

CHALLENGES

Risk

It’s complicated. There is a lot of risk to it and the risk is if I’m owning a production function and you’ve contributed code to it, and something breaks, I’m going to be held accountable for it. I’m going to have to support it. I’m going to have to get up at night and deal with whatever broke because you didn’t test some edge condition. It’s easier just to say no we can’t do this. So that risk was the biggest one that we had to overcome, to start to encourage a higher standard of acceptance such that we could take this risk of getting contributions from other people.

Commitment

The next one is commitment, both time and team.

Time is the easier one because – and I got into trouble for saying this in Europe, but – everyone does 120%. Some people even do 140%. It is basically going beyond your day job and providing some contributions to other teams or even functions you’re interested in, but Europe has some very strict guidelines around the 80/20 and just padding 100% of the time that they work on, so I was told to work on trying to figure out how we could adjust our external or additional contributions to within 100%.

So we went back to this concept of 80/20, 90/10, call it what you want. We didn’t really advertise it internally, but we took a few teams and said, let’s try it out, to see how much does our work really suffer, if we do set aside 10% of our time to work with other teams or things that we may be interested in personally. The product buy-in on this was really, really tough, as well as some of the teams just didn’t embrace it initially.

I won’t say this was a solved problem, but we continue to work on it and I truly believe persistence is going to pay off. Over time, both project owners as well as the teams will realize that having that 10% flexible time for me to work with other projects that I’m maybe interested in, is actually a motivating factor for me because I don’t mind the drudgery stuff I may be doing or I don’t mind some of the other things that may come on my plate, because I have that 10% excitement of what I want to do. Or try out a new thing. Or be able to look at a new exciting project that’s going on in some other part of the firm and be able to do that.

It also led to this whole confusion between projects and products and projects done by teams versus what the product ownership is. The reason I bring that up is, even though the Terminal is one big product, we have multiple products within the Terminal, and then we have multiple projects that go across multiple products – so there’s no one size fits all. So we would have to figure out what the right distribution of work across projects and products is. As I said, in an enterprise having evolved over time, time accounting or people accounting became a question, to say, where does a developer’s time go?

Again, we went back and forth on this, saying we shouldn’t worry about where a developers time goes, we should worry about the progress that we’re making with moving the product forward or the project forward, and the innovation that we’re bringing in, the new functionality that we’re bringing in, which is what our higher end clients need.

That is again a lot of proving by actually getting some initial teams to be able to participate in this sharing concept, move the product forward, and getting the product owners to actually talk about the wins. We had some crazy user stories being shared internally about just functional changes that we were able to move forward much faster because multiple teams were now able to collaborate at a completely different level.

Rules of Engagement

I spoke about rules of engagement. I spoke about people defining, so we didn’t set a one size fits all. We didn’t say this is the participation criteria across the board, we said, every team can now put in a contributing.md and I said team but I really mean a repository. Any repository, you can define your rules of engagement. You must have a contributing.md otherwise you’ll get a default one. And in that, your rules of engagement and your acceptance criteria for contributions. Then what we started doing was scraping all the repositories to find these contributing.md’s as well as started to showcase where people were being forthcoming about defining their rules of engagement really well and their acceptance criteria as well as where it was then possible for others to start contributing to it.

Buy in

I already spoke about the buy in. We had to get and we cheated again a little bit on this, we went around the product owners and found out which product owners would lend themselves to this concept of inner sourcing, who would lend themselves to saying, some portion of my time, 5%, 10% of my developer time, can be spent and we had various sort of negotiations with them which is to say, fine, I can move tickets in some other project as long as it helps my project move forward. If I’m waiting on somebody, I have the leeway to contribute to that particular project and move it forward for myself.

So we engaged with some of the earlier product owners. Once we had gone through six months with them, we got them to talk to other product owners and showcase how it was beneficial – not just in terms of moving the product forward, but in terms of the developers engaging with the other development teams on a much deeper level. We were engaging and collaborating at the codebase.

It also helped with keeping us motivated, and having options. I now like what’s happening in the other team, and I have mobility options to actually move to the other team and help them move things forward. We had various occasions where somebody moved to another team for six months, helped the move a particular area forward and then move back. It just opened up a variety of avenues for us.

It’s my baby

Finally breaking the myth about it’s my baby. How many of you still hold onto stuff saying that it’s your baby? I used to be one of those people 10 years ago. You have to learn to let go. Literally, it’s not going to get better continuing to be your baby, right? At some point of time, even parents let their kids go. So, the breaking down that concept of “this is my baby and I’m not going to let go” was probably the toughest one. So we had to continue to push on those people who thought it was their baby and work with them on an individual one on one basis. I will claim we still have a few. I think we’ve broken down most people to at least open the doors. They still think it’s their baby but they’ve opened the doors. We still have a few more to go and that’s been the toughest one.

DIVERSITY

Individuals

I started my talk with what got me to this place which is I had experiences across Asia. So in India, it’s a very hierarchal society. It’s changing, so don’t throw darts at me right now, this was 20 years ago. We had just started. The computer boom had just started in the mid 90s and it’s very hierarchal. You get delivered a set of tasks. You move forward. Nothing. You’re not allowed to question or offer a suggestion.

Unfortunately, I was sort of badly placed there. I was born and brought up in India, but I was badly placed there because my dad sort of encouraged us to really do whatever the hell we wanted. We were two girls. When I started working, it was really tough for me to hold back because if I didn’t agree with something, I would say, this is just wrong. I’m not going to write it this way. That was my individual experience. However, I discovered – as I moved into system administration and database administration, I was one of 50 to 100 guys sitting there – I was okay working with them because I had grown up that way. But the other girls that started joining our teams, were not okay with it. They found it difficult. That’s when my head started clicking and I said every single individual is different. I could deal with it but some of the other aren’t dealing with it.

Then I discovered that it’s not a gender thing. It’s individuals. They are individuals who are soft spoken. There are individuals who don’t mind putting their ideas out there. There are individuals who are more thoughtful. There are individuals who will speak off the cuff and we have to account for those individuals, for those different individual traits when we start collaborating and we have to try to create a practice where everybody is sort of self-policing themselves so that we are more inclusive. That’s something that just doesn’t come naturally. But we had to start talking about it and as I held more and more intimate 20 people, 30 people sessions on pointing out behaviors within instant messaging, pointing out behaviors with updates on tickets, pointing out behaviors with code reviews that were nasty, or appear to be nasty. I am a direct person. I can ask a direct question. I didn’t think twice about it. But the person on the other end or a newcomer on the other end, may perceive it as hey I’m not going to touch this thing because the next thing I do my head is going to get bitten off and I just don’t have time to engage with it.

That really is something that each one of you, individually, if you’re just conscious about the fact that the other person might be coming from a different place, we can collectively improve the developer culture across the board. Just by being conscious of the fact that somebody is coming from a different place and may have a different criteria in mind.

(By the way the picture up there is a fish tank at Bloomberg and I always get fascinated because every fish behaves differently and that’s why I wanted to put that picture in there.)

Building a culture of mentoring/coaching

Building that culture of mentoring, of coaching, is every individual’s responsibility, and just making people conscious, all developers conscious, of the fact that this is what’s happening. I found a very unique way to do it. Get a bunch of people in the room, of varying experience and at different levels in the organization. So two years’ experience to 20 years of experience and ask very provoking questions on how they would react to a certain statement out there or how they felt when something happened in IB and instant messaging or what would they think if they had a newbie question to ask. Who would they ask that question to? How would another person who was sitting there react to that newbie question?

When we started having these conversations, it was very interesting because people discovered, just observing and hearing other stories in the room, behaviors that they probably needed to change themselves. It wasn’t anybody judging it was just sharing stories. And we still do that to bring developers together even in meetups, we ask those questions, especially around being more inclusive, about the varying range we have.

Community driven

As I said, it’s all community driven. We leverage the champs, the partners, the SI partners a lot. I encourage developers to be their own police so we don’t have top down mandate. We don’t have a management decree coming down that thou shall do this. It is all based on grass roots efforts. We do have support now though.

TEAMWORK

Of course, it’s not, even though we are all individuals and every single individual contributes to it, nothing moves forward without us moving as a team including this collective developer audience as a team.

[Indicates slide outlining roles within team and a picture of a dog sled race team] The reason I very specifically picked this sled racing team is to point out the very, very simple difference. They are not all eight equal dogs. Each dog has its own personality. If they are trained, they are trained for the position they are running at. So the leader dogs versus the end dogs, have very different roles to play and part of the training goes into training those dogs that way. Those dogs don’t behave out of their roles. They behave in their roles.

I don’t mean to compare us to a sled dog team, but the reason I point this out is because when we’re functioning in a team, you will realize that and you probably already know this, that everybody plays a different role, apart from the official role. So some are more mentors. Some are more coaches. Some can ask more questions. Some are more outspoken and will take over the meeting or take over the design discussion and it’s their way or the highway.

What I’m really asking for in this is the roles should be really determined for the team as to who is doing what, but we should really embrace the differences and ask people – or make people comfortable – to participate in the team, even though the roles are clearly defined. Where people take over meetings or where people may be bullish about something, find somebody to coach them, mentor them, to change that behavior so that the team itself can evolve and become a better team.

TOOLS

When I go back two and a half years, I said okay, what are our silos? Why are we so siloed? Where is the collaboration happening? We didn’t have the appropriate tools. Tools did play an important role. Repositories were permissioned individually. I won’t even go back to whether we were using CDS, Purecase, SVN. Earlier versions of Git. We are now on Git but the reason I bring that up is because repositories are individually permissioned traditionally. That’s how we grew up in silos. So the first thing we did was say, okay, we’re going to open up our repositories.

“Oh no, no, no. You can’t open up my repository because I have sensitive stuff there.” What sensitive stuff? “Oh we store passwords there.” I’m like that’s not sensitive stuff. Take your passwords out. The repo is not the right place to store the password and keep a closed repository. This is a true story by the way. But it always came up as “oh we have sensitive code. We cannot open it up.” As I started questioning what is the sensitivity of that code, it always boiled down to one of three reasons. Three invalid reasons and I’ll tell you the one valid reason.

“I have some secure stuff there that I shouldn’t have put there but I put it there so therefore I can’t open it up beyond my team.”

“I have some…” am I allowed to say shitty code? “I have some really badly written stuff here. We’ve made some bad decisions. We have to clean it up before we can open it up. So we’ll clean it up and then we’ll open it up.” Of course it’s never going to get there.

And last but not the least is “oh, because these are low level APIs and we don’t want them to know what we’re doing and be able to leverage some of the other stuff, we can’t open it up because they can’t see the decisions we’re making because then they’ll directly access our codebase.”

The one valid reason which is probably true across the industry is 10% or 20% of the codebase probably was truly specific to competitive business advantage, maybe some algorithms. Maybe some business logic, etc. Right? That was the key, the glue, the thing that sold your product. 10%, 20% and this is just an off the cuff number.

The minute we said that all repositories are open by default, we started working through these restrictions that were laid out to us and we started just saying, you’ve got to open a repository by default. If you want to close it up, you’ve got to talk to me. Then of course I’ll wear you down with asking you questions and then I’ll take you to your CIO and wear you down with asking questions.

That was our first thing. We were pretty scared and skeptical that because of this rule, we would not get people moving into this concept, but as I go back to how I started my conversation with the early adopters, with the evangelist that we created, with the buzz that got created about having a tool set that actually works, we started getting people moving their codebases over from whichever legacy repository they sat on. And we started getting more and more requests for features such that the tools would enable them to embrace this change.

Agile brought in some rules. So our Agile coaches came with some very specific guidelines. We had to then coach our coaches on some of the ‘religion’ that they brought in versus some of the common sense which is just we needed to work with within our enterprise because our enterprise had grown up that way. Just to get them to recognize the differences and work with us was a challenge, but it’s something we worked through.

What we also discovered was thinking outside the box. In a traditional enterprise company, we didn’t have hackathons. We didn’t have coding days. We didn’t have space for ideation. So we started sponsoring a lot of those kind of activities. We have something called a Dev-X hack a thon which runs for a couple of days. We have it two or three times a year. We have it in London and we have it in New York. We do other cool stuff. The swag, the prizes, but the fact is that the ideas that come out of Dev-X hackathon get sponsored to get built up as a project.

So a lot of the tools integrations that we built up, were a result of the hack a thons. The idea started in a hackathon and then got sponsored and we could go ahead and build out that integration, amongst the other various SELC tools.

ENCOURAGING COLLABORATION WITH STRETCH PROJECTS

We found this to be a really, really interesting way of encouraging collaboration across teams. All the newcomers or the new classes that come in, I always encourage them, as part of their training to take on stretch projects. If they are interested in taking on a stretch project, I encourage people to work with their management teams to allow them to do those stretch projects. That seems to have helped us in moving the agenda forward because as people start to see the benefits both for the people that are working in their teams as well as the projects that they are working on, everybody has got a win, win situation.

What we also started to do was say, if I have opened up my repository, I’m going to have some issues being tracked and I can put in help wanted tags on the issues that are low hanging fruit for me and I can get others to contribute to them. I mentioned this function called sauc. You run sauc, you get to see a list of repositories which have help wanted functions. For somebody who doesn’t know specifically where they want to get started, or they may have an idea they can just go look at the help wanted issues, pick them up, and work on those. This was a really easy way for us to say, do it yourself. Self-serve yourself for moving something forward.

What we also did was shared infrastructure projects. Everything with software infrastructure which was related to the tools we opened it up. Some places it’s harder to accept contributions especially when it’s really related to compiler flags which go across the entire stack, so those are harder contributions to accept. But some of the simpler contributions are really straightforward. We also started to understand common pain points that came across because as you can imagine, we’ve opened up a codebase now. So I can look across my entire sauc repository and see everybody’s projects. If I have somebody working on containers, I can see who else is working on containers and create those opportunities to pull them together so that we don’t have everybody doing their own thing. And pull those projects together and actually sponsor it as a project so we can collectively work on that one functionality or feature or piece of infrastructure that we’re developing.

And with that, I’m going to say and encourage all of you to get started. You can look at innersourcecomments.org. I have references at the end and the three things, I called it my three pronged approach initially when I started, which is identify the early adopters, evangelize, and then get the sponsorship. I hope this has been useful for you.

Panna Pavangadkar is the Global Head of Developer Experience for Bloomberg’s Engineering group. Building a great developer experience is at the heart of what her team does, providing a development environment that enables application developers to focus on building the company’s core product: the Bloomberg terminal. Her past experience with databases, operating systems, infrastructure and application development in various engineering roles – as Technical Fellow, Vice President at Goldman Sachs (New York) and JP Morgan (Singapore) and NIIT (Pune, India) – gives her a unique perspective to understand and work to introduce and encourage wide scale change within the company’s developer and engineering communities.

Read more at the source

Our 10-point technical debt assessment

In the six years since we first introduced radically simple metrics for code
quality, we’ve found that clear, actionable metrics leads to better code and
more productive teams. To further that, we recently revamped the way we measure
and track quality to provide a new, clearer way to understand your projects.

Our new rating system is built on two pillars: maintainability (the opposite of
technical debt) and test coverage. For test coverage, the calculations are
simple. We take the covered lines of code compared to the total “coverable”
lines of code as a percentage, and map it to a letter grade from A to F.

Technical debt, on the other hand, can be a challenge to measure. Static
analysis can examine a codebase for potential structural issues, but different
tools tend to focus on different (and often overlapping) problems. There has
never been a single standard, and so we set out to create one.

Our goals for a standardized technical debt assessment were:

  • Cross-language applicability – A good standard should not feel strained when
    applied to a variety of languages, from Java to Python to JavaScript. Polyglot
    systems are the new normal and engineers and organizations today tend to work in
    an increasing number of programming languages. While most languages are based on
    primitive concepts like sequence, selection, and iteration, different paradigms
    for organizing code like functional programming and OOP are common. Fortunately,
    most programming languages break down into similar primitives (e.g. files,
    functions, conditionals).

  • Easy to understand – Ultimately the goal of assessing technical debt with
    static analysis is to empower engineers to make better decisions. Therefore, the
    value of an assessment is proportional to the ease with which an engineer can
    make use of the data. While sophisticated algorithms may provide a seemingly
    appealing “precision”, we’ve found in our years of helping teams improve their
    code quality that simple, actionable metrics have a higher impact.

  • Customizable – Naturally, different engineers and teams have differing
    preferences for how they structure and organize their code. A good technical
    debt assessment should allow them to tune the algorithms to support those
    preferences, without having to start from scratch. The algorithms remain the
    same but the thresholds can be adjusted.

  • DRY (Don’t Repeat Yourself) – Certain static analysis checks produce highly
    correlated results. For example, the cyclomatic complexity of a function is
    heavily influenced by nested conditional logic. We sought to avoid a system of
    checks where a violation of one check was likely to be regularly accompanied by
    the violation of another. A single issue is all that’s needed to encourage the
    developer to take another look.

  • Balanced (or opposing) – Tracking metrics that encourage only one behavior
    can create an undesirable overcorrection (sometimes thought of as “gaming the
    metric”). If all we looked for was the presence of copy and pasted code, it
    could encourage engineers to create unwanted complexity in the form of clever
    tricks to avoid repeating even simple structures. By pairing an opposing metric
    (like a check for complexity), the challenge increases to creating an elegant
    solution that meets standard for both DRYness and simplicity.

Ten technical debt checks

With these goals in mind, we ended up with ten technical debt checks to assess
the maintainability of a file (or, when aggregated, an entire codebase):

  1. Argument count – Methods or functions defined with a high number of arguments

  2. Complex boolean logic – Boolean logic that may be hard to understand

  3. File length – Excessive lines of code within a single file

  4. Identical blocks of code – Duplicate code which is syntactically identical
    (but may be formatted differently)

  5. Method count – Classes defined with a high number of functions or methods

  6. Method length – Excessive lines of code within a single function or method

  7. Nested control flow – Deeply nested control structures like if or case

  8. Return statements – Functions or methods with a high number of return statements

  9. Similar blocks of code – Duplicate code which is not identical but shares the
    same structure (e.g. variable names may differ)

  10. Method complexity – Functions or methods that may be hard to understand

Check types

The ten checks break down into four main categories. Let’s take a look at each of them.

Size

Four of the checks simply look for the size or count of a unit within the
codebase: method length, file length, argument count and method count.
Method length and file length are simple enough. While these are the most basic
form of static analysis (not even requiring parsing the code into an abstract
syntax tree), most programmers will identify a number of times dealing with the
sheer size of a unit of code has presented challenges. Refactoring a method that
won’t fit all on one screen is a herculean task.

The argument count check is a bit different in that it tends to pick up data
clumps
and primitive obsession. Often the solution is to introduce a new
abstraction in the system to group together bits of data that tend to be flowing
through the system together, imbuing the code with additional semantic meaning.

Control flow

The return statements and nested control flow checks are intended to help
catch pieces of code that may be reasonably sized but are hard to follow. A
compiler is able to handle these situations with ease, but when a human tasked
with maintaining a piece of code is trying to evaluate control flow paths in
their head, they are not so lucky.

Complexity

The complex boolean logic check looks for conditionals laced together with
many operators, creating an exploding set of permutations that must be
considered. The method complexity check is a bit of a hybrid. It applies the
cognitive complexity algorithm which combines information about the size,
control flow and complexity of a functional unit to attempt to estimate how
difficult a unit of code would be to a human engineer to fully understand.

Copy/paste detection

Finally, the similar and identical blocks of code checks look for the
especially nefarious case of copy and pasted code. This can be difficult to spot
during code review, because the copied code will not show up in the diff, only
the pasted portion. Fortunately, this is just the kind of analysis that
computers are good at performing. Our copy/paste detection algorithms look for
similarities between syntax tree structures and can even catch when a block of
code was copied and then a variable was renamed within it.

Rating system

Once we’ve identified all of the violations (or issues) of technical debt within
a block of code, we do a little more work to make the results as easy to
understand as possible.

File ratings

First, for each issue, we estimate the amount of time it may take an engineer to
resolve the problem. We call this remediation time, and while it’s not very
precise, it allows us to compare issues to one another and aggregate them
together.

Once we have the total remediation time for a source code file, we simply map it
onto a letter grade scale. Low remediation time is preferable and receives a
higher rating. As the total remediation time of a file increases, it becomes a
more daunting task to refactor and the rating declines accordingly.

Repository ratings

Last, we created a system for grading the technical debt of an entire project.
In doing so, we’re cognizant of the fact that older, larger codebases naturally
will contain a higher amount of technical debt in absolute terms compared to
their smaller counterparts. Therefore, we estimate the total implementation time
(in person-months) of a codebase, based on total lines of code (LOC) in the
project, and compute a technical debt ratio: the total technical debt time
divided by the total implementation time. This can be expressed as a percentage,
with lower values being better.

We finally map the technical debt ratio onto an A to F rating system, and
presto, we can now compare the technical debt of projects against one another,
giving us an early warning system when a project starts to go off course.

Get a free technical debt assessment for your own codebase

If you’re interested in trying out our 10-point technical debt assessments on
your codebase, give Code Climate a try. It’s always
free for open source, and we have a 14-day free trial for use with private
projects. In about five minutes, you’ll be able to see just how your codebase
stacks up. We support JavaScript, Ruby, PHP, Python and Java.

If you’re already a Code Climate customer, you can expect a rollout of the new
maintainability and test coverage ratings over the next few weeks – but if
you’d like them sooner, feel free to drop us a
line
, we’re always happy to help!

Read more at the source

A new, clearer way to understand code quality

It’s been six years since Code Climate introduced radically simple metrics for code quality: a grade
point average (GPA) from 0 to 4.0 for repositories, and a letter rating for every file. Today, we’re
going further by completely revamping the way we measure and track quality, and shipping a bunch of
new features to go along with it.

Every repository and file will now receive two top-level ratings:

Maintainability: An estimate of technical debt in the repo based on our standardized 10-point
assessment which looks at duplication, complexity and structural issues.

Test Coverage: The percentage of covered lines compared to the total number of lines of code.
(We ingest test coverage information from your continuous integration server using our new
universal test reporter.)

Here’s how it all comes together on your new repository Overview page:

On top of this foundation, we’re launching five major, new features:

Unified Code tab with maintainability and test coverage side-by-side

Gone is the isolated Test Coverage tab, which was an additional place to get a full view of your
overall quality. We’ve fully integrated test coverage information into the Code tab, and everywhere
else.

Drilling down, you can access per-file quality statistics on the new Stats sub-tab:

In-app configuration of code quality analysis

It’s now possible to control the way we analyze your code quality using simple, in-app
configuration. Easily select which checks to run and exclude files that are not relevant.

You can also easily browse and enable open source static analysis plugins, taking advantage of the
30+ tools that are compatible with our open, extensible platform.

For those who prefer finer-grained control, or wish to keep their configuration in version control,
file-based configuration using .codeclimate.yml remains available. If checked in, the
.codeclimate.yml takes precedence over the in-app configuration.

Reorganized and expanded Trends area

With all this new data available, we thought it was a great time to add some organization to the
Trends tab. The left sidebar now makes it easy to get right to what you’re looking for.

We’ve also added a new chart allowing you to see the total amount of technical debt in the project,
and the overall project maintainability, all in one place.

Improved quality alerts via Slack and email

Our pass/fail pull request statuses are great for ensuring that every change merged into your
codebase meets your quality standards. However, every once in awhile something may slip through the
cracks. For these situations, we’ve revamped the quality alerts we send via both Slack and email.
Here’s what it looks like in Slack:

And an email reporting some test coverage changes:

Alerts are sent when any letter rating changes, or any new files are created with “C” or lower
ratings. We think this new functionality is an excellent complement to our recently-launched
customizable issue alerts.

All of the above and more available via a REST API

OK, so this one isn’t completely new, but it’s gotten much better and we couldn’t resist including
it. Over the past year we’ve been developing Code Climate with an API-first methodology. As a
result, the data that powers all of the above features is available over a
robust REST API for you to take advantage of as you see fit.
Here’s a few examples:

Get the current ratings for an individual file

$ curl \
  https://api.codeclimate.com/v1/repos/:repo_id/ratings \
  -H "Accept: application/vnd.api+json" \
  -H "Authorization: Token token=<token>" |
  jq '.data | .[] | select(.attributes.path == "path/to/file.rb")'
{
  "id": "59c41d36d0c53d0001000001",
  "type": "ratings",
  "attributes": {
    "path": "path/to/file.rb",
    "letter": "A",
    "measure": {
      "value": 220,
      "unit": "minute"
    },
    "pillar": "Maintainability"
  }
}
{
  "id": "59c41d36d0c53d0001000002",
  "type": "ratings",
  "attributes": {
    "path": "path/to/file.rb",
    "letter": "A",
    "measure": {
      "value": 92.40506329113924,
      "unit": "percent"
    },
    "pillar": "Test Coverage"
  }
}

Get a time-series of test coverage information

$ curl \
  https://api.codeclimate.com/v1/repos/:repo_id/metrics/test_coverage \
  -X GET \
  -H "Authorization: Token token=<token> \
  -H "Accept: application/vnd.api+json" \
  --data-urlencode "filter[from]=2017-08-01" \
  --data-urlencode "filter[to]=2017-09-01" |
  jq
{
  "data": {
    "id": "59c41d36d0c53d0001000001",
    "type": "metrics",
    "attributes": {
      "name": "test_coverage",
      "points": [
        {
          "timestamp": 1501459200,
          "value": 98.57142857142858
        },
        {
          "timestamp": 1502064000,
          "value": 98.50960160504442
        },
        {
          "timestamp": 1502668800,
          "value": 98.53490376328641
        },
        {
          "timestamp": 1503273600,
          "value": 98.53314527503527
        },
        {
          "timestamp": 1503878400,
          "value": 98.5405557114791
        }
      ]
    }
  }
}

Just head over to your API access page of your user settings
area to generate a personal access token and get started.

These features will be rolled out to all repositories on CodeClimate.com starting today.

Wrapping Up

We hope you’ll agree that these changes represent a dramatic leap forward for Code Climate. As we’ve
been testing this functionality internally and with a small group of customers, we’ve found it
really changes the way we interact with code quality information day-to-day.

There may be a few rough edges as we refine and polish some areas. As always, if you have any
questions about anything, please don’t hesitate to get in touch.
Our fantastic support team is always here to help.

Read more at the source
close