Managing Your Team | Jeanine Jue

Okay, so managing your engineering team. We already talked about developer personality, therefore stating that all developers are different. Okay, so the mindset. Okay, we get stuck. Yeah, I totally do that. There'll be like one bug and I wasn't able to figure it out, and I'll spend a whole week on it, and I'm just stuck. I don't want to ask for help because I'm just stubborn like that. So that's where daily interaction with developers are needed, like the 5-minute standups every morning. Hey, try to help me out here. This is the problem I'm having. Things like that. And what else? So the standup meetings there. The big picture. It's interesting working with some different departments at companies. They're like, doesn't the developer know that this is the way the customer uses the application? We don't. We really don't because we're so focused on just getting that requirement done. It's like, okay, requirement to, put in a submit button on a registration form. Well, you need to tell me where that submit button is taking me and where you want that data to go. We're not, I mean, it's common sense to you, but we're working strictly on the requirements, so it's like shame on you for not writing good requirements. Engineers tend to overcomplicate things. I would, and I did this too, you would add so much extra code because it was fancy. Think about it. It's like when a developer's writing code, it's kind of like they're, like a painting, and we want to add additional stuff even though it doesn't make sense. That's why it's up to you to make sure they keep it simple. If all is needed is a for loop and not some complex algorithm, then make sure they just do the for loop. So the developer mindset. We're really bad at determining how much something's gonna, how long something's gonna take. And also, when we say it's done, it's not necessarily done. Done could potentially also mean, well, it's done, but we didn't test it. We ran it and it only has some warnings. So try not to rely so much on developers making up the decision in terms of how long it'll take to implement something. And I mean, overall, we're not great testers as well. That's something to also pay attention to because we're so focused on the code. I'm sorry, go ahead. Did you have a question? Oh, that was, you said not to rely on them to make these decisions for how long it takes to finish testing, so how would you— Oh, for testing?

Yeah.

Oh, I'd always have, so it depends. At an early stage, you could do one of two things. You can build out your test cases, and I think I was gonna mention that in this slide too. You can build out test cases, and like, okay, I wanna test, as a user, I'm going to test, I am going to log in. As a user, if I enter in the wrong format of an email address, it's not gonna let me submit. So I think as CEO, I think it's up to you to write the test cases and give the developers that understanding. I mean, developers certainly can test it, but they need the guidelines in order to be what to test for, because all they're testing for, and I'm not saying all developers, but what they're testing for is to make sure there are no warnings or errors or it doesn't crash or potential memory leaks. They're not testing for the whole usability, whether it makes sense. Also, feel free if you have any questions to interrupt me anytime. Okay, never squash the developer. I call it squash because never go to a developer and be like, I can't believe you screwed this up. We just launched this app. an update in the Apple Store. It's crashing, I hate you so much, don't do that, right? Because they already feel bad enough. And I personally, and especially I've learned this from managing as well, it's kind of like you really have to handle it a different way and just be like, okay, we have an issue. It's crashing in the store. Hey, can we test it out and see? Because the most important thing is to keep somebody motivated because you know Having a startup is extremely stressful. The last thing you need to do is having a parent tell you, oh my God, you screwed up, or you spilled milk on the floor. You really need to be as encouraging as possible. But again, if it happens again and again, then you have to reevaluate your team. But overall, I mean, what do developers need? Structure. Gotta give them some guidelines. Clear direction. Need to interact with them. That's why the stand-up meetings every morning, 5 minutes, hey, how's everybody doing on their bugs? And then also a 1-week review meeting, which I actually have there. And they need the encouragement. One thing that's important to— that was important to my team, they were introverts, and they certainly needed some visibility recognition. But don't do the award stuff. Oh my God, they just hate that, 'cause then, oh my goodness, this developer got the award, I didn't, I just— then they just start slacking and they don't want to code that much. But think about it. At the end of the day, you treat your developers right. I mean, the developers I had working for me, they would do extra hours for free because they were so passionate and they just loved to help me out because they know I care about them. I'm not going to work them to death. Then all of a sudden I discover that they're working on weekends for me. But again, I discourage that due to the fact I don't want them to burn out. So, go ahead. So what kind of, like, not title, but what kind of incentive would you give software developers? Well, first, what kind of incentive? Well, that they'd have, I mean, 'cause you don't incentivize, well, certainly in my case either. It doesn't take money to get somebody really excited. And wait, I think I listed here, Oh yeah, I do have here later on some of the incentives, like I'll sponsor their conference, you know, to go to a conference or give a talk. They get really excited about that. You know, feel free to add on an additional $50,000 to their salary. You're really wasting your money. You'd be better off sending them to conferences, and I also have some other stuff here. Conferences, hackathons, allow them to give presentations, and oh my goodness, they get so excited. What was it, a few years ago with my team, what I did, I gave them all software licenses to Experts Exchange. It's like $300 a person, right? And even though they could technically, I could give them a $300 bonus so they can get it themselves, but the fact that I thought of them and surprised them with it, they were like, oh my God, another developer tool. This is so exciting. Another network of people to connect to. Go ahead.

At my last company, they gave our developers like a half an hour to an hour of game time every day after lunch. We would just play multiplayer games together and hang out, and that really actually was super motivating for us.

That's a good idea. So some of the common excuses I've heard from developers, okay, why they can't get their stuff done. There could be a myriad of reasons, but detecting, is it true? Are they BSing me, or are they really having a problem? The system was down. I actually got this from a customer of mine. The system was down. I couldn't get it down. The API service was down. And I'm thinking, well, how long has it been down for? And then I'll go to the API service, find out how long it was down for. I said, it wasn't down. And I was waiting for something from somebody. And it's like, well, okay, let's facilitate that right away. Again, we don't want to accuse them. We just kind of want to solve the problem as quickly as possible. They come to you, well, I was waiting for this. Well, what do you need in order to get it done? So that's where you just have to be right in their face without micromanaging and making sure they have the tools in order to get the job done. I thought it was going to take 8 hours, ended up taking 5 days. Okay, I've worked with startups. Some of them do Slack, and they do take 5 days because they might be taking advantage of a co-founder that's not technical. So that's something you kind of have to gauge, and we'll kind of break it down a little bit. If they do end up saying stuff like that, and I think I have it in the next slide, checking lines of code and stuff. Oh, this is my favorite. I thought I uploaded the code onto GitHub. Didn't you see it yet? Yeah, right, okay, that's BS right there. It's like, if you don't know the standard GitHub command line tools in order to upload your code, you're full of crap. And another thing too, make sure they upload their code every day. I think that's really critical. I couldn't figure out this bug, but I added this really cool feature. I had this happen to me. They didn't want to fix this bug because it was boring, it was a pain in the butt, they couldn't figure it out. Well, they pulled this new feature, which really had no— it really wasn't even helpful for the product. I mean, I couldn't get mad at them. I was just like, oh, that's great. Maybe we'll put it in the next release. Son of a gun, we gotta put it— we need this bug fixed. So just having that whole little, hey, great job, but hey, how can we fix this upcoming bug so we can get a patch out? We can get our next release out. So again, as CEO, as co-founder, you're on the business side. I'm sorry, you need to be involved in the engineering side because a lot of stuff can— and I'm not saying don't trust your CTO or anything like that, but just to have that level of involvement. is really important. So going back to, is it true? Assess the issue, software, the timelines. Is it taking too long? Does this developer have a pattern? Break down the issue as much as possible. If they're having a problem with this bug, well, what is it that, what tool don't they have? Maybe they're just not very good at articulating what they need. So try to see if you can get as much information as possible. Ask for the numbers of lines of code. I actually caught a slacker developer and finally checked his code. He was only adding like 2, 3 lines of code a week. And I had a big team, so I couldn't even monitor that, and I was just like, okay, yeah, you son of a gun. But again, you always give them the benefit of the doubt, and you always say, okay, let's get you in more training. So maybe those bugs are too hard. I can't say he's a slacker, even though actually he was, but in some cases they might not be. So, and again, when I track and see, are they doing their job and doing it well, I'm doing it behind the scenes. I'll ask them questions, but they're not questions in which I'm throwing out accusations. I already have this information before going to them. And so take a look at the code they added. And this is where I said compare with sample. Again, going back to the CPR developers. Are they just copy and pasting? In terms of the number of lines of code, if you take that snippet of code, and I did this with my students all the time, the developers, take that snippet of code, throw it in Google, and see what comes back. So it's like, okay, are they just copying and pasting their parts of it, or are they really just adding new code, but that code snippet was just as good? But again, you don't have to be technical to do that. This is evaluation that you can do on your own.

Thank you.