Getting Started with Developer Productivity: Four Engineering Leaders Share Their Advice

Getting Started with Developer Productivity: Four Engineering Leaders Share Their Advice

Developer productivity is a hot topic and it’s seriously no surprise.

In 2023 JP Morgan Chase planned to spend $15.3B on technology. At startups, engineering represents 25% of staff and 31% of the payroll.

No leader wants to be underutilizing that much capacity, especially when tasked with lowering operating margins in this tough economic climate.

But managing productivity can be hard.

According to HBR, an Engineering Manager at Google may have up to 30 direct reports — too many team members to micro-manage. They simply have to focus on creating “the best environment for engineers to make things happen.”

But how do you broach the topic of productivity and the developer experience?

Whether you’re working at an incumbent focused on transformation and modernization or at a disruptor focused on innovation and grappling with growing pains, some challenges may sound familiar:

“Everyone has a different idea of what productivity is.”

“We don’t know what to build or prioritize to better support our engineers.”

“We don't even know where to start or what to be looking for.”

We hear that a lot, too. So we spoke to four seasoned engineering leaders to gather some tips on how to get started, how to become data-driven, and how to harness overall productivity insights.

When should you start investing in developer productivity?

Mustafa Furniturewala is Senior Vice President of Engineering at Coursera, a global platform for online learning and career development that offers online courses and degrees from leading universities and companies.

Mustafa has seen the company grow from 40 engineers to over 300 engineers in the last eight years.

While Coursera had always invested in developer productivity, the organization’s growth proved the tipping point.

“We had a dedicated team once we grew to about 100 people in Engineering,” Mustafa shared.

At Coursera, the developer productivity team was responsible for building a CI/CD pipeline that provided developers with an automated path to production, with a few key objectives:

• Keeping deployment time under 30 minutes
• Maintaining a low change failure rate
• Meeting availability goals

How does Mustafa define developer productivity?

“For measuring developer productivity, it’s important to not look at just one signal but rather have a holistic view that looks at developer activity but also other important metrics like developer satisfaction and the efficiency of flow of information in the organization.”

What is the role of data in developer productivity?

Vitaly Gordon is CEO and Co-Founder of Faros AI, an enterprise software engineering intelligence platform that enables the transformation to data-driven Engineering Operations.

Before co-founding Faros AI, Vitaly was VP of Engineering at Salesforce and the founder of Salesforce Einstein, the world's first comprehensive enterprise AI platform.

At Salesforce, Vitaly was highly focused on the productivity of the hundreds of engineers he managed. And his team knew it.

Passionate engineers would frequently pitch Vitaly a new technology, product, or process they thought Salesforce should adopt in the name of productivity.

“Without data, I could not separate the great ideas from those that were a waste of time. It was overwhelming,” says Vitaly.

Once Vitaly put in place a software engineering intelligence platform for the Einstein group, things changed. When a developer would pitch him a new idea, he changed his approach. Vitaly would say:

“Tell me what problem you’d be solving and what explicitly would improve. We have metrics, we have visibility, we have data. Think it over and come back to tell me which productivity, health, or performance metric would improve.”

That single question proved transformational. “While 90% of the people wouldn’t come back, 10% were serious about their suggestion and did indeed come back with answers. Those proved to be very good ideas indeed,” says Vitaly.

Do organizations have to re-architect their tools and processes to get good data? Vitaly says no.

“Save your energy for driving improvements, not gathering data,” Vitaly advises.

“With a solution crafted around solid data science, you should not have to change a thing. You can get productivity metrics just the way you are today — without introducing friction and overhead.”

How can you measure developer productivity without turning into “Big Brother”?

Jason Selvidge is VP of Engineering at Striim, a supplier of unified, real-time data streaming and integration for analytics and operations.

Jason recommends measuring productivity at the team level and to never use the metrics to compare and contrast individual engineers.

“My goal as a leader is to ensure we’re moving as fast as we can, meaning we’re maintaining our baseline or improving. At the team level, I like to track cycle time, commits per week, and pull requests per week. If we’re dipping below that, I’d like to understand why and help solve the problem,” says Jason.

Since Jason joined Striim, his software development teams have reduced cycle time by 73 percent.

He started with low-hanging fruit, like automated reminders when tasks were stuck too long in a waiting state. Then, he layered in changes to ways of working, like reducing batch sizes.

“To strengthen our culture, I involve the engineers in selecting which metrics we track and how we can improve them. I bring those questions to the team to create alignment on what’s ok to measure. And then I can provide guidance and suggestions on how to improve, drawing on my management experience,” Jason shares.

Jason’s rule of thumb is to devote 5% of your engineering effort to developer productivity, from the very beginning. “If you don’t start early, you’ll accrue a lot of tech debt and you’ll definitely start feeling the pain as you scale.”

Shubha Nabar has built data products and data science teams at LinkedIn and Microsoft. She met Vitaly Gordon at Salesforce developing the Einstein machine learning platform and joined him to co-found Faros AI.

Like Jason, Shubha thinks developer productivity initiatives are about improving day-to-day work for engineers, not policing them.

“Individual metrics can provide pointers for one-on-one coaching and mentoring. But in the dashboards and scorecards I use for reporting and analysis, I like the smallest unit of measurement to be the team and not individual developers.”

Shubha recalls a time she solved an inefficiency for over 100 engineers, which was estimated to be wasting hundreds of developer hours a week.

“I started picking up on low-level grumblings from our team about how long PR merges were taking. When the grumblings intensified, I dug in. The time spent waiting on dependencies and context-switching were really hurting productivity and their frustration was completely justifiable. It pained me to realize how much time was being wasted.”

Shubha figured out the problem and lobbied the SRE team to optimize the merge process.

“If I’d had the productivity metrics I do now, I could have taken action and unblocked my group much sooner.”

Shubha was recognized by Forbes as one of the top 20 women in AI. Now, as Chief Scientist at Faros AI, she’s bringing all the engineering data sources together in a single solution to support business-critical engineering analytics and automation.

Buy or build developer productivity metrics?

Many engineering leaders wonder if they should start by building their own metrics given their customized environments and use of homegrown tools. They also don’t want to be disintermediated from their data by canned metrics vendors, which address only one slice of the productivity equation.

“The buy vs. build paradigm in this case is built on a false dilemma. Engineering software should be buy and build,” says Vitaly.

Vitaly likens a software engineering intelligence platform to payment technology providers Stripe and Plaid, or customer communication and engagement platforms like Twilio. “You buy the things that are undifferentiated for your organization, like the canonical data model, the integrations, and the common use cases, and you use that foundation to build the experience that is unique to your company.“

A software engineering intelligence platform that’s open, extensible, and built with developers in mind can hit that buy-and-build sweet spot.

Mustafa has a similar view:

“At Coursera we [originally] built out dashboards on Sumo Logic that were error-prone and slow,” says Mustafa. “This is where we decided to pilot Faros AI for an out-of-the-box solution that also provided the flexibility and customizability that we need, and we are now rolling it out to the organization.

“We want data about our systems and processes to be easily available, queryable, and preferably all in one place so that data can be a bigger part of our decision-making processes.”

To get started with developer productivity, contact the team at Faros.ai.