1 of 21

How Product-Focused Companies Optimize For Developer Autonomy

Jon Kruger

Director of Engineering @ Upstart

2 of 21

Enabling Effortless Credit

Based On True Risk

3 of 21

We have a problem

We have a problem - building software is too hard.
It’s not because technology is not evolving, in fact our technical options are getting better and better every year.
Every small company starts out fast
Bureaucracy, approvals, complexity
Managers start focusing on advancing their career at the company rather than creating value, and there are more organizational politics.
No one set out to be like this

Upstart 250 -> 2000 employees
Actively fight bureaucracy and things that slow us down

Product-focused tech companies like Upstart have been focused on this problem for a long time.
Move fast, adapt to change quickly, remove unnecessary friction

I’m going to use my experiences at Upstart and how we do things as an example. By no means do we have this all figured out, and we didn’t invent a lot of these ideas. We also don’t always succeed at following our own principles every day. But we’re always trying really hard to figure it out!

4 of 21

What kind of value are you chasing?

5 of 21

What is a “product-focused” company?

Product

Public Website

Mobile App

Physical Product

Internal Application

Service

Technical Stuff

Creates Value

(you define what “value” means to you)

For a Customer

Public Consumers

Internal Teams

Other Engineers

6 of 21

Product companies measure success by outcomes

Objectives and Key Results (OKRs)

Objective - how we want to create value for the customer

Key Results - how we’ll know if we’re doing it

________________________________________________________________

Example:

Objective - increase customer engagement on our platform

Key Results

Increase monthly new user signups by 10%
$100M in orders in June

7 of 21

Characteristics of Product-Focused Companies

8 of 21

More autonomy for engineers

The expectation of developers at traditional companies is to

complete assigned work.

At product companies, it's to solve problems that the business has.

9 of 21

More autonomy for engineers

Product managers define the “what” (product requirements) and

the “why” (product strategy)

Engineering owns the “how” and the “when”

10 of 21

More autonomy for engineers

Engineers have end-to-end ownership of projects

Working with product managers to refine high level requirements
Technical design
Collaborating with other teams when necessary
Breaking down the work
Leading the team through estimation
Leading a group of engineers to implement it
Monitoring it in production to make sure it works

11 of 21

Engineers are creative problem solvers, not ticket workers

Creative problem solvers	Ticket workers
Responsible for end to end ownership of a solution	Responsible for completing assigned work
Success is measured by value created	Success is measured by work completed
Not viewed as fungible resources	Often treated as fungible resources
Work directly with product managers and business people to determine what to build	Get detailed specifications from business analysts or product owners

Ownership

At Upstart, we love to talk about how we hire problem solvers, not “ticket workers”.
solving business problems with technology.
smart engineers, it would be foolish of us to not consider their ideas
engineers often know the system better than anyone.
push business context down
Flatter pyramid

How success is measured

companies with the “factory worker” mindset

measuring efficiency of teams or individuals,
comparing engineering teams using standardized metrics,
Success = output, not value created

This doesn’t mean that we don’t track efficiency metrics like velocity, bug counts, etc. (after all, we want to be efficient too), but that is not the measure of success of a team.
Agile often is trying to measure work completed, not value created

Product companies want everyone involved in problem solving so that they can build the right thing

Fungible

At traditional companies, you may hear things like “we need 15 Java developers to complete this project in 6 months”.
So they hire 15 Java contractors for 6 months, then hand the system off to another team to maintain it.
Waterfall fallacy - detail out the requirements so engineers don’t have to think, then we can higher cheaper people to do the work
Many companies are somewhere in between
Upstart VT inefficiencies

Roles

At many traditional companies, engineers exist to translate business requirements into code.
The solutions are already decided by others
There is not as much room for problem solving in this world.

We have fewer roles at Upstart (no POs, SMs, BAs)
PMs - high level requirements (business goals, features the system needs to have, how do we measure success, designs/mockups)
Close collaboration, rapid iteration

12 of 21

More exposure to the business

Fewer roles in between engineers and the business

Organizing in cross-functional vertical teams

More exposure to business metrics

At traditional companies, requirements come to through team through business analysts, who got them from business people or a product owner.
This is often done to shield the engineering team from the business.
After all, we’re paying engineers a lot, so shouldn’t we shield them from distraction so that they can keep coding?

Product companies have fewer roles in between engineers and the business, and engineers are encourage to work directly with business people.
This can make it easier to get answers, and allows engineers to think like problem solvers and identify solutions for business problems.

Vertical teams

Don’t just reduce the barrier between engineering and business, we want to eliminate it

Engineering teams typically have more exposure to the business metrics.
Push context down

13 of 21

Investing in a less frustrating developer experience

Invest heavily in making your engineers more effective

14 of 21

Investing in a less frustrating developer experience

How good is your team at these things?

Deployment frequency	How often does your organization deploy code to production or release it to end users?
Lead time for changes	What is your lead time for changes (i.e., how long does it take to go from code committed to code successfully running in production)?
Time to restore service	How long does it generally take to restore service when a service incident or a defect that impacts users occurs ?
Change failure rate	What percentage of changes to production or released to users result in degraded service?
Reliability	The degree to which a team can keep promises and assertions about the software they operate

Source: Google 2021 State of Devops Report - https://services.google.com/fh/files/misc/state-of-devops-2021.pdf

15 of 21

Investing in a less frustrating developer experience

More frequent deploys is an absolute game changer

Want to hear more? Watch “Yes, I Test in Production (And So Do You)” https://www.infoq.com/presentations/testing-production-2018/

Many people I talk to do release on a regular cadence, often every 2 weeks. They say it’s not worth investing the testing automation that is needed to decrease that frequency. Let me tell you a story, maybe it will change your mind.

Deploy every 2 weeks
Feature might miss
Prod issue/rollback
30 microservices

Cost of deployment & regression testing -> 0
Deploy anytime
Feature flags
1% rollout, observability metrics
Fix and try again
Code gets to production quicker, takes less engineering time to get it to production

no validation in a staging environment
no waiting for a QA person to test it
easy to diagnose and fix a production issue
it’s really easy to figure out what caused the issue (because it’s just your code that got released)
no rollbacks of 2 weeks worth of changes
changes got to production much faster
less process and project management - we’ve eliminated the conversation about “this feature might miss the cutoff”.
We’ve shifted our validation efforts from end-to-end testing (which is probably why you had to release those 30 microservices on the same cadence), and focused on validation in production based on observability metrics.
Less need for “release trains”

An engineering team with these tools will be able to work way faster than one that doesn’t.
At Upstart, we are a fintech company, quality is of the utmost importance.
We don’t have all of the fancy capabilities that I talked about yet, but we typically deploy to production every day and are working on getting more sophisticated in our build/release process.
That small startup that’s trying to disrupt your company can probably do this
Large tech companies that are much larger than your company are doing this at scale

16 of 21

Just enough process

What do we need Scrum for anymore?

Read more: “How Big Tech Runs Tech Projects and the Curious Absence of Scrum”

https://blog.pragmaticengineer.com/project-management-at-big-tech/

Once you’ve eliminated release cycles altogether, some process starts to make less sense.
Sprint != release cycle
Definition of done changed
Sprint commitments

demos/signoff/deploy anytime
Signoff is more about rollout, turning feature on
Cross-functional VTs

Less scaled agile
Cross-functional, autonomous teams
Reduce cross-team dependencies
Less need for project managers
Less coordination
Less standardized reporting (no point to comparing teams - linear thinking)

Product companies tend to be less focused on controlling and squeezing more efficiency out of the factory (which has diminishing returns)
they would rather optimize for giving teams autonomy to create exponential value.

At Upstart, we still mostly use Scrum-like process because the bi-weekly cadence of meetings is nice, but the way we build and deliver code looks a lot different.

17 of 21

Higher leverage -> higher autonomy, higher pay

Engineers aren’t just coders, they are problem solvers,

therefore they are worth more

… which leads to higher caliber talent

… which attracts more high caliber engineers that want to work with other high caliber engineers

… because we’re optimizing for exponential value

18 of 21

What’s your next step?

19 of 21

Upstart is hiring!

Tech Platform / DevOps / Architecture

Auto Lending

Mortgage

Growth/Top of Funnel

Personal Loans

Pricing/Underwriting

Small Dollar Loans

Small/Medium Business Lending

Lending Partnerships

Loan Servicing

Data Engineering

Model Engineering

Machine Learning Engineers

Research Scientists

We are hiring for many roles across engineering and machine learning

(including managers!)

OPEN ROLES

20 of 21

Questions

?

21 of 21

Thanks!

Get these slides:

Contact me at

jon [at] jonkruger [dot] com

Thanks for coming!