Talk to 10 people and they might share 10 different definitions for staff developer. This is not too surprising, because the whole concept is relatively new. Programming as an industry is quite young, say about 80 years old, but even then we've had managers since the beginning. However, the concept of a staff developer as a career step is at most 25 years old. This is a concept where an individual contributor can have the same scope of impact and seniority as a manager.

What is a Staff Developer?

But beyond seniority, what makes one a staff developer anyways? At Shopify, staff developers spend a lot of their time writing code, but also bring experience leading technical projects, building large-scale systems, and making important technical decisions. At larger tech companies, they might work under titles like staff software engineer or technical lead. At smaller companies, they may have done stints as engineering directors or principal software engineers. 

A big misunderstanding is that a staff developer is a "more senior" senior developer, when in fact becoming one means taking on an entirely new role. Staff development is a form of leadership. So let's explore four ways that a staff developer shows leadership.

Technical Excellence

The foundation for operating as a staff developer is technical excellence, and technical excellence is gained through experience. In this case experience is not measured by number of years, but rather by the quality and diversity of projects executed. The average staff developer will have had a wide range of experiences, from working on multiple products and seeing large refactors and rewrites, to experiencing a technology shift, or adopting a new programming language on an existing product.

No matter how fast paced a team or company, no one can finish college or a boot camp, work for a year, and suddenly become a staff developer. It's unlikely you've seen enough. On the other hand, you could work 10 years supporting the same product, making the same changes, and be no closer to being a staff developer in year 10 than you were in year one. You just haven't seen enough.

They have also made lots of mistakes. Yes, that's right—much of the learning about how to implement something well comes from having implemented something wrong. They understand how to build solutions under constraints. They know when to implement new architectures and what "over engineering" looks like. When faced with many options for a given problem, a staff developer can pick the most appropriate solution.

If you want to know if you're growing your technical excellence, ask yourself:

• Am I making mistakes? The occasional mistake is a good thing. Mistakes show that we’re pushing ourselves to do hard things and forcing ourselves to grow. If you always do your job perfectly then you're not in a position that will force growth. You’re taking what feels like the safe path but is actually the path of stagnation.
  
  
• Are you asking more questions than providing answers? I often joke that staff developers should be renamed the "askers of questions". The role is NOT about having all the answers, but rather about knowing what questions to ask.
  
  
• Are there people I’m learning from? One of the shortcuts to growing fast is to make sure you’re working with people who know more than you about something, and are offering you feedback. For instance, request design or code feedback from people who will poke holes in your design. Actively seek out people to challenge your logic.
  
  
• Am I making time for professional development? The technology landscape changes fast. It’s not enough to do the product work. We need to stay on top of new shifts and paradigms. For example, I have on my list to play with Action Cable since I've never had a chance to play with that part of Rails. Sometimes it's pushing ourselves wider to learn about entirely new concepts, algorithms, and other related fields. Making time to go talk to a data scientist about what they do and what they wish developers knew is a form of professional development. And yes, at Shopify it's ok and encouraged to do this during work time. I had a manager recommend I schedule a few hours a week in my calendar for personal development work and I'm so glad that I did it.

Forming a Partnership

I have a riddle for you:

When is your boss also your peer?

When you are a staff engineer.

In many companies, it’s not uncommon for a staff developer to report to a team manager at the same level. From a team point of view, this can be quite useful. The team needs an individual who is accountable for team output and team health, and that's the manager. But oftentimes, the technology portion of the team will require focused attention and leadership. In this case, pairing a manager and a staff developer, we can create a partnership that cares for the entire spectrum of team needs. The manager will spend more time focusing on people while the staff developer spends more time on technology. But note that these two roles are not mutually exclusive, there can be significant overlap. A good manager does not ignore the tech, and a good staff developer does not ignore people. So a question to ask yourself as a staff developer is: how am I acting like a partner?

Gone are the days when you can hand off a problem to your manager. You’re now equally as responsible for finding solutions to difficult challenges. You’re also more likely to have your manager come to you for guidance in problem solving. After all, you’re a leader too.

Alignment with Business Objectives

Staff developers need to translate product and business objectives into technical proposals and decisions. You must demonstrate a strong grasp of the product and the domain where the team is building the technology. You should be one of the people in the room during your team's product planning, because that planning will rely on your ability to bridge the two domains of technology and product.

Aligning with the business can look like:

• Making quick judgements on what features are easy or hard to implement. Being opinionated on the scope of work as an input for the team's roadmap.
  
  
• Being a problem finder. In the last three months, has your team answered the same support request over and over that could be solved with a tweak to the product? In this case, it’s your job to advocate for such changes in the product.
  
  
• Being the voice for the infrastructure needed to keep the product functioning. Sometimes this can be purely technical, like saying we need to implement database sharding to handle the load planned for next year. Other times it can be technical changes that make the product produce better results, like anomaly detection and repair, or figuring out what errors are happening frequently and speaking to the impact repairing them would have on the customer.
  
  
• Saying no to the right things. This means saying no to technical suggestions that don't enable the product, or product suggestions where the engineering effort doesn't match the return.

Mentorship and Support

One big shift that happens when becoming a staff developer is we can no longer judge our impact based solely on what we do. We now have to judge our impact on what we enable our team to do. This shift is significant—we’ve spent our entire careers measuring our output in code added (or removed), PR requests, and features shipped. But good staff devs have a huge impact on the speed of delivery and quality of their entire team. This shift may feel less rewarding at first, but part of the journey is learning to produce impact through the enablement of others. This can include:

• Indirect mentorship through design reviews and code reviews. Design and code reviews have two purposes. The first is the obvious one to catch problems before they ship. The second is even more impactful: to transfer your knowledge on good design and coding practices to your broader team. You can point out alternative ways to solve the problem, and highlight things people have done especially well. As a staff developer it’s expected that you do more of the second. A good code review will not just affect the code it’s about, but the future code the author will write.
  
  
• Direct mentorship through coffee chats. A staff dev can also do 1:1s with different members of the team and pair with them. I find it especially important to know from my manager who is on the edge of a level change. People working towards the next level or who have just been promoted can benefit strongly from mentorship.
  
  
• Sponsoring those who are ready for more. As a leader who is deeply familiar with the team’s technical work, you’re in a great place to know everyone’s strengths and weaknesses. Keep an eye out for team members who are ready to take on more responsibility. When involved in planning, make sure to suggest tasks for those you think are ready to take on more.
  
  
• Providing an ear to those who need it. You may be in a position where you have more context about an individual than the manager. This means other individual contributors will seek you out for guidance and support. You’re in a unique position where you’re both leader and peer. When I'm concerned someone is frustrated I tell them we have a cone of silence over our chat. Nothing they say in the chat will leave the chat unless they tell me they want me to act on something. Sometimes people just need an ear, some advice, or just to know someone cares.

Staff Developer: An Adaptable Leader

So what does it mean to be a staff developer?

1. Technical excellence
2. Forming a partnership
3. Alignment with business objectives
4. Mentorship and support

It all boils down to this: a staff developer is an adaptable leader that's comfortable working with ambiguity. One of the reasons we see so much written about what it means to be a staff developer is because there are so many ways to operate as one. This is a role that is a combination of an individual's strengths and a company's needs. Part of the job is defining what your job should be, and iterating on that definition as skills and needs change.

---

We all get shit done, ship fast, and learn. We operate on low process and high trust, and trade on impact. You have to care deeply about what you’re doing, and commit to continuously developing your craft, to keep pace here. If you’re seeking hypergrowth, can solve complex problems, and can thrive on change (and a bit of chaos), you’ve found the right place. Visit our Engineering career page to find your role.