 Hi, my name is Purnima Kamath and I am a director with Women Who Go In Singapore. I founded the network with ULN in 2017 in January, so that makes us around two or three years now. So yay. I'm also an evangelist with YOW conferences. YOW is a conference organization. We bring experts from all over the world to do Singapore, to develop our communities. So if you'd like to know more of what we do and all the cool things we have in the future, so do chat with me later. My topic for today is essentially around life hacks for an engineering manager. Almost a decade back, when I first took on my role of an engineering manager, I really wish somebody had mentored me and prepared me into actually taking up the role. So this talk is titled, I Wish Someone Told Me This. What this talk is not about. It's not going to be about how agile is good or how scaled agile will probably be beneficial to your organization. It's not about measuring velocity of your team or how you could get estimates right or how your project can be under budget. Is there such a thing as under budget? I don't think so, but yeah, what the best team structure could be. But what this talk is about is essentially few life hacks 101 for managing teams. Stuff that I learned the hard way, hope I can bundle it up in 20 minutes and present it to you. A little bit about myself, my career journey, I graduated as an electronics engineer and started off my software journey in 2004. So my first job was as a Java and a web developer, so if you're familiar with technologies like 8051 microcontrollers using assembly language or Java 2, the ancient version or Spring 1.1 or Hibernate or JSR 268 Portlets, well that's the generation of software engineers I come from. I worked across various financial institutions like Morgan Stanley, Lehman Brothers and eventually Credit Swiss, which was my last job. I had developed OTC derivative trading systems and also the latest project I worked on was investment banking research distribution systems. Almost a decade back, I was given this opportunity to manage a couple of development teams and product teams across multiple cities and different time zones across Singapore, Pune, London, New York and Mexico. So whenever someone asks me what a manager does, this is the shift that comes into my mind. So managers are essentially middle men or middle women and who manage stakeholders on one hand and teams on the other. The most notably what you will see in this shift is the stakeholders and the team are never on the see. So at the same time, it's just like juggling both of these components together, goes to say something about the role, you cannot make everyone happy. So who are engineering managers? Different people who do different roles and there is an all encompassing engineering manager as well. Some people call themselves as people's manager because they're more focused towards people's career developments and their aspirations. Few of them are more technically minded who take architectural decisions for the teams on how the product should be delivered. Few of them are more delivery oriented like project tracking, resource management or what are the schedules, what are the constraints in the particular schedule when you're delivering stuff. All the ubiquitous engineering manager who does all of the above. What do these managers do? Managers hire people right now or the kind of project what the hiring is going to look like next six months from now. Communicating with stakeholders, be it product owners or users or if it's your small company, coordinate with your CEO. Back project from a schedule standpoint, monetary standpoint or time standpoint. Team objectives and appraisals and time sheets. The most fun part of being a manager. So on a Friday evening, just before you're going for your family dinner, you realize that you haven't approved time sheets and then you open this really humongously huge and slow system and you start typing in each 30 individuals' names and try to approve their time sheets, fun job. The only downside as engineers that we see while we are promoted to engineering managers is there's no coding involved. There's a huge perspective shift that needs to happen when you are a coder, when you code on a day-to-day basis and you move into an engineering manager role. So what do I mean by that? It means that you have to start delegating. As engineers, we have a tendency to do everything ourselves. We want to do every line of code is something that you need to draft and craft and create and submit and publish to production. A personal story, a couple of years back, we hired a vendor team in Pune. I was involved in the vendor selection, trying to figure out what is a contract that suits them best, scope out the project, what they would need to do, and stuff like that. And the only use case that we wanted them to work on is to convert this low-level Java transport, which used a messaging system for a service-oriented architecture and move it on to a shiny new technology at the time called as Apache CXF. So if you worked in software on open source projects in the last decade, you would know that the documentation was terrible. And people hardly had documentation for open source. And even if they had documentation, it was so convoluted and so complicated, people could never make sense of it. So naturally, the team suffered. They were not able to deliver it. And they were stuck at the minutest details that go into actually adopting that piece of technology. And unfortunately, we were not able to meet the timelines. My solution to it is I did the whole thing myself. I delivered it. And it was amazing. I felt really cool because I was a manager. I was managing these two teams who are disparate, who are in two different locations, and still not able to deliver. I felt really cool. But unfortunately, I realized after some time, I was the only one doing it all the time. So it was great for the project, but not for the team as such. And this was visible to everybody. Even the senior management kind of understood that there is no outcome coming out from that team. So obviously, we moved on. We moved on to a different vendor. We moved on to a different contract altogether. And the team couldn't make it. What could I have done instead? I could have actually spoken upwards to my managers and asked for some budgets on training, asked for more time on delivery. I could have worked downwards to my team and asked them to, you know, guys, fuck up. You have to complete this project. Or actually, I could have worked or trained these people to actually come up to speed and do the project and implement it. This is what I did with the next vendor that we had. And really happy to say that they are still around. So hopefully thriving. Another learning while growing in the engineering manager's role was to create teams which are not dependent on you. At any point in time, if you're managing at least two or three teams that could comprise of somewhere around 20 to 30 individuals, imagine a scenario where all these 30 individuals come to you with questions. There's only 24 hours in a day. And you are not able to answer each one of them. The best you could do is to create a team structure wherein you have only a couple of leads reporting into you and have those leads build their leadership skills to actually manage those subteams. So that kind of actually frees up a lot of your time to do more creative things, things that are more meaningful to you. It helps not just to maintain your sanity. It also helps build leadership in your team. Meet with the leads regularly. Call it if you're into scaled agile methodology. Call it scrum of scrums, if you may. We are no captain marvels or super girls here. We don't want to do everything. So yeah, delegate and build independent teams. The biggest boring-est stuff managers do is emails. There are so many emails, emails on action items, emails on minutes of meetings. Follow up on action items, follow up on minutes of meetings. It's just endless. It's the most time-consuming and the least productive part of any manager's job. And believe me, I've had nightmares. The email hell, where you have nothing to do but just responding to emails day in and out. Yeah, it's horrible. The solution to it is time-boxing. Time-boxing is an idea where you allocate certain amount of time to a task and just get to it dispassionately during that hour. It can be an hour. It can be two hours or whatever you allocate to it. It's a life hack. Dispassionately get to that particular task and you finish and you stop obsessing over it after that particular time period. There is this author called Charles Duhigg, who's written about power of habit, how creating habits around something and getting to it consistently becomes a natural phenomenon. So what it means is once you get to time-boxing on a regular basis, it comes to you naturally. So you just don't keep obsessing over emails all the time. This especially is important when it comes to time-boxing emails because, first of all, you would control the urge of responding to something immediately. Control the urge of responding to something at night or at midnight when you've woken up for a sip of water. It will set expectations amongst your team, amongst your colleagues, your peers, and also your management. They won't be expecting anything out of you at an unearthly hour. Or in times of constraints, let's say you have a production issue or you're not well, or you're on a vacation. People don't expect you to respond because you know that you're not available. You can also get to more important things that are more meaningful to you. The biggest aspect of being a manager is to build trusting teams. What do I mean by trusting teams? Trusting teams are teams that are, first of all, they're independent. They don't rely just on you. They rely on each other. Multiple subteams rely on each other. And teams that believe that you have their back. And this third point is extremely important in the software industry, unfortunately. A personal outage story, if I may. A few years back, there was this one particular session management bug in the app that I was managing. And the impact was for a few users. But I think the bigger issue was a compliance issue since it was a banking application. The bug was because of a poorly written code by this consultant in New York, who happened to not be around when the bug had actually surfaced. I and the team, we spent around two nights debugging the whole thing and fixing the whole thing. And eventually, when the fix went out, everything was hunky-dory. And we had a retrospective with our senior management on to what went wrong, what we could do better. This one of the senior managers, he was clearly upset because compliance issue. And if you worked in banking tech, you would know that that's a strict no-no. And he got on to the call. He was a little bit angry. He was a little bit upset. And he called the dev team a failure, which was very upsetting because the dev team actually helped fix the whole thing. It wasn't really the dev team's fault, if I can say so. It reduces the morale of the team when you have so much negativity in a call and especially coming from a senior manager. I lost two members from my team that month. And I think I would have left two if it was not for one of my mentors in that particular organization. So how do you build trust? First of all, set up clear, defined processes. And you communicate it well. You don't leave it to assumptions. You don't assume that a particular consultant, since he's based in New York, he must be really cool. And he will know what unit testing means. Apparently it doesn't. So communicate them clearly. Be flexible with those processes. See what works for your team, what doesn't work. And don't blame people for mistakes. Instead, spin it off into a positive way. Create learnings and improvements. Anger really doesn't help anybody. And I think a brilliant way to humanize the engineering manager's position is to create a backup or a deputy of sorts to actually also help to get a pulse of what's happening within the team. And also create a little bit of leadership. You mentor people on leadership. It also kind of builds more trust. Another critical aspect of our manager's job is hiring. There was this talk by Jessica Kerr few months back at Yau Sydney, where she talks about teams being a semantasy. So what is semantasy? A semantasy is a learning system and a learning system which is consisting of learning parts. So she says that you don't make great teams by hiring all superstar developers. She says, if you just build teams where the developers work well with each other and such developers create great teams. And these great teams in turn create superstar developers. So don't go looking for those champs who give like really cool talk set conferences. They might not be exactly what your team needs. But try hiring for more diversity. Tailor down your job description to make it more inclusive. Try avoiding words like you wanna hire superstars or hackers, it just doesn't work. Try and hire more junior devs because junior developers are, they are fresh minds. They are willing to adopt what you are telling them, essentially, and they adopt your culture very well and they really actually deliver what you are, the kind of things that you want them to do. And mentor more often. I think as engineering managers, what we don't do is try to mentor people and build them up. We are always expecting people to perform right from the get go. I think mentorship is extremely important. In my experience, most of a manager's job is just showing up. It's just showing up, it's setting up meetings and showing up to them. Setting up one-on-ones and showing up to them. One-on-ones should not be just about work or how many bug fixes have you done or how many GRAS did you solve or telling off people that they haven't done well in their jobs or something. It has to be about getting to know that individual more. It has to be about a personal life. It has to be about their habits, their hobbies, their aspirations, and try and build the semantics that you're actually expecting within your teams. Give it enough time and discussing with people is important. If you're feeling more radical as an engineering manager, host ask me anything. But yeah, let me know if you actually ever host ask me anything. The most common problem that engineers have when they take up engineering manager roles is job satisfaction. As engineers, we are used to the pat on your back. Great job, you fixed the production issue or congratulations, you have your certificate of appreciation, you fixed most number of GRAS this month. As engineering managers, nobody does that for you. Unfortunately, that's the truth because your senior management could care two monkeys if you've done a great job and your team is actually expecting you to pat their backs. So it's essentially, I wouldn't say a thankless job, but tending towards there. So how do you get job satisfaction in such a scenario? You create your own yardstick. First of all, you have to keep a track of your achievements. Those little aha moments that you get when you're a manager of your team, let's say that you actually helped mentor somebody or you actually helped somebody towards their career aspirations. You document all of this. I used to maintain an Excel sheet and I'm a big user of Microsoft One Note with the tabbed notes so that I can actually tabulate every month what I have done. Do it on a daily basis because it's important, not just from your appraisal standpoint, but also from your sanity, for your sanity. Because sometimes what happens is, actually most times, an engineering manager's job cannot be quantified. You cannot count how many successes you have had or what you could do better. You could only way to do it is document those small aha moments that you had through the year. If not, it's easily forgotten. And to not lose touch with coding. I think if there's one learning that I would have is as managers, it's so easy to not code and lose touch with coding. And it's important because especially when you're looking for jobs externally, coding is the entry criteria. A manager or a senior software engineer or a leading engineer or architect, the entry level criteria is code. So if you lose touch, your choices go lower. And it's also important to understand how your team thinks and also if they are giving the right estimates and so on. Try to see if you can contribute in small way on your own projects. If not, start a pet project. Attend women who code meetups. Come and join us. We talk about code on a regular basis. But in any other meetup across Singapore, I mean, they're all awesome. And keep up skilling. Most engineers, especially women, who get into the engineering manager's role are normally filling in for somebody. Somebody who's gone on a vacation. Somebody who's gone on a sabbatical. Or if it's a new role, amazing. But when you are given that position, ask for a raise. Ask for a promotion. Because normally, you are not offered that promotion and not offered that raise. Do not ever do it for the learning. Or it will help me understand if I will like being an engineering manager. Or think that if I do a great job, they will actually give me a raise or a promotion. It never happens. It did not happen to me. And I unfortunately learned it a little bit late. And be ready for resistance. Because when you ask them, ask your senior management for a raise for a promotion, because you're doing an engineering manager's job, you will be given a little bit of resistance saying that you probably should try. And think, see if it actually works for you. Keep reminding them. That's what you can do. And I think eventually, things do settle down. And once you know that the engineering manager's role is for you, you don't want to feel left out and you think that you actually spend so much time actually doing that role and not having been given a raise. So that's all I had from the tips basket from what I've learned. If you are going to take up your first gig as an engineering manager, be kind to yourself. And it's building teams, hiring, communicating, minutes, emails. It's a lot to do. It's a tough job. You do not have to know everything. And it's OK to ask for help. And just remember, everybody has a manager. Even a CEO reports to a board, right? So they've got managers too. Thank you. My Twitter handles. If you like generative art, you can follow me. I keep doing a lot of generative stuff. Thanks.