Career path for our software engineers at Staffbase - Regular
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 Rachel ...
Hello there, my name is Rachel,
and I’m glad to be part of the agile product development team at Staffbase.
When I joined the company I had worked as a Software Engineer for one and a half years already, and now I'm a member of Staffbase for eight months already. After my studies I was part of a project which aimed to ship a native app. There I worked mostly on native Android development tasks. By now I even collaborate with our QA member to write tests and review the PRs of my teammates.
At Staffbase I still work as a mobile developer. It’s great to be part of a cross-functional team and collaborate with different kinds of Product Developers, such as Software Engineers, UX specialists and Product Managers who know best what our customer needs. Within our team we care for sharing knowledge and getting in touch with all types of tasks, no matter if they are more Backend or Frontend related. Still, together with the team, I realized that native backend development is my strength. I’m proud of being a valued team member and I support my teammates whenever André Associate might need some information or Sam offers a pairing session to work on a tricky task.
It’s very cool that my team appreciates my opinion. Since I worked on different projects and products already, I speak up confidently and support whenever we need to come up with a decision. That way I made yesterday’s refinement a success since we were stuck with a story and its estimation. By openly sharing my view, asking several questions and coming up with ideas how to approach the implementation the team was able to identify a direction to go and to agree on an educated guess in terms of story points.
From time to time, I struggle with finding a balance between focused work on a task in tunnel mode versus collaborating with others in several kinds of appointments, meetings and pairing sessions. But hey, I think that’s fine. Whenever I see such an issue, I just bring it up since I know collaboration is key and helps me and others to learn and improve. That’s why I’m always up for working on a task together or having a discussion on how to approach a specific implementation. Meanwhile I’m experienced enough to still find good ways for ensuring I’d be able to work on challenges and tasks in a structured way. Recently, after consulting with my team, I just decided to use focus blockers in my calendar and in Slack, and so far it’s working quite well.
Since we live in a nice “fail and learn” culture, I really appreciate the valuable feedback of my teammates and dare to ask or provide open feedback to my colleagues as well. That way I even found a nice overarching topic to work on and to gain some expert knowledge I am really proud of. By setting up some reusable GitHub pipelines I made our process smoother and more efficient, which was highly appreciated by several people and teams already.
Another thing that comes with my development level is my chapter. Since I have a stronger focus on native development, I decided to join the Native Wildlife chapter. Every Monday I contribute to tasks and ideas of this chapter and participate in the learning activities with my peers there. In addition, I enjoy taking part in work related events sometimes and bring in my questions or experiences there. Thankfully there are a lot of great formats one can attend even for free, such as development, tech or agile related meetups or webinars.
By now, I’m quite familiar with the functional domains of my team. This enables me to act as a first responder when it comes to requests from other teams or production issues with our domains. This familiarity also helps me focus not only on functionality, but also on quality, performance, and security of our code.
This is what makes me a regular software engineer. In case this is your current or future role, how do you approach it? Feedback is very much appreciated.
Best, Rachel Regular