The job of a software consultant is exciting and dynamic. We enjoy being consultants because we welcome a new challenge, we embrace different perspectives, and we love continually working with the latest tech. And as we've demonstrated in previous installments, those benefits don't have to come at the expense of a welcoming team and a developer-friendly environment. At The Gnar we pride ourselves on our positive culture and our focus on work life.

There's a third piece of the puzzle: the support structure for the individual employee. Having a solid team and a comfortable work environment is great, but what do I do when I get stuck on a specific problem? How can I grow my technical skills? What resources are available when I want to learn more? What if I need help dealing with an issue outside of work? At The Gnar we are intentional about supporting each team member, whether it be on an immediate technical issue, a long-term career goal, or a personal hurdle. Being a member of this team means you are not just fingers at a keyboard; we recognize that you likely want and need support and that you have goals beyond just the next client. Following are some more consulting myths that we disprove at The Gnar.

Myth: I'm On an Island

While there are certainly some people who like to work alone, we tend to find that developers prefer to work on a team. For that reason we gravitate toward multiple-developer projects. A shared objective is a great motivator, and a shared burden is a lighter load. As our client list is expanding, the average team size is expanding as well.

Not to mention, it would be a shame not to leverage all of the knowledge we have between us. Our team includes alumni from Thoughtbot, Pivotal Labs, Harvard University, Vistaprint, MeYouHealth, Athena Health, and more. There is a wealth of experience between us, and we are always looking for ways to leverage that knowledge for the wider group.

When it comes to immediate support, we use Slack heavily. We have several language-specific channels for tackling a code issue or posting a new idea or article. We encourage our team to take their questions to one of these public forums, because if they have a question it's more than likely that someone else has that same question. It can be a little intimidating at first to post a question to #ruby for all to see. But once you see that first (or first three) responses back you'll be glad you did. We use Slack's huddle feature quite a bit, when pairing is warranted. We'll often open a huddle in one of our public channels, so that others can chip in or just watch and learn.

Myth: I Will Be Thrown Into the Fire

The false persona of the lone wolf gun slinger creates a misconception that to be in consulting you have to be able to handle anything at any time. We find that building custom software presents the same challenges whether in a product or consulting setting, and we feel the support should be the same for both types of organizations. Our clients expect a certain level of performance from us, and we aim to achieve that.

To that end, we will do everything we can to set our developers up for success. There is no chance you will be put on a project with a tech you are unfamiliar with (yes, we've heard of this happening) unless you want to be, and unless we feel that you can be successful with it.

Over half of The Gnar's business is return business. Not only does this demonstrate that our clients really like working with us; it also means we put a premium on maintaining long-term relationships with our clients. Putting a developer on a project in which they cannot succeed is not in our business interest.

Myth: I'm Just a Billable Resource

We hope that we have demonstrated in our previous installments that team members at The Gnar are anything but just a cost center. But we understand that this model does exist in the tech consulting industry.

We aim to support our team like any proper engineering team should. We don't hire folks just to fill seats, we hire for the long term. To do that successfully, we support our people as people, not just as employees. We hold one-on-one meetings for each team member on a regular basis, and these meetings are not with other engineers. These are meetings with our Director of People Operations, focused on any and all issues that may be impacting your day.

People need support in different ways, and we must learn from each other in order to understand how best to support each other. We have a diversity, equity, and inclusion working group that proactively improves our ability to help folks feel welcomed, respected, and valuable at The Gnar. We have a mental health and wellness Slack channel that many of us (definitely me!) utilize in order to deal with any internal struggles that could be impacting our lives and our work. If someone needs an hour or two to regroup, recharge, etc., we encourage them to take the time they need and make it up whenever they are back to feeling good.

Myth: I Won't Learn Much

Another misconception about consulting is that because the work is so heavily client-focused, there isn't time for a developer to learn and grow. Our founders understand that in order to retain quality talent, we need to support individual growth. Moreover, that forever-learning, beginner's mindset is exactly the kind of people we want working at The Gnar. We're interested in developing broad and deep skills.

On a day-to-day basis, we cross-pollinate via code review. At The Gnar the entire team has the opportunity to review any pull request. (Certain restrictions apply depending on the client.) PR review isn't just a benefit to the submitter; it can be a great way for a reviewer to learn about a pattern or a framework that they are less familiar with. We encourage our team to review PRs even if they only have questions. In fact that's a great reason to review! Gnar-wide PR review is a value proposition for our clients as well. When you hire a developer, you're not just getting that dedicated person, you're getting the whole team's input.

One of our favorite recurring team meetings is "Show the Codez!" We gather (virtually) every few weeks, and anyone who has signed up gets to talk about something cool or interesting they have been working on or learning about. It's a technical discussion that usually involves lots of code. We have some seriously impressive demonstrations, so much so that we've started recording them. Hopefully you'll get to see one soon!

Finding time to ramp up on new tech during the week is tough. We can't in good faith spend billable time on work that isn't billable. So we've created a program called Gnar Internal Learning and Development (GILD). When a team member has a window of time between clients (typically about a week), that team member is eligible to take part in GILD and spend those days digging into a tech that is in The Gnar's wheelhouse. The GILD member gets a paid crash course, and the company gains a stronger developer.

In some cases the best path to knowledge is your own. To that end, each team member is given an annual budget for professional development. Whether you prefer books, training videos, or in-person classes, The Gnar will help you reach your professional goals by subsidizing those expenses.

Series Conclusion

We hope that over this series of posts we have expelled some - if not all - of the misconceptions of working in software consulting. Working at The Gnar means a lot more than building apps for other people. It means engaging with challenging technical problems and being part of a team of people who support each other professionally and personally. It means working on projects that are worth working on, not just those that make money. It means building foundational software we can be proud of. And it means participating in a culture of quality and care. The Gnar is different in all the right ways when it comes to being a software consultancy. If you've been contemplating consulting and have preconceived ideas about it, give us a call. We'll see if we can explode some of them.

Credit where credit is due: There is an open issue related to author re-assignment on this platform. This post was written by the one and only @taylorkearns, and published by the Content Manager at The Gnar Company.

Learn more about The Gnar and our team.