Principal Engineer Role at Catawiki (A Personal Interpretation)

Catawiki introduced a new Growth Framework at the end of 2021. For the Tech department, one of the newly defined tracks is the extension of the individual contributor track beyond Senior Engineer. Previously, the only way to move up was through the Engineering Manager track, but now it’s possible to grow to Principal Engineer, and potentially beyond.

NOTE: Our growth framework currently defines six Individual contributor roles for engineers: Engineer, Senior Engineer, and Principal Engineer, all of which are subdivided in two levels of seniority. The framework leaves space outside this range as well. Since we don’t have other roles beyond Senior, our Principal Engineer role currently comprises all roles that are usually referred to as ‘Staff+’, and go by many different titles in different companies.

This new track seemed like an interesting path for me to explore. At the time, I’d been working as an iOS developer for 9 years in the industry, almost 5 years of which at Catawiki. For 3 years, I’d also served as Platform Lead for iOS, which meant I used 50% of my time to focus on the technical foundation of our iOS app, to organize meetings, and keep track of our technical backlog and plans. I was basically helping to keep the iOS developers across our teams aligned on our technical goals, and serving as a point of contact for others in the Tech department to ensure our technical roadmaps were aligned with what was going on elsewhere in the company. In doing so, I was already ticking some of the boxes defined as competencies for principal engineers.

I decided to start the conversation about becoming Principal Engineer with my Engineering Manager and our VP of Engineering — and mid 2022 I got the opportunity to take on this new role.

Yay! But what now?

Until then, most of my knowledge of the role was based on the high level competencies in our Growth Framework, and insights I got from conversations with my manager and VP. I gathered I shouldn’t see the new role as a simple continuation of my Senior Developer role. Instead, my new role would be considered part of tech leadership, and part of the job would be to figure out and communicate to others what we should be working on. Also, I was one of the first Principal Engineers, and we were all still figuring out what the role meant for us.

This was quite an overwhelming place to be in, so together with my managers I decided to start off with a couple of things:

1. Handover my current work, both the platform lead role and my ongoing product work to free my hands.
2. Use this freed up time to investigate this new role for myself: What does it mean for me? What can the company expect from me? How do I make sure to be successful at it?

For me, this personal investigation was crucial. I noticed quickly that staff+ engineer roles can be executed in a wild variety of ways, changing per company, or even within a company. Therefore, my goal was to not design a blueprint for the role at Catawiki, but rather guidelines for myself, and perhaps inspiration for others in the same role.

This article is the result, so far, of this investigation. It serves as my personal guide of how to act within the company, and as a guide for other Catawikians to know what to expect from me. I expect to be revising my guide in the future, since my focus and scope might change, plus I might learn that some guiding principles serve me better than others.

Investigating the Principle Engineer Role

During my investigation, the difference between being a Senior Engineer and a Principal Engineer became ever more apparent. As a Senior Engineer, I would also incorporate a number of the principles I list below, but from a different perspective, and usually much more implicitly. I think the fundamental difference between a Senior and Principal Engineer is the explicit notion of having a leadership role. This makes specific aspects of the work much more important, and pushes some other aspects to the background. Whatever you’re going to solve, will not be just code. In other words: a staff+ engineer is not simply a more senior Senior Engineer. It’s hard to make this very concrete, but I hope other readers of this document will understand once they read it.

For a long time, there were many angles and ideas floating through my head, and I didn’t know how to summarize it to something workable for me and shareable with others. Eventually, after much reading, some discussing, and thinking, I noticed that some high level themes kept coming back, regardless of the specific context. I decided to try and distill these themes into Principles, and structure my thoughts around these.

I split the document into three parts: Principles, How I Contribute to Catawiki, and Practicalities. In the Principles section, I will explain the guiding principles for me on filling my role as Principal Engineer. In the second section I will get more concrete about what this means for Catawiki, and what can be expected from me. The last part will cover some practical things, such as the tools I use that help me do my job.

My inspiration for this document largely comes from the book ‘The Staff Engineer’s Path’ by Tanya Reilly (Goodreads). I encourage every engineer to read it. There’s so much relevant information in it — I’m still digesting it and it really resonated with me. Furthermore, I read several articles, and had a number of good conversations about the topic with my managers, VP, and other Principal Engineers inside and outside of Catawiki.

Principles

Although it was very hard for me to distill a proper description for my role, I did see a number of recurring themes throughout my exploration of what my role should be, so I captured them as Guiding Principles — ten in total.

Be an Example

My way of working (how I communicate, approach and solve problems, etc.) will be noticed by others, especially given the visibility of my role. So I should be aware of this in my choices, making sure my actions reflect the company values.

Enabling Others

A large part of my work is aimed at helping others and the company grow. The work I take on should reflect this: multiplying my invested time by enabling smoother, faster, and higher quality development, as well as a better customer experience. This can be on a product level, platform level, or through personal growth. This leads to some guidance for picking up work:

• If someone less senior can also do the work, then it’s my job to delegate and help them do it better. To quote Michael Lopp: “If someone else would get a B for a job you’d get an A for, help them get an A.”
• If no one else can do it, but it also doesn’t enable others, then I’ll see if someone else can do it with my help.
• If no one else can do it, and it would enable others, then it’s a potential high priority project for me to work on.

Code as Principal

I think that for me as Principal Engineer, it’s still important to write code. It helps to keep my skills fresh and being able to relate to issues the other developers might be having. Most likely, I won’t be writing much production code, since most of that work can probably be done by others as well, and presents less of a growth opportunity for me. Most regular coding will come from proofs of concept, experiments around new tech, digging deeper into the stack, building reusable layers, and writing scripts to make tedious tasks (for developers or myself) more efficient.

Be Deliberate

Because I’m seen as an example, because my time is a sparse resource, and because people will be looking at me for decisions — I need to make sure to be deliberate in my actions and decisions. I should be a little careful when posing ideas and thoughts publicly, as they might be interpreted as a decision already made. I have to make it explicit what people can and cannot expect from me, whether I will take on a project or not, and what is expected from others at what time. Also, I should not leave pending decisions hanging. This also applies to my time and focus management: I have to make deliberate and realistic choices for myself about what to spend time on and what not. If I decide to take on a new project, I have to consider how and where it will fit my schedule, and if not, if I should drop another project for it.

Take the Time Needed

In order to make informed decisions, I should become comfortable taking time to properly investigate the subject matter, while communicating the status. It’s important I don’t jump to conclusions too soon. I need to make it clear to people that pressure to get a decision or certain result in a hurry, can lead to less optimal outcomes — which end up being expensive if taken on a level where decisions have many trickle down effects. Then, the consequences of my actions will stick around for a long time down the line, both positive and negative. As an effect, this means getting comfortable with delayed gratification: many projects will run for months before I can see the benefits and get a feeling of accomplishment, which is harder than celebrating quick wins. Also, the trickle down effect has the consequence of delaying gratification. Of course, the pitfall would be to postpone too much: perfection is the enemy of good.

Get, Give and Share The Big Picture / Context

A crucial aspect of being able to make good decisions is to keep the big picture in mind: what are the long term company goals and vision? Here, it’s vital for me to understand the proper context, and share it with other stakeholders to make decisions and agree on the way forward.

Document

Documentation for documentation’s sake can do more harm than good. But for many of the abovementioned topics, documenting is a vital part of improving. Writing down visions, plans, and decisions helps a lot in enabling others, and driving future growth. As a large part of my work will not be actual coding, documenting will take its place. So I have to be comfortable writing documentation like RFCs (Request For Comments), get input from the right people, and share results with the right people. At the same time, it’s crucial the documentation will not be the end station — it should be the starting point of actual changes, like new features, improved architecture and new ways of working. If not, my work will not have many benefits.

Drive for Commitment

A significant part of successfully finishing projects and having impact with my work through its implementation, is to have backing from stakeholders. This has many facets. I need to make sure all relevant stakeholders are involved in the decision, both from higher levels in the company, and lower. Ideally they all believe in the path forward, but at the very least should be willing to commit to it — even if they disagree. Some important guiding principles here:

• Ensure sponsors: if higher-ups believe in the project, it makes many things easier.
• Radiate intent: Make sure decisions won’t be a surprise, and be transparent about what I’m working on and the direction it’s heading.
• ‘Nemawashi’: ensure that by the time of decision making there’s already a consensus of opinion. Check with decision makers if they agree before the decision making meeting. Adjust if needed.
• Consensus is nice, but not at all cost. If people disagree but still can commit to the decision, that’s usually good enough.
• Work on a compelling story to sell it.

Lead the Way

In addition to all of the above, the Principal Engineer is expected to lead the way forward on a technical level. This means keeping in touch with the latest developments in the field. Therefore it is important to reserve time on a regular basis to read up on blogs, talks, etc. to get inspired about developments that are potentially beneficial for the company, and to share it internally. It can also mean sharing insights outside the company, and leading the way for the developing community in general.

Find the Problems to Solve

Most often the focus of the work will be finding the problems that we as a company, department or domain should solve — rather than actually solving these problems. Design and implementation should most often be handled by other engineers as this is their growth path as well. Overseeing the quality and timeline of such solutions is something both Principal Engineers and managers should do.

One tool to help figure out what problems to solve is reframing: to move away from the solution space and take a different angle at what the actual problem is (Thomas Wedell-Wedellsborg — What’s Your Problem? (Goodreads)).

How do I Contribute to Catawiki?

Given the above mentioned principles, what can other people in Catawiki expect from me as Principal Engineer? I’ll elaborate on projects within my focus areas, mentoring, keeping up to date with developments in the field and within the company, BAU (Business as Usual), and occasional interruptions.

Focus Areas

In addition to the general guiding principles, I select my projects based on a couple of focus areas, where my expertise can be of most use. This doesn’t mean projects have to completely fall under the focus area, but preferably they overlap at least partially.

I focus mostly on the native mobile experience and development, because it matches best with my background. I’m including both Android and iOS, since there’s a lot of overlap in high level goals, functionality, opportunities and limitations. There will always be room for differences between the platforms, but I think in general it will be most efficient to consider solutions for both platforms. It will also be beneficial for both platforms to have a principal engineer covering their domain, so there won’t be too much discrepancy between the attention one platform gets over the other.

Most of my time will go into projects covering these focus areas — roughly three days a week. This time will be mostly spent on focused work (writing, reading and coding) and I try to plan larger consecutive blocks of time for it. Besides that, there will be project-specific meetings, discussions, and other tasks required to successfully complete these projects.

Mobile Strategy

Mission: Develop a consistent long term vision for making the Catawiki Mobile apps and development experience world class, plus creating strategies on how to get and stay there.

Activities: Projects related to the future direction of mobile development within the company, such as future vision, architecture, quality control, and how the mobile apps relate to other parts of our ecosystem.

Examples: Writing a mobile vision, future for APIs consumed by mobile, strategies on how to support real-time updates on mobile clients, strategies for deep linking, or the role of hybrid solutions.

Partners: Mobile developers, especially the mobile Platform Leads. In most cases also other parts of the engineering leadership (Engineer Managers, other Platform Leads), product management, UX.

Mobile Product

Mission: Profit from the mobile platform strengths in the best way possible, across our product.

Activities: Driving technical decisions in the Ideation and Discovery phase of large and complex product projects that focus on mobile-specific features, or with a significant mobile component. Investigate problem space, potential solutions, create Proof of Concepts, write RFCs.

Examples: Supporting mobile-specific features like Widgets, Camera, Live Activities on iOS, and tablet experience. Also potentially features that benefit mobile use cases.

Partners: Product Managers, UX designers, Teamleads/Engineer Managers, Mobile developers from the relevant domain teams.

Mobile Tech

Mission: Speed up development processes for individual (mobile) devs, through improved tech stacks, processes, tooling, insights, documentation, etc.

Activities: Drive or advise on projects that improve the quality of life for mobile developers. Creation and review of RFCs in the mobile tech foundation domain, create Proof of Concepts to figure out good improvements. Occasionally write part of the foundation code. Look for opportunities to align platforms.

Examples: Writing an RFC for a new view architecture and how to migrate to it, tooling for generating code health stats, improved test tooling (automated or manual), setting up a process for dealing with localisation, investigating improved app security, and improve the way Customer Support Agents can assist users having a problem with our app.

Partners: Mobile Platform Leads, Mobile Developers, sometimes also other parts of the engineering leadership or other departments (Marketing, Information Security, Data, UX Design, Localization, CX, etc.).

Mentoring

Besides leading by example implicitly, I will also assist less senior developers explicitly by becoming a mentor for a number of mentees. My aim here is to help others grow their skills to the next level, making them more successful in their current role, or their next one. This way I think I can assist in the continued growth of our developers.

My aim is to spend a couple of hours per week mentoring. Besides providing an opportunity for growth to others and the company, this will also help me become a better and experienced leader.

Staying Up to Date

As defined in the Principles, I like to stay up to date with what’s happening in the field, and also what’s happening at Catawiki. This will make it easier for me to see new opportunities, shift gears if needed, for any active or future project in my focus areas. It also allows me to share relevant news with others if not specifically relevant for myself (such as platform leads, mobile devs, engineering leadership).

Sources for this: various internal (Slack) channels where people from the Engineering and Product teams share plans and upcoming changes, literature and blogs on (Staff+) engineering, online forums, conferences, videos, and more.

Business as Usual

Of course, I will encounter ‘business as usual’ during my work. Currently, I spend around 2 days per week on this, and I hope to bring this down to 1–1.5 days per week, to free more time for project work, mentoring and keeping up to date.

BAU for me exists of: meetings (1:1s, company meetings, team and platform meetings), code reviews, admin (emails, Slack, keeping track of my hours, planning my week, writing out meeting notes, etc.) and investigations (small things like checking out potential bugs, answering questions about the code from others, writing a ticket, discuss a smaller decision to be made). Interviewing efforts also fall into this category, as well as occasional training sessions.

Interruptions

For me, interruptions are requests by others that are scoped in time and effort, but are not regular things, and do take more than 1–2 hours. I try to keep this bucket to a minimum, but also want to be flexible to take this on occasionally if needed. For many of these, I will take into account the availability of others: if others are available, it might be better if they do it, depending on complexity and opportunity for growth. I’ll always make sure the scope from my side is defined as well as possible before working on it, and the priority warrants me stepping in.

Examples: putting out fires (production issues, failed releases), larger investigations with high priority, helping out a team short on capacity, semi-regular things like end-of-year peer reviews, etc. I aim for interruptions to not take up more than 5% of my time overall.

Practicalities

The combination of principles, focus areas, and the other ways I contribute give me enough context and guidance to plan my work.

It’s come up in multiple conversations where in the org chart it would be best for me to report. Given my focus areas and principles, most of my work won’t relate to a specific team’s scope. Therefore it makes most sense for me to report at the level above this, reporting to a manager with a larger scope. This makes it easier for me to select relevant work, and for the relevant work to find me.

I will finish with a short list of practical ‘tools’ that I plan to use to help me stick to this plan.

• I’ll review this document regularly, to check with myself whether I’m still on track, updating the document where necessary.
• I’m explicitly planning blocks of time for the projects I’m taking on in my calendar as focus time, and keeping a personal, brutally honest list of hours spent on each project during the week. This helps me understand how I actually spend my time and work towards how I want to spend my time within reasonable bounds. Knowing myself, I will probably not manage to keep doing this forever, but I think once I get a bit of a feel for it, it might become less relevant to keep close track.
• I keep a brag document to list my achievements, so that I keep a feeling of accomplishment with more long term projects.
• I try to organize my reading list using Tab Groups, to make it easy to save an article for later, and also clean it up once in a while as there will probably be more to read than I have time for. I will probably also train my scanning/triage skills to quickly see if an article is relevant enough for a full read.
• I plan to create a personal searchable library of sorts with references to interesting things I read with notes, to make it easier to retrieve something later.
• I keep track of my current projects and a backlog of ideas/requests, that I regularly prioritize and clean up.

Sources

‘The Staff Engineer’s Path’ by Tanya Reilly (Goodreads)

This is a wildly useful handbook for me, almost every sentence offers relevant and relatable information. Many of the topics are probably also useful for EMs or senior developers. Also there’s plenty of links to other sources to take a deeper dive. Some important chapters:

• Chapter 1: “What would you say you do here?” — Covers what a staff+ engineer is, or can be.
• Chapter 2: “Three Maps” — Covers how to figure out your position in the company, understanding your company environment and achieving you and your company’s future plan.
• Chapter 3: “Creating the Big Picture” — About writing a Vision or Strategy document, what it takes, how to keep all stakeholders aligned, and set yourself up for success.
• Chapter 4: “Finite Time” — Handles time and energy management, plus how to pick projects, stay happy and successful.
• Chapter 7: “You’re a role model now (Sorry)” — About values that help you to do a good job as Principal Engineer.

www.staffeng.com

• They have a podcast with many staff+ engineers — interesting to get a perspective on how other companies & people treat the role.
• They also have a guide for reaching/succeeding as staff+ engineers.
• And a number of interesting articles, and a book that I haven’t had the chance to read.

Rands Leadership Slack

• For any tech leadership role. Has specific staff+ engineer channels, with interesting discussions on things you might run into as Principal Engineer. I signed up for donut talks with other engineers to be able to share thoughts on how to do this job.

www.leaddev.com

• Interesting talks, conference, and blog posts.

Thomas Wedell-Wedellsborg — What’s Your Problem (Goodreads)

• Nice book about figuring out what problems to solve, and reframing.