Developer productivity: It’s not speed vs quality

The nuances and complexities of technology pale in the face of human sociological webs and intricacies. Such details can prove even more challenging than technical issues — when we involve human functions, solutions are not as cut-and-dry as updating a piece of software.

That’s why it takes people like Hazel Weakly to iron out a people-first approach for platform teams. By focusing on building effective teams, streamlined infrastructure systems, and the proper set of tools and automation, Hazel has helped multiple companies improve how they build their products. She knows how to strike the balance between the social and the technical.

What makes for a balanced development team that can build and grow efficiently? The answer is simple, but not always easy: Trust.

‍

How to gain the trust of your development teams

Gaining trust starts with understanding who is on the other side of the connection. Who am I speaking with? What are their goals? What brought them here, in this role, at this company? How can I support that in a way that benefits all involved? 

“Developers want to do good things. They want to make an impact, help people, and do what they need to do for the company,” Hazel says. “If you remove barriers that are in place for no real reason, and you enable developers by asking what they need, and give them that, it turns out that works really well.”

‍

Platform needs and budget at 5, 15, and 50+ engineers

Systems scale with company size — this is not a revolutionary fact. However, knowing when to scale and adjust processes can feel daunting. Timing is a pivotal factor in successful scaling. How does a company determine when to bump up a level? 

Level One: A group of five

“You need to invest in ratio,” Hazel says. “For platform engineering, infrastructure, for that area in general, if you have five engineers or so, that's about the number of engineers everyone can sit in the Zoom chat and program as the quintessential in-my-garage startup mode.”

A company generally will not need a high level of infrastructure in the five-eight range. Doing so could create an overly convoluted structure that hinders instead of helps. 

“If you have five people, everyone can know everything,” she continues. “You don't even need documentation, you don't even necessarily need to have a font or strategy or what have you. You talk to the other people, and you come to an agreement.”

Level Two: A group of fifteen

At fifteen employees, that is no longer the case. A company likely will not be able to get by with a single manager without them feeling overworked and spread too thin, which contradicts the people-first model we're focusing on.

“Maybe you don't need an infrastructure person, but you need expertise,” Hazel says. “The reason for that is because now, because you have multiple teams and multiple silos of information, you can't fully synchronize everything.” 

Lack of infrastructure at this size can lead to missed context around deployment, missing documentation around operations, and, in turn, a lack of understanding at an engineering level when it comes to feedback and implementation, plus how it impacts the customer.

A company will not have that complete feedback loop unless they intentionally build it.

Level Three: A group of 50+

“50 engineers is that threshold which a lot of companies have a misstep because they're in the middle of hyper-growth,” Hazel shares. “If you've seen the hyper-growth trajectory for a lot of startups, they go from 15 to 75 or 80 engineers in one year. It's a really common path to skip 50. But 50 is the inflection point.”

At this level, it makes sense to have someone dedicated to infrastructure and development, whose entire job is to help everyone be more efficient. 

“The first person that you hire for developer tooling will grow to become the person that helps build the internal platform. You don't have an internal platform yet,” she continues. “But if you don't have that key hire by 50, you're too late, and you're going to need to play catch-up.”

Playing catch-up is only acceptable if a company plans to play catch-up due to company priorities. A brand should not reach 150 employees with no plan for infrastructure, SRE, or infrastructure-dedicated personnel.

About 10% to 20% of an engineering budget should always be on infrastructure, even from the beginning.

‍

Best practices for addressing socio-technical issues in your teams

One crucial element of people-first processes comes down to measuring developer experience vs. developer productivity. If a company focuses solely on productivity, the social nuance is lost and, with it, the opportunity for improvement at a foundational level.

“The strongest indicators of developer productivity come from developer experience, and the area in developer experience that they come from is ‘How happy and satisfied and whole do developers feel working on the system?’” Hazel says.

Think of development like a garden. If developers enjoy working on the garden and it’s beautiful and healthy and makes them feel at peace, it’s a good quality system. That isn’t typically something one can measure through numbers. 

From Hazel’s perspective there are a few best practices for addressing socio-technical challenges.

Best Practice One: Flow

This practice pertains to asking developers meaningful questions such as:

• How are you feeling? 
• Are you experiencing interruptions?
• Are you staying energized?
• Are you motivated?

Best Practice Two: Context

Find out how much knowledge developers have to carry around in their heads that are not directly related to the problem they’re currently solving. If they write a piece of code, do they have to think of the entire system? Or, can they simply run a test suite? How can we lessen that burden?

Best Practice Three: Feedback

The quality of responses is paramount in this loop — not ticket velocity, not quantity — but rather focusing on whether these developers are completing meaningful work. Speed is only as effective as the direction efforts are aimed. Measuring speed without meaning leads to getting places we don’t want, quickly.

“Can you empathize with other developers? Can you work with them? Can you understand where they're coming from, and see what they need? And, then, can you get the buy-in required to get that accomplished?” Hazel continues.

Developing a well-rounded mindset that balances the social with the technical marks the difference between smooth-sailing infrastructure and demotivated developers. Tend to the experience, and productivity follows.

‍

Interested in learning more about sociotechnical solutions and leveling up DevEx? Listen on Apple Podcasts, Spotify, or wherever you find your podcasts.

‍