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!
Top comments (4)
Great post Tim! A lot of your experience mirror what we see also at our company.
The Local Development environment is hard to crack I agree, but valuable. We're looking into devpod.sh as a possible bridge between the 2. You can run it locally in Docker-compose or remotely in any environment in the Cloud and its the same syntax as GitHub CodeSpaces.
One thing we recently started doing is embedding some of the engineers on another team to experience what product developers are going through, have empathy and then bring that back to the Platform team.
Looking forward to more of your writing. You have a talent for this! :)
Thanks for the rec - I will have to check out devpod.sh!
One area this would be really powerful is in mobile development - it is very taxing for our engineers to the run the Jobber application + the mobile simulators. It's also a very brittle environment as well; as I understand it, this is not unique to Jobber but seems to plague mobile development in general.
Thank you for your kind words - hope you're doing well!
Great article! It really resonated with me - I work in a similar role (Developer enablement / acceleration / tooling).
It's interesting to read about the similar problems we've faced, especially:
Looking forward to your future posts!
Thanks for your comments!
I think M1+ laptops really changed the game a bit there where "needing" a cloud dev environment wasn't as huge of a sell as before. If the majority of our devs were still on old Intel machines, they would definitely be feeling it and probably want that environment for the performance boost. But now...it's a bit secondary. As I mentioned to Andre above, it's the mobile dev environment where people would want that cloud dev environment for the performance boost AND to have a ready-to-go environment that didn't grow stale.
Flaky tests - we basically ping the committer in a public channel, and when they look at the failure they can see which file failed and which team owns that file. Jobber does a great job of staying on top of the flaky tests!
The prioritization problem is definitely tough. I think it's a fine balance that can't be encapsulated in one framework, and you probably need to tweak your approach as you go. For instance, I felt like we've been so focused on wider improvements that we're taking the next few weeks to talk to all our tech leads and really hear what they're grappling with on the day-to-day.