Some time ago, we received feedback from many of our engineers in our business unit about how to develop at a certain skill level without addressing the next higher level. When we looked at our engineering career framework, we realized that it couldn’t provide a valid answer to that question. So we gathered ideas from our colleagues and created a guide that includes ideas for horizontal growth for our Associate, Regular, Senior, and Tech Lead skill levels. This is the continuation of a series of app posts describing how our colleagues can grow at their respective levels. Let’s move on to Sam …

Hi, I’m Sam. I’m a Senior software engineer at Staffbase. And, it’s the best job I can imagine.

Before joining Staffbase, I already collected a lot of experience in other organizations, doing programming and software engineering for quite some time. I regularly attended meetups and conferences and created a network of software developers, quality assurance engineers, and product managers I still maintain and extend.

At some point I stumbled upon a Staffbase job offer and felt like sending an application would make sense. And, yes, three years back I joined my team and got directly involved in an incident on our live system that influenced many of our users directly. We had no monitoring or visibility of our operations back then. My first task was writing automated tests to reconstruct the live issue. And finally, we found the root cause of the issue. Fixing the root cause meant rewriting basically the whole code of one domain. But, we made it and on the road we helped ourselves with monitoring and traceability.

One year ago, I got promoted to Senior. It didn’t just happen. From my point of view it was a recognition about what my team and I accomplished within the years before. We brought quite a lot of new features live, collected feedback and made plans on how to improve the functionality of our product.

I’m not the center of my team and I’m not in command. I see myself as a supporter who helps the team to make the right decisions. One of my tasks is to foster my team to grow in engineering, coding and domain skills. If I have to prioritize between getting my own tickets done or helping my teammates, chances are good that my team members go first. I’m approachable all the time for my teammates and for colleagues from other teams.

Our team is responsible for critical functional domains. We ensure that we all know our subject matters. The moment a new team member joins, I support them to get familiar with the domains, coding style and the rules in the team. When the new team member solves the first tasks we have pair programming sessions and joint code reviews. This helps me to get to know the new teammate and their programming skills. I don’t support onboarding completely on my own. We are accustomed to substituting for each other in the team here.

When doing a code review, I don’t have only code in mind, but also testing, performance, users perspective, documentation and security. I don’t let tickets pass that don’t fulfill these viewpoints. I encourage my colleagues to take this habit of mine on. And, they do.

I like mentoring colleagues. It’s only one mentee at a time, so that I’m able to handle my team support tasks and my own work. Mentoring is not teaching: It’s about listening, asking questions, providing feedback, but also guiding or giving directions. And it’s about thinking together about next steps to collect knowledge and experience with the topic at hand.

What else? I’m always open to provide feedback. I prefer being asked for feedback instead of approaching a colleague unasked. On the other hand, it’s sometimes necessary to go ahead. I regularly ask each and every team member for feedback. Our feedback topics are widespread: personal growth, options for solving issues, or process improvements.

I approach my teammates, when they need help or when they have questions about their tasks. That way I get context about the work my teammates are actually occupied with. This makes it easier for them to address open issues. I try to not interrupt my colleagues unasked. It works best directly before or after some meetings or breaks. Inside my team I’m the one that ensures that there are technical learning events. I don’t have to do everything on my own. We decide together what to learn or to try out next.

We still face incidents within the domains of our team. But, those are not that bad anymore like when I joined Staffbase and cause little or no harm to our customers. Incidents are now a chance to learn and to improve. I scrutinize our domains all the time from all the angles needed: deployment, operational, technical, functional domain. And I approach my team to discuss issues or chances we might have.

My communication skills have been an issue at first since I was accustomed to getting my will. I learned to step back, so that other team mates can flourish. Another issue was my understanding of our product managers role. I took an internship with another team which helped me to understand the motivation of our product organization. I continued with internships in different roles within our organization in the following years.

From time to time I step back from my tasks and try to get an overview over the current state of the domains I’m responsible for and figure out whether we are still on track. While doing so, I realize smaller issues which I can solve right away. In case those issues are bigger, I discuss them with the whole team.

That’s what makes me a senior software engineer. In case this is your current role or the role to come for you, how do you approach it? Feedback is heavily welcome.

Best, Sam Senior