Aligning developer experience initiatives to business outcomes

This week, we’re diving into best practices for structuring your teams, how to tie your initiatives to programs that drive business growth, and streamlining your tech stack! 

Elliot Graebert, Advisor at Coder, shares his insights and experiences in building teams at Palantir and the need to always tie your programs back to the needs of the business. 

Often, we can get caught up in the excitement of a project, but miss the larger picture. Which is why Elliot details the best ways to handle high and low performers, his strategy around developing new services and killing old ones and the struggles of trying to build an internal developer portal. 

Join us as we discuss: 

• How to set team structures and align goals to business drivers 
• How to drive the developer experience and balance the needs of the entire team
• The tension between building internal tooling or finding an existing solution

Setting team structures and aligning goals to business drivers

“I think it's a huge miss where engineering managers are spending their time ignoring their high performers because they're like, ‘I'll just let them do their job,’ and focus on their low performers.” — Elliot Graebert

Elliot has been around the block when it comes to team building: At Palantir, he grew a team from four to one large enough to need subdivisions — and then further still.

“I learned to make sure that the number one thing that everyone aligned with was business impact,” he says.

Alongside that guiding principal, Elliot starts with the end goal in mind and asks himself two key questions: 

• What does my ideal team look like?

• What is the ideal outcome I’m shooting for?

“It means thinking about where you could give someone a vision statement, some direction and some structure around the things they’re responsible for in a clean way,” he explains.

Once you have those answers, you can ask yourself: How many people does it take to solve that problem, and what kind of people are they?

From there, survey your existing team and determine if there are enough of those people present to form a cohesive unit and kick-start operations.

Driving developer experience and balancing the needs of the entire team

We’ve all heard the saying: You don’t leave a job; you leave a manager. And it holds true across all industries. 

A common way this issue presents is a newer manager hyper-fixating on lower-performing employees and neglecting their high achievers, believing themselves unequipped to add value to said high-performing employees.

“The low performers, at best, go from low to slightly higher. Usually, one out of 100, I've seen go from low performers to high performers,” Elliot says.“The high performers, meanwhile, are like: ‘There were things you could’ve done to help me, but you were never there.’” 

And that’s when they leave.

Elliot's top tips for avoiding this outcome and properly nurturing high performers?

• Never miss a one-on-one
• Always provide feedback
• Ignore any feelings of intimidation

When it comes to low performers, Elliot has a different set of rules:

• Give every low performer one chance
• Write down your feedback and expectations 
• Ensure there is a clear understanding of responsibility

“One of the biggest mistakes new leads make is not writing down their feedback and expectations.” — Elliot Graebert

The tension between building internal tooling and finding an existing solution 

Every team needs tools, but where do you source them from? And when is it wiser to simply build your own?

Some companies come at software adoption with an “if it’s not built here, I don’t want it” perspective — or even thinking “We don't trust anybody in the universe with this but us.” 

One way to weigh your options is to assess how much you have to lose versus how much your vendors have to lose based on what you're sharing with them. From there, choosing the logical option becomes a whole lot easier.

“Our developer team had 120 applications they ran with a ton of different use cases,” Elliot says. “The team was incredible, extremely talented and did a really good job automating all the infrastructure such that we were only spending a little bit each month on those services.”

When it comes to tooling, you have startups and larger institutions, such as banks. On one end, there is room for flexibility and experimentation across multiple tools and software; on the other, it’s more of a rigid, slow-paced environment built for reliability.

Elliot says the ideal structure is somewhere between those extremes. 

“I wanted to incentivize getting rid of old things and standardizing services,” Elliot says. “You grab a bunch of technologies, but you have to crush some things down and refocus it again.”

Elliot compiled a leaderboard of gravestones on a whiteboard, and every time they killed an unnecessary service in an all-hands, they’d clap and cheer for the death of the tool. 

“I was purposely trying to make it so that you get more praise for deprecating a service than creating one,” he says. 

That way, processes stay neat, needed and cost-effective. 

And that’s exactly how you structure a successful team.

‍