Engineering Leadership


"I generally say developers want to do three things... They want to solve hard problems at scale. They want to see that hard problem when they solve it... get put to use! The third thing that I think, honestly, is they just don't want to work with jerks.

I think if you master those three things then you end up with a very happy and productive development team.”

Devin Turner (@datsquire) - Profile Photo



Engineering Leadership

Engineering metric examples

So I think that some of the important metrics that we look at to get to the right answer are again, things along the lines of how quickly can a developer get an environment? How quickly can they get tests written? How quickly can they get a build deployed? How quickly can they get that code merged? How quickly can they get things out the door?

Metrics aren't about measuring productivity or grading someone.

What has to happen is you have to ask yourself "If this team is not as productive, Team A is not as productive as team B... what's in Team A's way? What can we do to help them? Are they having trouble writing tests? Are they not getting the regression paths that they pass as they need to through the test suite? Are they having an ID that they're using that doesn't integrate well with our backend systems? Is there something else there that's slowing them as they go through this cycle time to being productive?"

If you're measuring and managing engineering teams by metrics, I think you're missing the point. Metrics can give you information about the car you're driving, but they don't drive the car.
Maker Time

I'll give, I'll give you an example. Here at Slack, we had a... pattern over the past year where people were not having enough time to sort of spend time to actually doing coding. And when we actually went back and surveyed our developers, they were saying they didn't have enough time to do "deep thinking."

So we actually devised something we call "Maker Time" here at Slack. This is an example of what we did. And we said I think it's Tuesday, Wednesday, Thursday, Friday for three hours in the morning for all individual contributors, no meetings. Full stop. Like schedule time around that.

Jerry Li: Are the managers accountable for improving metrics to create a better environment for developers to be productive?

Allan Leinwand: They're not responsible for improving their metrics. There's no judging of managers based upon the metrics. There's judging a manager at based upon the product they produce or the infrastructure they're rolling out or in the developer productivity team, the tools that are produced to help that.

Origin of a Platform team

With growing pains, software entropy kicked in and product developers had to manage several cross-cutting concerns along with their feature work and timelines.

We need to solve problems holistically to handle multiple teams and applications instead of just the projects at hand

Team formation questions

But what does improving the platform really mean?

It is too broad of an avenue to chase after and what we need here is direction and focus. To help answer this, start with these three simple questions

Platform Goals

What are our key focus areas?

With this, we list down key goals that help achieve our overarching mission. These goals help provide much needed focus, that in turn translates to identifying the right avenues to tackle.

“The secret to becoming a 10x engineer is to help 10 engineers around you to become twice as productive .”
Code Governance

Define best practices and architectural guidelines . Advocate and enforce them via tooling, reviews, documentation. Provide coaching, participate in slack discussions and help engineers deliver high quality code.

“No idea is true just because someone says so. Test ideas by the evidence gained from observation and experiment. If a favorite idea fails a well-designed test, it’s wrong!”
Controlled Experimentation

Whenever we identify promising approaches to any problem, it’s encouraged to try them out through POCs, review results afterwards and make choices accordingly. Key features should always be AB tested and analyzed before complete rollout.

How? — Platform principles (values)

How do we operate?”

We now define our core values and operating principles that help set the right culture and mindset in our team.

We should know why we are doing what we are doing and the impact it brings to our developers. Now ruthlessly prioritize our short-term goals and activities so that they support our long-term vision.

Always be asking “Is this absolutely necessary to do?”

Collaborate Openly

The platform we build is our product and teams we support are our users. We collaborate like an Internal Open Source (aka Inner source) Team. We do not want any one person or team making decisions on how we solve problems for all teams. The key is to share your plan with teammates and encourage open feedback and suggestions through design reviews or other communication channels.

Platform level problems

TLDR; Scaling teams are hard. A platform team done right can help ease the hardships.

At Conde Nast International we grew from a team of 20 engineers to less than 100 in less than a year. We found out that building out a system that will be used in many markets has a lot of moving parts and repetition. For example rebuilding the infrastructure and application configuration. Adding third party add-on software. Building the application using CDN redirects. DNS registration and configuration.

Platform Authority

The authority of the platform team lies not in the enforcement of standards. But in the subtle steering of the development team into one decision or the other.

Accountability as a team is important to make sure that whenever the team is making a breaking change the rest of the teams are informed.

Blameless post mortem is a requirement to make each of the member feel safe to make changes. Building a better system at the same time taking ownership of the system.

  • vendor management
  • pipeline management
  • git and scm
  • observability (logging monitoring tracing)
  • soft skill and people management
  • collaboration with other teams and negotiation with the management
  • common workflow and architecture management
  • security
  • developer training and teaching
  • documentation development

Having a semi flat structure with multiple senior and principal engineer that could make agile decision is recommended. Also having a big team like this with many moving parts would mean that a technical lead role is unsuitable rather having a engineering manager for platform and solution architect is essential.

Making decisions in a bubble = 🤬

In the process of building our apps I received a private Slack message:

Why was the data dashboard built using React if our front-end stack is based on Ember? — a not very happy front-end engineer

  • 💀 I didn’t know we had added a new tool to our stack. 😳
  • 💀 Other team members who should’ve known about it, didn’t know either.
  • 💀 Someone made an important decision on behalf of our entire team, but the team wasn’t included in it.
  • 💀 No one, including myself, appreciated the surprise.
Goals of an internal RFC

We needed a way to make decisions as a team that would allow us to:

  • enable individual contributors to make decisions for systems they’re responsible for
  • allow domain experts to have input in decisions when they’re not directly involved in building a particular system
  • manage the risk of decisions made
  • include team members without it becoming design by committee
  • have a snapshot of context for the future
  • be asynchronous
  • work on multiple projects in parallel

You should write an RFC if you:

  • are building something from scratch. New endpoint, component, system, library, application, etc.
  • the need rewrite has crossed your mind
  • will impact more than one system or other team members.
  • would like to define a contract or interface between clients or systems.
  • are adding a new dependency.
  • are adding or replacing languages or tools to the stack
  • are in doubt of whether you should write one

If you see a low participation rate, you team members may be dealing with the following challenges:

  • 😵 They have too much going on.
  • 😱 They are not interested.
  • 🔨 Tools used for process management are not providing them great UX.
  • 🕰 They may need better personal time management.
The newbie tag enables psychological safety

As a team, we agreed that any comment or proposal tagged with [newbie] indicated that its author was coming from a vulnerable place. Whether motivated by lack of expertise, context or confidence, this tag allowed for us to make mistakes while knowing we were in an environment of psychological safety , that was supportive of learning for both senior and junior members.

We’ve found RFCs increase visibility into who is making decisions in a system and has helped managers identify situations where trust issues are preventing ICs from making decisions.

Authoritarian Leadership

These type of leaders ensure that they are the ones to impose expectations and define outcomes. Although it is efficient there are some disadvantages: 


  • Mistakes Reduced
  • Creates consistent results
  • Reduced time in making decisions


  • Lack of creativity and innovation
  • Group input reduced
  • Reduces synergy
Participative Leadership

These type of leaders take a democratic approach. The essence is to involve team members in all decisions. 


  • Increases employee motivation and job satisfaction
  • Increases employee creativity
  • High levels of productivity achieved


  • Communication failures can happen
  • Can be time-consuming
Delegative Leadership

These type of leaders focusing on giving tasks to their team. It can be effective, but team members will need to be competent.


  • Creates a positive working environment
  • Can take advantage of your employee's skills


  • Hard to adapt to change as people have specif task designated to them. 
Transactional Leadership

These type of leaders transfer something in exchange for their employees work. That could be extra money or an employee benefit.


  • Motivation increased if tasks are mundane
  • Employees feel rewarded


  • Lack of creativity and innovation
  • No empathy
  • Creates more followers, not more leaders
Transformational Leadership

These type of leaders present a vision to their followers and encourage them to achieve it. They also serve as a role model. 


  • High value on relationships
  • Employees are motivated and inspired
  • High value on a vision


  • Constant feedback is required
  • Tasks can not be pushed without the agreement of employees
What Leader Do You Want To Be?

Remember that all these leadership styles have their advantages and disadvantages. It is important that you do not try to mimic one or the other because none of them is perfect. 

Ask yourself these three questions to find out what leadership style is best suited for your team and organisation: 

  • How much time do I have to make a decision?
  • Are my team creative or innovative? 
  • What skills do my team possess?

© Brainstash, Inc

AboutCuratorsJobsPress KitTopicsTerms of ServicePrivacy PolicySitemap