- Hi there, I'm Dan Martell, technology entrepreneur,
investor and creator of SaaS Academy and in this video
I'm gonna teach you how to get your product built without
feeling like you've been taken hostage
by your development team.
And be sure to stay 'til the end where I share a link for you
for you to get my Weekly Sync process so you can not only
manage your team better but also ensure your developers are
actually executing on the features you need to get built.
(upbeat music)
So maybe you're feeling frustrated that you've hired an
external dev team and they've been working and the scope's got
out of control and it's costing you more and more money or
you hired a developer off of Upwork
and you can't really seem to get a hold of 'em.
He's not communicating.
He's kind of like here and not there.
You're kinda unsure if he's actually doing the work
or if he's just taking his time.
You're still paying him.
Things are getting built, fixed
but it's not moving to your liking.
Well, I'm gonna share with you some strategies to help you feel
absolutely certain that the money you're investing in the
product is getting put to good use.
That you don't feel like if you have to swap out this developer
or honestly if anything happened to them that you wouldn't have
to feel totally stranded.
Or if you needed to bring somebody else to augment the
team, you could do that quickly if all of a sudden you got a big
customer order, et cetera.
You know I started off my career as a programmer so technically
speaking I've never had this challenge.
I've coached many entrepreneurs, non-technical founders on how to
deal with this and a lot of the strategy I'm gonna teach you
today came from that process.
But I will say from a financial point of view and maybe you can
relate to this as well is I'm not an accountant.
I did not go to school.
I do not have an MBA.
I have never graduated from university.
All of my understanding of financials came through just
doing, building, buying, investing in companies but what
I did maps to the same process as your development team.
The first thing is I made sure that all of the financial
systems, and this is back going over 15 years ago,
was up in a server.
Today you would use something like Quickbooks Online.
But I made sure that we consolidated.
That I had multiple people involved in the process so no
one person could take me out and I ensured that I brought in
experts to help me understand and teach myself at a high
enough level how I could get through understanding the
reports and also ensure that no one person
could cause me challenges.
That's what I'm gonna walk you through
as it relates to your developers.
Step number one, cloud base source repository.
Now if you don't know, you should ask but all great
developers and really any development team should have the
code, the programming language that you built your product in
up in the internet, in the cloud.
The cloud is such a weird word, and essentially up on a server.
And some of the tools, and I'll link them below,
are sites like GitHub that allows you to not only have
everything in one spot but all developers can contribute to it.
You can deal with conflicts and as the business owner you can
actually see the change log of all the different changes that
are being made in real-time.
Honestly, if every day you wanted to go check out the
change log and see what's being contributed or submitted to the
code repository, you can see that.
So that's number one, is you got to get your code up in the cloud
and monitor it, ideally on a daily basis to make sure your
developers are actually pushing new changes to the repository.
Number two, centralized access control.
So when it comes to authentication or log ins,
you need a place where all of these log ins go there.
You have your administrative accounts on your servers,
in your source repository, all the different developer tools
that you might be using.
So the best way to do that is to use a product that allows you to
consolidate all those log ins but then share them to different
people or roles or groups of people like your development
team so that they can use those log ins especially if you don't
have the ability to assign a new user access to it.
So tools like a 1Password Team Edition or many others.
You can look online.
I'm gonna link some below so you can kinda see my favorite ones.
But doing that allows you to never feel like,
"Hey, if somebody got hit by a bus,
"I don't even have the log in to the server if I found somebody
"else to actually help me out.
"I wouldn't even tell them how to get access to the system."
You need to take all of that out of the minds of your development
team and put it up into a
centralized access control solution.
Step three, documentation reviews.
Now, I'm gonna ask you to ask your developers
to document their changes.
At a minimum when they're contributing new code to the
source repository, they should be writing
some level of description.
They should be commenting their code.
But I think it just makes it easier if you just start off as
a culture and say, "Hey, every two weeks we're gonna sit down
"and review the documentation."
And this could be everything from the database design.
This could be through some workflow diagrams.
This could be from pure code documentation but I think it not
only ensures that it's getting done right but it also lets your
development team feel like there's a reason for writing all
this documentation so that somebody's gonna see it and you
can also give them feedback and say,
"I don't really understand this. Can you explain it to me?"
But that way you know if you brought somebody else in they
could get ramped up very quickly 'cause all the documentation is
up to date and accurate.
Number four, pay for code reviews.
Now this is the one, I kind of stacked them based on absolutely
must to more advanced things and pay for code reviews,
I know you're like, "I'm already paying for the developer, Dan.
"Why would I actually have to pay somebody else
"to review his work?"
Well the truth is is just like in the financial example I told
you at the beginning, I need somebody else that
I trust to do a review.
And the good news is is there's so many incredibly talented
programmers that might charge you $300 an hour that you might
not be able to afford to write your code,
and trust me there's way less expensive options,
but to have somebody and just make it part of the process and
say, "Hey, every month I'm hiring a guy for four hours to
"come in, review your code, give you some feedback,
"give me some feedback on how we're building things,
"the frameworks. Are we building an extensible model?
"Like is it good programming code?"
And that way for a few hours, a few hundred bucks you're gonna
feel comfortable that it's being built right.
You're gonna have a second pair of eyes on the code base and
you'll know if all the other stuff I already suggested
is being followed.
So paying somebody else for a code review,
especially you can get it for free
if you build an advisory board.
I've got a video below on how to put that together so you can
watch that but having somebody come into your business,
look at the code, give you feedback on a monthly basis is
an incredible idea to never feel like your dev team's doing
things wrong or if they bounced and left then all of a sudden
some new person's gonna come in and go,
"Holy moly, you've got a spaghetti code,
"a rat's nest of features that really don't make any sense."
You just need somebody else to look it over.
Number five, succession planning.
So the best way to build it in to the culture so it doesn't
catch somebody off guard because the truth is if somebody's
actually writing code and being good,
the last thing you want to do is say,
"Hey, let's talk about who should take over your role."
The way I think about it is as a business you should just build
succession planning into the way you operate.
So that means for you as a CEO, your marketing person,
whoever else you have on the team,
you should always ask yourself what happens if somebody
has a baby, gets injured, gets sick, whatever it is,
takes another job.
And look, no harm, no foul.
We just need to plan for this and ideally on a quarterly basis
you're kinda just reviewing that and saying,
you know what?
Marketing plan if something happened for a month,
we would just transition the load or we'd hire this
contracting company.
And then from a development point of view,
well we would probably have to work with this contractor that
we met so why don't we just put the documentation in place so
that we could transition that.
Just the idea of talking about succession planning,
not specifically for your developer or your dev team but
just broadly speaking for your business is gonna help you get
the same result without isolating an individual.
So very important, get everything documented.
Ensure that we always pass the bus test;
what happens if somebody gets hit by a bus?
And then that way you'll sleep better at night.
Number six, continuous integration or what's called CI.
So essentially the concept is simple.
Any time somebody submits code to the source repository,
you know, up in the cloud, it builds the code,
it goes to staging first so everything it needs to take the
code, build it, deploy it to your staging server then you
ideally would go in there, make sure the features are good.
Everything's fun and then you deploy it to production.
So same thing but what happens is it automates that process so
you know that just the fact that if you needed to scale up your
web servers or scale up your database infrastructure,
the continuous integration process is gonna keep track of
dependencies so you never feel hostage to
even just the infrastructure.
There's the code that runs on the servers but then there's
your server configuration for your different environments.
You know developers usually build on their local
environment, then they push it to code repository.
That pulls it into staging.
Staging is where you test stuff and then that gets pushed out to
production where your customers interact with it.
So having that automatically deploy,
is what it's called, continuous deployment,
will allow you to feel comfortable that not only is the
code kind of centralized and documented and well built
through the steps one to five, but now all of a sudden the
server infrastructure and the configuration and just deploying
new changes is automated.
It's gonna make you feel super, it's an advanced thing so you're
gonna be like, "Man, we got CI. We got continuous deployments."
But the truth is is if you haven't done
one to five, start there.
At some point, somebody on the team's gonna bring it up because
it's just a great best practice for you to really
mature your development process.
So quick recap.
Step number one, cloud base source repository.
Number two, centralized access control.
Step three, documentation reviews.
Number four, pay for code reviews.
Number five, succession planning.
Number six, continuous integration or what's called CI.
As I mentioned at the beginning,
I want to share with you The Weekly Sync framework.
It's below in the description. Below this video,
you can click the link to download that for yourself.
I'm gonna go over a bunch of things that I do every week with
my team but specifically things like the scorecard so you know
what aspects to measure on each core function of your business.
The customer headline so you can actually have a place to bring
forward some wins that the rest of your team
may not even be aware of.
Things that they're building and changing.
Then also I'm gonna encourage you to rate every meeting so
that every person feels like they have the opportunity to
voice their concern if they're on a meeting that they shouldn't
be on or if it's not adding 100% value for them.
These are 30 to 45 minute incredibly
valuable must do meetings.
You can click the link below in the descriptions
to download your copy.
If you liked this video be sure to click the like button below.
Subscribe to my channel and leave a comment.
I'd love to hear from you.
What are you doing in your dev process to ensure
that it's just hummin' and rockin'.
I appreciate you watching this video
and I'll see you in the next one.
Yeah, do that again. - [Jaret] Yeah?