What It’s Like to Work on the Engineering Team at Possible Finance

 Tracie Hlavka, vice president of engineering at Possible Finance, has a unique approach to leading a team of software engineers. 

She doesn’t believe in setting goals just for the sake of having them. She doesn’t see labor-intensive status updates as the best indicators of how a project is going. And she pushes back against bringing in a big class of new hires all at once. 

Her reasoning? None of those things create a sustainable or successful team. 

Instead, her recipe for success comes down to three things: context, clarity and change.   

“I want engineers to understand ‘why’ they’re being asked to do something,” Hlavka said.

That’s why Hlavka aligns the team around six-month OKRs and “problems to solve, not projects to build.” To track progress, Hlavka uses tools that provide a holistic view of the problem. And when asked to onboard new hires for the year all in one quarter, Hlavka opted for a more sustainable pace. 

“I pushed back,” Hlavka said. “A third of the team was already new and I knew that adding too many people too fast would overwhelm our onboarding capacity and dilute the culture we were building.”

Hlavka made the case that one to two hires per month was the right pace. 

“This reflects how I think about management generally,” Hlavka said. “It would have been easy to say ‘yes,’ hit a headcount number and deal with the consequences later. But clarity means being honest about tradeoffs, even when the answer isn’t what people want to hear.” 

Hlavka added that the software team still has its sights set on a 50 percent growth this year.  

“We’re just doing it at a pace where every new engineer can actually be successful,” Hlavka said. 

Built In spoke with Hlavka in detail about how she guides the engineering team toward success while minimizing chaos. 

 

Engineering Leadership and Team Structure at Possible Finance

In your current role, what — and who — do you lead? 

I’m the vice president of engineering at Possible Finance, a mission-driven fintech working to make financial health possible for everyone. I lead five software engineering teams, with two dozen engineers, growing to three dozen. My core focus is building a high-performance engineering culture where engineers can do their best work. In practice, that means two things. First, creating a learning-focused culture. When everyone is getting better, the team gets better, which leads to higher-quality systems and career growth for the people building them. Second, relentlessly focusing on what makes shipping faster: clarity about priorities, a bias toward finishing what we start, investing in infrastructure that lets us move quickly and finding and eliminating bottlenecks in our development lifecycle.

 

What three words best describe your leadership philosophy?

Context, clarity, change. I want engineers to understand why they’re being asked to do something. That context leads to better decisions at the keyboard. I believe most management failures are really failures of expectation-setting, so I prioritize clarity and when something goes sideways, I look at my own clarity first before anything else. And I want an organization full of people driving change: improving themselves, their teams and our systems, where everything is an experiment and we’re always willing to try.

 

How Possible Finance Approaches Engineering Hiring and Team Growth

Share a recent decision that reflects your management style.

When we started planning for growth this year, there was pressure to compress our full-year hiring plan into Q1. I pushed back. A third of the team was already new and I knew that adding too many people too fast would overwhelm our onboarding capacity and dilute the culture we were building. I made the case that one to two hires per month was the right pace, even if it meant growing slower than leadership wanted. This reflects how I think about management generally. It would have been easy to say “yes,” hit a headcount number and deal with the consequences later. But clarity means being honest about tradeoffs, even when the answer isn’t what people want to hear. We’re growing by 50 percent this year, which is still aggressive. We’re just doing it at a pace where every new engineer can actually be successful.

 

How does your team celebrate wins or recognize contributions — formally or informally? 

We have a quarterly company-wide recognition program tied to our cultural values. It’s peer-nominated and each quarter a few people are recognized per value across all departments. It’s a nice way to celebrate the behaviors that matter, not just the outcomes.

 

 

What Day-to-Day Engineering Work Is Like at Possible Finance

How do you balance short-term delivery with long-term vision?

I think about this differently depending on where a product is in its lifecycle. When we’re exploring a new idea, the only thing that matters is time to first learning. How quickly can we find out if this idea is worth building? I have an old rule: We’ll hack something in once to see if it works, hack it in a second time to prove it’s real and the third time we’re asked, we build it for real. Sometimes the business decides the feature isn’t worth the cost of building it properly and in that case we should just stop doing it. 

On the codebase side, I prefer biting off refactoring as we go rather than one big rewrite. Any long-lived codebase has many versions of “current best practices” scattered across it. So if a project is touching some piece of code, I like to include the work to bring it up to current standards as part of that project. You can’t do it every time, but if you do it most of the time, the code gets better steadily without ever needing to stop the world.

 

 

How do you set goals for your team and track progress?

I’ll be honest: I’m not naturally a goals-for-goals-sake person. I’m more about being clear on what’s next and doing the thing in front of you well. We set OKRs every six months and maintain a stacked rank list of problems to solve, not projects to build. Product leads that prioritization with input from across the business including engineering. The actual projects we work on tie back to those problems but may shift in order based on what’s ready, who’s available and where dependencies exist. 

For tracking progress, I’ve never loved gathering status. Everyone wants to know exactly what they need to know exactly when they want to know it and they want to do no work for it to happen. So I lean into tools that make it lightweight. Linear’s project status feature gives a nice picture of progress when projects are structured well with milestones and weekly updates are low-touch to write. We’re also starting to use AI to pull status across Linear, GitLab, Notion and Slack so we spend less time chasing updates and more time acting on them.

 

How the Engineering Team at Possible Finance Uses AI

What excites you most about the team’s roadmap for the next year?

We’re in the middle of the biggest change in software engineering since the internet, maybe since the PC. Each engineer can have so much more leverage than at any point in the past and that’s only accelerating. We’re growing the team by 50 percent this year and every one of those engineers will increasingly have AI agents working alongside them on our code. What excites me most is what this means for the people on my team. Engineers who spent most of their careers hearing “no” or “not yet” now have a much wider scope to figure things out. Product developers can move up the stack and deliver more features faster. The constraints are shifting and I get to help a team of smart people figure out what’s newly possible.

 

How are company-wide goals and team expectations communicated and reinforced throughout the year? What helps employees understand where the company is headed?

We run company-wide all-hands meetings every two weeks, which keeps everyone aligned on where the business is headed. I also recently started a monthly engineering all-hands to talk about direction specific to our team. Beyond that, I do skip-level meetings with every engineer on the team. Those are partly about giving people a direct line to ask questions, but I also use them as an opportunity to connect the dots between our overall direction and the work they’re doing day to day. I find that context sticks better in a one-on-one conversation than in a slide deck.

 

 

Frequently Asked Questions