The CTO vs Status Quo series studies how CTOs challenge the current state of affairs at their company to push it toward a new height … or to save it from doom.

Teach taking full responsibility for delivery

At the end of our call, Boyko humbly asked to note he’s not a preacher. 

He had no doubt in the rules of alignment that Payhawk has, but cautioned us what he and his teammates follow might not work for other companies.

You see, Payhawk announced a valuation of $1 billion just 5 years after its founding. That was some proof the company has a really sharp strategy.

Our curiosity won — we had to look inside.

Boyko shared how a couple of clear-cut statements helped Payhawk’s engineering build up faster than other fintechs in a now shrinking market with 34% less funding (S&P Global Market Intelligence, 2023).

He feels that:

• product domain expertise wins over technical expertise,
• full-stack engineers who can deliver an end-to-end product accelerate delivery,
• engineers should not wait for permission to code in another team’s base,

Carry on to discover what Payhawk does to keep its employees laser-focused.

About Boyko & Payhawk

Leadership structure & comms

Eric Ignasik: Thank you for doing this interview, Boyko.

Before you co-founded Payhawk, you climbed the development ladder. I’m sure you had the drive to be better than any manager you’ve met.

Which alignment practices you knew you wanted to introduce that were missing or not cared for at your previous workplaces?

People at Payhawk tell me that, from their experience, the best individual contributors aren’t always the best managers. I’d like to counter that because — just in my opinion — the best managers are definitely top-performing individual contributors.

Some technology leaders argue that you shouldn’t remove a well-performing engineer from the team to make them a manager. Then who am I going to make one?

And yes, it happens that great individual contributors can’t manage well.

But for me, it’s unreasonable to assume that someone other than one of the most valuable engineers could be a suitable boss.

Could you tell us how Payhawk’s structure works for aligning departments?

Our Engineering Leadership Team has me, the Chief of Staff, and the Engineering Directors. Each Director is accountable for a product domain and works as the People lead for their team.

I just don’t put “People” in the title, as managing them is integral to the job.

Below the Engineering Directors’ level, we have engineers with no formal structure per domain.

We are pretty homogeneous as an organization because Hristo, our Co-founder and CEO, introduced what we call “PayhawkOS”, which is our internal operating framework created with Notion. 

PayhawkOS lists meetings, processes, documentation, strategic decisions, and what’s in the internal system.

With PayhawkOS, any employee can easily track down what happened and why it happened. If there was a meeting, you can see who took part in it and what was the outcome — if the data is not sensitive.

The idea is to allow employees to understand what other teams or departments are doing. 

By using PayhawkOS, we try to have the same practices all around. Whatever you’re working on at the company, you feel informed.

There are some deviations from what’s in the operating system, but we are aware of them and try to keep things as standardized as possible.

Also, for the Executive team to approve a process for Payhawk, it needs to meet our requirements.

A department that wants to add a process to PayhawkOS must define its meeting types and their cadence, the tools, and choose its administrator.

Michael Sols: Could you please explain what a product domain means for Payhawk?

For instance, we have spending management, which our customers use to set maximum monthly budgets for managers and teams. And there is also the domain of ERP integrations, which covers everything in the product that’s required to make it work.

Then, there’s expense automation. This domain is responsible for automatic data extraction, so users can simply upload an invoice and record a transaction without manual work. 

Accounts payable is another domain our platform has a service for, which is responsible for purchase ordering and bank transactions.

Every product domain has its own front and back ends and infrastructure. 

We like to have an eye on a direct competitor of a domain, which might be one product of another company or a single service. 

So if there’s another solution for, let’s say, accounts payable, our Product Domain Owners compare it to ours.

Payhawk’s services help businesses like State of Play integrate their finance management into one platform. Source: Payhawk’s YouTube

Eric Ignasik: Hristo, Payhawk’s CEO, you, and the hard-working staff formed a company now called Bulgaria’s unicorn.

I know Payhawk uses a valuemap instead of a roadmap. Can you list all methods that help Payhawk’s employees stay aligned under one strategy?

The Executive team prepares a strategic brief that explains our area of focus for the upcoming year.

We have a roadmap, but it’s more like a bucket of things that can be done.

We have seasonal planning every three months, which helps all departments align. The meetings are actually prepared for the entire year ahead.

During seasonal planning time, directors adjust their plans in line with the brief at specific meetings.

Like, there is a “roadmap roast” meeting at which we evaluate items for implementation. Commercial directors are there to give input on the deals they’ve been losing and what’s important for closing new deals. Customer success takes part to explain what the users are missing.

After seasonal planning, each Product Domain Owner decides what their team should implement to support Payhawk’s strategy at smaller meetings. 

They ask engineering to provide estimations. And based on these estimations, Product Domain Owners decide what gets prioritized.

Code bases as hotels

Let’s look at working with departments that silo themselves away and become inefficient. How does Payhawk prevent that from happening?

I think that PayhawkOS really does the hard work. Like, whenever you need to collaborate with another department, you log in, see who could help you, and understand how your project fits with their objectives.

We also have an interesting approach to engineering. Product Domain Owners are responsible for the features or the code base in their area, but their assets are not isolated. Whatever we build, we see it as a part of one product.

When you need to implement something new, you’ll likely have to touch a code base outside your product domain.

And I see companies where one product team submits a ticket for another to get something done. This is not how we work at Payhawk.

Everybody’s responsible for delivering their feature from start to finish. Engineers can code in the base of another product domain team without waiting for a green light. 

When you own something, it’s not your job to build a wall around it. It’s your job to be a good host for other engineers and to ensure they have everything.

If your code is messy or you think it will be hard to rewrite, you should act like the code owner and review each pull request. Every engineer we have follows this rule.

Sure, reviews take their precious time, but I see them as a top priority. You can’t say, “I’ll do this tomorrow,” because you’re blocking someone.

But you can also prioritize testing and expanding the documentation of your base until you can say, “I’m confident in my code. I don’t need to review every single pull request because making changes in my code base is safe.”.

But note this is what works for Payhawk, and I wouldn’t recommend this approach to just anyone.

Still, it seems the code ownership approach works for Payhawk. I’m curious if there are any other practices you’d be willing to try out.

I read about Spotify’s engineering process. They allow each team to choose their own technology and that makes them very fast, which is great.

But what’s bad is that their engineers can’t contribute to other product areas of the product that easily. Spotify’s teams probably operate like different companies.

I can see the benefits of Spotify’s chose-your-stack approach. But it comes at a cost — just like what we’re doing.

At Payhawk, everybody has the context and can do their job without being disrupted. Still, maybe we’re not that fast sometimes. It’s a clear trade-off.

As a Co-founder and the CTO, you have a deeper understanding of what different departments do.

Could you tell our readers what the Executive Team, Product, and Engineering need to agree on to keep the company profitable?

Well, that’s a tough question. We have some assumptions about which features would be most valuable to users. 

During our high-level discussions with the Executive Team and Product, we go over recent market changes, share our assumptions, and give feedback on the strategic brief.

I have never seen any strong disagreement because we trust people in specific roles to discover and prioritize what to deliver.

Engineering Directors don’t have a strong opinion of which feature we must build over the other, so we rely on what Product Domain Owners bring to the table. 

Other than that, we don’t really have that many touchpoints with the Executive Team or Product.

Still, Engineering has a lot of touchpoints with Customer Success to work on the entire user support flow.

If first-level support can’t solve a ticket, it goes to engineers. Our basic economic agreement is that engineering should scale with the size of the product.

If the product grows in features, so should the engineering department because it will have to deal with dozens of extra tickets.

The delivery mindset

Where in the software development life cycle do you see the most problems that are caused by miscommunication?

If you consider it as a funnel, the risk becomes smaller as you move towards release.

Of course, the costliest mistake in development would happen earlier, perhaps during roadmap discovery. Building a huge feature nobody wants is the biggest risk.

But even when roadmap discovery goes well, the next big risk waits during product discovery. The team must know what can be done to ensure the software delivers the potential value as promised.

And how much do you think the engineer should understand the commercial value of a product they’re working on?

Depends on the approach. As I said before, Payhawk ensures everyone has the right context. Maybe this sometimes comes at the cost of efficiency.

If someone’s job is just to code buttons, maybe they can make a thousand per day. But that’s not that valuable to us.

For us, being very knowledgeable about a specific technology is not important. What’s way more important is to know the product domain you’re working on and the user value it creates.

All our engineers are full-stack. 72 of them. I personally think this is the only possible option.

If people are really full-stack, they can own development, from reviewing requirements to deploying to production, and provide outstanding support afterward. If we removed this process, we’d lose a lot.

I wanted to ask about integrations. For the companies we’ve worked with, integrations can be a major blocker that disrupts ongoing projects.

For instance, Engineering might have to turn down requests for a month or two because of their workload.

How can Technology Managers minimize the impact that integrations have on other departments?

When Payhawk connects with external service providers, it’s very strategic for us to have a single point of contact responsible for one integration. 

It’s especially true for providers delivering technology for functions that are critical to our product’s success.

In such cases, a bunch of people take an interest in what an integration can offer. And they can overwhelm engineering with tickets and ongoing communication.

It really helps for a single person in-house to orchestrate an integration project. Then, you always know who to chase.

If that coordinator is on leave or sick, they should also choose someone else as a point of contact.

I also believe you shouldn’t be going to a support agent on the provider’s side, as they might not be responsive enough.

We don’t like to have external code in our code base. I mean, when I see the provider’s name in our code, this is usually a red flag.

They might have a different code base and processes to what we have, and building agnostic products is important. 

And we’d know because we changed payment providers multiple times.

Michael Sols: So if you have PayPal’s code in your base, then somebody has to manage that bit, right? And it’s added work. Is that also a problem?

Imagine your code base integrates with PayPal. If you need to switch providers, you need to fix quite a lot of things all around. That’s an unnecessary dependency. 

A Technology Manager has to really be strict about isolating external code.

So, as an example, Payhawk issues cards. For those cards, we receive transactions through the services of many different providers.

But for us, integrations are not a blocker. We implement one adapter, which is like a separate process for the transaction of this provider, and it translates the data into a format that Payhawk understands.

Tomorrow, if we need another integration, we’ll build another adapter.

Good to remember

Eric Ignasik: That explains it — thank you for elaborating. Lastly, I’d like to ask — what are your three golden rules for co-founders and CTOs that would help them create a better information flow at their organization?

I believe you should always remain an individual contributor. 

At first, if you’re responsible for the product end-to-end, you should be taking on its most important parts. But once the organization matures, the situation reverses. 

You should at least go into implementation to share your insights on how the code works, what is blocking an organization, and what’s missing from the product.

You can’t get this information just from speaking to people. You need to feel the pain.

Of course. I also believe the best insights come from doing the heavy lifting.

Resources

In our recent interview, Ben Brown, a CTO of a British company called Flock, recommended a book titled “Team Topologies.”

It presents a model for shaping an engineering team’s effective structure, culture, and interactions.

I mostly read articles and short pieces of information on specific blogs. 

But yes, I have a high-level recommendation that teaches a lot about providing value, which I think is most important. It’s called “Atlas Shrugged”.

You need to make sure you contribute in a space where your contribution matters most. That’s the main thing. Otherwise, it doesn’t make sense.

What’s next? Three actions for CTOs to take

This discussion with Boyko revealed that Payhawk’s cultural norm of reporting in a Notion-based “OS” might be critical for aligning all departments.

Still, it’s a big, top-down initiative that might not be present in some organizations. 

But the concept might be that one step is worth replicating first, as being uninformed is a recurring problem for employees.

To test Boyko’s rules for alignment:

1. Set an example of self-reporting in one source of truth, such as Confluence or Jira, by doing it yourself or through engineering directors or team leads,
   
2. Introduce the concept of an open code base with one official admin for one development, and see how this could be scaled into a team or department practice,
3. Consider restructuring the team to train or add full-stack engineers or ask for end-to-end deliverables to increase product domain expertise amongst people in the department.

And before you go, remember this one mental trick. Just because you’re already doing something doesn’t mean it’s done well.