Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations Five Behaviours to Become an Effective Staff-Plus Engineer

Five Behaviours to Become an Effective Staff-Plus Engineer



Blanca Garcia Gil takes a step back and goes through a handful of skills that when applied strategically will help one amplify their impact in a team.


Blanca Garcia has worked in the Data Platform team at the BBC, where she built highly scalable data ingestion pipelines and led teams improving access to data in the data warehouse and data visualisation. Prior to the BBC she held a variety of roles: web applications development, mobile prototyping and working on a content management system, as well as writing high throughput APIs.

About the conference

QCon Plus is a virtual conference for senior software engineers and architects that covers the trends, best practices, and solutions leveraged by the world's most innovative software organizations.


Gil: Are you already a senior engineer who is looking to progress their career but not take management responsibilities? Or perhaps you're thinking or trying to get a role that goes beyond senior engineer, and you're exploring what it means to be a principal engineer, a staff engineer, and what are the common things amongst those roles? Or maybe you're here because you're managing senior engineers, and you are looking to gain a better understanding of the roles and progressions, you can coach them to grow their careers further. We're going to be exploring what are the five key behaviors that will make you a more effective staff-plus engineer.

Why Did I Want To Become a Principal Engineer?

The first thing, we're going to start with my story and what was my motivation to become a principal engineer. The last organization I worked for was the BBC, the British Broadcasting Corporation. It's quite a huge place to work at. It has 20,000 staff around the world. Of those 20,000 people, 3000 are in the engineering division. My journey there began as a senior software engineer, and I worked across a variety of teams. One of those teams was the internal data platform. I was there for three years, when something happened. There was a business decision higher up that we're going to migrate our analytics provider. This impacted many areas of the business, but our team was on the critical path, because we ingested, we cleaned, we modeled, we stored, and we also managed the internal access to that analytics dataset. This was a huge opportunity for our team to migrate away from a legacy architecture, which had become very problematic, because it basically had Big Ben style operational issues. Troubleshooting these issues left ourselves very demoralized, because they took a long time to investigate. Sometimes we just didn't have enough time to dig into needle in the haystack type of problems, and also, it left the business without data needed to inform critical decisions. It also happens that I have a background in tech support. Throughout my career, I have been on-call for many years in a variety of products. One of the things I found was a lot of the times, across those organizations I worked for, we were missing the learnings from those life issues, and we were not really applying them. This meant that we were constantly solving the same problems, all these issues were slowing down our delivery of new features.

Going back to our story, I was very excited because I saw this as a golden opportunity to apply those lessons learned. Also, I was in a team who was rebuilding and having that opportunity to make the decisions about the next version of our data platform. Our team had also suffered a high churn, so there weren't many people in my position who understood that context. We knew that it was key to avoid going through the same pains all over again. I also felt that I had a lot to say. I wanted to jump at the opportunity to frame those lessons into questions for everyone in the team. Our team was quite big. We were almost 25 people, and we organized ourselves into squads. We were each of us working in different problems of the areas. One of the key things was that together, we were going to come up with the solutions and decide the technologies which would avoid altogether or at least be able to mitigate the issues we had been coming across in the past.

I took on leadership of one of the squads, who was developing something which we had never had before, which is a data lineage store. This is used in data platforms sometimes to be able to keep a record of all the data that is flowing through your systems. It can help you to troubleshoot issues and understand historical context of things. This data lineage store over time became a critical part of our system because it helped us not only to be able to isolate the failures while we were investigating them, but also keep track of metrics such as service level agreements and also measure the processing latency of the dataset. At that time, my former title was senior software engineer. Looking back, I saw this as the time that I took a leap. I had a lot of people supporting me on this, and set myself on the path to become a principal engineer. When a former role opened a few months later, I really went for it. In summary, my motivation and my reasons, it wasn't about knowing all the answers, or wanting to make all the decisions by myself. I wanted to be able to take a step back, understand the wider picture of the problems that we were dealing with. Think things through and apply those lessons learned, and work with our teams to build something together which we could own and evolve over the longer term.


We're going to be going through, what is a staff-plus engineer? What is the definition of that? What are the different flavors of it, because it can vary a lot? We'll see the different areas that it can vary. Then we'll jump into the main focus of this talk, which is the five behaviors. I've highlighted in the agenda the five behaviors, so there's going to be no surprises, but I will be explaining situations, and how and why you will apply those behaviors. Then we'll summarize all the content together.

What Is a Staff-Plus Engineer?

What is a staff-plus engineer? Do you know what it means, this pretty new term? Essentially, it's the technical roles that come after senior engineer. How did this term come about? In 2019, Pat Kua who's a seasoned engineer leader, and he used to be, amongst many other things, the CTO at N26. He wrote a blog post talking about the three paths of career development for software engineers. In a typical company, a software engineer is considered to be on the individual contributor path. Most people would really think, a principal engineer to be on that same track, but Pat Kua thinks a bit differently. He says that the responsibilities of a principal engineer or a lead developer span beyond contributing as an individual person. Instead, that individual contributor path is reserved for people who are domain experts. This could be people such as a database specialist, or someone who is a performance tuning specialist, and so on. Then there is this new path called the technical leadership track, and that is made up of people who have technical skills, and use them to lead others.

Then fast forward one year later to that in 2020, and Will Larson who is the CTO at Calm, he found out that he didn't have a great understanding of the responsibilities of staff engineers in his team, and neither did they. He set himself a task to understand and document what were those different experiences from staff engineers across different companies. From there kind of draw those common areas amongst them all. He turned that into a book called, "Staff Engineer." That book has been really useful for myself and many other people to gain understanding of the roles and manage their careers more effectively. It also happens that Tanya Reilly wrote the foreword for that book. She wrote a blog post ages ago called Being Glue. I met her virtually last year because we got to go host a virtual conference focused on staff-plus engineers, together. She's also currently writing a book to help other staff engineers navigate their careers. There are a few chapters available which you can read already. Also, if you can't wait, there are many posts in her own blog that provide many resources for staff engineers.

Role Responsibilities

I'm going to start first with the role responsibilities, and we're going to be going through a few of them. The first one that everyone asked about is, do you still code? It's almost like we measure whether we are still engineers or not because we are still coding. In this role or roles, you will find yourself you might be writing code at various times. It can be code for prototyping or exploring some problem spaces. You might be doing code reviews and contributing to certain areas of the code base. Most people would say that in order to remain that technical, you have to code, but in my experience, as I spent more time in a principal engineer role, I found that I took a step back off coding. I was more involved perhaps in code reviews. I was also more focused in mentoring and coaching engineers. There's time and space for coding as well.

The second responsibility is technical direction. What this means is gaining understanding and solving the real needs of the organization. It's not just about deciding a programming language or a technology that you're going to be using, and you perhaps find exciting. It's more focused on the business. Think that in these positions you are accountable to the business first. Setting the technical direction is about owning an area. Then, for example, thinking back about my experience, I took ownership of data storage within our data platform. Then I worked on setting the vision and moved people in that direction. In my case, it was a new problem space for me when I started the role. What I did was I engaged with a supplier, so we work with a third party, in this case, it was Amazon. I also worked with the architect that we had in our team and our product manager, and then the squad. We explored the problem space, and then the possible solutions, because they were quite severe performance issues at the time. We had to take some time first to understand and solve the immediate issue, and then think about that longer term, of what we wanted to get to.

The third responsibility is about mentorship and sponsorship. This key thing is what will differentiate you from maybe more of a senior engineer. This is because you're leading others, and you have to spend time in those around you, because you will have a far greater impact than you could ever achieve independently. Also, a way to create change that lasts is actually by investing in others. What this means is that, just take time to share the experiences and the advice that you have, and build the relationships with the engineers that you're working with. Understanding where people want to get to, and help them on that journey. There's an extra step that mentoring is about maybe helping people, but then the sponsoring thing. Sponsoring is about giving people opportunities to grow, and advocating for them. For example, if there's someone in your team that you know wants to progress their career in a certain direction, and you know there's an opportunity, for example, for them to give a presentation amongst a new group and they would be really excited to do that. You actually give that opportunity to them. You support them along that. These kind of opportunities get people visibility, and also get them to see the impact of the work, and also helps them grow in a way that feels very supportive. Also, that you're not really spoon feeding them, they're doing the work themselves. This will have a twofold benefit. One of them is them growing, obviously. The other one is that because you've believed in them, and you've given them these opportunities, your relationship with them will become a lot stronger. That is something that feels even better than actually committing your own code, sometimes.

The fourth responsibility is about providing engineering context. This is about wealth. Think that every organization has processes for decision making, and to make making those decisions earlier. This process usually entail asking people to provide perspective for different areas, and make sure that the necessary context to make that decision is shared. In this role, you will be one of the people who are asked to provide context and you'll be in the rooms virtually or in person where these decisions are taking place. This is the time that you can create a huge impact. In my past experience, when it came to rearchitect our analytics ingestion pipeline, I took some time to reframe those past pains. Also, I was engaged in other working groups that were making decisions for where our data platform was going to be going a few years down the line. I was asked to explain the types of issues to a group of technical leaders, and to give them that context of the experience I had had operating and maintaining the previous architecture. That context was taken into the principles for the data platform that we're working with. Then, for future technology decisions, it was also documented. Why is this important? Because if we don't hear and we don't document those decisions, one of the issues that generally happens in teams is that you make decisions without really understanding maybe some of the possible caveats and some of the issues that you can have down the line. Getting on board people, it doesn't really slow you down, seeing that is an investment in avoiding future pains.

Then the last but not least of the behaviors is about getting involved in strategic value projects. Sometimes you are going to be spending time working on projects and making sure that they get done, because they are very important for the business, and you're going to be leading others along. Sometimes these projects don't feel like they are very shiny because of the tech, but this is something that is ok. This is where I recommend a talk from Tanya Reilly, called Being Glue. Staff engineers provide that glue. It's about doing sometimes the behind the scenes work, that it doesn't sound that glamorous, but you're making sure that the work is getting done.

These five responsibilities are very wide ranging. It can sound a bit unsettling to some people thinking, is this everything, I have to just manage all of these things on my day-to-day as a staff-plus engineer? Not every day, all of them. You will focus on different ones at different times. The good thing about the role is that it can be a bit about figuring out, what are the most important things for you right now? One of the common things of the role is that, overall, you're going to be working to longer timeframes. I'm highlighting this because it is one of the hardest things to get used to when you transition to a staff-plus role. When you develop software, and you're writing code, and you're writing your tests, and you have automation to do your build and deploy, your feedback loops are very short. You're very used to getting that feedback very quickly. This is very rewarding, because you're moving quite fast.

Then, once you move to a staff-plus role, your feedback loops are not that tight. You're working with people and you are not all the time working directly with the code base. People take a much longer time to give you feedback, and for you to also wait for changes to take effect before you can understand what needs adjusting. You have to learn to be a bit more patient through those longer timeframes. Also, those means that you're actually going to be working in things that have a higher impact. Reframe that and keep reminding yourself that you just have to work through things. One of the good things that I find about these roles is that these role responsibilities, they vary with time. If you like variety like me, you're going to have a lot of joy. I linked there Will Larson's post, which is where I have borrowed these five main role responsibilities.

Different Flavors

We're going to move on to the different flavors of the role. We've seen there's a variety of responsibilities, but how do you know which ones are the ones for you at a given point? How do you figure out what is needed in the context that you're working on? We're going to go and see the variations. Also, we're going to see within the role and within different companies, what are those variations and what they look like? The first flavor of the role is called a tech lead. This is quite self-explanatory. The tech lead guides the approach and the execution of a particular team. They partner closely with a single manager but sometimes they got partnered with a few managers within a focus area. Then there's the architect who is responsible for the direction, the quality in a certain area. They have in-depth knowledge and they also understand the technical constraints and the user needs, and certain organization leadership and navigating that organization. The third one is called the solver. This is a flavor that digs deep into certain problem areas, and he finds the appropriate path forward. Sometimes they focus on a given area for long periods, and sometimes they can bounce between different hotspots as the priorities change in the organization. Then the last one is called the right hand. The right hand is a role that extends a senior leaders attention, and borrows some of the responsibilities. This is a role that you can see at very complex organizations. They provide more bandwidth for senior leaders.

I've actually had the opportunity to work, for example, in my role. I worked with an architect and a right hand. The BBC is a very complex place to work at. The role when I was a principal engineer, I can see that I was a tech lead for given periods, and I was also a solver when I jumped into some crisis, for example, with the performance of a data warehouse. As part of my role, I did a lot of internal presentations at different levels to help people understand the problem space and the context for decisions for our data warehouse infrastructure. Because this was a critical part of the data storage. Then the role that I had, for example, was quite targeted within the problem space, which was data platforms. When I worked with the right hand, the right hand had a much wider scope, which was across entire departments.

Next, I'm showing you a slide, which is, what are the flavors across different companies? This is a diagram that I borrowed from a site that is called Levels FYI is a site that is focused on transparency for tech roles, and salaries. I borrowed data for a few of the bigger tech companies, which is Google, Microsoft, Netflix, and Apple. What I want to do is not to compare salaries, but to compare the different levels that the principal engineers are working at. I have highlighted in dotted lines the three different principal engineers in the career ladders that are in three of those companies, and you find that they are at different levels in the journey. They probably have slightly different responsibilities and slightly different scope. Then there's a couple of them who are Netflix and Apple, that actually don't have the name of principal engineer highlighting them, they still have very senior engineers, but they might have just different names, or just different scopes in Netflix. The senior engineer path is very long. This is for you to actually understand, what is the differences? Also, if you're applying to the roles, be able to draw parallels between the pain that you have, or the company that you're coming from and where you want to get to.

Key Things about Staff-Plus Engineers

To summarize this part, what is the key thing about staff-plus engineers, generally? You have to understand the responsibilities and you also have to understand the levels. I am not wanting to give you a lesson in salary negotiation. It's more about the growth in the role, and does it match your career goals, what you're looking to learn, the types of problems you want to engage with? Also, what is the level of autonomy? Depending on the level of seniority, you will be more tied to a team or more floating between different teams and different areas. Also, what is your ability to influence the outcomes that you want? If a role is too embedded in a team, you might not be able to influence those big decisions that you're looking for. If you are one of the people who is looking to land your next staff-plus role, there is a talk in this same track by Nicky Wrightson, who's going to give you advice on how to learn that role.

Five Behaviors of a Successful Staff-Plus: Communicating and Listening

We're going to jump into the core of this talk which are the five behaviors of a successful staff-plus engineer. The first one is communicating and listening. The reason I'm highlighting this as the first one is pretty obvious. This is a behavior that is a foundation skill that you will most likely have been working throughout your career. As you progress, it becomes a key skill. It is an underrated skill. Normally, we will not be adding this to our career paths, but it's critical for you to think about it, and develop it intentionally. One of the ways that you will be applying it is presenting internally and externally. In order to be effective, you have to learn to navigate through different levels of abstraction. Sometimes you have to be talking very low about the code, and sometimes you have to just talk about maybe principles. Also, while you're presenting, sometimes you're going to be asked to explain to people what the technical strategy means for them and the team they're working in. Also, one of the things that we sometimes forget about communicating is that you are going to spend time writing things. You can be writing blog posts. You can be writing emails. You can be writing requests for comments, which are documents where you want to make decisions, and you actually ask people to feed into those documents. They serve as a way to facilitate sometimes in-person meetings, sometimes asynchronous conversations. One of the things that is the main responsibility of your role is that you are one of the people that can be in charge of driving decision making. This doesn't mean that you are the one who's making the decisions, but you have to get people together, and you have to develop a process for people to make those decisions together.

Technical Strategy

The second behavior is technical strategy. First, we're going to take a step back and explain, what is technical strategy, because a lot of people don't really maybe understand what it is? Essentially, it is how we use the tech to achieve something, and how do you measure it being effective? This is in the context of a business at our organization. What is this business plan made of? It's made of principles. It's made of objectives, and it's made of tactics. A good technical strategy is focused on outcomes, because the teams and the engineers are the ones who should own how to get to the objectives that the organization sets. Why is it useful? You might be asking. As the organizations grow and become really big, you need a shared context. This type of strategy should be providing that shared context, so that people can draw decisions and derive decisions from a similar understanding. Also, it states the priorities, so priorities across different projects, and different goals. It also creates alignment, because if everyone understands where they want to get to, and also what things can be for others, then it makes it easier to align with other teams and collaborate with other people. A good strategy should also inspire you. Why do I say inspire? Because if it's saying what is the problem space and what things you would want to improve, and how they would look good, then you would have ideas as a result of what areas of your products you would improve to be able to achieve those goals. That's what I call inspiring, because you want to feel that you have something to say and you have something to contribute, not just be told all the steps to get to the place.

In a role of staff-plus engineer, how are you going to be contributing or providing that technical strategy? First, you're going to be understanding the systems that you work with and how they connect between each other. You're going to be providing technical context to discussions. Another thing you're going to be doing is you're going to have to learn fairly quickly unfamiliar things. Not just the systems that you're used to working with, but understand architectures, also code bases, and also technical decisions, and be able to contribute to them. One of the things about stepping into new areas is that in this role, even though you have a lot of experience, you also have to not be afraid to ask questions that you think are very simple. One of the really important things is that in this role while you're explaining things and if you want to make proposals to change things, you have to learn to quantify and draw some data from the systems that you're working with. Because sometimes in order to be able to convince people, you're going to have to show them, for example, the hidden costs of projects or the benefits of stopping doing something. That is by getting some data, and then also understanding what the data means. That being able to quantify, that will add a lot of weight to the proposals that you have, because you're showing that it's just not your own personal interests. You're actually speaking on behalf of your team, or sometimes your entire department. It's something that you have to be very aware of that you have to base what you are speaking about, not just on your own experience, but you have to be speaking to engineers across the teams that you're working with.

Networking and Influencing

The third behavior is networking and influencing. Now is when we all think, this dreaded work. Why networking? It is because of one big reason. In this role, you are an enabler. This is not just about you solving the problem by yourself. People are going to come to ask you questions and you're not going to know the answers, and you're not expected to. You can be very helpful and you can unlock people by knowing who can help them with that. How do you know who can help others? You have to work on building up your network. This network is going to help your team but also you're going to help your network because they will draw on your experience to help the team. It's like a win-win situation. It's very important that you spend time developing your network. What are the smaller tasks that you will do as part of networking and influencing? You have to learn how to navigate an organization. What this means is, who makes decisions? How do the internal processes work? What are the different competing priorities? How are, for example, build versus buy decisions made? How do you create a business case, to move change and drive things forward?

Building your network means that you speak to engineers, but you also speak to people who are not in engineering roles. People who are at different levels. Sometimes you're going to have to need some help to learn, who is the person that you should be speaking to? For example, I've used a lot of introductions, people introducing me to other people, so that perhaps they would give me sometimes, and we could just introduce each other and learn what the other person did. Because it is very important that to build trust, you need to be able to speak to people, one-on-one. It doesn't need to be very long meetings, but be able to have that one-on-one focus time. Because that's when you listen to them, and you really get to know them, and they listen to you. That way, you have a more successful relationship for the future. The last thing about networking and influencing is that, in these roles, you're usually not managing people. Sometimes we think that we don't have much power. There is an informal power that comes with the role. You have to be very careful about the words that you use when you're speaking to people, and also your behaviors, because people are going to draw those. They're going to see, and they're going to watch very closely what your actions are. I'm going to summarize the networking and influencing with, use your influence for good. Use that to create good change. I have seen a lot of maybe unintended consequences of people or me sometimes not realizing that a word out of context could really give people a lot of pain.

Technical Leadership

The fourth behavior is technical leadership. I personally quite like this, because it is about getting engineers to buy into an idea, not necessarily yours, but bringing people together, creating opportunities for cross team collaboration. This is a very rewarding part of the role for me. Also, to get people to collaborate together, you have to create that psychological safety. You have to then create the trust in groups. Not only one on ones, when you're networking, but also in the groups that are working together. How do you do that? Guide yourself with your values. Use your differences to bring people together. We sometimes forget that tech is very rich culturally, we work with many different nationalities from all over the world. Our differences can bring us closer if we have the space to share them and get to understand each other. In the role of a staff-plus engineer, you're going to be sometimes spinning up teams quite frequently, and you have to be able to create that trust and get them to almost hit the ground running. This is a way that you're going to be amplifying your impact, because you're going to be coaching them, you're going to be delegating them. You have to learn to break the behaviors, break the work into smaller pieces, so your team can then take responsibilities and get the work done. Also, remind yourself that you have to manage your energy, because people will always take a lot of that. It's more about mentoring and sponsor engineers, it's not necessarily about you doing all the work. The technical leadership is helping others grow, and helping people grow on their own path to staff-plus roles. Because at the end of the day, what you are in this role is a force multiplier for other people and your teams.

Managing Career

The last behavior which is a bit of a bonus here is about managing your career. This is something that you might be thinking, how on earth am I going to find time to balance my own career while I'm doing everything else that we've spoken about? It's about managing your energy, knowing where to flow, and setting time aside to be able to work on the different types of work that you're going to be doing. Some types of work are kind of more meetings, but then there's these other types of work that you need to be very focused on your own, which is what we call deep work. You have to really organize your agenda accordingly and sit down with yourself, write your goals, because this is going to be your way of knowing what you should be focusing on. It should be broad enough, align to the organizational goals. They're going to have quite long timelines. This is going to give you time to actually reflect. I reflect usually every week or every couple of weeks, and I know many senior engineers do. Just reflect and understand, what have you accomplished? Are you still on track with those goals? What things have changed? Adapt as you go along.

Also, your goals help you understand when you have so many things on your plate, what is the top priority thing? What do you need to focus on? Why are you doing something? Also, there will be some things that come to you that you don't necessarily have to do. It's not about doing everything, it's about knowing what to focus on. The rest, you have to either delegate. You discuss with your manager, you discuss with your team, but it's not for you to be doing. The very important thing is to ask for feedback in your role, how you're doing. Have those conversations regularly. One of the things about giving feedback is that you have to also become better and more effective about giving feedback. Because remember, you're growing other people around you, and you're also becoming a better communicator, so you're slipping bits of feedback into different areas, not just doing a once a year performance review, because small bits of feedback more frequently will help you more than a big document every so often.

In order to grow, you will need mentors yourself, but the people who will really grow your career significantly will be sponsors. Be always on the lookout for sponsors. If you can have a formal sponsor who you can liaise with regularly, that's even better, but not everyone has a formal sponsor. Spend time talking to people outside your organization, to keep an eye where things are. Go to conferences, such as this one. Also, have that group of people that can cheer you on when you have days that you feel that you don't accomplish anything, but then can also challenge you and make you take a step back. Think things twice before you decide where to go with something. Take care of yourself, because if you try to do everything, you're going to end up burnt out. This is something that can catch you without you even realizing. It's very important that when you take time to reflect in this role, that you know where you're going towards. You also know what motivates you, and what is driving you. You realize that you are actually spending time on those things, because those goals help you sustain that motivation and create the discipline to keep growing in the role. The summary in this case for managing your career is setting the goals, tracking them, and reflecting.


Understand what level you're working at, and what the expectations of the role are. This is the first thing to start on a good foot on the role. Apply these five behaviors intentionally, depending on the situation that you're in. Then remember and remind yourself that this role is on the technical leadership path.

Questions and Answers

Nardon: How do you balance the time expended in mentoring and teaching others with the time that you need to use for doing your own work? How do you manage to do that?

Gil: I think for me, it involves a lot of blocking out the slots in my calendar. At the end of every week, I used to have my little reflection time that was like 5, 10 minutes. I would also look at the week back and see, what meetings have I been in? Where have I spent my time? Then, almost set goals like how much time can I or do I want to spend mentoring people, and just allocate the time in the week intentionally. I found that in the role, if you wait to have free time, that just doesn't happen, there's always something else. There's always something urgent, someone that needs something in the time. For me, it was about planning, and about also offering to people. If I had some space for mentoring, then maybe I would share it with sometimes the managers, and say, "I have a bit of time because someone I was mentoring doesn't need that any more. If you think someone else could benefit from time with me, just please put me forward for that." It's about allocating time, and then almost planning. It doesn't happen that much on the spot these days.

Nardon: How do you keep motivated when you are working on initiatives that don't involve shiny things, but that do have high organization value?

Gil: I'm a very curious person, by nature. I've spent about 16 years in tech. At first, I wanted to work on all the shiny new tech. Then, over time, I realized that usually the nitty-gritty problems involve the not very shiny stuff. In order to motivate myself, I try to always think, what is it for me to learn in this situation? What are the takeaways? Also tell myself that it wasn't forever. I almost put a timeframe, because there were some jobs that actually I have to admit that I resigned because I was not mature enough to think that that wasn't forever. I thought, my career is going down the drain with this. That can be a very common thing. What I did in the last couple of years, especially when I was working on the data warehouse problems that was not very shiny at all, but speak to my manager regularly. There was a point that I said to them, I think I've had enough of this. We set some goals to almost make myself redundant from that problem space and figure out what people or team would be happy to learn about it. It was me selling a bit the problem space, because what is something that you have learned and you might have gotten bored. It might be something that is a learning opportunity for someone else. It's not forever, and also hand over before it gets too late. Then you're like, "I am dead tired of this. I don't want to do this anymore."

Nardon: Do you recall a tech strategy that stood out to you as particularly successful?

Gil: If you remember or you know the tech strategy at least in your department or the organization that you work with, that means it's already successful. Most people don't know what that tech strategy is. I used to know the strategy in my department, but I remember doing an exercise with my manager, because I was asking them, how do you link this up in the organization? How can I have bigger influence on these problems that we're facing? I realized I had no idea how the tech strategy linked. That's when I realized, this tech strategy is not really very successful, because if I don't know, then my team doesn't know either. Success means that you know it.

Nardon: What approach do you use to quantify data that's hard to quantify? Data about usage, revenue are easier. Something like comparing the cost benefits of different technical pivots sometimes aren't obvious.

Gil: My experience with working with data is, especially when you're at the start of maybe importing a dataset, which is what we did in the data analytics platform. Spend some time setting up the metrics for that data, and see whether those metrics can be achieved with the dataset that you have or not. Also, ask yourself, why do you need those metrics? What are the decisions that you want to be able to derive on them? Because I have seen that we went in my team from almost having no metrics to too many. Then people just get bogged down by so much data, and no one really looks at them anymore. Going back to your question about, how do you create those metrics? The earlier you do it, the easier it is going to be.

Nardon: Could you provide some examples of goals for becoming staff developer or growing as a staff developer?

Gil: The quick path, figure out from these behaviors, do you find any areas particularly difficult, or are there any gaps? If you don't know, ask for feedback, not just your manager, but your peers. If you know people, you can just say, "I'm trying to grow further in my career, and it would really help me if you gave me a bit of insight into what was the recent experience we had working in this project together." Don't say the word feedback. A lot of people get really shaky about it, and they feel that it's like a big responsibility. You just want a bit of insight into how they perceive working with you. I found that people were very constructive, and it really helped me and it kept me motivated, because then people saw that I was trying to improve. That helped me then go and sit by myself and then sit with my manager and say, "This is the feedback I've collected, and these are the goals that I think I need to work on." Then my manager would also contribute and maybe give me some feedback, but it was always driven by me. My manager in that case gave me a bit of room with that, because I think they saw that I was very invested in improving, so they just left me to figure out things.


See more presentations with transcripts


Recorded at:

Sep 30, 2022