#154 Anand Safi is setting people up for success

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Anand Safi 0:00
The fact that when I started my career as a QA engineer by building test plans or test strategies on how I'm going to approach this, how I'm going to break it apart or find columns, that is how I went into my programming journey as well. And over the years, I realized there was a lot of value that there was not like a lot of moments where I had to, oh, I missed that. Or you're right, I need to do this null check. Or you're right. That is a thing I did not think that a user could do actually. So always trying to be customer centric, in true sense for product development really helped me rather than being a developer per se.

Tim Bourguignon 0:55
Hello, and welcome to developer's journey, the podcast bringing you the making up stories of successful software developers to help you on your upcoming journey. My name is Tim Bourguignon. And on this episode 154 I receive Anand Safi, over the past decade, Anand has progressed from aspiring engineer to engineering leader. He is now an engineering manager for Mark43, in Quebec, and is also a startup advisor, a volunteer board member, a tech mentor outside of his role, and he loves reading about engineering, culture and team dynamics and new advancements in tech. And a warm welcome, to devjourney.

Anand Safi 1:36
Thank you, Tim, for inviting me, it is great to be here. And I really look forward to our conversation today.

Tim Bourguignon 1:43
Awesome, I do as well. So as you know, the show exists to help the listeners understand what's your story look like and imagine how to shape their own future. So as always, let's go back to your beginning. So where would you place the start of your dev journey?

Anand Safi 2:01
Yeah, I placed my start. Right from my high school time. Right. Around that time, when I got in, I had a choice actually. So back in India, after you do grade 10, you have a choice either to pick a focus on mathematics or on biology as one of your two core areas. I went with mathematics. And there's a reason I bring that up. Because my entire family has doctors, both my parents are doctors, my uncle and auntie doctors. So everyone in my family has been through that other career path. But for me right from the start, there was something that stuck around analytical thinking, or problem solving are just those puzzles that I felt that I wanted to just flex my brain a little bit more, there's nothing wrong with the journey of being being in the medicine field. But I wanted to just kind of continue and explore what the future holds and do something a little different from what my family has been doing for decades. So that is how I chose the mathematical path. And I was always good as mathematics right from school and in college. And that is how I ended up in an engineering college for my bachelor's degree actually,

Tim Bourguignon 3:18
did you decide into going into into tech, because you could have gone the mathematical router and stayed in, in academics? And on some research on math, etc? What decided you do going this way instead of the other?

Anand Safi 3:32
Yeah, that's a great question. So within mathematics is just using that as a base. But then at the same time, during my high school days, that's when I got my first computer. So again, thinking of that as a toy, or just psyching it out as as, as a young adult or teen, I just started playing around like first with video games are just those things. Back then used to play things like Prince of Persia, Road Rash, or just different different kinds of just RPG games, nothing, nothing to kind of at the scale of what we have now. But that is how computers was just natural. And then during the early days in my engineering, college, actually, so the first year, we don't have to choose a specific area. So we could be probably all around the college have the same subjects. And from the second year, you chose a specialization. So even in my first year during those common subjects, a lot of that was of the assignments or just kind of the things that I had to showcase like case studies was done through computers. And I was naturally getting good at that actually, that is just trying to structure information and do a class presentation just trying to summarize things or just trying to articulate things in a better way. And that is how kind of just technology became a more a natural choice for me versus the electrical engineering side or the computer's engineering, which is well, more core. But I went with information technology, just looking at the plethora of information out there and trying to present it in a more structured, concise manner.

Tim Bourguignon 5:18
What difference did you make back then between computer science and information technology? And how do you decide one against the other? What was the, the key elements that made you balance one of those?

Anand Safi 5:27
Yeah, so I was. So again, between me and my younger brother, I was kind of the more reserved, or the calm kid during during my childhood, while my brother was always a little more curious, he would, he would kind of open our radio player or kind of break apart our Casket or the recorder. And just he was he was more curious in the hardware things or how things are wired up, I was less, kind of worried about how it was wired up, I was just fascinated on how it was presented to me as that kind of that end user, if we could say in in today's world, actually. So I was more into the presentation layer versus the just kind of the layer on how it's all put together. So that is aware in in the college that I went to the to clear paths where information technology was definitely had those programming languages and some courses related to microprocessors and just hardware engineering, but there was only for like, two semesters. And then we went more detail into software engineering SDLC, the lifecycle and those things, while the computer science department or or that discipline went more deep into the hardware side of things, or just in terms of circuits, or just assembling chips, and just micro, micro processors and all those kinds of things. Okay, makes

Tim Bourguignon 6:53
sense. Makes sense? Because I'm jumping far ahead. But what we'll come back to you all to the beginning of your of your career of your studies and your curriculum, and I'm interested in the image you had of the industry back then, when you made this choice, I'm going more into information technology and not core computer science, the the the prediction image you had in your mind, did it turn out to be true? Did you envision our industry back then the way it is? Or do you have another understanding the had some surprises in there?

Anand Safi 7:24
Yes. And no, yes, in the sense that image I had held true. But no, in the sense, the image I had is a little tiny piece of the information technology or the software industry as a whole. So during my days in India, during the degree that I was pursuing the four years, when I would see my seniors or people who would graduate from the program, there was always a single talk, like the most talked about employment opportunity, mostly, or the career choice was getting a job as a programmer, just like a becoming a programmer. And that is kind of what I thought. And that scared me actually, during college because I was great. As I said, with software engineering, or SDLC, as a whole, I was still picking up the programming as a skill or like coding, it was not that I was doing a lot of algorithmic puzzles, the puzzles I was doing back then was more aptitude based while programming requires a different sort of algorithmic approach, actually. So it scared me in my couple of final years that if I'm not good at giving my programming exercises, maybe I have a future just when I graduate, or what role am I going to get? And once I started kind of looking more into the field, and only now that I realize even now, I discovered career paths that people end up taking that yeah, that checks out that this is a totally valid career path. That's an engineering role, actually, where I had a very singular monolithic view of what the entire field is, which is just you become a programmer and write code all day.

Tim Bourguignon 9:05
Do you think it was per design this way? I mean, now that that's a loaded question. You got this for your study. So probably there was a lot of math And then there was a lot of programming and not a lot of something else, which turned out to be the the important. missing information to realize that there is not just programming. Do you think it was intended like this during the curated curriculum to really try to create programmers? Instead of creating? I don't know, design people, user experience people, etc? Or was it just your views and things? And you were picking the hints back then that you were picking and looking with with different eyes right now, you would pick something differently, but it's like,

Anand Safi 10:32
yeah, I think it's probably how the attack or the education industry has always been, like, we still see and I'll hear people say, like, what I learned in school is way different on what I have to practice or do in my day to day role. Actually, I wish somebody taught me agile, I wish somebody taught me how to do testing via selenium, or like just any tool. I wish somebody taught me how to do system architecture in a proper way. And think of all these concepts, we are introduced or just barely scratched the surface, you do ER diagrams, or like entity relationship diagrams, and college UML diagrams, all those kinds of my classes had those, there's hardly a time that I use that day to day, maybe once, or if even if I do, there's a technical business analyst or any other department who ends up doing those diagrams versus my discipline or role. So again, I It's it, I think there's still a gap, because programming courses are kind of still, you're taught five languages, like I was taught Java, I was taught front end, I was taught a little bit of Ruby, all of these, they're ever changing as well. Like, what I was taught in Java back then in college, like in college does not hold true. Half of the things I've changed from a syntax and conceptual evolvement standpoint nowadays. So I wish that the focus is more along like different disciplines within the software culture versus making it programming heavy, and then just barely scratching the surface on a couple of other things altogether.

Tim Bourguignon 12:07
Okay. Okay. I spent a lot of time thinking about my past in this regard, as well. Entering see that there's really a mix between very timely stuff, like, Okay, we learned Java, we learned we learn C++, we're going to C sharp, just you just do hit the ground running and be able to be programmers when we start. But on the other hand, at least the curriculum in which I was taught her some stuff that I am starting to appreciate now 15 years down the line, and seeing Oh, that's what they meant back then. Which is very hard trade off between between usable now and and usable later, making you be ready for your first job and making ready for career. That's really a hard, hard mixing metric to find.

Anand Safi 12:52
But to your point, I didn't meant to put that in in criticizing way. But I think maybe there's a reason, because some of the concepts that I could get it now there is no way I can think I can get it 15 years back, actually. So there's a reason they don't kind of expose a lot of complex information to not overwhelm folks back then. And starts with basic programming assignments or just kind of singular tasks and kind of writing code for those challenges. Yeah,

Tim Bourguignon 13:21
yeah, sure. Sure. Sure. So how did you how did you transition into the professional world with big air quotes? How was this first contact? Ideally, your first job? How they did it? Is this reality check look like? Did you fall from your from from from your cloud, saying, Oh, I can be something else? And then programmer, I'll do that look like?

Anand Safi 13:42
Yeah, so for me, at the end of the four years, as I said, like, I was not sold on the fact that I could be a great programmer right from the get go. And along with the fact that I felt there was more to this than just, I did not buy it that I just needed to be a programmer. So the way I approached it is I already in my final semester or so I had decided that my next path was going to go for a master's degree, and get an even more kind of advanced look of what are some other things that does feel happy because when I started looking for programs for master's degree, I saw that the curriculum was a little different than what was in pastures. It was some specific topics and more advanced things. So I wanted to get the full picture rather than being just worried or scared and just diving headfirst into the first programming job that was sent my way actually. So in that sense, I probably took a very risky bet back then I did not sit in any of those campus Placement Interviews, I did not interview formally for roles back in India, because the program ended in May. And then on August 10, I flew to us for my masters so this is because the colleges in the US have kind of their admission process figured out six to nine months back. So during my final year of my Bachelor's, I kind of knew that I already had admissions from a few universities in the US that I was coming for masters. But the reason again, was that a yes, I felt there was more to the field. And I should not just kind of take what's there without knowing what what the full picture is actually.

Tim Bourguignon 15:25
And did you get that full picture

Anand Safi 15:26
a little bit more, but not not totally, I did get a bigger picture than post my Master's at least I did not take up a programming role actually, I took up a role as studying as an asset. So like, as a QA engineer for eBay. And that is definitely it was more about just looking at existing workflows and trying to poke holes. And again, that is kind of goes back to my analytical thinking or just kind of problems ongoing or just kind of trying to find problems in the happy path. That is a now I can think that it draws a parallel, right, not trying to agree to anything on face value. People said programming is the is the only way I did not buy it came for Masters, simulated QA, someone says this always works 100% of the time, I don't bite and try to poke holes and and go deep into that, actually. So at least I got exposed to a new kind of whole discipline that is software testing, which which does wonders for me even today, actually, in how I operate. How so. So the way it helps me is if I just don't programming at the file or module level, a lot of that was just taking the requirement as is or the need of the hour tasks at hand, and then building a solution for that. So eventually, over the ears when I did become an engineer, building, the solution was the last thing on my mind, actually, the fact that when I started my career as a QA engineer by building test plans, or test strategies on how I'm going to approach this, how I'm going to break it apart or find problems. That is how I went into my programming journey as well, trying to take a thing and say, what is the flow? How I'm going to approach this problems? Can I break it down even further, can I write a test or kind of make my business logic kind of just solid, that this is my happy path. And these are some things that could trip the user. And these are my edge cases, because that is how I operate as a QA engineer, the happy path, I do it in two minutes, but the remaining one hour I spent in the non happy powder edge case. So that is what I did as an engineer. And then actually writing the core logic, the functional logic came in last, actually. So that was just giving me a whole different perspective. And over the years, I realized there was a lot of value in that there was not like a lot of moments where I had to, oh, I missed that. Oh, you're right, I need to do this null check. Oh, you're right. That is a thing I did not think that a user could do actually. So always trying to be customer centric, in true sense for product development really helped me rather than being a developer per se.

Tim Bourguignon 18:17
How do people I mean, by that your colleagues tend to react to this way of approaching problems. Is this natural to them? Or are they surprised when they are the curious?

Anand Safi 18:29
Yeah, so I have mixed mixed reactions. Because there are some people who come from this, this background, either being in the testing space before as a step, or just believing in being thorough and trying to make sure that you're covering all possible scenarios. So I do get that. But at the same time, when I work at a startup, or I'm moving in a very fast paced environment, they tend to push like, could we be a little more nimble, we can tackle it down the road. Let's not worry too much. Let's not overthink in terms of being too thorough, or all these scenarios, their requirements stated, it is good enough, let's just build for that. And let's go to the next thing. And if something comes breaking or cracking down, we'll tackle it when we get there.

Tim Bourguignon 19:22
It's always a trade off. You always have to defensive or too offensive and somewhere you have to meet in the middle, whatever, whatever what I've seen workout quite often is this this defensive mindset and then making the trade off of saying I'm not going there, but I'll I'll put a safeguard, saying, Well, I'm going to prevent you from going this direction, because I know there's problem there but I'm going to prevent you from going there. And this way at least I know you're not crashing and burning. But the cannot do that if you're always thinking about the happy path first because he You, you, you obfuscate to seduce places, this defensive mindset is actually really good. And I always have to have at least one person thinking like that in a team. That's really, really important. If we talk about the cross functional functional teams, really, you have to have someone with this mindset. It's so it's so important. Very cool. So why did you decide to steer your your career towards software engineering, creating solutions after starting a successful career as a as a QA? Expert?

Anand Safi 20:31
Yeah, so I think as a QA, when I started my career, it was still pretty much like a deputy back, it was still mostly manual testing, automated testing was done in some aspects, but not at that level. And I became really good at the manual testing aspects, I was, like, able to crush my sprint goals or commitments really, really fast. So as a natural progression, I've moved into automation, let me see with some of the stubs and the marks are just tooling, if I can add some logic, like basic assertions in terms of just trying to see that, if this is the given data, and if I invoke these functionality, then this is an expected result. That also was not too problematic, then I expanded into a little bit more kind of hands on automation. So which is Jasmine, mocha cucumber tests like step definitely like the whole behavior driven development, still not super kind of programming oriented. And again, the fact that I was able to progress this naturally or easily was because I did have six plus years of schooling in computer science department with information technology, I've done courses or those kinds of things. So I had my foundation solid that helped me. So moving on to a little bit of behavior driven development, like writing English scenarios, plain English, like, as a user, when I click this button to add product to cart, my cart, well, you should say this, and then that there should be one item in the cart, those kinds of things. And it just naturally happened that I didn't ask for it, like I was not doing all of this to become a programmer, it was just that it's kind of an S curve, right? Like I started the bottom, if I reach out kind of being good enough, or this becomes my routine, as a natural kind of progression looking for that next challenge is, then the team would say, looks like you're good, do you want to start experimenting or doing a little bit of that. And that is when I picked up some bug fixes, or just at my role that happened that put me into the programming journey. That is just an aspect that I was able to grasp the things real fast, unable to make progress that helped me, but there's a huge piece, there's a story there on how I actually moved into development formally, is the company that I was working with back then we were a really small, scrappy startup in those days. And then, for good or worse, we decided that we don't want people in the engineering department, whether QA or dev team to have any silos. We want software engineers, and not software developers actually. So as an engineer, you should be able to understand the requirement, put some working solution against that, be able to test it and understand how to put it out in front of the customer. And this no silo approach led me that we formally shut down QA as a concept as a team. And then there was a group of us that was transitioned formally into engineering. And that is when I kind of I joined us that software engineer, not super entry level, because this was not out of college, I still had three years of automation QA experience, I still had my bachelor's and master's, but as a junior to mid level software engineer, and that formally kicked off my programming journey. So it found me rather than me trying to just work day hard, I see a lot of folks in the testing field, that they feel that programming is something better or the natural evolution for after being a QA. But I don't treat it that way. That is a very important standalone skill. And it's not that since because you're a senior tester, you should just strive to become a programmer actually as your next career path.

Tim Bourguignon 24:23
So it's very true. I love to present it this way. Even even non programmers I'm making big air quotes. I actually programmers nowadays, if you work in axial every day, you're programming. And the only thing that differentiates programmers is is what your mindset is. So maybe in if you're working in Exel, you're actually a with a business mindset. You're solving a problem with a business mindset. If you're creating software solutions, then you're you're a developer with a solution mindset. And if you're a QA developer, you're the developer with with a breaking things mindset. And this is very valuable. Each of these mindsets are really valuable. How do you approach I'm jumping again ahead what we'll come back to that later. Yeah, I read in your in your in the intro that you're an engineering manager. Now, how do you balance those different mindsets to create a harmonious team able to really talk about some problems? How would you define this as an engineering manager nowadays? Yeah,

Anand Safi 25:25
and again, great, great way to put it that is, and I think the parallel I draw here is a lot of people say that we should strive to kind of make people come over their weaknesses, and always kind of have a growth mindset or just kind of say that if you're not good at this, just focus on being better at this. But the way teams work is, more importantly, using each other's strengths, actually. And that is kind of the essence when I put on to manage a project or just a task, I am able to break it down into actionable things where people using their strengths can able to make collective progress or meaningful progress. So if I have a product manager with me, the first thing would be just to provide clarity on the business need, like what we are doing, and why we are doing this. So just as sell the other team members on the vision and the benefit, whether it's a strategic benefit, whether it's a kind of KPI benefit, or it's kind of hitting our revenue targets, what are we doing? And why are we doing that athletes, that is a strength that is first leverage. The next is using the senior engineers, or the architects on the team to do a technical feasibility check. Actually, I don't want to call any engineer without giving them technical clarity or direction and throw them in the mixing, go figure out or just figure out the how, without having some feasibility conversations or discussions as a group, like let's brainstorm. So that is when we will see let's do a POC or let's do a strike or investigation to see what is the level of effort it will take for terrorists using people's strengths to just isolate the business logic and just approach it from a technical standpoint, to make this a reality. Are we set up? Or do we need to do things first, even before we think about that, that problem that we are asking to be solved from a product side. So first, I have to figure out then we will see if this is something big enough that we need multiple people to collaborate on. Or if this is good enough for any person on the team to implement that athlete, that again, presents me a great opportunity to either use people to their strengths, like if it is something small, I can get anyone to just knock it off in a week or a sprint. But if it's big enough, it gives me now the opportunity to if somebody is has kind of a developing skill, that they need to be a better team player or they need to work with like they're too much isolated or fragmented in their role. This is a perfect opportunity to collaborate with another engineer or brainstorm a little. So that is where I can use that to my advantage or to the teams that rank is not my advantage in order to make progress on that problem it so it's just kind of breaking it down even the smallest of requirements or user story into what are some things each person in the team can do to their best of their strengths and probably just get some learning experience out of it. So that we're we are not kind of giving the same person the same kind of work. There are no bottlenecks, and we're not having kind of silos of knowledge in the team itself.

Tim Bourguignon 28:52
Okay. Makes sense. Makes sense. That's really cool. Thank you for the for the explanation. Then let's go back. Let's go back to your first engineering. Formal would be awkward. I'm making a lot of air quotes today. formula for first formal engineering role. What went after that? What's what's between this this first engineering role and your first management role? How did that story look like?

Anand Safi 29:15
Yeah, so my true first engineering role was an internship. So back in my Bachelor's, the last semester was meant to be an internship. And so I did actually work in India for six months as an intern, and I had no idea that what I was getting myself into, again, it it just happened that I caught a role just through an acquaintance or through networking. It's not that I formally acquire into because that is the case with internship right? There is a someone in the field needing some experience, can we give them that experience or just like a taste of what are working actually in an industry or working with it? He works like so, through mutual connection, I got placed as an intern for a company that does ERP. So they do inventory management and quality control. This is 10 plus years back, so I am remembering the bits and pieces. But that internship was maybe it was just that I got it through networking, or just this part it that way, there was very little expected of me in terms of output. All they wanted to do is make me understand, which I think is good. It's just making me understand how does the end to end flow looks like. So there were training modules, there was a lot of shadowing, which I think is really important. When you're too junior or starting fresh, you don't want to at that stage, put somebody to test and say, show me that you can do this or showcase me your skills. Because the skill building is what happens in the early months or years actually, you cannot put someone and assign them a task complex and a friend say, do this, and we are going to judge you on how you do it, you first need to give them some structure information and time to settle down and get a sense so that they can absorb it first, and then give it back to you in some form. So I really liked that they thought it that way that I was shadowing for the most part, I was reviewing documentation and workflow. And I had what I had to do is make kind of a presentation on what I felt the system flow was. And in the process, see, what are some questions I have, like, why are we sending requests this way? Or even after we are sending this request? Why do we again send a request three seconds later? What is the problem? Like I didn't know back then what it was a web socket, or how do we keep connection open or listen or pole for things. So if they were expecting that I would know these things, that is kind of where close to my original point like each college or each country has education curriculum different. So you cannot expect that people would know that for the first 3060 90 days, you need to give them the context. And and there's a reason they are there. Because definitely they have potential. So you need to trust that potential. And then they can do wonders rather than the other way around.

Tim Bourguignon 32:26
That is very, very shrewd, or I like to speak about acceleration and not level. So is he you don't want to vet how high or low whatever high and low means a person enters the company, you want to see the delta between where they started, and where they are six days after that. And that's that's the hint of the potential you can take somebody didn't do any programming. And they can just knock your socks off in 30 days, because you gave them the correct ideas. And then they are way better in terms of progression than any any other person. Maybe you're not there yet, but you're seeing a progression. And that's that's was really important. And as manager, you really have to observe this really have to to pay attention that

Anand Safi 33:12
that kind of notion that I shared holds true today, real life example, like very recent, as a manager when I'm onboarding new engineers, or when we are doing performance reviews, you cannot say simply to someone that you were underperforming, you're you're not meeting the expectation, the first thing you need to do is look inwards. Did you set them up for success? Did you give them enough opportunity? Or did you give them kind of did you enable them to showcase those skills? So there's a lot of things that first you need to do. Because if you don't do that, or if as an organization, you're not finding those opportunities, people will assume that that is not an area that they need to upskill them or they need to uplevel they will assume that the team leads them in other directions because nobody is telling them. You cannot magically expect and say, well look in the career ladder out of these 10 things you did not do the six things. Well, we never talked about that the entire year. And now you're bringing it up. Did Did we have meaningful conversations or discuss like each thing is important? If not, then somebody will assume that what they're doing is what is the need of the hour and what is expected of them in their role?

Tim Bourguignon 34:24
Or even even worse, what is this career thing you're talking about? Yeah. So many companies don't have such a career ladder or such a mapped out path how you grow into a company. Absolutely.

Anand Safi 34:35
That is that is one one other deep discussion. Yeah. Well,

Tim Bourguignon 34:43
before times run out, can you really take us really fast to your first management job? And then I'd love to talk a bit about mentorship.

Anand Safi 34:50
Yeah, so I think the first management role is again, I have not super far into my formal engineering management journey, but I think a A management or self leadership starts at any level at. So my actual management role, informally would be back even when I was still a solid engineering IC. That is when I would take upon managing small to midsize projects and work with other stakeholders. So that's how you want to see your ICS progress, that they are taking on tech leadership, or practicing self leadership, that they need minimal supervised supervision, they don't need their managers to step in, they don't need their managers to set up a meeting or they don't need like to wait that their manager will communicate to the wider team. As an IC, when I used to complete a feature, our I used to test it or push push it out into production, I did take the opportunity to connect with the business folks or the technical account manager and tell them, hey, this is ready. This is kind of what I see, can you take a look, they will do that. And that is kind of how I built rapport, that I started managing the end to end lifecycle of anything that I own actually. So that is kind of the comments that I started getting that you are super easy to manage, because I need little to no management into sense. There is minimal oversight needed, you don't kind of put boundaries that this is my role. All I'm asked is to code that my role ends there. And now I'm waiting till my manager is free from all his days meetings and comes back or she comes back the next day. And I say that I'm waiting on you to get back. Well, I did this, but I think he will take it forward actually. So be management is just kind of a characteristic of a person that you are able to take control might not alter your control, but just control that you can take it to the next level or next step and not just kind of end your role or task, feeling that you are done. So I always thought like how can I not stop here and wait on someone else, in a reasonable sense, at least take it forward to the next level. So that we make continued progress as a team

Tim Bourguignon 37:10
is really in terms of of owning the whole problem and really embodying the solution, not not just creating one part and saying well let somebody else take care of the rest. You're the solution from from the beginning.

Anand Safi 37:23
But in terms of the more formal manager management role, actually did did a talk on this sometime back that first thing I want people to realize that that change is not a promotion, it is a different career path. So again, same as the parallel that I want to go into engineering because that feels fancy or that is a promotion in my career. If I'm in any different discipline, the same as for engineering ICs. Many people after being senior enough feel that the only way to progress in this company or have more authority or say is to go into a management role. It is a different career path. And that is when I realized that I am kind of responsible for the collective success of the team and the individual versus my own work output. So writing code became less and less and it's on Sundays non existent because that is not my primary criteria. My primary criteria is to keep the team unblocked, keep the team kind of just aware of the current happenings and provide them clarity whenever they lack clarity in terms of making meaningful progress. So success became more abstract. It was not that I completed 15 story points or I did 10 features or I have looked my GitHub has 500 Plus contributions in the past year. The success was I was able to deliver a product or commitment on time, or in a reasonable timeframe with minimal burnout and still happy morale for the team. So a lot of the things I realized on what my responsibilities are, they are way different than an engineering IC. As an IC, a promotion is becoming a staff engineer, Principal Engineer, where you're doing dealing at a file level or module level, you move to system level across systems, you move to dependencies or how to build something from ground up. That is a vertical promotion. Horizontal career path is not a promotion and management is just a different career track that I moved to

Tim Bourguignon 39:25
when you were one of the major things when you realize when you move from IC to management's individual contribution to management is how easy it is to get your fix of off success. As a developer. You push some small features and you solve some problems every day. And so you get those endorphins every day so hard. That feels good. I did something today. Most of the time. It's done the work that's been done. Oh now it works. Yes. As manager. don't get that anymore. How do you cope?

Anand Safi 39:55
It's true, right and Greenbuild at the end of the day or test not failing on the CI CD by pipelining is a dopamine boost actually, and I feel my day went productive as a dev actually, for me it is success now is that there are no firefighting that we had to do. So there was no war room situation or P zero p one incidents, that is a day went well, that is there is no conflict between teams in terms of lack of clarity that the last thing I want is anyone on the team assuming that that is the other person's job, actually, I want actually people to feel empowered, and to it even waiting for an official direction, or kind of waiting for the next person or the next teammate to do it, actually. So that is when when I see someone taking initiative, success is instant, right? It's not kind of, at the end of the day, it's a singular thing. Success for me is throughout the day, when I'm in different conversations or different meetings, that is successful, when I'm in stakeholder conversations with the design or the product team. If they feel engineering is doing good, or there's definitely more visibility, and they understand why we are tackling tech debt, or they are empathetic on why this is needed versus just moving fast. And being a feature factory that is success for me. When my direct report is on a proper career ladder path. And he's not confused on what they're doing. Does that hold any value for the larger company's strategic objectives? They understand what they're doing? What is the motivational value for us as a company and how it does move the needle that is success. So I've just learned to kind of have my own metrics on Yeah, that is a win, versus there's no set criteria that as a manager, there will always be kind of visible wins, or there will be far more recognitions or those kind of built passing our code committed successfully with no errors, or just rolled it out to production with no bug ticket created, those kinds of things.

Tim Bourguignon 41:56
Amen. For proxy metrics, have to find the one that that that makes you happy and focus on that. Awesome, awesome. How does mentorship fits in this picture?

Anand Safi 42:07
Yeah. So mentorship fits in the sense is that there is much more to software engineering now that people are realizing than just writing or code or implementing solutions. It's a mindset as he pointed out earlier. So mentorship is more about developing the mindset, and how do you approach any given situation? So I've written articles on this recently a little bit that how to maintain calm under chaos. So that's kind of for me, right? Like, you will see that in meetings, if we work together that I am probably silent 90% of the time, but people would expect that I'm always jumping in trying to put my decision making hat or just kind of dictate what course we take. But I always take a backseat trying to assess what everyone has to say, or get a read of the situation, before putting out what we are trying to do as a team actually. So the mentorship is trying to coach people on that thing. Like, don't jump on the first observe thing you hear, just take a moment to assess, get more context, ask the right questions. It's not questioning everything. It's asking the right questions. There's a difference in there actually. Right. So once you're able to know the reason or where someone else is coming from with that proposal, there is a chance for more meaningful discussion and conversation, versus this being a full blown debate where people are trying to just hold their side steer in that regard. So that is an aspect of mentorship that I kind of teach people or just how to approach situations in general. The other thing I teach is, or not teach, but I talk with people is not spreading yourself too thin. What I see is when people are new to the software engineering journey, and this this all things are what happened to me, right, I was doing front end, I thought back end is where there was a lot of value. I started doing a little bit of full stack, I realized DevOps is crucial. Everybody's doing AWS certifications, what am I doing here just doing full stack. So it was really easy to just like jump from thing to thing. And I felt I was felt like that's when my manager told me let's focus on something yes, definitely get an experience for things. But then at some point you need to determine your core focus area, because if you spread too thin, you will just be kind of a master of none in terms of just and that is what not teams the they definitely need words that help people but what they need is smart generalist who can kind of become specialist when needed. So that is where versatility comes in. That you're a mix of smart generalist and a specialist as and when needed. But if I was just a generalist all along, then I would not be able to go deep in a particular area when my team needed it actually. So it's great to Be aware or just kind of have an initial read on each aspect of SDLC or the last development lifecycle. But if needed, then you should become that point person that when there's something not rendering, let's go on and on, on what is causing that. So that is something that I realized on how to not get fascinated by every new thing or discipline that you're exposed to on in software engineering, and kind of hold your ground. It's not just still being narrowly focused, but it's still having a core area, along with trying to expand your understanding and reach across different areas.

Tim Bourguignon 45:39
Do you steer the discussion as to where to reduce topics? Or do you let your mentees come up with with those ideas? How do you handle

Anand Safi 45:48
so that is where I corrected myself like there is no teaching. And while it's not that these are the topics that I want to mentor someone on or coach them, mentorship for me is really open ended, that is talking about the confusion that they have, or these problems they're facing that week or over the past couple of weeks. And through those discussions, real life situations, we would normally stumble upon this underlying concept that that how we can approach this particular one, or going forward how we can develop that mindset to approach similar situations like this in the future.

Tim Bourguignon 46:26
Very cool. Cool. And I think if I read your your profile correctly, you're very active in this doing on multiple platforms with multiple mentees at the same time, how do you prevent yourself from being spread too thin and not being able to help each each mentee like they would need it?

Anand Safi 46:46
Yeah, absolutely. That's a great point, the fact that there are multiple platforms, because each platform has a different set of user persona that they tackle or strong with. So one of the platforms is where a lot of people who are not from engineering backgrounds, or are new to their engineering journey, come to that platform for benefit of mentorship on how to even get their engineering career started one platform, another platform specializes only in New or experienced engineering leaders. So this is either tech leads or staff engineers who want to go into engineering leadership, or new engineering managers who just got their first direct reports and just kind of don't know how to proceed or just want to have someone to talk to, and validate that whether their approach is correct or incorrect, or whether they need to fine tune any of these things. So it's only a couple of hours a month across a permittee, or in general, but the value is different with each platform and each experience. And that just kind of one one platform, it just helps me share my experiences and my learnings or pitfalls that people should avoid. But on the other ones, I actually ended up learning equally, because I am also in the same Engineering Leadership space. So that is more of a conversation. And it's not always what is going wrong. There's often conversations on what went well. And that is where I learned that this is a success criteria. And they were able to put this idea into motion and to work for their team. Let me see if I can do the same. So I also get ideas and things to try and experience in that regard. So it's not full. Overall, it might be 20 hours or less during the given month. But the value is tenfold than just kind of doing my core roles and responsibilities

Tim Bourguignon 48:39
that absolutely I've a big smile on my face right now. Because that sort of thing. I realized as well. I could have many mentees at the same time and basically have spies in different organizations and seeing what works, what doesn't work. It's like living three lives at the same time. I

Anand Safi 48:55
love that emoji. Because that is kind of what would because it's difficult to come up with a lot of hypothetical ideas, ideas today, need to have some backing or some data to go. So if you are able to know that someone in the industry solved it for their team, you can propose it with reasonable confidence and try to pitch it to your own team. Actually,

Tim Bourguignon 49:15
one thing that is always it's hard is to find a mentor. So what would be your advice for somebody let's starting the career and say I think I should beneficiate? I would benefit from for some sort of relationship. But I have no idea how to approach someone to get through the vices, what would be your your tip there? Yeah,

Anand Safi 49:35
it's you. We could definitely they could definitely try just searching on search engines to try to stumble upon the right ways. But I think it's leveraging your network. And by back what I mean is either using LinkedIn or something to see if someone is in the role that you desire as your next career move actually. So it's kind of cold call but a little more More than just cocoa, right? You can share your background and share with people that I am in this role, what you are doing seems like where I want to be, would it be okay? If I just spent 15 to 30 minutes just asking on your journey or learning or how to approach that. There could be things that you know people from there's a lot of like Slack groups nowadays or communities where you don't need a formal mentorship program or spend a lot of dollars in re enrolling in a formal mentorship experience. There are so many people who just help day in day out, because as long as you pose a question, and they will be able to give you some form of answer, if you want to go deep, or if you want to make that a growth area in focus, it's good to get a mentor who can keep you in check in terms of whether you're making progress, whether you are focusing and making improvement each week. But if you want to just get some question answered, or just kind of figure out just the basic next step, there's a lot of ways to achieve that. Whether there are forums or communities of engineers or groups that you can definitely pose it because a lot of people are doing that form of things as well. And then there's also a lot of content being written on platforms like medium work, or other other places on their own blogs, where people have just documented their experience. And I'm sure there will be content out there related to your own journey and the exact question, you'll find at least a couple of matching material or resources, which will give you an indication that whether you need a mentorship or they needed mentorship to get to the next level. So it's not that mentorship is the only way to make success happen or kind of progress to the next level, it is a great thing. But definitely do your own research before just assuming that just because someone is a mentor, they will do wonders, it will be you who will be doing the work at the end of the day, they will just kind of be that guy too, you in terms of how to approach it, and how not to get overwhelmed and and kind of put more structure and a framework around it.

Tim Bourguignon 52:15
So Amen to all this. Thank you very much. That's very wise. I love it. The idea of approaching someone and say, Hey, you have a cold? Yeah. How did you get there? I love that. As you probably heard Julian's podcast is basically what I'm doing. Very, very cool. I don't know, where would be the best place to continue this discussion with you, you have so much to say. I'm sure people want to contact you and ask you question and how you get there?

Anand Safi 52:40
Yeah, I think my LinkedIn would be the number one place all these platforms, because I don't want to recommend a platform or just a specific thing that that changes as well. But I think LinkedIn is the best way to get in touch, I do make it a point to even if I get a lot of messages, I do make it a point to do a 32nd read of SMS message to see if I can help or assist in any way. If not me, I definitely think if I can direct them to someone else who can assist. It's not that I have answers, but it's just, I want to do the best I can. So LinkedIn would be the best strategy. It's under my name. I'm Safi,

Tim Bourguignon 53:19
and we'll link into the show notes. And thank you for doing that for taking the time. It's really, really cool. Answering all this people. And thank you for taking the time to share your story with us. That was really cool. Anything else you want to plug in? Before we go today?

Anand Safi 53:31
No, I think I'm good. That's loud, actually, just some reflections off my own journey. And I think I already have a couple of things I need to just look back on like, and leverage in my current role actually.

Tim Bourguignon 53:43
Awesome. That's the best feedback I can get. Thank you very much.

Anand Safi 53:48
Thank you. Awesome. Thank you.

Tim Bourguignon 53:49
And this has been another episode of dev journey, and we see each other next week. Bye. I hope you have enjoyed Anand story as much as I did. His advice of approaching someone telling them that you are interested in a similar position to theirs and asking how they got there is so easy, yet, I personally have never used it. It's been on my mind since I heard what you took out of his story. You can reach me on Twitter. I'm @Timothep or send me an email [email protected]. You can also use the comments section on our website, Devjourney.info, right under the transcript of this episode. Now, think about your friends, your family, maybe your colleagues who could benefit from hearing and advice about leading oneself and mentoring others. Tell them to do so. Today. Send them a link to this episode. Tell them so subscribe, and tell them to say hi.