Dan Martell - July 02, 2018


How To Avoid Being Held Hostage By Your Software Developers


Episode Stats


Length

11 minutes

Words per minute

202.2753

Word count

2,264

Sentence count

84


Summary

Summaries generated with gmurro/bart-large-finetuned-filtered-spotify-podcast-summ .

In this episode, I teach you how to get your product built without feeling like you have been taken hostage by your development team. I talk about how to manage your team so that you don't feel like you are losing control over your development process, and how to ensure that your developers are actually executing on the features you need to get built.

Transcript

Transcript generated with Whisper (turbo).
00:00:00.000 Hi there, I'm Dan Martell, technology entrepreneur,
00:00:02.040 investor, and creator of SaaS Academy.
00:00:04.000 And in this video, I'm gonna teach you
00:00:06.000 how to get your product built without feeling
00:00:08.600 like you've been taken hostage by your development team.
00:00:11.040 And be sure to stay to the end where I share a link
00:00:13.240 for you to get my weekly sync process
00:00:15.640 so you can not only manage your team better,
00:00:17.720 but also ensure that your developers are actually
00:00:19.720 executing on the features you need to get built.
00:00:30.000 So maybe you're feeling frustrated that you've hired an external dev team and they've been
00:00:38.080 working and the scope's got out of control and it's costing you more and more money or
00:00:42.480 you hired a developer off of Upwork and you can't really seem to get a hold of him.
00:00:47.660 He's not communicating.
00:00:48.700 He's kind of like here and not there.
00:00:51.080 You're kind of unsure if he's actually doing the work or if he's just taking his time.
00:00:54.980 You're still paying him.
00:00:55.840 Things are getting built fixed but it's not moving to your liking.
00:00:59.660 Well, I'm gonna share with you some strategies
00:01:02.960 to help you feel absolutely certain
00:01:04.860 that the money you're investing in the product
00:01:06.960 is getting put to good use,
00:01:08.660 that you don't feel like if you had to swap out this developer,
00:01:12.200 or honestly, if anything happened to them,
00:01:14.400 that you wouldn't have to feel totally stranded,
00:01:18.220 or if you needed to bring somebody else to augment the team,
00:01:20.620 you could do that quickly if all of a sudden
00:01:22.120 you got a big customer order, et cetera.
00:01:23.960 You know, I've started off my career as a programmer,
00:01:27.620 So, technically speaking, I've never had this challenge.
00:01:31.120 I've coached many entrepreneurs, non-technical founders on
00:01:34.100 how to deal with this and a lot of the strategy I'm going to
00:01:36.100 teach you with today came from that process but I will say
00:01:40.400 from a financial point of view and maybe you can relate to
00:01:42.460 this as well is I'm not an accountant.
00:01:44.380 I did not go to school.
00:01:45.240 I do not have an MBA.
00:01:46.280 I've never graduated from university.
00:01:48.200 All of my understanding of financials came through just
00:01:51.240 doing, building, buying, investing in companies but what
00:01:54.020 I did maps to the same process as your development team.
00:01:57.380 The first thing is I made sure that all of the financial
00:02:01.280 systems, and this is back, you know, going over 15 years ago,
00:02:04.380 was up in a server.
00:02:05.480 Today you would use something like QuickBooks Online.
00:02:07.620 But I made sure that we consolidated,
00:02:09.500 that I had multiple people involved in the process so no
00:02:12.420 one person could take me out and I ensured that I brought in
00:02:16.260 experts to help me understand and teach myself at a high
00:02:19.240 enough level how I can get through understanding the
00:02:23.200 reports and also ensure that no one person could cause me
00:02:26.700 challenges so that's what I'm gonna walk you through as it
00:02:29.000 relates to your developers.
00:02:30.300 Step number one, cloud-based source repository.
00:02:33.800 Now if you don't know, you should ask but all great
00:02:37.200 developers and really any development team should have the
00:02:40.220 code, the programming language that you built your product in
00:02:45.120 up in the internet, in the cloud, the cloud is such a weird
00:02:48.420 word and essentially up on a server and some of the tools
00:02:51.920 and I'll link them below are sites like GitHub that allows
00:02:55.800 you to not only have everything in one spot,
00:02:58.100 but all developers can contribute to it.
00:03:00.000 You can deal with conflicts and as a business owner you can
00:03:03.500 actually see the change log of all the different changes that
00:03:06.280 are being made in real time.
00:03:08.720 Honestly, if every day you wanted to go check out the
00:03:10.540 change log and see what's being contributed or submitted to
00:03:13.460 the code repository, you could see that.
00:03:15.560 So that's number one is you got to get your code up in the
00:03:17.920 cloud and monitor it ideally on a daily basis to make sure
00:03:21.220 your developers are actually pushing new changes to the
00:03:24.460 repository. Number two, centralized access control.
00:03:28.460 So when it comes to authentication or logins you need a place
00:03:31.960 where all of these logins go there.
00:03:33.760 You have your administrative accounts on your servers,
00:03:37.060 in your source repository, all the different developer tools
00:03:40.460 that you might be using.
00:03:41.660 So the best way to do that is to use a product that allows you
00:03:45.260 to consolidate all those logins but then share them to
00:03:48.260 different people or roles or groups of people like your
00:03:51.520 development team so that they can use those logins especially
00:03:54.420 if you don't have the ability to sign new user access to it.
00:03:58.260 So tools like a 1Password Team Edition or many others,
00:04:02.760 you can look online, I'm gonna link some below
00:04:04.420 so that you can kind of see my favorite ones.
00:04:07.260 But doing that allows you to never feel like,
00:04:09.900 hey, if somebody got hit by a bus,
00:04:11.940 I don't even have the login to the server.
00:04:13.980 If I found somebody else to actually help me out,
00:04:16.400 I wouldn't even tell them how to get access to the system.
00:04:18.640 You need to take all of that out of the minds
00:04:20.740 of your development team and put it up
00:04:22.640 into a centralized access control solution.
00:04:25.640 Step three, documentation reviews.
00:04:28.940 Now, I'm gonna ask you to ask your developers
00:04:31.740 to document their changes.
00:04:33.040 At a minimum, when they're contributing new code
00:04:35.440 to the source repository, they should be writing some level
00:04:38.440 of description, they should be commenting their code.
00:04:40.740 But I think it just makes it easier if you just start off
00:04:43.740 as a culture and say, hey, every two weeks we're gonna sit
00:04:46.140 down and review the documentation.
00:04:48.440 And this could be everything from the database design,
00:04:51.040 This could be through some workflow diagrams.
00:04:53.300 This could be from pure code documentation.
00:04:56.120 But I think it not only ensures that it's getting done right
00:04:59.240 but it also lets your development team feel like
00:05:01.920 there's a reason for writing all this documentation
00:05:04.560 so that somebody's gonna see it
00:05:06.320 and you can also give them feedback and say,
00:05:08.120 I don't really understand this, can you explain it to me?
00:05:10.200 But that way you know if you brought somebody else in
00:05:12.460 they could get ramped up very quickly
00:05:14.000 because all the documentation is up to date and accurate.
00:05:17.000 Number four, pay for code reviews.
00:05:19.260 Now this is the one, I kind of stack them based on
00:05:22.360 absolutely must to more advanced things.
00:05:24.560 And pay for code reviews, I know you're like,
00:05:26.160 I'm already paying for the developer, Dan.
00:05:27.960 Why would I actually have to pay somebody else
00:05:30.100 to review his work?
00:05:31.100 Well the truth is, is just like in the financial example
00:05:33.600 I told you at the beginning, I need somebody else
00:05:36.180 that I trust to do a review.
00:05:38.220 And the good news is, is there's so many incredibly
00:05:40.980 talented programmers that might charge you 300 bucks an hour
00:05:43.980 that you might not be able to afford to write your code,
00:05:46.620 and trust me, there's way less expensive options,
00:05:49.620 but to have somebody in and just make it part of the process
00:05:52.360 and say, hey, every month I'm hiring a guy for four hours
00:05:55.560 to come in, review your code, give you some feedback,
00:05:58.740 give me some feedback on how we're building things,
00:06:01.040 the frameworks, are we building an extensible model,
00:06:03.240 like is it good programming code?
00:06:05.680 And that way for a few hours, a few hundred bucks,
00:06:09.240 you're gonna feel comfortable that it's being built right,
00:06:11.780 you're gonna have a second pair of eyes on the code base
00:06:14.780 and you'll know if all the other stuff I already suggested is
00:06:17.420 being followed.
00:06:18.420 So paying somebody else for a code review especially you can
00:06:20.980 get it for free if you build an advisory board.
00:06:23.060 I've got a video below on how to put that together so you can
00:06:25.460 watch that but having somebody come into your business, look at
00:06:29.320 the code, give you feedback on a monthly basis is an incredible
00:06:33.160 idea to never feel like your dev team's doing things wrong or if
00:06:37.400 they bounced and left that all of a sudden some new person is
00:06:39.880 going to come in and go holy moly, you've got a spaghetti
00:06:42.900 code, a rat's nest of features that really don't make any
00:06:47.580 sense, you just need somebody else to look it over.
00:06:50.280 Number five, succession planning.
00:06:52.400 So the best way to build it into the culture so it doesn't
00:06:55.920 catch somebody, you know, off guard because the truth is if
00:06:58.680 somebody's actually writing code and being good, the last thing
00:07:02.260 you want to do is say, hey, let's talk about like, you know,
00:07:05.220 who should take over your role.
00:07:06.660 The way I think about it is as a business you should just build
00:07:09.920 succession planning into the way you operate.
00:07:12.760 So that means for you as a CEO, your marketing person,
00:07:15.660 whoever else you have on the team,
00:07:17.020 you should always ask yourself what happens if somebody has a
00:07:19.960 baby, gets injured, gets sick, whatever it is takes another job
00:07:24.540 and look, no harm no foul.
00:07:26.140 We just need to plan for this and ideally on a quarterly basis
00:07:29.340 you're kind of just reviewing that and saying,
00:07:30.780 you know what, marketing point if something happened for a month
00:07:33.420 we would just transition the load or we'd hire this
00:07:35.240 contracting company and then from a development point of view,
00:07:37.980 well, we would probably have to work with this contractor
00:07:40.640 that we met, so why don't we just put the documentation
00:07:43.980 in place so that we can transition that.
00:07:45.720 So just the idea of talking about succession planning,
00:07:48.660 not specifically for your developer or your dev team,
00:07:51.460 but just broadly speaking for your business,
00:07:53.260 it's gonna help you get the same result
00:07:56.100 without isolating an individual.
00:07:58.900 So very important, get everything documented.
00:08:01.900 Ensure that we always pass the bus test.
00:08:03.740 What happens if somebody gets hit by a bus?
00:08:05.600 and then that way you'll sleep better at night.
00:08:07.960 Number six, continuous integration, or what's called CI.
00:08:11.540 So essentially the concept is simple,
00:08:13.640 is anytime somebody submits code to the source repository,
00:08:17.280 you know, up in the cloud, it builds the code to the,
00:08:21.780 you know, it goes to staging first,
00:08:23.620 so everything it needs to actually like take the code,
00:08:25.680 build it, deploy it to your staging server,
00:08:27.660 then you ideally would go in there,
00:08:29.320 make sure the features are good, everything's fun,
00:08:31.900 and then you deploy it to production.
00:08:33.520 So same thing but what happens is it automates that process
00:08:37.220 so you know that just the fact that if you needed to scale up
00:08:41.320 your web servers or scale up your database infrastructure,
00:08:44.120 the continuous integration process is gonna keep track of
00:08:47.620 dependencies so you never feel hostage to even just the
00:08:52.020 infrastructure.
00:08:52.820 There's the code that runs on the servers but then there's
00:08:55.620 your server configuration for your different environments.
00:08:58.020 You know developers usually build on their local environment
00:09:01.220 then they push it to codes repository.
00:09:02.620 That pulls it into staging.
00:09:04.020 Staging is where you test stuff and then that gets pushed
00:09:06.460 out to production where your customers interact with it.
00:09:09.260 So having that automatically deployed,
00:09:12.020 it's what it's called continuous deployment,
00:09:14.360 will allow you to feel comfortable that not only is the
00:09:16.660 code kind of centralized and documented and well built
00:09:20.640 through the steps one to five but now all of a sudden the
00:09:23.380 server infrastructure and the configuration and just
00:09:25.740 deploying new changes is automated.
00:09:28.540 It's gonna make you feel super, it's an advanced thing.
00:09:32.480 So you're gonna be like, man, we got CI,
00:09:34.180 we got continuous deployments.
00:09:36.360 But the truth is, is if you haven't done one to five,
00:09:38.120 start there.
00:09:39.060 At some point, somebody on the team's gonna bring it up
00:09:41.120 because it's just a great best practice for you
00:09:43.600 to really mature your development process.
00:09:46.060 So quick recap, step number one,
00:09:48.100 cloud-based source repository.
00:09:50.560 Number two, centralize access control.
00:09:53.760 Step three, documentation reviews.
00:09:57.300 Number four, pay for code reviews.
00:09:59.840 Number five, succession planning.
00:10:02.040 Number six, continuous integration or what's called CI.
00:10:06.040 As I mentioned at the beginning I want to share with you the
00:10:08.180 weekly sync framework.
00:10:09.840 It's below in the description below this video.
00:10:12.180 You can click the link to download that for yourself.
00:10:14.380 I'm going to go over a bunch of things that I do every week
00:10:17.120 with my team but specifically things like the scorecard so you
00:10:20.560 know what aspects to measure on each core function of your
00:10:24.600 business, the customer headline so you can actually have a place
00:10:27.800 to bring forward some wins that your rest of your team may not
00:10:30.900 even be aware of and things that they're building and
00:10:32.900 changing and then also I'm going to encourage you to rate
00:10:36.340 every meeting so that every person feels like they have the
00:10:39.440 opportunity to voice their concern if they're on a meeting
00:10:42.580 that they shouldn't be on or if it's not adding 100% value
00:10:45.340 for them.
00:10:46.340 These are 30 to 45 minute incredibly valuable must do
00:10:49.720 meetings you can click the link below in the descriptions to
00:10:51.580 download your copy.
00:10:52.920 If you like this video be sure to click the like button below.
00:10:56.160 Subscribe to my channel and leave a comment.
00:10:59.060 I'd love to hear from you.
00:10:59.900 What are you doing in your dev process
00:11:01.600 to ensure that it's just humming and rocking?
00:11:04.060 I appreciate you watching this video
00:11:05.480 and I'll see you in the next one.
00:11:09.720 Yeah, do that again.
00:11:10.720 Yeah.