Asset 1 hunter casablanca mastGeneral envision VidantHealth HunterIndustrial Lexmark Teradata ValuePlace Xerox

How to Build a Front End Team

by Andrew Mosby
  • Careers
  • Culture
  • Development

Ok, Google. “How to Build a Front End Team.”

If there’s one thing that every developer knows, it’s that what you don’t know, Google can tell you. Seriously, Google (and by extension, Stack Overflow) is every developer’s bestie. Even the most seasoned devs often find ourselves knee-deep in a problem that we can’t solve quickly. The good news is, somebody before us got to the other side.

Open source FTW.

But there’s one thing that—no matter how I ask it—Google won’t tell me. I am not feeling lucky.

There are plenty of articles out there about how to grow at the individual level. But when your agency grows from a one-person team to a multi-person, multi-experienced, multi-interested team, how do you stay consistent? How do you ensure that you’re learning and getting better? How do you ensure that your code is meeting the highest standards?

At many agencies, the nuts and bolts of how to keep code top-notch might be enough to grow a team well—and that's a big part of this article as well. But first, we have more to consider—and that’s place.

Small Town Flavor

A friend of mine who just got married recently told me a story. She was at the wedding of a friend who was also from Johnson City. The band starting playing Wagon Wheel, which is a stalwart of gatherings here in Johnson City—mostly because of the reference to Johnson City near the end of the song. When the band got to that lyric (“...but he's a-heading west from the Cumberland Gap to Johnson City, Tennessee”), the person standing next to my friend leaned over and said, “As if there was a real place called ‘Johnson City.’” She laughed and reminded him he’d be at her wedding, which was in two weeks in—you guessed it—Johnson City.

So, you’d be forgiven for not knowing exactly where Johnson City is. (Actually, even the writers of Wagon Wheel were a bit off. Johnson City is actually east of Cumberland Gap.) And this is something we have to contend with when searching for talent to join our team.

But we live in the mountains for a reason. We have that Southern Hospitality on LOCK. We will say hi to you on the sidewalk even if we don’t know you. We will open the door for you. We’ll tell the clerk that you were in line first if you had to step out for a second. And we always do what we say we’ll do.

These faces behind the screens at Ntara don’t live in tech hubs like New York City, Atlanta, or San Francisco. We all live and work right here in Johnson City. And—unlike the tomatoes and squash in our home gardens—good Front End Developers aren’t in abundance in our community.

How do we grow well?

When we do get lucky and find great people to work with, how do we grow as a team? How do we make sure we’re not solving the same problem different ways? How do we ensure that we’re getting stronger?

“Sharpening the Axe”

One of the biggest challenges Ntara faced when we were only rolling two developers deep was workload. Projects were always coming in with little-to-no space after one and before another. That left us making the same mistakes and fixing the same issues on every project.

Our axe was dull.

Since then, we’ve added a one-week “decompress mode.” This is the perfect time to take care of small maintenance issues that websites tend to need. We optimize images that are too big, clean up scripts that take too long—anything that speeds up our sites.

Decompress mode is also a great time to update our home-grown CSS and JS frameworks. Any bug we fixed or cool feature we'd like to have as an option, we integrate at this time.

For example, we added the functionality to keep navigation visible at all times on one of our sites. So, once we fully tested that across mobile devices, operating systems, and web browsers, we can safely add it to our Javascript Framework.

This way, next time it seems like a good solution, we just call it:

StickyNav();

This saves us development time and QA time.

Professional Development Plans (PDPs)

Any small agency is going to struggle for documentation. It always seems like there’s something more important to attend to. But really, documenting and editing your process saves so much time and anxiety in the long run. It’s always worth the time spent.

In the case of the PDP, the number one objective is to ask where a team member is and where s/he wants to be. We’re currently working on rolling out these plans with each member of our Front End team because Ntara strongly believes that as we focus on taking care of our individual team members, the team grows stronger.

We’re also at an early enough point in our growth as a team that we can create a PDP of sorts for the entire team. Here are a few of the items on our team list:

  • Be more accessibility- and performance-minded. The internet is for everyone, so we can continue to make our sites faster (for slow connections) and more optimized for assistive technology (like screen readers).
  • Test for QA while doing a site build. Have our phones and tablets refreshing our code as we write it so we can see which code works cross-browser and which code is a bit buggy.
  • Mentoring program. At least two Front End Developers should be on each site build and it is the job of the Lead Developer to train and mentor throughout the project.
  • Research and development. Every Front End Developer should spend 10% of his or her time actively pursuing R&D. For Junior Developers, this might involve a focus on growing basic individual skills, whereas Senior Developers might focus on building the process and skillset of the team as a whole.

Code Reviews

I read about the advocacy of code reviews all the time. But so much of the code review talk focuses on back end code languages. A huge reason for this is that these languages are much more black and white/right and wrong. Yet, CSS can be a bit ambiguous—there are many ways to solve problems. But, a code review asks the question, “is this the best way to solve the problem?”

At present, we’re leaning on the expertise of others. CSS-Tricks contributor Geoff Graham just wrote an article about this very thing that I’m still digesting. I particularly love his focus on CSS style guides and on site performance.

So, for us, this one’s a work in progress. More to come as we implement our own version of code reviews.

Standing on the Shoulders of Giants

This should go without saying, but we all try to stay on top of current trends and developments in technology by following the industry leaders.

A few of my favorites include (in no real order…): Chris Coyier, Dave Rupert, Jen Simmons, Sarah Drasner, Marcy Sutton, Jason Grigsby, Trent Walton, Eric Meyer, Dan Mall, Jeffrey Zeldman, Yesenia Perez-Cruz, Brad Frost, Jason Santa Maria, Luke Wroblewski, and Paul Irish.

Conclusion

At Ntara, we actually like each other. You’re just as likely to see members of our Creative Department (Designers, Front End Developers, UX, UI) together at a local brewery downtown as you are to see them in each other’s work space.

That’s when real magic can happen—when the people you work with are the ones that you want to spend time with. Off-hour conversations turn into the next great user experience. And at Ntara—because of the larger communal culture in Johnson City—that magic happens all the time.

So, building our team is not about convincing some stud developer from a San Francisco startup to come here. It’s about finding those who have a desire to build incredible digital experiences and who share our values of caring about people and this community.

Then we work them into the team. We teach them.

And that’s where the structure comes in.

Lead Developers mentoring Junior Developers…
Code reviews to ensure standards…
Standing on the shoulders of giants....

As we grow the individual, we’re building and strengthening the team. And when the team gets stronger, everybody wins.

Join our team

Looking for something?