Leveling Up My Manager Skills

I’ve been working at PSPDFKit for seven years now, which means I’ve experienced many changes in employees, teams, and products. I’ve been the team lead of the Core team for about five of those years, but my transition into that role was something that happened gradually and naturally, and not as the result of a big leap into management.

The Core team is responsible for dealing with all the technical details of PDFs and implementing the low-level features required by other teams. In other words, all the code we write and maintain is included in all the PSPDFKit SDKs, and it forms the foundation of them.

Historically, the Core team has always been small in size, and due to the expertise of its members, we’ve always managed well without too much “traditional management.” Everyone on the team has always known what to work on and how to do it without needing me to direct their work or micro manage them.

A recent big investment from Insight Partners means PSPDFKit is growing at a larger scale. This, in turn, means more products, more people relying on our team, and more coordinating between projects.

As a result of these changes, I decided it was time for me to level up as a manager. While I’ve been a manager for some time, I mostly worked as a contributor and let the team manage itself. But I know that as the company grows and my team potentially grows, I should have more official processes in place.

Managing a Team? That’s Scary! 😱

I have to admit that getting more involved in a management role was initially a little scary to think about. I’m used to just commenting on GitHub issues and writing code. I’ve never been a big “people person,” and spending lots of time managing project boards and Google documents didn’t sound like a good time to me, because it takes away from time I could spend developing our product.

However, the more I thought about it, the more I warmed up to the idea. I do enjoy a new challenge, and the idea of expanding outside of my comfort zone started to sound intriguing. I also knew I had a good team that would support me and help me out, and that I could get whatever help I need from the CTO and other managers at the company. I recently became a first-time dad (it’s a rule to mention the baby any chance you get 👶), so perhaps that change in my life made me feel more comfortable taking on even more!

Setting Some Goals

The first question is: Where do I even start? Well, I have a few initial goals:

1. Making sure the members of my team have as little stress as possible and generally enjoy their work.

2. Having a better overview of the various projects we have going on.

3. Keeping other teams happy by giving them good estimates on when something is done and being able to notify them if there are delays.

I’m well aware that there’s more to being a good manager than this, but I have to start somewhere, right?

From Goals to a Plan

Seeing as I’m not the only person managing a team at PSPDFKit, the first thing I did was look around and see what other teams are doing. The Core team is in a rather special situation, as basically everyone relies on us, but I was sure other teams have similar goals.

The first thing that got my attention is that our Server and Services team (responsible for the great Server and API products) was using sprints. This seemed like a great way to slowly introduce some management!

Because all my colleagues are super nice, Arek, the Server and Services team lead, immediately agreed to give a presentation on how his team does sprints, what works well, and what issues they’ve encountered.

With this new information, I made a new plan and presented it to my team for feedback. It was received positively, which assured me I was on the right track.

From Plan to Execution

We’re a small team of senior engineers — which makes us think we need less planning than we really do. But we still didn’t want to introduce too much overhead.

So we decided we wanted to do a light version of sprints. I’ll maintain the backlog, and every two weeks, we’ll come together for a sprint planning meeting where we’ll go over what happened in the previous sprint and talk about what we’re going to work on the next two weeks. We’ll try our best to not modify the sprint tasks, but we also have to realize that sometimes, important things that we have to work on will pop up (or as Arek nicely put it: Here be dragons).

For now, our plan consists of:

• Daily Today and Out for Today messages. They tell us what people are working on and what they achieved — kind of like a daily standup.

• Weekly Monday hangouts. These usually only take 20–30 minutes, and we try to keep it very casual. To be honest, they’re mostly for team bonding.

• Two-week-long sprints, with a one-hour-long sprint retrospection and planning meeting every second Friday.

• Quarterly feedback sessions between me and each team member. This usually consists of an hour-long call where I ask everyone to prepare answers to a couple of questions and give them the opportunity to ask me whatever they want.

To be fair, we mostly did all of this already — the only new thing is the sprints.

At PSPDFKit, we often do our best work when we do something incrementally: We start with something, see how it goes, and adjust as needed. This is also how we plan to treat the sprints. If two weeks is too long, we may try one week. If the sprint meeting isn’t long enough, we’ll extend it. If sprints just don’t work for us, we may try something new. It helps dramatically to have good communication with the people on your team, and I always try to get as much feedback as I can.

With all these things in place, I think we’ll have no problem achieving the above-mentioned goals. Sprints should reduce the stress on the team members, as we can all decide on how much we work in the coming weeks, and the workload is (mostly) fixed. Fewer surprises, less stress. I’ll also have a much better idea what the status of any given project is; I’ll see the sprint progress, and I’ll also see the daily “standup” messages, which will enable me to communicate clearly to other teams if there will be any delays.

Of course, there’s also quite a bit of work that’s more specific to me, including:

• Keeping up with what all the other teams are doing, and if something requires work from our team, adding it to our task backlog.

• Looking at new customer issues and trying to prioritize them correctly.

• Positioning myself as the “support person” on the Core team. If something pops up unexpectedly, I’m going to try to handle it myself first, so that other people can have as much uninterrupted work as possible.

• Always being ready to answer questions and trying to unblock people as quickly as I can.

Conclusion

I’m not sure if I have a conclusion yet. I wrote this blog post directly after we had our first sprint planning, so the outcome is to be determined. But I’m excited to be on this journey and hopefully become a better manager for the people on my team as our company evolves beyond being a bootstrapped company to one that’s expanding at a rapid pace. I know I’ve still got a lot of work to do, but I’m very motivated to get going and make everyone’s lives as easy as I can and hopefully demonstrate our core values through my actions.