Pointer is a reading club for developers. It’s a window into what other current and future CTOs are reading and thinking about.

Subscribe at www.pointer.io

5 Mistakes We’ve Made Scaling our Engineering Team

by Brett Boskoff

Author’s Background: Brett is the former head of development at RootZoo and now is co-founder and CTO at Splash, the world’s first experience marketing software that gives event producers the tools to design beautiful events, own every lead and seamlessly manage engagement and communication to deliver ROI.

Brett earned his Bachelor of Engineering degree in Biomedical/Medical Engineering from Vanderbilt University.

_____________

Scaling an Engineering organization is something every tech company must go through. One could argue this is an ongoing practice — your team is constantly scaling with every new hire.

As a technical co-founder, I’ve made plenty of mistakes. So many. Things that give me terrifying flashbacks. This may or may not have included bypassing Git and dropping files to our live environment via Cyberduck. But I digress.

Along the way, we’ve gotten better at managing the constantly evolving organism that is a tech startup. A lot better. We’ve lost some good men and women along the way, but 5 years in, we have righted many of our wrongs.

Regardless of your current dev team size, funding situation, or general phase in the process, here are 5 things that you should NOT do as you grow.

1. Rollout Strategies: Go Big or Go Home

This is nothing new, but it can be a hard rule to abide by. We strive to merge constantly and deploy often.

As your velocity increases, hotfixes can morph into features, and turn into epic-sized releases with several dependencies before getting merged in. Don’t let this happen! A decent way is to account for this in sprint plan meetings. Ask the question “How will this feature be released to our audience?” as early as possible.

Releasing features to 100% of your user base will likely be brutal. Creating silent release strategies for long-tail builds has been incredibly beneficial for us (cough cough buzzword city). For more immediate, large impact builds, devise a plan to push out to a selection of your audience — 10%, 20%, etc. When everything is stable, open the flood gates.

2. Unit Testing: We’ll do it when we have time.

I am embarrassed at how late we started integrating unit tests. I know, I know, you want to get as much done possible in the early days, so your testing has taken a back seat. As a dev team of 1–3, it’s tough to prioritize testing over product build.

I’m not suggesting 100% coverage. But please, find the major touch points of your application and make sure you’re covered. As the team grows, plan some time for testing in your future builds. It will save you tons of time in the long-run. If you’re too late down the road, plan a sprint in the coming weeks to focus on optimization and improving existing coverage. Depending on your team size, if everyone contributes, it can be a quick process.

3. One Javascript file to rule them all.

Ah, the good old days of 20,000 lines of spaghetti jQuery running most of our front-end. Don’t do it. If you’re working on a new feature for an existing part of your product, break it out into a separate file. Make it extendable for future-use on parts of your site that don’t exist yet. This rule applies to front-end, back-end, CSS files, etc. Find the modular breakpoints and separate.

A crucial part of the equation is internal best practices. If everyone is coding with similar behavior, this process will up. Come up with your own set of best practices for your team. Iterate when they’re outdated.

For reference, our own set of rules for internal Javascript best practices can be viewed here: http://devhonorcodejavascript.splashthat.com/

4. Putting new developers in a bubble

You’re moving a thousand miles an hour. You have to fill out your feature set ASAP. It can be tempting to throw a new hire on a siloed project.

I believe this is the worst mistake you can make with someone new, regardless of their experience level. She or he may feel isolated, do things their own way, and will likely fall short at the original goal. It’s like a game of telephone gone horribly wrong. In the end, you will have to rebuild the telephone.

Quick, easy wins is our preferred method of starting out. Come up with a few projects, 2 hours to 2 days in scope. No one wants to do trivial work — these builds should be low effort, high impact changes. Get this person used to submitting pull requests and having their code deployed to a live environment. Perform code reviews as often as possible. Once you feel that your new colleague is up to speed and ready for more, throw them onto larger builds.

5. Learn Fast.

Move past the sunk cost fallacy as quickly as possible. Getting stuck in your ways will cost you in the long term. This is not to say you should adopt new technologies at every opportunity — I actually prefer stable, mundane tech (Dan McKinley covered this topic well — http://mcfunley.com/choose-boring-technology). It’s important, however, to realize where weaknesses are in your process/technology and improve.

Many of these changes will come from new employees. Be receptive to feedback from your newest minds. If a new hire hadn’t questioned our deployment process, we would still be deploying in a manual 10 step process. Or taking 3 days to set up a computer for a new hire after they start.

Cue the flashbacks.

I’d love to hear about any (now obvious) mistakes that you’ve made as well. Please feel free to email me at brett@splashthat.com