Navigating AI, Platform Engineering, and Staff-Plus: InfoQ Dev Summit Boston Preview

Eder Ignatowicz: Hello, fellow developers! This is Eder Ignatowicz, your Chair for the upcoming InfoQ Dev Summit in Boston, If you're looking to stay ahead on critical topics like Generative AI, security, modern web applications, and more, learn directly from over 20 senior software practitioners navigating these challenges as they share their experiences and practical insights you can apply immediately. Plus, there's plenty of time to connect with peers and speakers at our social events.

InfoQ Dev Summit Boston is brought to you by the team behind InfoQ and the renowned QCon international software development conferences. Find out more at InfoQ Dev Summit Boston (June 24-25). I'm looking forward to connecting with you in Boston this June. See you there!

Daniel Bryant: Hello, and welcome to the InfoQ podcast. My name is Daniel Bryant and today I had the pleasure of sitting down with a panel of speakers from the upcoming InfoQ Dev Summit running in Boston on June 24th and 25th. I'll let the panelists introduce themselves in just a moment and then we'll launch into a fascinating conversation that covers many of the most critical technical decisions that senior software developers face today. We'll talk about platform engineering, software testing, Staff-Plus good technical leadership, and many more topics.

Introduction to the Panel and InfoQ Dev Summit Boston Overview [00:53]

Dave Grizzanti: Hey everyone, my name is Dave Grizzanti. I am a principal engineer at the New York Times, and my talk at the Dev Summit coming up in June is going to be about the platform that we're building. At The New York Times, how we're trying to engineer paved paths for developers, and just make a more user-friendly developer platform.

Loiane Groner: Hi, everyone. My name is Loiane. I'm currently working as an engineering manager's lab development manager, and I've been in the industry for 18 years, primarily working on the Java technology stuff and a little bit on the front end, as well, with Angular and similar frameworks.

Thiago Ghisi: Hello, everyone. My name is Thiago. I'm the Director of Engineering at Nubank. Nubank is a FinTech, and we're going to be talking about how to grow beyond senior, telling about the perspective of someone that is never been a staff engineer but has managed a few and seeing multiple failures.

Daniel Bryant: Fantastic. Yes, some great topics already springing to mind. Eder, last but not least, I'd love to get your introduction.

Eder Ignatowicz: Thank you, everyone. My name is Eder, a Software Engineer at Red Hat for more than 10 years. I spent the last 10 years working with Java and front-end developer. My scope is on developer tools. Recently, as many of us, we move it for AI. I'm working now with MLOps for Kubeflow Tools. And beside this work, I'm also the Chair for InfoQ Dev Summit Boston, that's why everybody is here. Thanks to everyone for coming. And also, I'm the Co-Chair for the QCon London 2024.

Daniel Bryant: Yes, very briefly everyone, I’m Daniel Bryant, one of the co-hosts of the InfoQ podcast. My background is in Java development, so I feel at home here. I'm also building platforms and working with teams building platforms at the moment, IDPs. So David, I recognize what you're going through there, as well, and I love building teams and taking them to the next level. So Thiago, what you mentioned about the staff-Plus, like building folk’s career, I think that's really important too.

AI's Impact on Software Development Lifecycle [03:12]

Shall we kick off, and Eder, you teased the AI thing there. Elephant in the room. Everyone is doing AI. I just got back from Kubecon in Paris, AI was everywhere, right? How do we think that the software development lifecycle is going to fundamentally alter with AI? And feel free to pick any part of the STLC you like. I'd love to know what you're most excited about in the near term with how AI can affect software delivery.

Loiane Groner: I can speak from the experience that I have from generative AI tools that I've been using, especially with Copilot, which is a generative AI that helps developers to streamline development, and also testing as well. The experience that I had is that it definitely boosts productivity. I think one of the major concerns that folks have, and especially what we read from the community, is that, "Am I going to be out of a job because of these AI tools," right? And I think we've all been there. We have created tools that are generating code for us at some point in our careers, just to streamline the process, and streamline development as well. And I see the generative AI as one of those tools.

One thing that we have to be careful of is not to trust AI 100%, to not trust blindly what the code that is being generated for us. You still need to review what's being proposed to you, what's being recommended to you, and then change accordingly. One of the things that I particularly enjoy is that some of these tools that are using the code base within the companies, so those tools are going to be able to learn what are the standards, the development standards that you use, the code practices, security practice as well, that are being used, and help those developers to code and code the solutions according to the company's standards as well.

But it definitely helps with productivity. I've used a few times as well, especially when generating task cases, this is what I enjoy the most using this tool. Usually, the first task case, I have to write it myself just to tell the tool how I like things done. As I mentioned, the code that is being suggested might not be exactly the code that I want. So usually, the first test case, I write it myself and then the tool is able to learn what I'm doing, and then the next ones it's going to suggest and generate according to my preferences. And of course, we have to tweak here and there, but overall, it's speeding up development a lot.

Thiago Ghisi: What I'm most excited about is not necessarily the coding generation part, it is more like AI helping us to answer, "Are we building the right thing?" Helping us to navigate complexity, right? For example, go over a massive amount of user feedback and try to prioritize things or help to almost understand that complex going on a code base and trying to create diagrams in a way that allows us to visualize the code base in a different way. And I think that's what I'm most excited about, there's this book called Your Code Base as a Crime Scene, right?

Daniel Bryant: Love it.

Thiago Ghisi: I'm really excited about applying AI to some of those principles to help to, are we working on the right hotspots? Are we working on the right priorities? And I think also, as Loiane was saying, try to understand backwards what is this code doing or is this the right test, and giving some template and some structure to how you want to apply AI. It is another fantastic use, and I cannot get tired of playing with GPT4. And I think they always impressed me, but I feel there are so many unknowns at this point, right? So many unknowns that you have to double, triple check every single thing that's happening. But I'm really excited about how it's helping us to navigate complexity.

Daniel Bryant: Love it, and definitely, as Adam Tornhill, we've actually had him at QCon speaking in the past. I'll definitely put Adam Tornhill's book, Your Code as a Crime Scene, a fantastic book. I'll link that in the show notes as well. Anything else, David?

Dave Grizzanti: Yes, one thing I wanted to add, because anyway, I think people think of tools like Copilot and just software generation as the primary example that is going to affect developers positively or negatively. But one of the areas I'm really interested in, and Thiago hit at this, is not just helping developers write code, but using, in my case, platforms that teams are building. Because oftentimes, every company has some unique twist on what they're building based on their requirements or systems that they have. So you're not just taking something off the shelf that may have perfect documentation. So you're getting users to adopt things and you're trying to keep up with the tools, right, good documentation. But in the end, there's a lot of questions and answers that end up happening over Slack or messaging tools you use.

And in many cases, what the developers want is they're like, "I want to deploy my app but I have this unique use case." That answer ends up needing to be curated by a human, but in reality, it’s probably buried in our documentation someplace but they don't want to spend 45 minutes reading it. It'd be great if you could ask a local ChatGPT-like tool, "I want to build my app and have it publicly accessible and provision a database and do this," and it can give you the YAML or whatever you need to do that, but that's specific to your company. So that's something I think that could be really helpful.

Daniel Bryant: Plus one to that. I'd say I'm definitely working in that space and that sounds like the future, right? Love it. Eder?

Eder Ignatowicz: Another point that I experienced, as I mentioned, that I'm onboarding a new team and new domain, there is AI and Kubeflow and MLOps. I had zero knowledge of Python two weeks ago, because Kubeflow as a base, is a complex project, and each person that I talk to that works in that area, it's hard to find someone with their full picture. The LLM, especially with ChatGPT, makes my onboarding a much more pleasant experience, especially the amount of questions. They are the simplest questions for people on the team, especially the senior, that they want to bother them so much, that the LLMs can answer. And especially this size of a complex because the Kubeflow code base is huge. Because each project they lives independently, and in the end, they are packaged together, so it's hard to be in one brain of someone of this complexity. And LLM can be, it's been a really helpful tool for me to onboard faster.

My reply to this question before having this onboarding experience was, it’s a nice assistant to my developers, but now a familiar highlight is on the onboarding on a new code base in a new domain. It's much more better than being stuck for hours in problems.

Thiago Ghisi: Here is an interesting use case I have seen. Nubank is a Clojure shop, and there are a lot of developers who have never worked with Clojure functional programming. So I think one use case you have seen is, as you navigate on the code base, you ask what is this function doing? He's like, the few developers that I have mentioned, try that before you ask on Slack, and they have been pressed by how much easier it is to digest and to do examples, and even, "Oh I want to write this in Clojure." I would write a similar thing in Java, how would it be the equivalent that would be using the functionals, and it's really powerful.

Shift-Left Approach: Security and Reliability in Software Development [10:38]

Daniel Bryant: A few things that popped out to me there. One was around some understandability, a real use case where I've been able to understand systems, that you perfectly said it, Eder, I can't load it all in my brain, I need that Copilot, I need that second brain. Can I load it all in? I think that does relate to architecture, right? Always a classic coupling in cohesion, and I wanted to look a moment, something I hear a lot at in InfoQ and at QCons is what's the right size architecture for me?

David, you touched on it, in terms of your platform for your company was an architecture for your company, right? And there probably is no one single answer here, depends on the use case, machine learning versus web versus all these other things, but what do folks think? What are you hearing around serverless versus microservices versus monolith? Are people doing only one architecture at the moment, or are we definitely saw that microservices 10 years ago? Everyone was doing microservices, or are people mixing it up now, perhaps with the benefits of AI too?

Eder Ignatowicz: It's funny because when I join a code base other team because I have opportunity to work with multiple teams with the Red Hat because I work with tools. When I talk with a team that go 100% on microservices, they want to start to couple back some microservices to become bigger. And now, when I got a jump over a team that I have a single monolith, their problems are related in regard to the monolith that they want just the monolith.

So my answer for this question is that there is a middle term. Especially what I like is to bond with the context of the team where the team is able to have a fully understanding of their domain in their scope and they can move up. That's why I mostly like about microservices and microfrontend is to make the team be scoped inside the domain and worry and hide the complexity. And then have clear APIs and the team stops about those APIs, … When they ask about, what's the right size? I'm not able to answer this, this is a tough problem. There is a lot of depends on the context.

Daniel Bryant: So a lot of nodding along from Loiane and Thiago as well. Do you want to add to that at all?

Thiago Ghisi: So the one thing I would add is, at the end of the day is about model urge, right? You want to have things that are independent and you can load in your brain pretty much going back to LLMs. One thing that might be changing is that now we're able to load a much bigger code base because we're able to navigate of assistance. That in the past that as we would try to keep things as small as possible, and now, if LLMs and AI can help us to find those boundaries, right, the bounded context and help to pretty much make it clear when boundary is not clearly defined, when there's there are real violations. So that maybe you don't need as much would say, set the repo level, at the network layer level. You can have other tools that are setting the boundaries in different way, but I don't have strong opinion in this.

As Eder said,I think every time you go to one side, you miss some part of the other side, and there are challenges and benefits on both ways. I think AI can definitely help to set new grounds on this, I guess.

Loiane Groner: The experience that I'm going through, we have a little bit of everything. There are applications that we're trying to segregate, maybe have distributed modules, and even break down to microservices. There are microservices that we don’t want to go back to monolithic approach. So again, it really depends on the scenario, on the use case as well. But one thing that I find it's a little bit interesting that as a developer, you always will want to use the latest technology, whatever is the hype right now and whatever everybody's talking about. But having firsthand experience with managing an entire product, knowing how much it's costing to make those decisions, that takes a toll as well. Even you as a developer, you want to use whatever it's new on the market, you have sometimes to be a little bit cautious as well and how much that's going to cost at the end of the day. So this is also another concern that we have to think about when making these decisions.

Daniel Bryant: That's one latest hotness. David, platform development, platform engineering, latest hotness, right? How do you think architecture relates to platforms and vice versa?

Dave Grizzanti: I do think the modular monolith is an interesting sort of hybrid between microservices and then what people call microservices but are in reality just distributed monoliths. Because they have tightly-coupled dependencies on each other, I saw a lot of that in my previous role with applications that were, you deploy them separately, but in reality, they all need to be up and running in order for the app to function. I see all teams leaning into monorepo's as well recently. I know that's been an up-and-down trend. It's interesting being in the platform space seeing that because, from the software side, there's a lot of advantages to it, shared libraries and everything. But it gets tricky when it gets to deployment and infrastructure management with that because sometimes the monoliths are managing it, but they want to deploy their software differently, but they want the benefit of having everything but a shared code repository for shared libraries.

But then it gets tricky trying to manage all of this development and deployment workflows. So I think it's hard to strike the right balance, but I do think that some mix of shared code and shared module but not trying to decouple deployment as much as we went to with microservices is probably the right balance.

Daniel Bryant: Riffing on all the conversations there, we, as developers, we do get distracted by the shiny sometimes, right, the new thing? And we swing violently to one side then we swing back. Like my, dare I say it,  20-year career, I've seen literally the various different approaches for dumb clients or pushing the complexity to the backend and vice versa. I've seen monoliths, I've seen SOA, I've seen microservices. We are constantly swinging around. Hopefully, I like to think we're getting better each time, but there is definitely some swinging going on. That's why coming to places like the Dev Summit and chatting about, "What are you doing?" And hopefully, learning from other folks, and not making all the same mistakes is a really good thing. So I think that's fantastic. I want to shift gears a little bit now and look at some of the testing, and so, things like shifting less than security, that kind of stuff.

Platform Engineering at The New York Times [16:43]

We've already mentioned a few of these things, but I hear two things actually. I hear some folks saying, we need to shift everything left for developers, think about security earlier, think about all the ilities, reliability, all these things, scalability. Then I also hear developers quite rightly pushing back, going, unless you give me the tools, I can't think about all these things, right? So I'd love to get people's thoughts. There's definitely a platform angle here. There's a development angle, there's a management angle from a people leadership point of view as well. And I'd love to hear about the current challenges you're all bumping into. So, who wants to go first on the shift left? Is it good or not?

Dave Grizzanti: I can jump in from the platform side with a few anecdotes that I've seen. Yes, I think this is the better trend over and over time. I was at Comcast Security and had a quote at the time, it was like, "Security should be built-in, not bolt-on." So it was like this big shift to get people to think about it at the beginning of the life cycle, which is great. But I think if you don't give people the tools or the patterns to follow, then what happens is they end up solving it their own way. And you get a lot of drift in what tools they pick or how they do it, and then it's almost the same problem that you have with infrastructure costs and everything. It's hard to wrangle it back in after time.

Same thing with reliability, people establish different types of SLOs, use different monitoring tools. It needs to be part of the life cycle for developers. But I think similar to what languages people are using and developing paid paths, we really need to come up with patterns for people to follow and give them the patterns in the beginning and establish that at the get-go instead of it just being something that they have to figure out on their own.

Daniel Bryant: I definitely think codifying best practices at both in the human understandable way, but as we alluded to, maybe from machines in the future is something I'm hearing a lot even from the platform space. People are like, "What's the tool I should use to understand the costs of this change to the architecture? What's the tool I should use to understand security?" And at the moment, they're all quite diverse tools. I come from the CNCF, the Kubernetes space, and the landscape grows every day. It's like a massive landscape, right? And just figuring out which tools to use, it's half the battle sometimes.

Eder Ignatowicz: Everything connects with a well-established, perhaps in the company of a platform engineer. As David said, in our way to standardize because this should be deciding... We should shift to let security but deciding which type of application, what to be my providers but to be my observability tools should be in point of view at least. Our responsibility of the engineer to consume those tools. But having access and providing a standardized way to consume those frameworks should be a matter of the platform engineer, because, in the end, if, as we said, each team decides to run their own security education, then on observability framework this will blow up in production with 10 different systems to consume and make those systems to integrate. So, I think connects a lot this shift to left efforts that we are having in an industry. Also, with the platform engineer because as we said, we need to have an easy way for people that are building applications to easily consume those tools.

Thiago Ghisi: Yes. That's a really interesting take. Almost, if you think about a couple of years back or maybe 10 plus years back, it was almost impossible to build things in because you didn't have enough platforms, it didn't have enough maturity on most of the things. So it's almost you're reinventing the wheel every time you're doing a new code base, deploying a new service. Now with microservices, it's almost like you get a lot of things out of the box, right? You get a lot of the good standards, what the company expects for you to be doing in terms of security for logging. And I think that helps a lot with the shift left. I had never thought about the relationship between those two sides of the coin and how the evolution of both made easier. Of course, DevOps and all that how combining and automating things became critical to built in more solutions versus doing later, right?

I think one challenge that I still see, and I think that's more on the performance side, is almost how much you balance investing a lot on fine-tuning early on when you still don't know if that piece of the infrastructure is going to be critical, is going to be a bottleneck or not, and how much you do as you are rolling out, as you're seeing the bottleneck appearing. I think security logging out those cross-functional requirements, let's say, are fine, but there are some that almost you have to play with it to be able to iterate on it. You never know how much you should invest. I think performance is one of those that, in my experience, has been challenged to build in, right, because you never know where the bottleneck will be.

Daniel Bryant: Yes, big plus one to that Thiago. I think, as they say, it was sort of premature optimization is the root of a lot of evils, right? And that's that delicate balance because yes, if you build something and it's not in any way optimisable, nightmare, right? And the same with security, I like your built-in versus bolt-on, David. I could totally relate to that. I've seen some systems whereas a consultant I was brought in, they're like, "Make it secure." And I was like, "What? Where do I start with that?" So I think that there's a lot of challenges with this stuff. And again, come back to the AI thing. I think AI could probably help some of the challenges I had back in the day of understanding these systems, but I do think we're moving to this sort of experimentation mindset now. So it is put some stuff out there, baseline security, baseline performance, but the ability to optimize if we identify and we want to make the changes, right?

If there's anything else on that topic. Otherwise, we can move to a bit of platform engineering. I know we've touched on this a few times. I'd love to just dive into something I'm hearing quite a lot at the moment around as a product, platform as a product is being brought up. And I've heard also something I want to connect the dots on. I'm sure a few of you bumped into Team Topologies, which is a classic piece of work by Manuel Pace and Matthew Skelton, buddies of ours at InfoQ. But I've heard a few times us talk about APIs, and the way I look at Team Topologies, it's almost like an API for your teams, right, your people as much as they're the systems. So I'd love to know people's thoughts on platforms.

Is your company treating the platform as a product? Are you looking at things like team topologies where you have your stream-aligned teams or your sprint teams, your scrum teams, whatever want to call them, enabling teams, platform teams? I definitely see a lot of this when I'm chatting to folks in the industry, but are you seeing that too? Are folks really embracing this product mindset, this Team Topologies mindset? I see you're nodding there, Loiane. You're definitely seeing that in your work.

Loiane Groner: Yes, we call it segregation of duties because, at the same time, it's important for you to know everything that's going on. It's important for you to know everything that needs to be done. But, on the other hand, it's also good to have teams specialized to do each part of the development life cycle. The development team, apart from the development, building the product, and building the functionality, they also need to know about security. They also need to know a little bit about testing. They don't have to be experts on it, but they should be able to have the least amount of security that's expected within their code. We just talked about it at the same way, the testing part as well with all your unit testing, integration testing from the development perspective. And, at the same time, you have a team that is specialized in Agile or Scrum master that their job is only to be the Scrum master of the team.

They're not going to be developing, or they're going to be something else. And, these responsibilities, they also can be done across teams as well. Not necessarily if you're a Scrum master, you're going to be responsible for only one team, but you'll have different teams that might be from different organizations or might be contributing as part of the same department or the same line of business. So, definitely have seen that shift. And it's good as well because at the end of the day you need to know what's your responsibility, right, what's your role within the company. I know that when we cross on above the senior level, the Staff-Plus the principal, this line's a little bit blurry because you're doing a little bit of everything. But especially for some teams, if you can have that definition of what exactly you are responsible, what is the expected outcome from your role, and also to assist the company, how do I evaluate the performance of that particular person? So if you have that definition defined, it definitely helps.

Daniel Bryant: Yes, multiple angles here, right, in terms of... I like what you said, in terms of being super clear on responsibilities because in some of the jobs I've struggled in, I was not clear of my responsibilities sometimes, all the team's responsibilities. And so Team Topologies that applies that kind of API with SLIs and SLAs on top, right? Which I think is really again, a bit of a programming way of looking at building teams. But I like that with my background. I think that's interesting. Any other comments at all on what platforms can and can't provide?

Thiago Ghisi: Yes, so I mean, another comment on my side is about the platform as a product. And I mean it's something I have seen a lot throughout my career, especially in the early days that a lot of the platforms were created with the intent of creating reusable components and for engineers, what someone thought it was a good idea. But later on, what I have being funny is that those kinds of platforms that are not as successful as the platforms that are created as a product in the sense that you go after the customer, you ask them what they are struggling with, where the complexity is, and you almost reverse engineer what is being a pain point for them. And then the platforms on top of that instead of, "Oh, I believe there is complexity here. I'm going to create a platform for this."

A lot of cases of platform teams that have been put in together are more and more, "Let me talk to a lot of those engineers or even product people that work on those areas, and let's see what they're struggling with and then let's build a case for platform." In the past, that was the completely opposite platform. It was created by engineers, and now almost, we're embracing more PMs, more designers, UX on the creation of those platforms to set the boundaries at the customer level because I think that is critical for later on. Like, how you're going to find documentation, how you're going to find your APIs, it all comes from there. So it is incredible to see this shift as well.

Dave Grizzanti: I had the feeling just like for us at the times, a lot of the initial momentum around the platform is to save money, get consolidation of technologies. Obviously, they want to improve developer productivity, but a lot of the choices initially made are not necessarily what's best for internal developers. It's like, "What's best for the company?" And then we're like, "Okay, yes, it needs to be user-friendly and usable because we want to improve. They might be used to using out in the world from the major cloud providers who've been building it for 10 plus years."

So it's just trying to find that balance of quality and taking customer feedback and figuring out where that balance is. The other thing I'll say about the team topology thing that's been interesting is, at least for me and then other folks I've talked to in this space, is that every company's modeled differently just based on how the teams were set up at the time, some historical context that might be relevant to the company and what's the right balance, what team controls the runtime and what controls the developer experience, who build the IDP, what technologies are being purchased and used versus built internally and how do you align those so you're getting product input from the right people, but you're not having this kind of ivory tower architects that are saying everyone follows these exact rules.

People still have autonomy to build and experiment with things but not get out of hand so that they're going off on their own, and doing something that might impact the developer experience in a negative way.

The Staff-Plus Engineer: Navigating Career Growth in Tech [28:13]

Daniel Bryant: We're hearing a lot of interest around Staff-Plus, for example at InfoQ and QCons as well. And I'd love to open the floor as in what's everyone's experiences in terms of being part of a team, of leading a team. How have things changed over the last, say 10 years as software development changed in general, what do you think? What topics are top of mind that we're going to be discussing at the Dev Summit?

Thiago Ghisi: Okay, I'm going to start with, I was talking to an old friend about how when we started 20 years back, there was no such thing as engineering manager or as staff was. It was pretty much everybody was an engineer and there were also some roles that disappeared. Like PM was not there. There was the assistant architect, the person, the BA. You don't see much of that specific roles is there, and incredible how much the evolution of both sides of the equation, right? The management track and the IC track have actually put us in a much better place, and how the almost segregation of duties, as what they would say on the kind of IC versus management track, also helps us a lot to separate responsibilities and help to scale, especially when you have a big engineering org, and you have a lot of problems, a lot of competing priorities.

So the first thing I want to bring to the discussion is that those things are new almost. I don't think they're probably 10 years old. I don't think there are companies using Staff-Plus or maybe the IBMs and Suns of the day in the early 90s, but they were rare. But the popularity of career tracks and having those new levels formalized happened recently. And I think the topic we're going to talk on the InfoQ Dev Summit would be more about the patterns that I have seen for engineers that have been able to not only grow as senior engineers, but they were able to go beyond that to the Staff-Plus level and why so many senior engineers that don't understand that going to Staff is a completely new job.

It is not doing the same and it is completely different. You have to operate with a different archetype. You have to delegate a lot more. I'm going to talk basically about the shortcomings and some of the patterns that I have seen of those successful people, but I would love to hear from others if this understanding of those things are recent and what you have seen before I jump into that.

Eder Ignatowicz: Yes, I have the pleasure to work with the InfoQ and the QCon since I was a junior developer. I was the guy that was collecting votes behind the scenes as a volunteer in the past. Because there was no clear definition and one thing that I know is that I don't want to be a manager. So when I saw that people at the QCon, I always take the chance to ask those people what they are doing differently. And I did that for the last 10 years. So we met each other. My favorite question is, how do you end up doing what you are doing right now? And the thing is, in the last 10 years it's so many different answers because I think our industry is new and it lacks understanding of the role. And each company has different definitions of what this person after senior does.

But all the companies, most of the companies, they have such type of position. And that was funny because every person gives a different point of view of how, what they do, and why they end up in these type of positions. And after Will Larson launched his book, the Staff Engineer book.

Daniel Bryant: Great book. Great book.

Eder Ignatowicz: When he splits in the four archetypes, the tech lead, the architect, the solver and the right hand clicked like a lamp for me.

Daniel Bryant: Yes. Nice.

Eder Ignatowicz: Because out of more than 100 people that I talked at QCon, I was able to compartmentize them and each of those categories and even put myself on one of those categories. Going back for a question, Thiago, I think our industry is unhappy that we started this conversation at QCon two or three years ago with the track. And I'm happy that the industry is moving forward to have such type of discussion, and more and more the staff people that are going beyond senior, they're being more vocal about what they do and what are the roles, what are the input, what are the expectations? And I'm super happy because we are able to do these for people that are starting their careers. They have a clear path of how to stay at IC. I totally respect the managerial work and the director-level work, but there is different work than I see. And now I think I'm glad that we collectively, as an industry, we are able to share this knowledge more openly of what have beyond senior

Thiago Ghisi: And I would say it's your gray area, right?

Eder Ignatowicz: Oh, yes.

Thiago Ghisi: Especially how you become one, right?

Eder Ignatowicz: Oh, yes.

Thiago Ghisi: How did they differ across companies? But the other thing I want to bring to the equation is, I think the Will Larson's book was definitely groundbreaking on the staff I see side. But I think the work actually started early on because the management track was as ambiguous and as problematic as the staff side was. And I think there was another book, I think it was The Manager's Path, that was launched a few years that also created the management track engineering because that was super like, "Okay, what is the engineering manager? What is the tech manager? What's a senior engineering manager? What is a director, what's a VP?" Those definitions were never there, and were never in written format. And I think that work started to almost open source career letters from different companies opened up a lot of new material.

Will Larson's book, Tanya Reilly's book that came later on that also was super great. But I think the one thing, and I see this on both sides, right? Both on a promotion of someone from senior to staff or someone from a tech lead to engineering manager, there's still a lot of variables that are impossible to quantify on the checklist, right? And I see a lot of folks whenever they were able to grow from junior to mid-level to senior almost following by the book, right? And they feel that from senior to staff or from, let's say, tech lead engineering manager, director is the same formula. It's not a formula and varies a lot. And that's why a lot of people struggle with that because they want to apply the same formula to go to a completely different level. That's why I actually argue that staff engineering is a completely new job.

It's like the same way that, okay, moving from IC to manager is a completely new job. Moving from senior engineer to staff is almost as different as moving from IC to manager. And the engineers that don't understand this tend to struggle a lot more because they still want to be the solver. We actually have found a lot of names that, okay, I was always this archetype, so I can just apply the same that I was doing and do the same here. And that's actually a problem because, in my experience, solvers are actually deception of deception. I have not seen many. But folks look at the archetypes and you, "Oh, it's almost 25% each." No, it's almost the huge majority is on that lead architect side and right-hand and solvers. I can probably count in my hand, how many of those I know because those are that rare…

Eder Ignatowicz: At Red Hat is the same audience. It's like, right hand is the group that works with the CTO, a really small amount of people. And the solvers was, it's less than 10%, I would guess one 2% and all the others are our tech leads and architects.

Daniel Bryant: I'd love to get, Loiane, your thoughts. And David, you already mentioned about some changing role. Thiago mentioned there, that plus is you need that bigger picture, right, compared to what we did as a more senior IC.

Loiane Groner: Definitely. Yes. I did the transition myself from my IC to a tech lead. It's still an IC, but it starts to get a little bit more responsibility. And that Manager's Path book, that's great for that to know exactly what do you need to do to be a tech lead. And then from a tech lead to a team lead, getting a little bit more responsibility until I became a tech manager/engineering manager. It's definitely a completely different role. I do a lot of technical things as well because I enjoy doing that. And this is one of the things that I ask to keep doing because it's something that brings me joy. Completely new job, right? You can leverage all the skills that you have, but as Thiago and as Eder already mentioned, it's very different in the same way that when you become a staff engineer. As Thiago mentioned, it's not just the next step.

Again, it's the set of skills that you have to learn a completely different. And some people see it is the next step for your career if you like to continue as an IC. But at the same time, and I'm just going to raise another question here is it is completely okay to stay at the senior level as well if you don't want that set of responsibility? So not necessarily you have to become a Staff-Plus engineer or a principal engineer after you reach that senior-level or a tech lead level. It's completely okay to stay as well and learn new tools, learn new languages, new technologies. Again, at the end of the day, when we're talking about careers, you have to do something that's right for you. There is no recipe, this is what you should do, this is what success looks like. If you're not a staff engineer, you're not successful or nothing like that. So at the end of the day, I just have to do the right thing for you. What brings you joy.

Daniel Bryant: Okay, very well said. David, do you have any thoughts? I think that New York Times have got an engineering ladder, from what I understand?

Dave Grizzanti: The Times also does, but maybe it's fewer positions than Comcast did and talking with other folks. I think every company has different variations of this ladder. I think the biggest struggle I've seen with folks is a career growth and what they want to do, but also wanting to simply make more money. Which is an interesting dynamic with these positions because in a lot of companies, I think in order to make more money, you need to get promoted, but you may not want to do the job that you're moving into, right? Staff is a different job, and senior principal is a different job than staff, distinguish whatever your company has. And you're like, "I want to get to the next level, but you're being promoted into a job that maybe you won't like or may not be good at."

And it takes some self-reflection to maybe realize that. It would be nice if companies created more breadth within a given role. I could say senior here and be a solver staff level, but stay at this position. And just be really good at it and have the company reward you for it without having to necessarily change job titles. A lot of these things are new, as we've been saying. So maybe with time and maturity, these things will expand, and we'll get more used to them. But I found that to be interesting, just differing in what a title means in a certain company and how people treat them.

Thiago Ghisi: That's super interesting. And I really love what Loiane said about me staying as a senior engineer not being a failure, right? I think because we have been putting those career letters out there, people start to assume that, "Oh, if I'm stuck here in the middle, there's so many more levels to grow up. I have to go there at all costs." I think that's the impression that I get. And it's almost like people forget that on the management side, we have exactly the same problem, right? Not everybody was born to be the CEO, and not everybody was born to be a C-level executive. Not everybody was born to be a VP. And a lot of people are happy to be a manager, a really impactful manager for years and years. And as Loiane said, changed domains change company, it helped to grow careers, and they're happy, and they're fine, and they're not in a rush.

I see a lot of folks in a rush. I have been a senior for five years. Oh my God, I'm wasting time. Because I think the incentives on the other side, yes, there are companies, everybody can be a staff. And I think some part that's true, but on the other end it's almost... I discussed this on Twitter a couple of years back, I almost would vote to create a separate letter for staff engineering that would be completely detached from the IC letter that would be evolving senior lead. And to give the impression, there's a lateral move and is not a continuation of the letter. But not everybody is like that, just there are other incentives that come into play. But I think that's, as David said, as we're evolving as the industry, I'm really curious to know how things are going to shift over the next couple of years.

An Overview of InfoQ Dev Summit Boston Talks [40:44]

Daniel Bryant: Fantastic insights. Any final thoughts? Why should folks come and watch your talk? That's probably a good thing to pitch, right? I know you all doing a talk. Let's keep it super tight. Let's do the elevator pitch for why someone should come and attend your specific talk. Dave, do you want to go first? I'll put you on the spot.

Dave Grizzanti: Sure. So yes, I'm talking about building successful platforms and some experiences we've had at the New York Times. So, if you're interested in some of the challenges we've faced and successes we've had, stop by in June.

Thiago Ghisi: Yes, I think my talk is going to be about, I would say, the strategies and day-to-day that I have seen working for staff engineers in my experience as a peer, right, or as a manager, not doing the job but the outside in almost perspective. So you're going to learn what to do and what not to do and what are examples of, let's say, what you call staff projects or big projects that are the kind of projects that those people that are at this level are running and how they compare to projects that directors or VPs are running at the same time.

Loiane Groner: I'm going to be talking about security for developers, which is beyond authentication and authorization. So we'll talk about those things that are usually implicit in the tickets that the cross-functional and non-functional requirements. So I hope you join us and find out.

Daniel Bryant: I guess you got the overall pitch, right? You're running the show.

Eder Ignatowicz: Yes, yes. My pitch is that as we will have 20 people, like these three bright minds here that we have here to talk about experience and practical insights for soft development. And come to Boston, it'll be super fun.

Daniel Bryant: I love Boston so I can watch the Red Sox play a game, right? They've got some fantastic museums. I love spending time in Boston. I am looking forward to it. Fantastic.

Eder Ignatowicz: And in the summer is the best place in the world.

Daniel Bryant: Yes. Love it. Love it. Fantastic. A great advert for the city and for the tech and for the people. That's a great combination there. I say, thank you so much for joining us.