A week in the life of an Engineering Team Lead

TheyDo’s first-ever employee, Kees van Lierop, gives us a peek into what it’s like being an Engineering Team Lead at TheyDo.

Welcome to the intriguing world of ‘A week in the life’. In this series, we’ll embark on a journey with one of our amazing TheyDoers who will provide an intimate window into their working week. To kick off our ‘A week in the life’ series, there is no better place to start than with our first-ever employee, Kees van Lierop. 

Excluding our co-founders, Kees was the first employee to join TheyDo in 2019. Since then, Kees has been part of our journey as we’ve progressed through seed and Series A funding round stages, growing from four to more than 50 employees. We caught up with Kees to learn more about why he joined, his role, and what it’s like to work at TheyDo. Here’s what he had to share with us.

Why did you join TheyDo? Tell us about your first year here.

Along with the technical challenge, the main reason I decided to join TheyDo was the human support I received from the co-founders. In 2019, I had to be hospitalized after being diagnosed with diabetes. I'm grateful for the support that the three co-founders gave me (they sent a TeaDo support package). It was definitely a testament to the fact that we were building a very human-centered culture.

In the beginning, pre-COVID (2019/2020), when I was working part-time for TheyDo, we were already preparing for a remote-first setup, not knowing what was to come. So when the global pandemic hit, it didn't really impact the way we were doing our work. In fact, it made working for TheyDo much more attractive. When the whole world was trying to adjust to the ‘new normal’, we were in a privileged position to focus on a perfect work-life balance in uncertain times.

During this period, we were transforming the early-stage prototype that TheyDo was when I first saw it at the end of 2018 (running on Wordpress ) into a stable MVP. We were working on many challenging engineering projects, like setting up our own back end system, SaaS platform, TypeScript and GraphQL, and working on our first real-time collaboration features (the Journey detail page). Progress was incredibly fast, because in this greenfield environment we did not really have to 'care' about a lot of traffic on our platform, or complex business logic. We continuously maintained effective and efficient lines of communication and collaboration within our small team.

You recently transitioned into an Engineering Team Lead role. How does it differ from your role as a Senior Engineer?

While I previously allocated 100% of my time to engineering, it’s now about 50%, as the other 50% goes into one-on-one meetings and guiding people through their growth plans. I’m also now the first point of contact in the team when it comes to cycle deliveries and those processes. It's not that we have a hierarchy where we need to directly report on a weekly basis and I'm pretty thankful for that, as I still have the opportunity to do the work that I love to do.

What's the most rewarding part of being an Engineering Team Lead?

It’s especially rewarding when you see that people are happy in their work, and happy to work with you. We’re also introducing career pathways into engineering. I think supporting the team moving through the levels will also be incredibly rewarding.

How do you set your day up as a Team Lead?

I don't plan my days but I do plan my week. Since I've become the Engineering Team Lead, I have fixed one-on-one meetings with my team members that need to be properly mapped in my calendar so that there's no possible conflict. Once these are mapped, I allocate project work to the gaps in my diary based upon the three week cycle. Wednesday is usually the easiest because of the no meeting policy.

Can you expand a little more on the 3 week cycle?

Yes, right before the cycle starts, the team stick their heads together to discuss the capacity and priorities that we have. When we have estimated our work, we'll achieve a consensus on what we can commit to in a timespan of three weeks.

From there we start the work, and from day one that produces pull requests. The frequency changes based on the context of the project; some days we'll submit 10 pull requests, others just one. It depends a bit on the complexity or the size of the project. We also notice the benefits of pair-programming and are increasingly adopting this in our day-to-day workflow.

In week two, we have an alignment session with the team in which we talk briefly about certain opportunities and solutions that we'll focus on in the next cycle. We then distribute the work to individual engineers and make sure that projects get refined from a technical perspective because we need to have that prepared in order to proceed with implementation and realization.

In week three, we should be able to have a clear overview of those initiatives for the next cycle. This includes a better understanding of the efforts required to actually build it, and if it will fit in the schedule for that cycle or if we need to scope it down or chunk it into multiple parts. This happens with all the stakeholders that are involved—with different departments, the co-founders, and even with clients.

After the three weeks we have a one week ‘cool down’. This allows us to work on potential spillovers from the previous cycle, work on engineering-specific projects (one recent example being our front end migration from Vue 2 to Vue 3"), and be best prepared to start the next cycle. This is the invisible work that you can't see but it's very relevant to do for the long term.

What does the code review process look like at TheyDo?

We're using GitHub and everybody who contributes to the code base submits their work through pull requests. We then do code reviews according to the following criteria: Is the code secure enough? Does it scale well? Is it legible? Is it maintainable? These are sets of pillars that we have defined as a guideline in Notion.

We have reached a point where the application has scaled so much in terms of QA, that we can't exclusively rely on manual testing anymore. That's why we are increasingly focusing on getting more automated test coverage.

With TheyDo being remote first, how do you collaborate with your team?

I do see that other companies struggle a little bit with a 100% remote culture. This is more around them lacking understanding of what is expected of them.

In terms of what we do well, I believe that within the Engineering and Product teams we have the right structure and tooling in place. We have Notion, Slack, and Gather in which we find the right balance between how we communicate with each other. We also know exactly when something should be written versus verbally communicated.

I really, really like that this is an async process. We can review or respond at the time that is most convenient to us, instead of having fixed daily or weekly meetings that last way too long and consume a lot of brain power.

What impact will AI have on software engineering?

Obviously, AI is a big thing right now. We've been trying out co-pilots from GitHub, which is sort of like a lever on how to complete your code. For me personally, I feel like it has improved velocity by 5-10%, and that is because a lot of those suggestions need to be edited. It's not as though what it produces is 100% accurate or usable for your use case.

I think the generative part of AI is very strong right now, but it still needs some more work on understanding context. And that is maybe a user-facing problem because I think in order to get the right output, you have to have the perfect input.

What are you looking forward to most at TheyDo?

An engineering milestone will be going to a domain-driven setup. We currently have a monolithic system, and while this works really well for us now, this is probably not the setup that scales to 10, 15, or 20 teams

What sets TheyDo apart from other companies?

TheyDo’s product engineering setup, where engineers own projects and initiatives, stands out in comparison to traditional engineering roles where tasks are assigned to you. As we are still building TheyDo, it’s the opportunity to have a big impact on the product.

It's also got to be the welcoming culture and the most inspiring people you could work with.

For anyone considering a role within TheyDo’s Engineering team, what piece of advice would you give them?

Be aware of and prepared for the product engineering role and the freedom and responsibility that it grants you in comparison to being assigned tasks. I do believe that we offer the flexibility and guidance to get the best from engineers in a way that suits their expertise.