Transcript
Wrightson: A couple of years ago, I wrote an article about what it was like to be a principal engineer. Following that, I started getting pinged by engineers that were wanting advice on doing this role. One wet and miserable day I went for lunch with an engineer who had reached out to me, he asked me a really simple question to start with, how did I get promoted? This question really took me back. I'd only really thought about how the role was now and how to do the role. I never really thought about the road that had brought me into the role. In essence, that one question led to this moment of me giving this talk.
Background
I'm Nicky. I first got promoted to principal engineer at the Financial Times, and from there, I was principal engineer at Skyscanner. I should note that I keep saying principal engineer, I was never staff engineer, but that's because staff didn't exist at FT or Skyscanner. It's one of those annoying things about this title, which makes it all the more murkier. Recently, though, I joined Blenheim Chalcot as ventures CTO, where I provide engineering support to all of the ventures in our portfolio. This isn't just an extension of what I did as a principal engineer, but as I've expanded my influence from one company to many companies.
Outline
I struggled with the title for this talk, because it's less about secrets or shortcuts. Really, all it is, is a set of observations and behaviors that I've witnessed that got people promoted to the staff engineer role. First off, I'll talk to you about what a staff engineer is. I will elaborate from my own point of view. Then we'll move on to the guts of it. How do we get one of these roles? Finally, how do you succeed once you're in that role?
What Is a Staff Engineer?
What is a staff engineer? First off, I think we should talk about why the role exists. In fact, do we even need the role? I went a good 15 years working as a developer before I had even heard of these roles. To answer that, we also need to understand the different organizational models, the tooling, the processes, the culture that caused this. Traditionally, we had our own servers somewhere and dedicated teams looking after them. Teams were grouped according to their role, DBAs, developers, BAs, and so on. The architecture is led normally by a group of architects that design systems upfront and handed off the implementation. There was good reason for working in this manner. We had physical machinery. We had to buy physical disks for new projects. We needed to know how much that was all going to cost. There was also monolithic applications where your changes could affect many pieces of functionality beyond the scope of your implementation. There was high risk operating in the production environments, and we needed a QA function to make sure everything fitted together right. We had explicit teams coordinating and pushing out releases every couple of weeks or months. There was a lot of manual testing.
Then came along several things that are closely related, autonomous teams owning end to end architecture and operations, owning entire domains, features all running on elastic compute with the DevOps mindset. These roles we'd had in the previous world had become responsibilities. Every team member was responsible for architecture, databases, operating and running the software, deployment and QA. We now have the teams that are architects of their own destiny, releasing many times a day, choosing what they use at every step, deciding what processes to use to get the best results. These cross functional autonomous teams were still delivering towards company level objectives, which makes them one cog in a much bigger picture. Which means although they're autonomous, they will also need to be aligned with other teams in parts of the company.
This is the Spotify graph for alignment. You'll see, if your autonomy is low, and alignment is high, there has to be top-down directional leadership. Instead, we want the teams to fully own the problem, not only the how, but the what. What is the right thing to build to achieve the company objective? Fully owning the problem space needed support, especially if the problem space was either super murky, complex, or involves other teams. We had a gap where some of those centralized functions used to bring us alignment. We also had a gap in experience, we were expecting engineers to master more than we'd ever previously, own more or be accountable for more. What we needed were coaches, mentors, people interested in those cross-cutting concerns. People experienced in designing their way out of murky and complex problem areas, enabling the engineers to grow and own their own problems.
Metcalfe's law is a concept used in computer networks, and it states that networks impact is the square of the number of nodes in the network. This is true for teams in organizations. Basically, the more people, the more complex the communications are between them, and between the teams, and the more work needed to align. In early startups, you don't necessarily need the staff engineer role. The founding engineers are normally comfortable with ambiguity, the org is small enough that alignment can be achieved through just chatting with people. The leadership should be taking care of the CTO who's probably still quite hands-on, or you have a lead engineer. Then you get into the organizations that I'm much more familiar with. The FT, and Skyscanner fit very much into this bracket, less than 1500 engineers and the product is often focused very heavily in one domain. Then you jump up to the FAANGs. There's other ones up here, Uber, Microsoft, for example. You can see the influence has to widen as the complexity increases, and you'll see more of these higher level roles at FAANGs. FAANG organizations will have staff, senior staff, principals, senior principal, distinguished, and fellow, while the FT was much smaller and only needed one level, so we settled on principal.
Staff engineers don't only provide that holistic view over the systems and push for cross-cutting concerns to be considered. They also had mastered their trade, and so were able to provide technical guidance and support to engineering and beyond. I found that illustrating some common misconceptions about this role often illustrates what it is. A staff engineer is working cross teams or the entire organization, providing technical support, whether it be helping a team with a gnarly problem, or helping technical strategy definition, or rolling out something that can impact many teams. While the senior engineer will typically be embedded in a team working with teammates to define and deliver towards their objectives. There's a common misconception that a staff engineer is just someone a bit more experienced than a senior engineer. Sometimes, unfortunately, promotions are given to seniors for recognition of how brilliant they are at being a senior, but not recognizing that the staff role is a complete shift.
There's these two books from Marshall Goldsmith, he says the ways that got you to a certain level are not the same ways of working that will get you to succeed at the next. For the jump between senior and staff, this is very true. Your problem solving and delivery most likely made you a kickass senior, but what will make you a kickass staff engineer is the ability to make everybody else a kickass engineer. You should not be working as you did as a senior, this is a different role, you're enabling versus delivering. Some going after promotion in their organization because it's the only way for them to get the pay raises, which leads to seniors ending up in staff roles and not really enjoying it once they've stepped up. I know several staff engineers that have actually gone back to being seniors at other companies as they missed the role. Facebook split compensation and promotion, so you can still keep getting rewarded without having to get promoted. I think that's the way it should be. In this crazy hiring market, at the moment, I'm actually seeing little difference in pay bands for senior and staff outside of FAANG organizations, indication that you could probably get the same amount of cash for doing a senior role.
Somewhat related to the idea of senior. Senior are those out there that believe that if you hire a staff engineer, they'll automatically get much more delivered than if you hire a senior engineer. Of course, this is totally dependent on the staff engineer and the organization. However, on the whole, this is total crap. At best, a staff engineer will be delivering as well as a senior, as both will be masters of their trade. Staff engineer superpowers don't lie in lines of code, but seeing the bigger picture, teaching others of patterns. Best of all, we have a tendency to have quite a few battle wounds from actually operating systems so we can help identify where to delete code in systems instead. This tends to be a longer game though. This is one of my favorite tweets, I quote this often. I change it slightly, I say, "As a principal, I like to delete whole systems."
Traditionally, you would reach a decision point as a manager versus architect. Architect, you remain technical but reduced being hands-on, and it was often a highly directional role. Architects for buildings, for example, draw up plans for a house before even planning permission has happened. This name was not accidental for the software world, upfront design allowed for budgeting of resources. Now these resources are no longer physical, the cost of change and iteration is smaller. We can change this role. Architects did provide a holistic view over the entire system. This is often where the gap that a staff engineer can fill. The teams can then concentrate on delivering business value and trust that their staff engineer will relay cross-cutting concerns. We're also more interested in the operational angle than architects tend to be. How do we maintain this software? How do we support this? What does the development lifecycle look like?
The problem spaces you'll be approaching now are far more complex and bigger. That complexity is normally derived from adding people to the mix. Solving purely technical problems is the easy part, organizing more people in teams to solve things, now that gets tough. You can no longer head to your desk and code your way out of a problem. You need to bring others along with you or get others championing the right solutions. To succeed, you might need to get many teams and people pulling in the same direction. This becomes less about the tech, more about the people and more about the influence. There's a distinctive shift in tooling from Visual Studio to Confluence and Zoom. Engineering managers often frown when I say that we're both enablers, but from a different angle.
Real World Examples: Senior IC Behaviors
I thought I'd give a couple of real world examples to illustrate what I mean by this. This is Sarah. I worked with Sarah at the Financial Times. Prior to becoming a tech director, she was principal engineer in the content team where I was also working. We were containerizing our apps and moving to a homegrown container orchestration platform. Some of the groups there, we were playing around with Go and we were seeing more Go accidentally sneaking into production. However, it was often lacking the belts and braces of our other production services that we wrote in Java. Sarah knew that we were at this crossroads, and we either adopted Go or doubled down on our Java. There was two distinct camps within the group, one extolling the virtues of Go, and the second one complaining about how hard it was to support the Go apps we had. Sarah's approach to resolving this was to go away and assess those virtues and work out best practices for Go if we were adopting it. Such as, best ways of testing, best ways to put health check endpoints in that conformed with the rest of the organization. She brought this all back to the group and used it to convince us to give Go a chance. Nowadays I think nearly all of us consider Go our primary go-to language, except for one person who's still a diehard Java lover. Here Sarah went off and answered loads of questions that our group was stuck on. Our engineers were completely stuck, then she persuaded them to give Go a chance. She was improving the development process, team morale, and pushing for better alignment amongst the teams in the group.
This is another example, this is Scott Anderson, staff engineer at UserTesting, and formerly principal engineer at Skyscanner. Skyscanner has a wonderful incident review process. There's a no blame incident review process. It's very well defined. After an incident, one or two of the folks involved in the incident will write up the incident and will discuss it with a wider group, facilitated by a principal engineer. What Scott noticed were people weren't going deep on the root cause analysis and purely stating what they were fixing to resolve the incident. This was ok from an incident point of view. It's far less ok from a learning point of view and certainly wouldn't help future incidents or stop future incidents. We all know there is no such thing as one single root cause to an incident.
He proposed that after an incident the squad should get together and do a root cause analysis session. He chose to use the Ishikawa template or otherwise known as Fishbone template to allow for teams to examine many causes of the incident. Scott started by talking to the teams about the problem with the current mechanism and describing the benefits of the new approach. The sessions involved going much deeper to understand the full context in which the incident occurred, which in turn created greater learnings but, more importantly, could really help stopping a similar incident in the future. He was socializing the problem. Once the teams were on board, he facilitated the first few sessions. Most importantly, he then started training others to facilitate these sessions. Soon the entire tribe were running their own root cause analysis sessions. Alongside it, he was able to convince product and leadership that the whole process of writing up the incident was to be categorized as a P1, it was immediately actionable, which led to fresher write-ups into the events. Here, Scott identified a way in which the engineers could learn more and be more autonomous. The staff engineer aspect is the way in which he socialized the problem and taught others to take over.
Instead of giving a recent example of me behaving as a staff engineer, I'll try and give you probably the first example I recognize myself. I joined the FT to work on a multi-year reimagining of the content backbone of the organization. It's starting very much Greenfield. Then came the priority to make it the sole content platform by decommissioning the previous incarnation. Linking up the decommissioning and the rollout of the new functionality was stupidly complex. Around when I was getting promoted, I recognized myself doing this staff engineer role, because we could see the light at the end of the tunnel, we'd bitten off these huge chunks that were easily owned by teams in an autonomous manner. However, we were now at the point of bringing it all together. There was lots of temporary coupling to be able to deliver the right solution. It was made more complex as we had three countries we were working across: UK, Bulgaria, and Romania. It would have been easy to come very directional, and send out detailed design docs for others to implement. However, instead, I invested going around each of those teams and coaching them about the whole bigger picture and how they could fit into that. This allowed them to decide what they were building to satisfy those integration points. This enabled direct communication between the teams rather than going past me. Here, I was teaching others how to be able to own what they worked on and enabling autonomy.
The staff engineers enable others. We're highly technical, and we share that. We're paying it forward, we are teaching others. Staff engineers have their eyes across teams on the whole, not always, and are generally looking at things that could benefit many teams, not just one deliverable.
How to Become a Staff Engineer
How do we now become staff engineer? I've explained that the title of my talk was slightly clickbaity, because I have no magic checklist for you to complete to get promoted. What I can tell you about is my journey, and also I can tell you some tactics and behaviors I've seen others do to get the promotion, and some of the learnings I've had from actually being part of the recruitment board myself. At this point, though, I strongly suggest some reflection on why you want this role before going after it. As I said previously, it's not just a senior-senior. If you're really enjoying what you're doing, understand where you're going with this promotion and what the compromises will be in taking this role. At the start of the talk I spoke about how I wrote a thing, and an engineer floored me with a simple question, how did I get promoted? What I replied was, "I'm going to give you a pretty disappointing answer really, because I didn't go off to this role intentionally." Sure, I might have been very forthright about getting the promotion in the run-up to it. In fact, I made sure my manager was well equipped with all my own evidence. This is normally something the manager gathers. Only after that, I realized I was already doing the role that I went in for the promotion.
The even more disappointing part of this answer, is how I got to that point of doing it. I loved what I was doing. It led me to questioning more and taking on more responsibility. I was incentivized by the love of what we were building, and I wanted to make it better. With it came my influence, my domain knowledge just grew. I also needed to get others on board to deliver even better than I could do by myself. If we look back to the earlier example of me going around the teams spending time getting them to understand things more deeply, that was what I loved, the overall effect. I loved seeing people taking the reins, and themselves getting the bug for the problem we were solving and the product that we were developing. I could see real tangible impact to my actions. I really liked that. That's why I continued to be a principal. I never went back to being a senior.
You now want to go after this role. Where do we start? The obvious point is get yourself promoted in your company, if your company is large enough or if they have this role, of course. Every organization is going to be different on the way that this happens. I'll only be talking about my own observations and experiences. There's something called the staff engineer project. Staff engineers are expected to proactively identify issues and work out what it takes to solve them. Most promotions expect evidence of you doing this role before going for it beforehand. When the senior engineers don't have immediate access to gnarly enough or impactful enough projects, there can be a tendency to go and look for those projects elsewhere. Again, this is totally dependent on the organization and the individual. It can be a trap. I've seen folks so focused on the project for the promotion that it either takes them away from delivering real business value or, worst case, they get promoted. Then this project gets thrown to teams who had no say in its development, and they're expected to support it. I'm not saying this can't work. I really am not. Be wary of going after solo projects as a tick box exercise. Collaborating with your team and leading on something with bigger business value can bring you the same outcome.
You will have worked out by now, it's a step up. It's not as easy as previous steps up. Previous promotions, all you needed was to take some stuff. There was quite detailed ways in which to get that promotion, it's not the same here. If it was, I'd be sending around a checklist to you rather than struggling to get all the information into a 40-minute talk. You can reduce the need to go on the hunt for that staff promotion project, and there are some supplementary ways to bolster your evidence. A good sponsor can help in so many ways. They can put you in the room for these interesting problems and challenges that you might not normally see. They can also increase your visibility with groups that wouldn't normally be in contact with. Often those on the promotion board for example. Not only visibility but these people can bolster your reputation. Sponsor might be your manager, might be a mentor, or it might be somebody you befriended at a coffee machine. Whatever the relationship, your sponsor needs to be up the ladder in some manner to help you.
Enabling others is the cornerstone staff engineer role, a force multiplier. You might be enabling engineers directly like the examples earlier. However, you could be enabling anybody in the organization. I've seen staff engineers be fantastic bridges between product and engineering, enabling product to bring the right thing to the table, or using their influence to get automation prioritized. It might help customer success, for example. If you're using your influence to make other people's lives easier and grow other people, you're doing the staff engineer role. We can think back to the examples of me, Sarah, and Scott. We were investing in others and enabling them rather than going solo.
In this role, you're expected to exert your influence over an ever widening group of stakeholders, and during the promotion, processes will be a key factor. In the simplest form, who on the promotion board has felt your influence? You can start building these skills at any time. The biggest way to start is writing up your ideas and learning how to socialize the problem. There's also the somewhat awkward task of building a network, but participation in events outside your team scope can help build that network, and also can get your name and face in front of people you wouldn't normally interact with. Leading showcases or getting involved in guilds, cultural groups, helping with recruitment. A personal favorite for me, though, is cross org training. I did a diversity and inclusion training, and I ended up in a group with the CTO and a tech director, both of whom I spoke to more during that training session than I had previously in my entire career. Be careful, though, to spend too much focus on these activities, there's always a balance between these activities and delivering day to day.
Keep a constant log of your evidence and how it relates back to your company values and career frameworks. If your company doesn't have a career framework, then ask your manager what's expected of you to get promoted. Unfortunately, at this level, whatever your manager says or the framework gives you, won't be a simple checklist. This is from Skyscanner's framework, you lead and influence a team in a deep problem space or a number of teams across a broader area. This is intentionally vague. What is the definition of leading or influencing? What's enough, leading or influencing? What do we mean by deep? This also allows for change. I was sometimes across the entire org, and sometimes I was going super deep on a problem with one squad. Finally, get others ideally a level that you're going for at least to vouch for you and to support your evidence.
You've decided to move on from your current company for whatever reason, might not be related to the promotion process, and you start thinking you might want to be a staff engineer at the next company. This is a difficult one, because people are normally expecting you to have previous experience with that role. It might be wise to target smaller companies or even startups. Startups won't necessarily have this role, but going in for a lead role at a startup that's growing fast could put you in the perfect spot to be that first IC. You'll end up doing the same responsibilities at a smaller scale. Also, in the same way you had evidence for your promotion, start mapping out what you're doing at the moment to other companies expectations of the role. Have clear evidence that you can do the job, exactly like the promotion. You need to find out who really supports this role. I found that when I was approached by recruiters and companies, they agreed with everything I said. I sent them through blog posts. I thought we were on the same page, but they didn't understand the role or what I needed.
Pants or pants anyone? Don't assume the words, because the words are the same, they carry the same meaning. We have a whole track dedicated to this subject of these levels, and that's because it's not universally understood. When you go for another role, be explicit on what you think that role is and ensure that expectations are aligned. I used to always send this blog post from Silvia Botros and expect people would read that and map it to my expectation. It's just not enough, and I found out the hard way when I ended up with a title but none of the same responsibilities. How do you make sure though, you can be aligned? The easiest way is if they have a career framework that supports these staff engineer roles. Then it means that they've really thought about why they need the role and what it is to grow people in this role. It doesn't need to be public, the ones I've put on the screen are Dropbox, GitLab, Notion. Without a career framework, it makes me uncertain that we're on the same page. It also makes any feedback in the role hard because you don't know where you're being measured against.
Reverse interviewing. Ask to speak to others that are doing the role, really find out what a typical day looks like for them. If you're the first staff or principal, though, speak to those that you'll be working with. What do they expect you'll bring to the table? If it's that small, you could speak to the CTO as well. Why have they ok'ed that they're hiring this role? What do they intend for you to do? What will your success criteria look like? How to become a staff engineer, find a sponsor, enable others, and broadcast your presence, and build the evidence. This holds true, regardless of if you go for a promotion or if you go and get another job at another company. The three things are still needed.
Starting Out as a Staff Engineer
Then when you start doing these things, how do you know you're doing well? We've covered what a staff engineer is. How to become a staff engineer. I want to now talk about starting out as a staff engineer, how do you succeed? There are books like this one that can help you quickly settle into a new role. I think, first and foremost, you need to recognize it as a new role. You are promoted into this and you need to plan how to adapt to that new role. This may involve plans to extract yourself from teams who will take on more responsibilities, but be explicit about these early steps and work with your manager and team leads to define what that looks like. There will be significant changes, though, and I'll talk you through some of the hurdles that I've seen with this jump.
The biggest change that I struggled with was time management. Staff engineer's time is super spiky. You have the autonomy to define how much you take on so be careful not to overload yourself. Your work won't necessarily be on a board or spoken about at standups. Managers tend to have calendars rammed to the brim with meetings and senior engineers have majority focus time. Realistically, you want to sit between these two things. Still allow for focus time, but also appreciate that you have a slew of meetings that you didn't used to have. I now try and get all my one to ones in one day. When you move into this role, there's a great number of people that will want to have time with you and get your opinions on things. These one to ones are not quite the same as ones with your manager. It might be mentoring, coaching, or just informational.
Then, there's how you fit into the company processes when there's planning season coming. I've given the OKRs as an example, you could use whatever planning mechanism. At the start, when the objectives come down, you're working on tech strategy and trying to look at what it looks like across the group or the company. Then you get teams involved and work out what exactly you're going to build. The ambiguity gets less as the process progresses, but it's not really linear, like I stated before. It's more a little bit like this, you diverge as you work out what problems you should be going after, then you converge and then you explore alternatives to deliver on those problems. The ambiguity lessens, but it's tempting to go after time fillers when the ambiguity lessens. The trouble is you do that and suddenly planning season is back on you and your workload has gone through the roof. There are several ways to combat this. The simplest is to recognize the spike, and constantly have an eye on that next planning session. Also, rather than going after large projects, try to go in these quieter times, try to concentrate on smaller, achievable pieces. I actually create a Trello board and run a Kanban session for myself, which also creates documentation for my own reflection. Apply a whip to yourself there, I recommend.
I have a tendency to want to fix everything all at once. This is not the best approach. For starters, you spread yourself too thinly and you end up fixing nothing. Secondly, it can erode relationships. You don't tell a friend that you think their baby is ugly. That will never go down well, even if it's the truth. The same can be said for pointing at teams code bases and saying it's all crap. Rather than pointing fingers you can work out how to make these peoples' lives easier instead. Be sure you're not stepping on other people's feet in the process. If there's a stinking [inaudible 00:34:51] set in GitHub, don't presume you're the only person to smell it, others might already be invested in sorting it out. I always start with this. What's your biggest pain point, when I go on to teams, rather than identify my own pains? These examples are just literally the last few months' examples. I can tell you, 9 times out of 10, engineers will complain at some point about deployment, but these are the places that you can make real impact.
You've established relationships with other engineers, engineering managers, and product managers. However, these relationships shift when you get into this role. You might have more stakeholders than before. Be explicit about how your responsibilities will change in this new role, especially if they're folks that you've already got a relationship with and you're used to working with. When I joined a new tribe in Skyscanner, we had an explicit tribe level session to establish expectations for the role. Above was for the three principal engineers, but we did it for product lead, tribe lead, and senior management also. This allowed us to be explicit in how we expected to work together. In another tribe, I did something similar, but we used RASCI. I think we spent more time defining what the difference was between responsible for and accountable for, so not necessarily the best outcome on that one.
Gergely is writing a book and he has been putting some snippets up on Twitter, and one of them is about how staff engineers can get stuck. He talks about them getting stuck because the role is unclear, because the objectives are unclear because of going broad too quickly, of having too many interruptions. Much of it I can really relate to. It all comes back to not having a clear view on your objectives. If you know what you're expected to work towards, everything can layer up from there. Then you want to know how well you're doing in this role, and it really gets tough at this level because there's delayed feedback. Most often, not always with credit. You're now an enabler, you're coaching others, even if you're outlining technical strategy. Strategy is only useful once it starts delivering business value. You're no longer at the front line delivering the value, so identifying your impact becomes more difficult.
I keep notes, and I regularly judge my impact. I often write these up for my manager as well, to keep him on the same page as what I think I'm achieving. Agree with your manager, clear expectations and deliverables. I sometimes even do a very awkward and cringy task of scoring myself. The important part is do not score yourself against other principals. I started out as a principal and I constantly compared myself to the two principals I thought were very good. One had already transitioned into being a tech director. These people were at the end of being a principal engineer, how was I supposed to marry up to them just starting out in the role? Take their behaviors, and see which ones you want to fold into your own. Your visibility used to come from agile processes, and standups, planning, showcases, your manager could really see what you were doing. However, now, you might be in those ceremonies, your manager most likely won't be. You also won't be pulling tickets potentially and your commit history in Git will have tanked. Work out what works for your organization, but writing tends to be a useful tactic. An unread document though isn't going to help anybody. You need to socialize your ideas.
There's a much longer feedback loop in this role. You'll be drawing up strategy. You'll be coaching. This comes with delayed results. When I first heard someone articulate one of my ideas as their own, [inaudible 00:39:15]. Then I realized it's actually a measure of my success. They'd layered in my thinking to their own and it'd become a deliverable. They didn't really realize that I had actually had input into the process, which leads me back to the importance of writing. I found that it's great when people layer in my ideas, but don't let yourself become invisible in the process. Write up your ideas as they come to you. Writing also helps you scale your influence. Keeping technical, this is such a struggle. How do you balance that writing, coaching, networking, while still being technically relevant. Make sure you keep room to keep your hands in whatever interests you. However, don't end up on the critical path. Your time is super spiky, you don't want to be coding over the weekend or being a bottleneck. Small improvements like monitoring improvements or small spikes can help you keep your hands in the code. I read a lot too, but that isn't for everybody. My morning routine is to gorge on the tech side of Twitter. Starting out as a staff engineer is quite tough because your time is spiky. You've got to get your handle on good time management. You've got to be really explicit about what the outcomes are of your new role and measure the success against them.
Summary
I've now told you what a staff engineer is, how to become one, and how to start out in one. Do you want to enable others and grow other engineers? Make sure your impact is wide or deep, but make it visible. Set clear expectations of what you want to achieve in the role and constantly evaluate yourself against that. Remember that tech is easy, but bringing the people along is hard, so hone those influencing skills.
Questions and Answers
Nardon: You said that a senior-senior is not a staff plus engineer. I agree with that. My question is, not everyone wants or need to be a staff plus engineer, sometimes you can be happy being a senior-senior or something like that. How do you know if being a staff plus engineer is the right path for you, instead of becoming the technical side, but being a senior-senior? How do you communicate this to the company in a way that they are not going to just think that you are a loser or something because you don't want to be promoted as a staff plus engineer?
Wrightson: I think that you've got to be introspective. I've seen a lot of seniors go into staff, not quite realizing the level of extra meetings they're going to be in, how much people stuff is involved. They don't really understand that. Really understand the role that you're going for. It might not be the case in the company you're at, that it is like that. Understand how it differs from the role that you're doing and what you like about your role. What makes you smile when you get out of bed in the morning? What are you excited about? For me, it was being able to do change on a larger scale via different mechanisms. It was different style of challenges. That's what I was enjoying, and a different way to do it.
You had a good point about your company, if you turn around and say you don't want to be promoted. It is unfortunate, some companies, and I've seen this in many companies I've worked, that they define their progression or their recognition via promotions. I think this is a bit unfair. I've now seen the tri-modal view on things, which means that techies that really like being close to the code and being hands-on, can stay doing that, but get a recognition in a different way. You've got to have that conversation with your manager and the company that you're within, within the HR, but there's no guarantees. That's a terribly hard one to change the whole cultural aspect of, but at least be vocal about it.
Nardon: Is staff engineers rebranding of software architects?
Wrightson: No. I think they've come about because of architects. We can do a similar role, and I suspect most architects can do a principal engineers role. This is complete generalization. Architects tend to do upfront design and pass the architecture down towards teams. This came from when we were thinking about physical disks, physical machines that we needed to get by before we started writing the software. Now, we're not. Now all the teams are working in an autonomous manner. It doesn't mean that they can all do their own thing completely, we still need alignment, because we'll never get to those goals. That used to be the architect's role, but now the staff engineer provide that because the teams are owning the architecture. Staff engineer provide that help with alignment, versus directional architecture, and coach teams maybe to own their own architecture and to make the right architectural decisions rather than to provide them the blueprint.
Nardon: Do you think it's feasible and also worthwhile to try to convince your own organization to introduce a staff plus engineer track, especially if you yourself want to pursue it? Have you seen any examples?
Wrightson: It's completely dependent on the organization. I know that at the Financial Times, the track got introduced, and that came from an engineer going, "I don't want to be an architect. What should we be looking at? How should we be looking to work?" She was the one that was questioning ways of working. That's how it got introduced. It's dependent on your organization, and whether your organization needs a staff engineer role. If you can talk to all of your colleagues, there isn't the complexity of alignment often you need a staff engineer for. It's another one of those depends.
Nardon: I think that there are companies that are in different levels of maturity. If we are having these questions here it's because there's still not a standard in the industry about these roles.
Wrightson: Definitely. Talk to people about opportunities for growth. Your company has a responsibility towards you for growth. It depends on which company you're in, and to what that growth looks like and should be provided. This is one route to growth.
See more presentations with transcripts
