Hey folks, and welcome to the small tech podcast by Ephemere Creative.
I'm your host Raph.
And today.
We are going to talk about scale.
Now for context.
I am used to working with small companies, whether that's startups
or non-profits or sometimes it's just entrepreneurs with an idea.
Yeah the sort of largest companies I've worked with are in the
sort of 30 employee range.
Our clients vary a bit more than that, but myself personally
that's the that's the experience.
So that's my caveat before, before we start this episode, but I think there
are still things that are important and interesting to think through when you are
considering scaling your company and your product even just from that sort of two
founders or a small nonprofit or whatever.
And you've got this product and it's got a few users and you need to take it
to thousands of users and you need to onboard a few employees to help manage it.
Those are things that aren't always as obvious as they might seem to be.
And yeah, they can be pretty complicated and they can help set the
tone for like your company's growth.
So.
Yeah, let's talk about it.
I kind of already touched on it, but the way I'm going to talk about
growth or scale in this episode refers to users of an application.
It refers to the size of your team that is managing and, or building the application.
It's going to be about the infrastructure that your application runs on.
And it's going to be about communication and how you interact with users.
Those contexts, but broken down into design, engineering, marketing,
and communications and operations.
So let's talk about design.
One of the things that I find happens with early stage products you know,
an entrepreneur with an idea who's just ready to throw out an MVP or
you know, a smaller organization who just wants to test out an idea.
Is that design is very fluid.
It's just throwing ideas together and changing them on the fly, testing them
a little bit, but not a whole lot.
Running them by some people that you trust, maybe a couple people
that you don't know so well, if you can get ahold of them, but in the
early stages, it's pretty tight.
It's pretty limited.
And so you can be very flexible and just throw things around.
Eventually, that starts to get disjointed.
If you don't have a system in place to manage your design assets, how you think
about design, your design principles?
And I guess even just like your information, the research
that you do on your users.
The data that you collect as you do interviews with them, that sort of thing.
And I think it becomes more and more important as you grow the product.
And as you grow the team, To make sure that you have all
of those things in place.
I think about this a little bit from a technical perspective,
because that is generally how I approach things is as a developer.
And so I like to know that a design team has things sort of tightly systematized.
Perhaps at the early stages, as you're starting to build a bit of momentum,
it doesn't need to be a full design system but at least some basics about
color usage about, about spacing.
And that sort of thing to help guide a developer so that they
don't always need to refer back.
They just know.
All right.
Yep.
This is kind of how we do things.
And if they see something in a design, they kind of instinctively
know what they're working with.
Otherwise, if they need to double check for every single design, like
the pixels in between things or the spacing you're going to have a mess.
It's going to be bad.
And so just getting into the flow of creating sort of structure around design
will help you create structure around your development processes, which might seem
like it could slow you down initially, but it will speed you up down the line
because developers won't need to always be questioning everything that they see.
So I think, yeah, basically just making sure that these things are organized
and communicated and sort of spread throughout the organization in a
sort of structured way where people kind of know where to get things.
From an engineering perspective.
I have this thing that has happened to me many times over the years, which is.
You build a monolith at first because it's simple and you can
get something out the door quickly.
And very quickly once you start to gain traction and people start to
interact with your product or maybe you're just handling more data.
Maybe something happens in the system.
And even if you don't have a lot more users, you're now processing
much larger video files or you're bringing in a million things to
process instead of the thousand that you were processing the day before.
And you start to realize how certain parts of your application just.
Would do much better being split out into their own infrastructure
that's specialized for its use case.
And so you start breaking apart this monolith into different services.
AKA are our favorite microservices term.
And that can be painful.
It can be.
Very helpful, but painful.
Because splitting out those things that are tightly coupled generally
when you're building a monolith.
It's just, it's hard if you're not technical, basically you're
taking things that have been like tightly bound together.
And expect to be bound together.
And you're trying to split them apart into these different systems that now have
to interact with each other more loosely and they have to grow independently and
change and they still need to be able to talk back and forth with each other.
And that stuff becomes kind of hard to organize.
So, yeah.
On a side note.
We at Ephemere Creative are building a framework called the Chewy Stack,
which you can find at gochewy.io.
That's G O C H E W Y dot I O.
And the whole point is to make it really easy to build something that
feels like a monolith when you're working on it but actually is deployed
as microservices and makes it easy for you to build out those services.
And manage the infrastructure on which they run and how they're configured
and how they talk to each other.
Basically the idea is it should be easy to build microservice-based applications.
Or just as easy to build them as it is to build monolithic ones.
So that's my little side note.
The other thing as you start.
Growing your your technical product.
Is that you'll find.
Okay.
So you will start splitting things into microservices.
And now maybe you've got a couple of developers working on one service and
other developers working on another.
And you need to make sure that everyone is able to run what they need to run
effortlessly otherwise work stops.
And there's a whole thing around dev ops and making sure that deployments
are automated and all of that.
But I think another thing that's not spoken about enough that I
find is often a huge pain point.
Is making sure that developers actually can run what they need
to on their local machines.
Even before deploying to an environment that they control, making
sure that they have access to the things that they require is painful.
So make sure you think through those processes, whether it's just like access
control in your git provider of choice or whether it's cloud environments or
provisioning laptops or whatever, like just make sure you've got a good process
to make sure that developers communicate between each other, the requirements
of the application and can get it up and running quickly without having
to jump through hoops or go through meetings with other developers and.
Make sure things are documented.
I know we all put that off developers.
Love to put off documentation.
The other thing is like, as your systems become more complex you know, you will
inevitably add different services, whether they are your own services that you're
managing or you're using third-party APIs.
You're providing integrations to other systems.
And as you do that, just little things sort of explode into bigger things.
And one little system that fails here is going to cascade
into a giant failure elsewhere.
And that can happen even with like pretty small applications
and it can be hard to debug.
So make sure that you have tooling in place to be able to find those failures
and make sure you can fix them fast.
Okay, so marketing and communications.
This is the stuff that I find is the most, like fun, to deal with
in in terms of like, scaling.
In part, because I just love looking at like the data and the flows that you can
build on top of on top of the data in an application or around an application.
I don't know.
It's just really neat to me.
And I love integrating apps.
With tools like Segment and Customer.io or Intercom, or I don't know, whatever else.
But I think there's something really important there.
Which is that early on, you might just use an SMTP provider and you
might just shoot out emails from your app when certain things happen.
And I think that's valid for a lot of use cases, even as you grow.
But there are certain things that you'll find, oh, I want to
communicate something with a user.
It's more about onboarding or it's about I don't know, retention.
You want to bring them back?
After they've dropped off for a while or, and those things you don't really
want to deal with that in your app, you, you should be doing that elsewhere
in a system that's built for it, like customer.io or like Intercom.
And you can build these really complex flows.
And that will help you sort of scale your communications.
But then you also need to be able to respond.
And so making sure that you've got like the right.
Infrastructure in place to handle people trying to reach out to you is
important that can even just be like, if you're using Google workspace.
Just make a group for like the support email.
And make sure that the right people have access to it.
It can be that simple, or you can use a custom, like a shared inbox with Intercom,
where you can collaborate on messages and see user data as you deal with it.
Or something like that.
But I find that some people don't know that those systems exist, and yeah, I
guess I just wanted to put it out there.
Like you, there are tools to like, make your life easier when it
comes to handling a lot of people trying to talk to you at once.
And you will need to scale up your team to deal with that, but there are things
that you can do to make it simpler.
So yeah.
Operational perspective.
I guess this ties into everything that we've already talked about.
As you're building out with just like a couple people you don't
really think about process.
It's just, it's responding.
It's things happen and you react to them.
But as you find people who like your product.
And it starts to solidify somehow in some ways.
You then get to a point where you're like, okay, we're doing this a lot.
And.
I can't do it anymore.
I needed someone else to do it, but I'm the one who knows how to do it.
And.
From an engineering perspective, just because that's how I frame things a lot.
We always think about like building systems and so writing
scripts to automate things for us.
In a human mode like.
You can't do that.
But you can.
Document things.
And you can tell people, Hey, this is where you need to look
for all of the information to.
Through the things that you need to do.
And I think it's really important to start doing that early to say,
yep, these are the processes.
These are the ways in which we do things and the ways in which we provide our value
to the world . And getting that done ASAP.
As soon as you start seeing that you're repeating yourself over and over.
And you start thinking, man, I wish someone else would do this.
Start documenting it.
I think also this ties back to what I was saying about design,
but like making sure people have access to the data that they need.
And don't have access to the data that they don't.
Is a good thing to start thinking through ASAP.
You want to make sure that you know, that someone that you hire who might
turn out not to be a great person.
Doesn't have access to things that they shouldn't have access to.
On the flip side, you want that go getter.
Who's just an amazing new hire who wants to help out and has great
ideas about how to do X, Y, or Z.
That, To have all of the things that they need to get that done.
And sometimes it's not super obvious all of the things that they'll need.
So just making sure you have, I mean, it could be as simple as like a shared drive
in Google workspace, just being like, yep.
This is where all of the marketing assets go.
This is where we put all of our, I don't know, sales information.
Stuff like that.
Just making sure that they have access to that and they can use it
without having to ask you for it.
Because if they're having to ask someone then you're, everything's going to
slow down and it's going to be a pain.
And then there's tied into this like communication.
I know so many people who think about this a lot, because it's painful.
Like communication is so messy.
Just generally.
Because of the proliferation of 20,000 different ways to communicate.
As a team.
Or as a human being with other people,
On your phone, on your computer.
But yeah, just making sure that you have clear guidelines on how to
communicate with other people when and where I think that's really key.
That's the thing that sometimes I have trouble with.
But I think it's really important as you grow a company, as you grow product.
Making sure that people know who they can reach out to when, where, why.
Yeah, I dunno.
I feel like that's mostly it.
I guess this was just sort of my thoughts.
I was thinking about like a few different companies that we've worked with at EC.
And a companies that I've worked with in the past and thinking
about like those challenges.
As you go from, you know, a couple of co-founders to 10 employees, 20
employees, 30 employees, or you've got 10 users on your app and suddenly
you've got a thousand users on your app or 10,000 users on your app.
And you're just like, oh, I think I need to change things.
I think I need to be ready for this.
Cause it's happening fast.
So yeah, just a couple of thoughts and hopefully they were helpful.
So yeah.
If you want to keep up with this stuff, make sure to like, and subscribe that's
on the YouTube or in your podcast app, or I don't know, we've been posting some
of this stuff on LinkedIn and elsewhere.
If you have thoughts, if you want to, if you want to talk to me on
the show, that would be awesome.
Reach out I'm at raphael@ephemerecreative.ca.
Shoot me an email.
We can chat.
We can do an episode together.
And yeah, we all want to do some good in the world.
So go out there and build something.
Good friends.
See ya.