50 STASHED IDEAS
I think if you master those three things then you end up with a very happy and productive development team.”
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?"
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.
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
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
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.
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.
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 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?”
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.
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.
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.
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.
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
We needed a way to make decisions as a team that would allow us to:
You should write an RFC if you:
If you see a low participation rate, you team members may be dealing with the following challenges:
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.
These type of leaders ensure that they are the ones to impose expectations and define outcomes. Although it is efficient there are some disadvantages:
These type of leaders take a democratic approach. The essence is to involve team members in all decisions.
These type of leaders focusing on giving tasks to their team. It can be effective, but team members will need to be competent.
These type of leaders transfer something in exchange for their employees work. That could be extra money or an employee benefit.
These type of leaders present a vision to their followers and encourage them to achieve it. They also serve as a role model.
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: