Coach Mike: Working with Developers

All right, thank you everybody for joining us. This is Dustin. I am your podcast host and producer. Welcome to the Founder Insights Podcast, a Coach Mike episode. I'm joined here by Mike Supravici.

Hey Mike! Hello everyone, uh, it's great to be back. Just as a quick introduction for those that don't know me, and if this is the first time you're listening to the podcast, my name is Mike. I lead the Alumni Success Group here at the Founder Institute. Prior to this, I was an entrepreneur just like you, basically been through all the all the worst, or worst stories that you've probably seen. I've probably seen them myself. I also manage a portfolio of 4,000 companies here at the Founder Institute. So it's likely that I've also experienced from secondhand, I guess, from a founder, some of the challenges that you may have seen. So I'm here to share my knowledge in any way that I can.

All right. Yeah. And we're also joined in the studio today by our expert developer, BV. Do you want to give a little intro on yourself, BV?

Hello everyone. Thanks for having me here. I'm BV. I'm the founder and CEO of CodAstra. We do software development predominantly for startups. So before starting this, I mean, I have a software development experience of about 12 years. So I've done full stack development, managed a team of about 40 engineers with a couple of products.

And that's, yeah. And that's what we want to talk to today about is best practices for basically working with developers. And, you know, BV is sort of our in-house expert. Along with Mike, who they do a lot of our product and software development work for the Founder Institute. So I guess we kind of just want to dive right in and talk about, you know, different development resources. And I think like at the most high level, we want to talk about the difference between working with in-house developers versus working with outsourcers. So to kind of cue it up.

Yeah, so at the startup stage, the whole entire like in-house versus outsourced developers is like an interest, very interesting like debate. And you hear opinions about it all over the place, but just know that there's no one right way to do it. It just kind of depends on where your business is and what your abilities are to basically recruit. So in-house, the way we're gonna talk about in-house like moving forward for this podcast is these are folks that you've been able to recruit onto your team, whether it's as an employee or as a co-founder, okay? You know, and we're gonna talk about like, outsource as basically like someone that you've kind of hired on either as a contractor or some sort of contracting firm, and they're not necessarily part of your team. This is just one of the projects that they kind of work on. All right. So those are just two different approaches and neither one is better, right? You hear a lot of information about like, oh, well, this one's better for— it just depends on the company and what you're building. And in some cases it does make sense for you to have somebody in-house. And in some cases, it's okay for you to basically use a contracting firm depending on the use case.

Yeah. And so I think we want to kind of go through and talk about the pros and cons of basically working with an outsourcer and talk about it that way. So, I mean, to just kind of pose the question, you know, what are basically, I guess, some of the cons, right, to working with an outsourced team?

Yeah. So maybe I can start on this. So just a quick background. Maybe I should talk about this in my introduction as well. So I, I have been leading product development teams for over 10 years. I've launched 6 successful products before joining the Foundry Institute and I also lead product here at the Foundry Institute. So I've kind of seen all of it, like whether it's technical co-founders, hiring engineers, working with contractors as well. So I've kind of been exposed on all sides of it, right? And so one of the cons, I guess, of basically using a, let's call it like an outsourced firm, is that they're not there with you necessarily every day. They're not necessarily part of the actual mission of the company, right? And necessarily, and that could actually be okay in some cases. And as a result of that, they're also just gonna be basically kind of focused on kind of building their business, right? And sometimes it's delivering a product for you. Sometimes they may have other clients that they did develop for. So things like that. BV, do you have any cons on your end that you can kind of think of?

Yes, one of the major things I generally see is different business philosophies. So that, that's one of the major things which you need to look at. You need to look into a firm which is in line with your philosophies and they understand your product and they're in line.

Yeah, that's a super good point, you know, because if you're basically like using agile terminology, which we'll talk about maybe later, which is essentially iterating very, very quickly and then they're kind of doing like waterfall or some other type of product, right? Then that's just not going to work with your, your process as well.

Yeah, but there's some upsides as well, right? Especially for, you know, early stage founders or if I'm not technical, right? So like what, I guess there's, what are the pros, uh, that come to mind of being able to, to contract with somebody externally?

I guess there are two major pros here. The first is the cost and the second is the ease of hiring.

Mm-hmm.

So because you don't need to have an engineer at your place, you can actually hire from a place where it's not very expensive, as expensive as here. And, uh, probably, uh, you can find better talent there most of the times. So that's one thing. And the second thing is when you're hiring someone in-house, you need to go through a thorough process, make sure that he's the right person because you're going to retain him for a while. So all the hiring pain is gone and you can try out someone for a couple of months and if you don't like, probably you can always make a switch if you're going for an outsourcing firm.

Yeah, it's true. It is a little bit quicker from that perspective, particularly for those of you who are working in the United States. But this is also the case in many other countries, right? There's a lot of laws and regulation around employment. Versus, you know, a contractor. With the contractors, generally a little bit easier to part ways, essentially, right? There's no severance costs, things like that, unemployment, like things like that, right? So that's, that's definitely a benefit. Another benefit too is, you know, just being able to find people based on their kind of like their portfolio and things like that and kind of match it with like your, your style, right? Because a lot of folks kind of like advertise for this. You can find multiple people that can make sense for what you're doing and you can basically get them to do it like right away. That's also like another pro of using it. So the way I tell startups to think about it is just think about kind of like the type of business that you're building, right? Like if you are a purely, and I mean purely product business, and everybody thinks that they're product but they're really not. If you're purely product, then the only way you're gonna succeed is basically based on just like the product that you build, well, it's very likely that that needs to be part of your core competency as a team. For the founding team, like I would say at the very minimum, you should probably have a product person on staff, ideally also like an engineer as well, like that's on working together, probably in the same room to try to kind of think through this, right? So what's an example of a product like this? Like a social network, right? Could be one of them, right? Which you probably wanna kind of develop this way, you know, and you're kind of like gonna live and die by the user like experience that you're doing, and you're gonna have to iterate on that very, very quickly. But there's a lot of other companies out there that have a product, but they're not necessarily like product businesses. So a marketplace is a classic example of this, right? Like if you're building a marketplace, and I've used this as an example in previous like podcasts too, but like if you're building a marketplace, you technically don't really need like a product to even do the marketplace, honestly, right? You can just start facilitating transactions like, hey, you got this thing to sell, I go find you a buyer and you go ahead and do that. You can do that without a product, you know what I mean? And so that's mostly like an offline business and the product kind of, you just need something to kind of show that you're there, right? And so in that case, you know, maybe it's not as critical, at least at the early stages, for it to be like the number one, like core competency of, of the company essentially, right? So just, just kind of something to think about as you build your business.

Mm-hmm.

So for those kinds of businesses that, you know, uh, the core competency is not the product itself, right? So like a marketplace is the example you used, what are the kind of the ways that we can— you go about engaging with an outsourcer or development firm? How does that contract come to life? You know, what is the normal email correspondence that goes back and forth? Or, you know, kind of how does setting up that relationship work?

Yeah, maybe I can talk about sourcing, and then maybe you can come in and talk a little bit about like the other end when somebody like, like me or someone kind of engages you, tries to engage you, right? So From a sourcing perspective, it's very, very critical that you use trusted sources to get in front of people, right? Because there is a real risk of not only you losing your time and your money with regards to this, but just possibly even some IP-related things as well. So you definitely want to come through a trusted introduction if possible, right? So, you know, if you're a Founder Institute alumni or founder, for example, like we have a series of of folks that we know have done extremely good work for our community, and we can basically connect you to those folks. Another way is to use, you know, certain marketplaces out there that basically specialize in this. So for example, a good place for this is someone like a Toptal, right? What Toptal does is that they put engineers through a pretty rigorous process to basically ensure that they're a good fit. They actually give you an actual recruiter, and they basically make make sure that this is like a good fit. So, you know, maybe if I was to take a step back, like, you should also kind of understand where you are in your, your core competency as far as evaluating talent, right? So like, if you're a founder that has never built a software product before, you know, I certainly recommend that you basically go through a process more like a TopTal or something like that where they can literally match you with the type of person that like makes sense, or some sort of like a good recommendation of where you can find a development shop or an engineer that has worked with founders that basically don't know what they're doing. And, but if I was to just like summarize, basically founders that don't have never built a product before. Now, now if you're like a, a really good product manager or even an engineer yourself and you just need some help to basically outsource some of the non-core work of the things that you're doing, then you have a little bit more leeway there, right? Like you, you are able to better spot and identify talent through resumes and other marketplaces as well.

Mm-hmm.

You know, and then can you Maybe talk a little bit about like what are some of the things that you think about when you're trying to engage with like a particular person, if this is like a project that even makes sense.

I really like what you said about having a trusted introduction. That's really important because one of the cons which we did not discuss about outsourcing is data theft, which is a big deal for some of the companies. So I mean, of course you can always have legal documentation done there, but always having a trusted introduction is a good idea. And in addition to that, Going back to whatever I was saying about the matching of the philosophy, so it's important to find a company which actually is in line with what you think, and also the, the tech stack they're using probably is in line with what, what is needed for the product.

Yeah. So how do you interview the potential customer? Because I'm sure you do a lot of that too. When you have a lot of potential inbound customers, you want to make sure it's the right fit. You don't want to waste resources because otherwise it could be a big mess. Aligned, right? How do you think about like expectations and stuff like that?

Yeah, so that, that's one of the major things which we do because generally we take up about less than 20% of the projects which we generally come across because we, we have a limited set of engineers who are really good. So we want to give projects which are really interesting and which are guaranteed to succeed going forward. So one thing what we do is we try to understand the product, what's the status of the product, and do they really need engineering talent. So for example, very recently we were talking to one of the clients who were like, okay, I need 2 engineers for like 4 or 5 months. Let's get into an engagement. And what's the cost? She was directly jumping into the cost, but I was like, wait, hold on, hold on. What is the product about? What do you need this? And then we, we finally understood that she actually doesn't need full-time engineers at all. She just needs some Google documents for automating everything. And we ended up with I mean, it was a friendly relationship where we set up some documents and done. So yeah, so some of the founders, they actually don't know that they need engineers. They just think they need engineers and they go with hiring. So that's something. So we see if they actually need engineers and then what's the product they're trying to build. And sometimes there are a few tools which are available on en already where you don't have to reinvent the wheel again. So if there are tools like that which they can leverage on, so probably you can do with that. So Going with the marketplace example you were talking about, one of my friends wanted to have car rental product built, and then there was already a service existing for something similar, so we just set it up and it was going well. Again, so what I said is we do full-stack development. So what we look at is we kind of look at, uh, founders who are really passionate, who understand the product, and who actually need custom product development required for them.

Yeah, that's interesting. You know, I'd like to also just dive in a little bit more about, you said this really interesting point around like, is the project interesting enough for like the talent, right? Can you talk a little bit about that and like the talent and like their work capacity and how they engage with the project and things like that based on like just the type of project it is and things like that and why that's important?

So to speak specifically about the engineers we have on board, so all our engineers are from IITs, which are like You can consider them as the cream of the talent, so they're quite expensive. It's really important for us to give them interesting projects to retain them on board. Any project you give, I mean, each engineer is equal to 4 or 5 typical engineers which you find. For us, it's become a real big challenge to actually give them interesting projects. To give an example of a project which is not interesting would be a typical project. I mean, someone comes in and says, I would like to have a social networking site with no direction actually, to be very frank. Better way to say that is, okay, they would like to have a social network which influences ABC, and then you are actually married to the idea. So the people actually understand what the product is doing. Yeah. So we would like to actually take projects where we understand where it's being influenced.

And yeah, so the whys really seems to be like really important also just for, even though it is a contractor, they still have to want to like, want to work on this and otherwise you're just not gonna get like, as high a capacity potentially, right? And so as a founder, from a founder's perspective, you know, you really need to like think through the why this is important, right? And why this is valuable, even when you're trying to work with potential contractors for your project.

That's correct. Yeah. So engineers understanding why the product is being built, that, that, that's really, really important actually. That keeps the project really interesting.

Yeah.

It sounds like from the founder perspective too, like having a real clarity for what this product actually is, is a challenge that, you know, you see on and is founders coming in and it's a little ambivalent or not quite clear, you know, what they're in a ballpark of what they want, but it's just not specific enough. So in terms of like communicating and planning and working with an outsourcer, I mean, what are the kind of— so I know like there's things, you know, specs, wireframes, kind of how can founders help, especially if they're non-technical, they don't come from the product management background. What are kind of the toolkit that they can use as non-technical people to communicate that vision to you?

Yeah, and this is super important. So, you know, just from our end here as the Alumni Success Group, we work with a lot of founders, and I would say that every single time that a project doesn't work out and it causes a lot of pain on both ends, by the way, not just the founder but also the vendor, right, where nobody's happy, where this is basically a big mess, It's because of this where we're about to talk about right now, you know, because either expectations weren't set correctly by both sides or something was lost in communication or there was a tremendous amount of feature creep that wasn't accounted for and it was expected as part of like the initial bid and all this other stuff. So like if I was to kind of summarize like the most important thing to like a successful relationship with like an outsourcer or an outsourcing vendor, would be like incredible communication on both sides, really. So that's part of what you should be testing for when you're actually interviewing folks, and they would appreciate it too for various reasons, right? Especially if they're like, let's say there's a time zone difference, right? If you don't get back to them that day, then that change could take another day or another day after that to get fixed, right? So now all of a sudden your schedule just slipped by like 2 days because you didn't make that make that change. So we could talk about some tactical stuff. I just wanted to use as an example why communication is extremely important. So if you take anything away from this podcast, overcommunication is key in working with any sort of vendor, actually with anybody in your company, but in general with like, especially if they're remote, not with you, overcommunication, that way the expectations are set correctly.

Yeah, and there's different ways to kind of control your scope, right? There's like time versus project-based billing. I mean, what are sort of, I guess, to get a little more in the weeds, you know, what are kind of ways that the non-technical founder can be efficient at communicating in this way?

Yeah, no, I agree with that. Well, the first thing I would say is maybe we should go down in this and talk about this like tactically, right? Like number one, how do you communicate? Well, you should definitely have some sort of a spec, right? What spec means is short for a specification for your project. Which is essentially what you're trying to build. And BV, correct me if I'm wrong, like, how many projects do you start on that don't have a spec?

Many, actually. But we, we really help the founders come up with the spec. But that's the first step we need to—

yeah, okay, fair enough.

But as you said, most of the founders come to us without any spec, but we really want to start with that.

Yeah, you can't— so in other words, you can't start a project without a spec, right? So what are some of the most important things that You like to see in like a spec that will help you kind of really define a project, possibly even bid on it and things like that.

Yeah, so let's look at this in terms of the life cycle of specification of a project. So first we start with a documentation of what you would like to have. So probably you, you have some inspirations on, okay, this could be the product. So that's how we generally start when we write a scope. We generally kind of have screenshots of, okay, we take a screenshot from that particular product and say, okay, it could be something like this. So I mean, it need not be on a document per se, it could be in your mind too. But you start with documenting what are the list of the features or kind of things which you'd like to have. And then you put them into life by drawing wireframes. So when you draw wireframes, you could use tools like Balsamiq, which is available, or you could even use Paper Prototypes, which is something which I use very often, which is really fast. You can always discard things and draw something pretty quick. So I always go with paper prototypes. That's the best way of communication. With prototypes, the key is to not have details there. It's all about the user workflow.

Black and white, man. Black and white. This is what I always tell people too.

Yes, black and white, big boxes, no text. That's all. So that just explains you what's the workflow going to be for the user. And once that is done, probably you can have a designer or you yourself can add— I mean, you can have multiple wireframes. And then you can decide on one of them and then probably add more details to have some text. And probably some— then you can add some text, and that's when the development starts. And even when development starts, you're not just going to give the entire thing. It's okay, this is what needs to be built. You need to break this into bigger features or user stories. So what I would say is, let us say you would like to build, for an example, social networking site. So if you want to break that into multiple modules I would say chat is one functionality and user follows or user friend requests is another module and probably photo albums is another module. So I'm loosely using the term module, but best term to use here is epic. So in agile terminology, it's called an epic where it's a collection of bigger— I mean, it's a big feature which itself could be called as as a product. So you divide your product into epics and then you break down that into smaller tasks. You call them as user stories. And we are not calling them as tasks, we are calling them user stories because you really want to understand how the customer is going to use them. So the way you define user stories is, as a friend, I should be able to send a message to another friend. So something like this. So you, you're going to define who is going to use this particular feature or this page and what are they going to do in this page. So you're going to break that into multiple user stories.

So let's do that. So let's do that right now. It's actually not about it— that's a really interesting point. So let's take, let's take the login flow. Would that be considered an epic login flow?

Yes, that's an ideal example. So when you take a login, so first you, you can You can clearly see that that can be broken into sign up and sign in and forgot password. These are the 3 things.

Great.

So the whole login is going to be an epic. You can call it authentication. And then as a visitor, I should be able to sign up into the application. That's one user story. And then you can add some wireframes into this user story saying that, okay, this is how the page is going to look. You're going to have username, password field, submit, And then if the user enters wrong password or user is already into the system and he enters the email, you're going to show some message. So that is one user story. An existing user should be able to log into the system and then the wireframes show a username and password, you sign in, you're going to the dashboard. And then someone forgets, a user should be able to recover their password. So these are kind of user stories for authentication epic.

That's super interesting. And that's actually really helpful because many applications have this exact workflow, right? So, you were talking about communications, Dustin, one of the things we do here at FII, and I've basically done throughout my entire career, is that I use some sort of a scheduling tool. Like, in this case, I use Asana, and we'll have a column for epics, right? And then a column for what we call sprints, which is what we're gonna do this week. right? And we basically break down each feature using more or less a user story, more or less, right? It's not like the classic way, but it's pretty much the same concept. This is what should happen, things like that. And you kind of see the projects progress because the next stage of the project is in development, right? Then the next step is, what do we have? BB's QA, I think, right? Or something like that. Then HQ sign-off, which is us. And then we basically push it into production, right? And then back to the communication, which is how this started, everybody that's involved in this project understands where the project is, what everybody's working on, and how things are progressing. And if things aren't progressing fast enough, it gives you an opportunity to figure out why the schedule is slipping. It's like, "Hey, BV, what's going on here?" It's like, "Oh, we ran into this thing when we did this rearchitecture of this feature. It turns out that it's more complicated and it's actually added another a day and a half of development, right? And then you know what's going on, and then you can kind of budget what's going on there, right? And so that's why it's really important to use a tool to basically communicate about how the epics are going, how to each user story within that, and so on. So you've got the spec, and then you basically have a tool to basically kind of try to manage through that spec, essentially, right? And then I would say the last thing here is we like to use Slack here, but whatever tool it is, One of the things I found really helpful with remote teams in general is just scheduling a time every single day where we will know that we will be on there and we just talk and we just say hello, even if it is, I'll just be like, hey, hey, BV, like, how's it going, man? But in general, like, we generally talk about features, right? And your goal is to ensure that you answer all those questions at that time. I don't care what's going on in your life. I don't care if you got other things. Get that done. Because remember, if you're working with people that are in different time zones and things like that, it could be like a 24-hour cycle. So if you don't get back to people as quickly as you humanly can, then you can introduce another day, possibly 2 days of slippage in your schedule. So you just want to make sure that you answer all the questions as detailed as possible so that things can move forward, you know what I mean? And so just keep that in mind.

Yeah, it seems like that communication is really, really critical. I guess kind of other Interruptions can happen too in agile development, and whether you're testing some kind of new integration or there's slow feedback, all of those things, I mean, it all comes down to being able to communicate.

Yeah, and the idea is to make sure that you don't have slow feedback, right? Because slow feedback starts to get, make it percolate its way in through the entire project, and eventually the project doesn't end on time. And then everybody's like, "Wow, I can't believe this feature got delayed by 2 weeks." Yeah, because we the feedback wasn't fast enough, right? And so it's really important for you as a founder. This is how you're able to use basically like an outsourced development team to basically help you get to the product faster. It's like, okay, I got this build from the developer. Boom, I gotta go out and show it in front of a customer like right now. And let's go see what happens. Oh, customer did this, said this, you know, let's go ahead and try to improve this feature and things like that. And just kind of get into like the cycle, right? And the more you schedule times, the faster your cycles are gonna be. If you know it's every single day you have this one-on-one with, with your developer, that means that the, the first thing in the morning you need to do is you need to talk to your customer so that you can get all this information right before your meeting, right? And then that's how you start to create kind of like this, like very rapidly, like evolving kind of process with the team that's maybe not there with you.

Makes sense. Bibi, what have we forgotten to talk about? What are other, any other best practices that come to mind that we, uh, yeah, we talked about specing.

So we talked about breaking into epics and then into user stories. One thing which we missed somewhere in between is about the estimations. So before we start the development, we really need to estimate each of the stories on how long it's going to take. And in general, we need to account for a bit of a buffer in general because there is always some feedback cycle involved here. So that's one thing. And then what we generally do is, going back to what Mike was telling The workflow varies from team to team, but the workflow which we use is we have a column called icebox where any new idea we get, we just dump into the icebox. And then any user story which we think is needed, which makes sense, we pull them into the next column called backlog. Backlog is always a sorted list of user stories with the highest priority top at the top and lowest priority on the bottom. The next story is working on or current activity. If I'm an engineer, if I don't know what to do, if I'm done with the task, I don't have any confusion of what needs to be done next because I just take the top item from the backlog, just pull it and start working on that. When we are pulling an item from icebox to backlog, we generally try to estimate the task, trying to see how long it's going to take. Then every week we have a sprint plan meeting where we try to see what can be achieved in this particular week. This could be one week sprint, it could be two weeks sprint, it could be one month sprint. It depends on team and the pace at which the product is moving. We generally have a one week sprint. So let's say there are 4 engineers working on your team. So 4 engineers put together, it's about 20 workdays. So you try to schedule 16 days of work here, not 20 days, because generally we lose 1 or 2 days in trying to communication and some of the, what is, high priority bugs which will block the development here. From the backlog, we have already estimated the tasks. We'll take the tasks which account to about 16 days of work and pull them into the current sprint. And then we take task by task as we keep doing. We move into the current, we work on that, and then we move into the QA where a test engineer looks into that and tests and make sure that everything is according to the spec And because we work remote, we have one more QA section where is client QA. Here we have HQ QA where once that feature is tested, we deploy into a staging environment and then move into HQ sign-off where the client actually, or you as a founder, go through that and then see if it's according to what you wanted it to be. And once that's there, you can say, okay, it's all right, it's ready to deploy. Then you move to the next column called Ready to Deploy. Then we make it as release and deploy probably once a week or once a day. It depends again on the pace at which we are moving, and that's a cycle.

I'm really glad you brought that up as far as the estimation, because as a product manager, that's one of the main things that you have to do. One of the things that the rule of thumb that I generally live by as a product manager here is I just generally try to double every sort of estimate that we get from the engineering team, mostly because, you know, with software, it's just, to a certain extent, it's really difficult to estimate things until you really know the case. But it also buys us enough of a buffer to ensure that we reach things on time. And I recommend that you think about that as well as you kind of like start scheduling tasks. So if you— somebody says it's going to take a day, just double that, and it's going to take 2 days. And then If you are seeing a lot of slippage, meaning that the team is not making those estimations, so you've already doubled the estimations and they're not making them, and then they're not making them on a regular basis, then you basically have a problem. The way you manage through that problem is, first of all, you try to find out what's going on and why. Now, assuming that you don't know, like this is the first time you've built a product like this and you've never managed a software project before, What I would do is with those objections that you are getting from your team is I would go and reach out to several of your advisors or people in the network that you know or that have managed some sort of project and just say, hey, are these legitimate excuses? Right. But that's kind of like not a nice way to say it. But, you know, I mean, like, you know, these are not legitimate objections, right? Or they are legitimate objections, right? So I would do that as a first step. And eventually you will figure out if these are better and better and you will get your bearings and you start to understand, yeah, this makes sense. This doesn't make sense. Now, if you see this pattern continuing, let's say this pattern continues 3 or 4 times, then that's a pretty good indicator that you need to move on, and you need to go on to possibly another resource or things like that, because if that's the case, it's more difficult for you to build even bigger features, bigger things, and maybe this person is just not a good fit for the company moving forward.

All right. Well, I think that's about all the time that we have to talk. But thank you, Mike and B.V., for talking about product development with us, and, uh, thank you to our audience.

Yeah, that was really fun. Thanks for coming, BD. That was really great.

Thank you.

All right, awesome.