A glimpse at an Engineering Manager’s life at PayFit

I started my position as an engineering manager at PayFit a year ago.
Before that, I used to juggle between a manager role and a tech lead role in a small startup, a position where I learnt and grew a lot.

Although I had gathered some knowledge through readings and interviews, I was not very sure about what would be my daily contribution as an engineering manager in a scale-up context.

After a year of intense growth aboard this ship, I finally feel ready to share some aspects of the daily life of an engineering manager at PayFit.

Team

Product team organisation

At PayFit, the Product organisation is an adapted version of the Spotify model with tribes, squads, and chapters. Each tribe is led by a Product Director, a Design Director and an Engineering Director. At PayFit, this trio is called the tribe’s Triforce.

Inside every tribe there are squads that are in turn led by a squad triforce: a Product Manager, a Product Designer and an Engineering Manager. You can find a detailed description of the product organisation in this article by PayFit co-founder Florian.

My experience with the triforce

So I’ve been working hand-in-hand with a product manager and a product designer for a year now. Together, we define our squad’s vision, build our features and contribute to the development of our squad’s strategy.

This means that the three of us share the responsibility of:

• building a roadmap for our squad (composed of engineers),
• setting our objectives and key results, in agreement with our tribe’s and company’s objectives,
• aligning with other teams’ triforces to anticipate dependencies and to mitigate risks,
• handling every aspect of the product lifecycle, from the discovery to the monitoring.

In these tasks, we are supported by many: our squad’s engineers of course, but also other teams: Product Ops, Design Ops, Data, Product Marketing Managers, etc.

There are no hierarchical links between members of the triforce, and each of us reports to a different director of the tribe we belong to: I report to the engineering director, the squad’s PM reports to the tribe’s product director, and the designer to the tribe’s design director.

The impact of the triforce

Let’s dive into what I feel are the major benefits from having such a trio at the head of each squad/tribe.

Convictions and decision making
Every member of the triforce can focus on a few specific aspects at a time and rely on the other members to handle other aspects. We diverge and take the time to dig deep in every field (design, product, engineering) then converge to build convictions together.
During my first weeks, making decisions on urgent matters was much easier with my triforce around. I really felt supported and guided until I could bring my own vision to the balance.

Three is the perfect number
We challenge each other a lot and benefit from our differences to spot edge cases when we build the product, to add new ways to learn from our customers, or to define the level of performance for our services.
Having to align the three of us before taking actions helps us invest energy on mature ideas. Debates are also often good opportunities to gain expertise on our product.
Moreover, we manage to break silos by discussing different aspects of the product: the customer delight, the go-to-market strategy, application’s performance, and much more.

Shared learnings
We offer each other the possibility to define our roles and change them when needed depending on circumstances.
For example: In my triforce, I participate in the discoveries and user interviews because I appreciate being close to the end-user. The product manager attends our engineering weekly reports about bugs or service-level analysis because he is interested in it.

All triforces do not work exactly the same, people can adapt their roles depending on their squads’ needs and their own ambitions.
I had the opportunity to grow as an engineering manager but also to get out of my comfort zone from time to time and defend our roadmap or prepare a feature rollout.

This model works very well so far. However, I think it remains efficient as long as we limit the team’s size and the number of different scopes that we own.
Our triforce relies on 5 brilliant engineers who report to me. This leads me to another aspect of the job: managing people.

People Management

This is the part of the job that was almost totally new for the tech lead that I was. It is now the most gratifying part for me. It is also the one where I learnt the most about myself, my strengths, struggles, and my patterns of communication depending on the personalities I interact with.

I have weekly 1-1s with every team member, a great moment to be closer every week, to grow empathy toward their work, passions and ambitions, and also to exchange feedback and  continuously learn from each other.

Coaching

One of our main values at PayFit is Humility.
We all want to grow and learn, and we’re all coachable. Being able to listen to every team member, to understand their concerns and motivations and to give them feedback is essential in my role.

Before joining PayFit, I was already familiar with feedback models that are clear and impactful. I had enjoyed reading "Radical Candor" from Kim Scott, which helped me understand that giving constructive feedback is all about caring.
I was also concerned about managing a team I did not hire, how I could get to know them and help them grow. I read Julie Zhuo's book "The Making of a Manager", which gave me a diversity of ideas about preparing 1-1s depending on the team’s size and state.

After joining, I could benefit from the workshops and the training that the People team organised, around how to receive and give feedback, how to manage as a coach, and the Process Communication Model.

With these tools, combined with my passion for psychology and personal development, I was ready to be close to my team, to understand their way of working and communicating, and to adapt my communication to their own need for growth.
Of course, everything does not always work out smoothly by the book. I am learning every day about my own biases, and every new team member joining with their own personality helps me learn more.

It is essential to manage performance and achieve real progress. This is done by setting clear goals with the team members, and explicitly sharing the expectations with them from one quarter to another. I do this during our sprint retrospective, or during individual 1-1s.
I also see it as a requirement to work with every engineer on their professional evolution, through the lens of their career path.

Team stages

Every team goes through several stages of development: Forming, storming, norming, performing. And, if it comes down to it, Adjourning – but we haven't come to it, luckily.

In each stage, the team’s needs are different, and my role as manager has to adapt:

• When the team is forming, my role is to create the psychological safety for people to get to know each other, recognize their skills and roles in the team and explore the scopes to absorb the knowledge.
• When the team reaches the storming stage, it is much more complicated and energy consuming; the team members confront their ways of working and argue more, we can observe less progress and more questioning of the missions and the processes. I am still learning as a manager how to be the most useful at this stage, encourage more shared leadership and push conflict management methods.
• Then comes the norming stage where the team is more confident, happy and productive and the performing stage where the team is even more proactive, offering support and showing autonomy.

Working at a scale-up like PayFit, where we have hyper growth and recruit a lot, is a great opportunity to challenge my skills during these stages.
I learnt how to acknowledge them and adapt, and I still figure out new tips every day. It is also my role as a manager to think of a strategy of growth that does not put the team in a continuous storming stage.

Recruitment

Recruitment is an important part of the job.
Choosing the right person to join the team is never an easy task.

The first thing I did on the topic, together with my team, was to set up a kickoff meeting:

• We listed the exact skills we needed for the team and if they are compulsory or nice to have.
• Then, we decided the steps of our interviewing process and created score cards for it.
• Finally, we ran the whole interview as a simulation with one brave team member and we shadowed the process to be able to have enough empathy with the candidates.

Once the process was ready and approved by the whole team, we were ready to receive candidates. We then got the support from the great Talent Acquisition team for sourcing.

During the hiring process at PayFit, a candidate meets almost the whole team, and each interviewer gets the chance to assess different skills.
Interviews are designed to be inclusive and reduce any potential biases. Hiring managers are trained at PayFit against their own biases and the process is made of panel interviews with 2 interviewers most of the time.
In my team, we also avoid giving exercises as homework to the candidates in order to be more inclusive.

After the recruitment, it is my role to assign a buddy to the new PayFiter (we call them "Paybies"). This buddy is a colleague who will help the newcomer succeed in their first missions and embrace PayFit’s culture.

Tech management

I stopped coding when I joined PayFit.
In fact, I don’t get the chance to read code except for very few code reviews. I know, it sounds sad. But I have the chance to manage a full team of 5 great engineers who are very good at it and do not need my help at all.

Some engineering managers still find ways to code regularly – they are often with smaller teams, with the position of Team Leads. Hence, depending on the team’s size and the triforce’s responsibility, some managers code on a regular basis, others don’t.
However, even if we don't all code, all EMs do system design with their teams, build the tech strategy, and make sure to see it adopted.
We also prepare our features beforehand by solving tech dependencies and mitigating risks. Along the way, we all keep learning and testing new things.

When I was a tech lead in my previous experience, I often found it very challenging to find the right balance between having the big picture in mind (anticipating potential issues, recruiting, challenging the status quo, working on a plan for the tech debt, etc.) and rolling up my tech sleeves (focusing on one development at a time: coding, testing and delivering).
I sometimes coded during the week and longed for the weekend or a day off to find enough time to think outside the sprint and the list of tasks we committed to doing.
It was in a very small company and the very dynamic (and amazing) tech team owned the whole product: we did not have to worry about alignments with other teams, about capacity planning, about complex architecture. Yet it was hard to find that balance: code, or step back to think a little.

Today at PayFit, we are a dozen of engineering teams that collaborate on the same product. This means much more time spent on alignments between teams, a bigger need to define and adopt an engineering strategy, and also a closer attention to the software architecture to make sure our features are loosely coupled and scale correctly.

With all this, meaning the different aspects of people management, my work with the triforce, and my participation in the daily rituals to manage delivery and production, I guess you’re no longer surprised that I don’t code anymore :)

Paradoxically, I have learnt more engineering concepts in this last year than I expected, particularly in software architecture, domain-driven design, and monitoring services performances.

To keep growing in our roles, engineering managers share knowledge through bi-monthly syncs, mentoring and very cool initiatives such as book-clubs.
On a personal level, I try to get more and more involved in the team's technical life. I believe that understanding the stack and knowing the delivery circumstances in details help better understand any potential time-to-production issue.
It is also a way to understand the skills that are missing in the team and encourage more learning and mentoring in specific fields to help the team grow.

Onwards!

So, this is how I defined my role this year.

I am sure it will still evolve depending on the situations I’ll face. It is also probably very different from some other engineering managers’ daily work at PayFit.

In any case, my hope is to show that your role as an Engineering Manager is not set in stone, and that your expectations about your daily tasks can greatly expand when in the right organisation.
To me the Triforce at PayFit was a breath of fresh air, and I can't see myself moving back to something less collegial.

Header photo by ThisisEngineering RAEng / Unsplash.

Illustration for Tuckman's Model of Team Dynamics taken from Scott M. Graffius.