Behind the scenes with Jobber’s Dev Acceleration team

Many software companies love to obsess about customer obsession. That’s no different at Jobber: our teams are honed in on providing an easy-to-use experience for service professionals so they can focus on providing value to their customers.

But what about developer obsession? How can we do the same thing for our developers and make it easier for them to deliver value to service professionals?

At Jobber, we decided to tackle that problem with a new team called Dev Acceleration. The goal of this team is to address the bottlenecks and pain points that hinder development productivity and reduce friction with suboptimal tools or processes.

This type of team can go by many different names: dev acceleration, developer experience, or even engineering enablement. The norms around naming this team isn’t commonplace at many software companies, but the core idea is spreading.

This post will take a behind-the-scenes look at what it’s been like to establish the Dev Acceleration team at Jobber.

Know your developers and establish your mission

First and foremost, a Dev Acceleration team has to dig into developer pain points and the status quo without initial bias. They must know and listen to their customer: namely, developers. This is no different than any other feature team!

It’s important to come into this role with opinions that are loosely held: you can have a preconceived notion of what needs to be done, but in order to make progress, it comes down to establishing a mission and establishing relationships with engineers who can guide the team in the direction of that mission.

How that is achieved at one company can look extremely different at another!

I’ve worked with companies that had many different teams managing their own infrastructure and operated their own microservices with Kubernetes. There was a high demand for a platform engineering team that could provide services for teams to manage their own services independently. Jobber, on the other hand, has a centralized infrastructure team hosting a Rails monolith that most of our engineering teams work on simultaneously. Clearly, what engineers desired in my past experience may not be something that Jobber engineers want, need, or even think about!

When I started at Jobber, my manager had compiled a 12-page document exploring pain points within engineering. This was a great starting point to focus my energy and talk to people within engineering about the most pressing issues. Over the course of a few weeks, I chatted with many engineering managers and principal engineers to confirm the pain points in that document, and from there generated a developer survey to get feedback from the rest of the engineers in the company about their experience.

From the survey responses we received, I felt it was prudent to follow up with developers who showed some passion about the bottlenecks at the company. This usually comes from senior engineers or tech leads, but it’s important to note junior engineers' opinions as well. Seniors may be skilled enough to work around some of the challenges, but they can overlook some of them. Juniors might struggle with these hidden problems. By engaging with engineers of all kinds and encouraging them to follow through on these problems, we foster that culture that generates great quality-of-life pull requests from engineers that want to make Jobber an easier habitat to get things done.

Establishing a Developer Acceleration mission

A key question for any developer experience team to consider is: How are you actually improving the developer experience or productivity at the company? What does developer experience even mean?

Answering this question will get your team to start thinking about its mission and your metrics. For us, our mission at Jobber is: we enable engineers to ship faster. That means we’re focused on producing four types of value for developers:

Speed: we remove blockers that are slowing devs from shipping code faster
Efficiency: we reduce developer toil and build our tooling to scale
Clarity: we reduce cognitive load and make processes easier
Autonomy: we reduce dependencies and make tooling that is self-serve

These values serve as the benchmark for where we want to go. From these values, we can determine metrics that prove that we’re having an impact in our target value area.

In the future, we want to leverage frameworks like DORA or SPACE to provide quantitative and qualitative data for our work. But for the time being, we’ve kept our focus on honing our metrics to more targeted areas within our control.

It’s likely that some of the work will be a lagging indicator. You might not see results right away. Be patient: Adoption of your new, improved tooling and processes will take time.

Exploring themes and bottlenecks

With the soul-searching complete, it was time to dial in on the low-hanging fruit that could provide the most impact. We knew there were great opportunities to improve the speed at which things are done at Jobber. But we had to be mindful that we didn’t spend a lot of time doing the wrong thing to speed things up based on loose hypotheses. Personally, I think one of the worst approaches a team like this could take would be to take on a large and lengthy project filled with uncertainty and ultimately fail to deliver results - or even worse, results that no one wants!

That was almost the case with our first project, and why we live by taking small bites and working iteratively.

Improving local dev environments

Something that was addressed by many engineers in the company was difficulty getting their dev environment set up and keeping it up-to-date. Our setup can be a bit tedious, and it’s not uncommon for a tooling/language update to happen in our codebase which can break a few developers’ environments if they miss the public service announcement.

To address this, we decided to explore GitHub Codespaces and dev containers as a way to automate the dev environment and provide on-demand testing environments for engineers, product managers, and engineering managers to access. It was actually pretty easy to get Jobber running in Codespaces in a couple of days! But could it be a full-on replacement for dev environments? Would it support all of our integrations? Would it be stable enough?

We delivered a proof-of-concept, a trial run with a handful of devs, and further investigation that revealed the Codespaces experience was too tedious and required much more effort and automation to bring up to parity with a local dev environment. Ultimately, we decided that it was not worth pursuing further and would revisit in the future.

But this was a great example of pivoting quickly: we placed a small bet, got some feedback, and decided it wasn’t the best use of our time to bullet-proof a solution there. With a small team of three engineers, there were even bigger wins to be had with that involved less uncertainty.

CI/CD pipeline

The performance of the CI/CD pipeline affects every single Jobber engineer. Whether it’s a flaky test, a blocked deployment pipeline, or long-running test suites that get slower by the day, the impact of a poorly running CI/CD pipeline can silently grow and is most likely to be accepted as ‘that’s the way it is’. At Jobber, there was some degree of that but there also wasn’t a dedicated team to tackle those sorts of issues with the time needed to dig deep.

As a result, a majority of our time has been spent improving the performance of that pipeline and stabilizing that process for the future growth of more Jobber engineers to build, test, and deploy their changes.

Our biggest win so far has been reducing the pipeline time by nearly 50%. Our test times were sometimes hitting 20 mins per run for 30,000 rspec tests and 6,000 Jest tests. With some work towards more efficient usage of the testing infrastructure, we’ve brought our times down to 12 mins per run with 40,000 rspec tests and 10,000 Jest tests for roughly the same cost per run.

Prioritizing the most impactful work

We could have put all of our effort into making GitHub Codespaces our dev environment of choice, but was that guaranteed to be useful, adopted, and loved by our engineers? Tackling the low effort/high impact items may not be flashy, but when you’re a small team just starting out, it’s important to establish trust and deliver meaningful results.

What this looks like at another company will probably be different. A developer experience team will likely have a different focus based upon their developer discovery work. But it’s important that you’re not led astray by recency bias, where the last thing that bothered you seems like the priority. A Dev Acceleration team has to discern the high impact work that will affect the most people.

Where we’re headed next

As mentioned earlier, Jobber is a monolith and the majority of our teams contribute code to the same repository daily. As we scale, we want to ensure the values we espouse scales with the monolith, too. We don’t want to slow down just because we are growing.

That means maintaining speed and efficiency: we want to build our pipeline to scale for fast builds, test suites, and deploys. We average around 40-50 commits to our repository a day and we want to build a release pipeline that scales for releasing 100s of times a day.

We also want to improve autonomy and clarity. Establishing ownership over components of the codebase is a critical piece of the puzzle. We want to improve our tooling for staking ownership within the monolith and have that propagate into our observability and processes. This will make it easier to scale our day-to-day operations of the monolith.

And most importantly, we want to hear what devs have to say about their current experience. That means crafting a developer survey to hear their pain points and allow us to establish quantitative and qualitative metrics to see if we’re working on the right things, and making it easier to ship code faster.

Hiring for a Dev Acceleration team

Maybe after all this discussion, you’re starting to think about what it would be like to put together a team of your own to tackle the large, festering issues at your company. It’s tempting to just put together a Dev Acceleration team from your pool of existing developers. After all, they should know their problems best. But then you might be taking away your best developers from providing great features to the product!

I believe a mix of tenured engineers, and new, but experienced engineers is the best fit. The tenured folk have a great understanding of the day-to-day pain points of development, while the new hires come in with a fresh perspective. They offer a way of tackling problems that may be accepted as status quo, and can also distill best practices from their previous experiences.

It’s also beneficial to have developers of different types and backgrounds. Not everyone needs to be an expert in your existing tech stack.

For example, it’s completely reasonable to have some developers who are proficient in the stack paired with some site reliability engineers (SRE) or DevOps engineers. Together they can cover a large breadth of the work that comes with a Dev Acceleration team. Similar to having a mix of tenured and new developers, a blend of expertise offers the benefit of having many different perspectives for solving any challenge that might come up.

Dev Acceleration is an iterative process

Dev Acceleration teams are forging a fairly new path.

This practice has been established at quite a few larger companies. It’s now starting to make its way into growing startups that are looking to scale up their engineering department.

There are not a lot of industry standards around how developer experience teams operate and perform. It’s a lot like when DevOps was first becoming a thing.

We know we’re going to make mistakes, but we do this by making small bets and getting feedback quickly. Dev Acceleration teams really benefit from feedback loops. Software is built upon iteration, and Dev Acceleration is no exception. It will take investigation, experimentation, and being flexible to figure out what works.

Dev Acceleration teams will have the main benefit of working so closely with their customers. It’s a rewarding experience and a privilege to see and interact with the devs who are benefitting from your work on a day-to-day basis.

About Jobber

Our awesome Jobber technology teams span across Payments, Infrastructure, AI/ML, Business Workflows & Communications. We work on cutting edge & modern tech stacks using React, React Native, Ruby on Rails, & GraphQL.

If you want to be a part of a collaborative work culture, help small home service businesses scale and create a positive impact on our communities, then visit our careers site to learn more!