How can I unblock engineers on the team without getting into the weeds and debugging the issue myself or pair programming with them?

Right now, I create work tickets and add context so engineers can easily pick them up. Engineers will then come to me with technical problems as they get blocked on these tickets, which requires a lot of time from me.

How can I unblock engineers on the team without actually diving into the code with them?

What are the things I could do to get most out of when attending multi day Conference's for example DriodCon.

Appreciate any thoughts about networking and bringing some learnings back. How to digest knowledge through the day usually its all theory heavy. What are the ways to relay and implement some learning in our projects or share with others in the team ?

Right mindset when attending conferences?

Based on talking with engineers working on Product teams, I have good list of projects where we could be spending time. The project themes are mix of improving existing architecture, pain points  vs adopting new technologies, API in the code base.

How can I prioritize the most important projects while also keeping the developers happy by adopting some new technologies?

What are the heuristics to plan the projects for the better engineering work stream?

We maintain a healthy suite of E2E tests, which does catch regressions sometimes before release.

It is hard to keep track of it all manually, but I believe that each time a regression is caught before release, it's overall positive on time spent. Each instance of this happening saves time which would have spent hot-fixing the issue in production if the regression wasn't able to be caught early by the tests.

How can I verify my hypothesis and make sure that this overall E2E testing effort is well-run, impactful, and net positive with engineering time investment?

What's the best way to carry out an end-to-end (E2E) testing effort?

For purely technical projects/platform work, how do you convey the impact to leadership/performance review committee? During performance review, do managers care about the impact of technical projects?

One thing we try to do is treat platform teams as enablers of delivery teams, i.e any platform work should impact product work directly. Sometimes we can quantify direct impact, but most of the time the impact is indirect which is hard to back by data and quantify.

Another angle is that delivery team engineers are the customers of platform team - If we enable them to deliver valuable feature faster and cheaper, we succeed. Again, this is hard to quantify with concrete data.

So my overall question is: How do you link and quantify technical projects like app optimization and performance improvements to direct product and business impact?

How do you convey impact for non-product, technical efforts like adding tests and fixing crashes?

My team spends a good amount of time fixing random/recurring low priority crashes. The goal is to keep the overall crash rate under our agreed SLA. Crash rate naturally goes up over time, so we need to continually invest time plugging up these crashes to keep the overall metric below SLA. 

Is there a way to quantify this in numbers. Maybe we can draw the connection between these fixes and a better user experience that ultimately affects the app users' ratings in the Play Store?

We fix a lot of random/low frequency crashes to meet an overall crash rate SLA. How should I think about impact here?

I improved a complex library integration in our app, which reduced our amount of crashes and memory leaks by X amount. I can pull some concrete numbers from the Play Console and Firebase dashboards to back this up.

However, I'm wondering if the overall business even cares about these memory leaks and crashes. For context, the feature worked fine overall prior, evidenced by the fact that there were no real user complaints about it.

I improved a complex library integration to reduce crashes and memory leaks - Was it worth it?

One of the mobile platform projects I led was to improve X pattern in the app and then document best practices around it so engineers understood this new pattern and continued to propagate it.

My proposed impact is that this promotes consistency in the app's codebase which should lead to faster code reviews and enable engineers to deliver features faster. How do I quantify this?

How do you measure the impact of refactoring your codebase to use a new pattern?

Since the engineer implementing the task went in a different direction from what I had in mind, now I feel like I have to dive into the code and explain the approaches I wrote, and also get involved in the code much more than I would like. How can I overcome this?

I made an eng task with 2 different options, but the engineer submitted a draft PR with a completely different approach.

Recently the app has been having navigation issues. An engineer picked up the ticket to fix these bugs, and I provided the context and starting point. However, they had trouble with it, so I’m checking out their branch and helping them debug. We just want to make sure it’s not broken as it’s a big change. Is this too in the weeds?

I’m not sure if I should be on top of everything - I don’t think it’s possible. Another instance is an engineer working on coroutine migration. Should I be working on it?

How involved should I be as a lead engineer?

Cookpad Inc. is a food tech company. The company operates Japan’s largest recipe sharing service, with 60M monthly unique users in Japan and 40M monthly unique users globally, allowing visitors to upload and search through original, user-created recipes.

Cookpad

Lead Software Engineer

When it comes to building better infrastructure for product teams to ship, there's 2 axes to consider:
- **Broadness** - How many teams does this new infra support?
- **Depth of impact** - For the team who need this new infra, how much does it help them? There's 2 axes to evaluate that that come to my mind:
  - How much it shortens their development time (i.e. increase their velocity)
  - How much it increases their smoothness/safety when shipping (e.g. instead of releasing with an average of 5 bugs per launch, it goes down to just 2)

To make things even trickier, teams are often times not all equal. If there's some team in your organization that has a mission-critical project at the company level, it might make sense to prioritize a project for them even if the solution would only help them.

> adopting new technologies...

I would be wary of this; one of the most common ways I've seen engineer cycles be wasted is with pointless migrations and refactors, which is super common in more mature companies. I think it's really important to understand the exact problem the new technology is solving and push past the "It's more modern" aspect. In particular, I've seen a lot of new technologies show that they're really good at a specific development use-case (which will be touted heavily in their GitHub README or whatever) but struggle at a lot of existing ones.

Generally you can make an existing framework cleaner by spending more effort introducing smart abstractions and modularizing the code. See if you can solve existing problems with these techniques before you bring in a new technology.

Zooming out, it's always nice to get outside opinions on these things. I recommend talking to your manager/skip about your proposal and using them as a sounding board.

Robinhood, Meta, Course Hero, PayPal

Alex Chiou

Senior engineers have proven themselves to be extremely capable at shipping high-quality, complex software efficiently. This collection breaks down how they operate and how you can get to this level too.

What are the heuristics to plan the projects for the better engineering work stream?

Cookpad

Discussion

Cookpad