The fifth episode of The FOSSA Podcast discusses managing engineering projects. FOSSA’s VP of Engineering and one of our most senior developers join the show to share their experiences and best practices in scaling and managing teams, including gauging success and planning and delegating work.

Note: If the embedded podcast recording is not visible in your browser, you can access the direct link by clicking here.

Episode Outline

  • Introductions
  • Evolution of project management at FOSSA: 1:16
  • Project management in the pre-agile era: 9:54
  • Scaling and managing multiple teams: 14:08
  • Gauging engineering organization success: 24:21
  • Delegating and planning work: 30:29
  • Scaling teams and roles: 38:15

Episode Highlights

Evolution of Project Management at FOSSA

The initial version of project management at FOSSA was working off of a daily to-do list. The next stage began when we hired our first product manager and started trying to formalize project management and began agile ceremonies. Our next evolution happened when we started splitting from one large engineering team into multiple teams and figuring out how to scale project management across teams. With our current approach, there is much maturation in the philosophy of project management. We shifted our focus from the agile ceremonies to understanding why we do a specific ceremony and applying the valuable parts at FOSSA.

Ultimately, project management is an iterative process where teams hone in on whatever works for the organization at that time. It will evolve over time as teams grow and people change in and out and the work that you're doing changes. Teams need to understand the techniques they want to pick instead of adopting ceremonies wholesale because many ceremonies are geared for specific team sizes and configurations.

Project Management in the Pre-Agile Era

Before agile, companies followed the waterfall model and used Microsoft project charts to create a project plan that captured the number of people hours and who worked on each project. But effective project management is more about flexibility and communication than the specific process you're following. For example, early in my career, I was on a team that was using what we today call "waterfall.” But it worked, because development and product met regularly to assess, reprioritize, and rescope the project, almost like a modern agile project.

Scaling and Managing Multiple Teams

The question of how you scale into multiple teams has two parts. The first and more explicit question is internal to the engineering team: how do you organize your team internally?

At FOSSA, we got lucky because our product had a clear and obvious division between the web application and the CLI. So our initial division was to create web app and CLI teams. It was a natural split because the domain expertise, development languages, tooling and deployment models, services, and entry points between the two teams all had a natural separation.

Within engineering teams, a lot of team organization will be based on the shared skills of your engineers in terms of the domain, in terms of tooling, in terms of language, in terms of deployment, and support.

The second and implicit question is how you work cross-functionally with other teams.

While cross-team communication has its own sets of pain, most friction is created because of the slow migration of the engineering team backward away from the customer to be more internal. Because as the number of customers increases, it becomes harder for engineers to be on the front lines of customer contact.

There are multiple ways of splitting teams for teams that do not have a natural divide. But teams have to balance allowing specific groups to focus on certain areas of the product and go deep in terms of their knowledge, experience, and ability to support it versus everyone having to know everything that is not sustainable as you grow.

When the split is made in terms of execution, resolving code ownership is tricky. Sometimes, the most experienced team gets ownership and then they slowly dole it out to other teams as they get pulled into issues. But when these splits happen, it's important to give it time to take effect and not rush to make changes.

Gauging Engineering Organization Success

We can measure small indicators, like development velocity over time and consistent predictability. There are also qualitative measures like feedback from the team and sprint retros.

However, it takes more work at a startup with many people early in their careers to get a good calibration of what high performance looks like. Almost all engineering managers' input signals will be qualitative and intuition-based.

Examples of signs that things aren't going well are if you feel like you are constantly swamped by critical bugs and unable to ship any new features, or you abandon features halfway or build features without getting market or customer feedback.

Delegating and Planning Work

A good way for engineering managers to gauge this is to check if the team's work creates value. Instead of ensuring individual work streams for everyone, how can the team work together to accomplish the right goals? Managers must also train and delegate activities within the team and resist the temptation of taking the easy way out and doing it themselves.

It is also tempting to run your team at 100% capacity, i.e., everyone on the team has assignments that take up all their bandwidth. But the flip side is that as bugs come in, the team will not only be unable to fix them but even triage them immediately. Having a little slack capacity will be beneficial to the team.

It is inefficient and tricky for developers to divide their time between their usual work and bug fixes daily. So, at FOSSA, our on-call rotation lasts two weeks to ensure it aligns with our sprint cycles. In those two weeks, they look at bugs or answer questions on the team Slack channel or talk to customers, and during their downtime, they either address issues in our backlog or whatever bugs them the most during the on-call.

The nice happy side effect is that when you are on the sprint, you don't need to worry about distractions.

Scaling Teams and Adding Roles

One way to think about this is what are the various roles (engineering manager, product manager, project manager, and program manager) in an organization, and when and where do we add these roles within a team?

The engineering manager role focuses on keeping individual developers happy, resolving interpersonal conflicts, hiring people, and doing performance management. This role scales linearly with the count of engineers that you have.

The product manager role is very focused on why and what to build. This role scales with the number of customers and the market size you are trying to build for.

When adding new roles, you must consider where you put them and how you get people to communicate. Teams must watch for scenarios where a person/role passes along the message without adding value.

When a new role is added to the team, it is important to ensure that the other members are responsive to the needs and requests of the new role. Ensuring that there are no points of overload in the team is essential for teams to communicate efficiently to identify and prioritize the right workstreams.

Episode Host and Guests

Sara Beaudet, Support Engineer, FOSSA: Sara is the host of the FOSSA Podcast. They are passionate about cybersecurity, open source software, and helping people explore the world of technology.

Dave Bortz, VP of Engineering, FOSSA: Dave is FOSSA's VP of engineering and owns the company's entire software engineering function.

Leo Zhang, Software Engineer, FOSSA: Leo is an engineer on FOSSA's Platform team, which owns the back-end analysis services that power FOSSA's underlying data platform.