Since bringing on a couple of contractors, one question that others ask is:

oWhat is it like to go from working on projects by yourself to working on projects with a team?

Or, more simply, what’s it like having contractors? The short answer is that I dig it because it affords some advantages:

  • we have to have a sharp division of work,
  • the business can take on more projects,
  • we’re able to collaborate on things (which is something I miss about flying solo),
  • and more.

The other side of this, though, is that I feel like I have to learn what it’s like to start a business all over again.

Team communication can feel like starting all over.

Like starting with a blank slate.

This, by no means, is a bad thing. It’s the opposite. But when you go from working on projects on your own and developing your setup, then there’s a period of adjustment that happens.

I’m still experiencing this and working through it. It requires both conversations with your team and a bit of introspection to determine if what you’re doing is still right for the way you work or if you should adjust it.

Team Communication

Obviously, this particular topic is broad and I – along with many of you – could talk about a variety of things as it relates to running a business.

But, for today, the one thing I want to talk about is the role in which team communication, not your software development tools, play in delivering solutions to others.

Your Tools Matter (But Not As Much)

For example, I’ve worked at placed where they bring you a machine with a particular set of tools and say “This is what we use to build our projects.”

Sure, it requires that you learn it, but part of me liked this as it removes a headache that comes with figuring out what to use. It also prevented me from having to make those decisions on my own.

On the flip side, it also made it harder to introduce a new tool because it would disrupt the workflow of an entire department. When you’re a small team, though, it’s a bit easier to adjust.

Visual Studio's my favorite IDE (for now).

Visual Studio Code has become by my favorite IDE.

First, when working for yourself, you likely have your favorite:

  • IDE,
  • source control system,
  • build tools,
  • deployment tools,
  • hosting environment,
  • and so on.

When you bring others into the mix, though, you’re bringing the same exact things except it’s on their terms. Now you’re tasked with having to determine if you should stick with what you have, evaluate what they have, make them adopt your tools, adopt their tools, mesh the two, or start over.

This isn’t a trivial manner especially when you’re working with one another to solve a solution for a client. I could write much more about this. And don’t get me wrong: I think it’s a topic that should be discussed and it’s something that I think is important.

But there’s something that sits above all of this that should never be underestimated, and that’s the process of team communication.

Communication Matters (And Matters More)

I’m not talking about making sure on checking in on people’s moods each day (though that’s important), and I’m not talking about chatting in text or Slack or IRC just for the sake of it so that you feel productive.

Team communication is more than Slack.

Team communication is more than Slack.

I’m talking about fully communicating requirements.

Case in point: Say I’m talking with a client, accept a contract, and then am ready to move forward. I know what they want, the existing designs, and how something should work. Then I bring in a teammate, and I say “Hey, let’s get started.”

The problem here is clear, right? S/he has no idea what it is we’re after.

And it doesn’t matter how much you outline the steps in your project management tool or chat about how something should work.

Furthermore, you can have the sleekest, most efficient tooling setup possible, but if your team is not clear on the requirements of the project then none of that matters.

When you decide to hire someone to help you with projects, and when you decide to start collaborating on the solution, table the discussion about tooling and first discussion requirements.

This cannot be understated.

If you know the requirements and your teammate does not, or if the requirements aren’t clearly communicated for one reason or another, then the proper solution won’t be delivered. And this is obviously costly.

Furthermore, if you end up thinking you have the same ideas in mind and end up implementing something completely different, then you’ve got another set of problems with which to deal.

As far as my business is concerned, I’m primarily concerned with developing relationships with the people with whom I work both on my team and with whom hires us.

But if the internal discussions around the solutions we’re working on aren’t on the same page, nothing else matters – not your tooling, not what you ship, not how fast you ship it, and not if it simply gets done.

More To Come

So in a future post, I’ll share a few ideas from personal experiences thus far – both mistakes and wins – in hopes that you’re able to avoid whatever it is that you may face when you opt to grow your team.

Don’t get me wrong: It’s a fantastic thing to do (and I love it), but it requires adjustments on levels with which I wasn’t completely prepared.

In the meantime, if you have things to contribute to this post, then please feel free to do so in the comments. I’m always eager to hear how freelancers and those who are also self-employed or who manage teams handle this particular topic.