Looking for resources on increasing your team's / peer's productivity

Ah, this one is an interesting - Folks usually just ask about their personal productivity. It's great to see you trying to level up your team! So aside from sharing Taro resources with your peers (talk to your SDM about expensing it), here's some ideas:

1. Review pull requests faster - Of course, you can control this individually: If you review your teammates' commits faster, they will land code faster. At a broader level, you can try implementing a 1-day turnaround SLA for code review feedback across your team. Maybe create a communal code review meeting at the end of every day or something so everyone can pitch in to fast code reviews together. Here's some more resources to help there: [Taro Top 10] Code Review
2. Implement a no meeting day - From what I've seen, this is either Wednesday or Friday. At Meta and Robinhood, it was Wednesday. No meeting days are so important for doing deep work, and I wrote 80% of my code on no meeting days. We talk in-depth about this crucial productivity lever here: A Powerful Tool For Software Engineer Productivity - Focus Blocks
3. Do better system design - At a massive FAANG company like Amazon, it's much better to be proactive instead of reactive. If you feel like some of your teammates' past launches could have gone better, this is a culture you can try championing. Follow the advice and process from my course: [Course] Frontend System Design Masterclass - Building Playlists

If these don't work, let me know by replying. Happy to brainstorm more. The fact that you're thinking about this is a good sign of SDE 3 mentality!

Adding on to Alex's great points, you need to debug productivity first in your team. Where are engineers spending most time, what takes forever, what are the most annoying tasks. You can just ask engineers and you'd be surprised at the number of ideas you'll get.

But, in my experience, there's a few obvious culprits

1. Too many meetings: engineers don't know which ones are useful to them, organizers don't know why a meeting exists etc.
2. Too much firefighting: that's a reliability issue in your systems. Much harder to solve, but a long term problem to solve.
3. Too many interrupts: other teams, or team members are asking ad-hoc questions that interrupts flow. Might want to sheath your engineers from these incoming requests via office hours.
4. Unnecessary bureaucracy: too many processes to launch a simple thing, or get access to logs, etc. Stuck in getting approvals, writing docs, creating presentations etc.

Happy debugging! Let us know how it goes

It's awesome to see this kind of initiative from a team member!

The existing answers are tactical and great for general time management. Here are some points that come from the perspective of the bigger picture:

• What are the motivations of your individual team members and leader? A teammate's motivation is the source of their productivity, and understanding them can help you help them find their role and responsibility on the team. People are motivated and feel rewarded by different things (e.g. money, achievement, team camaraderie and support, etc.). The core problem of building a great team (or improving the team quality) is how to align the incentives so that the team is driven both individually and collaboratively to achieve a certain outcome.
• What are the pain points of the DX (developer experience)? Identifying and ranking these will help you figure out what the important problems to fix are. There are an array of things that could be improved here. Some examples:
  • The team spends a lot of time fixing critical bugs.
  • Build times are slow
  • There exists repeated manual operation.
  • Test coverage is low.
• What are missing gaps in technical knowledge? Each teammate's skill lies somewhere on a spectrum and some people care to grow it while others don't. As a teammate, identify and filling gaps through knowledge sharing can make a surprisingly big difference to team velocity.