Point Person: Leading Epics at FQ Engineering

At FloQast, we generally divide up feature and product enhancements into epics. An epic focuses on a customer pain point that we want to solve. We also use the concept of a “point person” on my team. This person focuses on making sure the epic is successful and that we are all heading in the same direction.

While technical complexity is obviously a factor in determining the appropriate project lead, this role is not limited to only the most experienced engineers and rotates with different epics. I found it empowering that even as a newer engineer I was given the opportunity to learn and grow in this way. These are some of the important lessons I took from my first experience leading an epic at FloQast.

📚 TL;DR

When I first started writing stories for the epic, I found myself deeeeeep in the weeds.

I had gathered a lot of useful information about the changes needed, how we might build the features, and dependencies to be aware of. The project scope is usually more broadly covered in the engineering requirements document (ERD)… so what about the nitty-gritty implementation details?? This felt like context my team could really benefit from and who doesn’t love a good Jira novel?

Fortunately (for everyone), my manager introduced me to the Gherkin style of story writing which led to much clearer and simpler messaging. There are a multitude of ways to achieve the same outcome so it’s important as the point person to be adaptable, open-minded, and keep it simple. 

🤝 Share Ownership

I personally feel a lot more engaged in my work when I have ownership and creative freedom over the process. There’s a desired outcome but there’s flexibility in how I get there. I can honestly say that all of the epics I’ve been a part of at FloQast have been led by engineers that fostered this atmosphere… it’s almost like we’re hiring really good people 

When these engineers were leading as point person, they empowered me to be a part of decision making, share my perspective, and feel comfortable asking the “dumb” questions. They encouraged me to take on tickets that I was intimated and challenged by, even if it meant velocity would temporarily take a hit. When I needed support, they brainstormed and pair programmed with me, setting aside their own work so that I could progress in mine. Being in the presence of these types of people ultimately produces capable leaders across the team.

🌎 Macromanage > Micromanage

Despite having this frame of reference, I naturally still encountered some growing pains in my first experience as point person. On the surface, things went really well, but not without some internal struggles along the way.

🚨 Warning: we are about to embark on a journey into the human psyche 🚨

As someone that always strives to be helpful, it’s a fine line before you find yourself in helicopter parent territory.

For me, this can mean overextending myself and offering to help when I don’t have the capacity. It can also mean not delegating enough because I don’t want to overburden anyone else or (cringeee) relinquish control. It probably doesn’t come as a shock that a lot of this stems from a fear of failure, fear of being seen as unhelpful, maybe some FOMO. And the list goes on…

While I’d like to think this only negatively impacts me, this can create bottlenecks and inhibit team understanding. It’s important to be mindful of these tendencies and their broader implications. This awareness encourages me to seek support when I catch myself trending in this direction.

📍Find Your Channels

Identify the appropriate outlets and tools for communicating with stakeholders early on in the epic. My team often dedicates a slack channel to the epic (i.e., #project-name) to streamline communication. This has been especially useful on larger cross-functional projects with multiple engineering teams, product managers, and designers. Using a central channel ensures that context is accessible and all relevant stakeholders can contribute to the discussion. During the project, this gives everyone a central platform to ask questions, raise issues, and communicate status updates. Customer-facing teams also use the channel to share real-time customer feedback, influencing how we invest in the product going forward.

💡 Helpful Resources

• Writing Engineering Requirements Documents – ERDs
• Managing scope: A practical guide to user story splitting for agile teams
• Writing user stories with Gherkin
• Ways to approach technical story writing
• Increasing Predictability for Software Estimations

Kelli Budd Holland

Kelli is a Software Engineer at FloQast and has prior experience in Accounting. Kelli enjoys exploring the PNW food and music scene, hiking, and geeking out on distance running.