Organizing engineering projects for tech leads

From my experience as a TL on a 50+ engineers project in 2021, I learnt a framework of organizing engineering projects that I apply to all other projects I do, big or small.

Agile, waterfall, scrum?

There's tons of software development/project management strategies out there. I hereby confess that I have little idea of what they mean or how they work. Google has generally been wary of committing too heavily on project management. TLs have a lot of freedom on how they organize projects, and program/project managers rarely go deeper into engineering execution.

Delivering a product is a behemoth task involving various functions (product, legal, privacy, UX, operations etc.). In this post, I want to focus on general strategies that tech leads should employ to execute projects.

Where to start?

Let's start when product spec is somewhat clear i.e. product requirement docs drafted, UX spec drafted. MVP (minimum viable product) timeline is clear.

TLs start with direction: Depending on the scale of the effort, a L5/L6/L7 individual contributor (IC) would decide a technical direction (10ft view of new components/systems, philosophies, principles), and build alignment with other senior ICs and management on the approach.

Partner with managers on scoping: Based on the timeline, a rough scoping of the effort is shared with managers. ICs and managers work together to figure out a staffing plan (engineering required per team, loaning from other teams, hiring, etc.)

Designing the execution

It's time to plan out the execution.

Break down MVP into milestones. Define tangible product milestones (with target dates) that can be well tested in isolation by end users. Why?

• It's easier to build stuff incrementally vs whole hog. Conversations can be focused on the immediate milestone.
• It's great for team morale too when they can see tangible progress.

Break down overall system into smaller parts. This is a critical part of TLs jobs. This would later serve as foundation of defining sub-teams during the execution. You can break it apart by systems (vertically) or user journeys (horizontal) –?evaluate both options to see what works best.

• Plan a high level design that lays out interactions between systems. Delegate detailed design of each of the systems to other engineers. For each of the designs, define scope, owners and timelines of when they will be completed/reviewed.

Time for building actual stuff

It's time to implement the designs, integrate systems and test the product. Without going into details of day-to-day (such as stand-ups, tracking tools etc.), here's what I think most TLs ignore, but is important.

Grow leaders. Depending on the size of the group you are leading, you will need to start thinking about hierarchies of engineers. As a TL, you cannot interface with more than 3-4 engineers effectively. Define 3-4 large areas and assign senior engineers to them. These senior engineerings then can be responsible for the next layer of junior engineers.

Know your team. Everyone has strengths, weaknesses and aspirations, based on which you want to assign areas/responsibilities. For example, say, I have a new L4 who doesn't have context of the full system yet. I will assign them on developer testing of one of the milestones –?that will require them to interface with other teams and learn end-to-end while debugging.

Coach and mentor. Have weekly 1:1s with immediate "reports", but bi/tri weekly 1:1s with everyone on the team (depending on the scale). Listen empathetically and provide inputs. Provide context on things happening at your level to the junior engineers.

Plan two weeks, two months, two quarters ahead.

• Set "responsibilities" for next two weeks, with some concrete goal (such as interfaces defined, or part XYZ coding finished). Keep track of progress in stand-ups (daily, twice a week etc.).
• Plan for things that will be happening 2 months later. You may need to scope out a monitoring/alerting plan, a logging framework. You may need to mitigate certain risks (to the timeline, correctness/testability, etc.).

Note that farther the time, lesser the details you need to worry about.

Take responsibility. Some areas and engineers may need more attention than others at different points of time. Know when to step in deeper to help out (pulling in timeline, reducing chaos, helping implement complex pieces). At the end of the day, your goal is that everyone succeeds, but your bandwidth is limited.

Communicate effectively to leadership

• There might be newly discovered risks which may impact timelines. At a regular cadence, do pulse checks on each of the areas with leadership.
• Uplift the hard work being done by the team too. Celebrate the milestones!

In summary...

Designing and executing large scale projects is a great opportunity to acquire not only technical skills but crucial leadership skills needed by tech leads.

These times might also be stressful and uncomfortable. Find a mentor to talk to, build right mindsets, and don't forget that growth cannot happen without discomfort.

Leave in comments how you organize projects and grow teams!

Some other upcoming topics on this blog –?"so you want to be a tech lead?", "principles of mentorship", "building trust", "dealing with organization friction", "writing good design docs".