How to hire for a Meteor product team?

1

In my company I’ve been designing and building all of our Meteor-based product for the last year, and now we’re thinking about raising money to start kicking more ass. I have to come up with a sound plan to hire a team for our product, and I wanted to get some tips from more experienced PMs/engineers on how to structure such a team.

We’ll probably have the budget for a team of 3-5 people, based on the needs of our product, and I’ll be slowly transitioning in more of a PM role as we are able to actually make the hires.

The way I’m currently thinking about it is fairly simple:

  • A designer (UI/UX), as we’re quite design focused and need to unify our design language across the board
  • 2-3 engineers
  • Myself as an engineer first -> going towards PM

My question is mostly about the engineers (though feedback on the structure is obviously appreciated), as I don’t know how to structure a Node team. Our backend and frontend being so intertwined (because/thanks to meteor), does it even make sense to hire for different skillsets, or should I just recruit full-stack type of guys, with maybe one of them putting a bigger focus on front-end?

So as time goes, I currently think we should prioritize our hiring efforts in this order:

  1. Front-end/full stack engineer (because it will take the biggest load off of me)
  2. Designer (out-sourced until then)
  3. Full stack/dev-ops oriented engineer (our CI infra could need some polishing for example)
  4. Full stack generalist to fill the gaps

Does this make sense to any of you, and if not, how would you approach this ? Other Meteor-product team tips? :slight_smile:

Your help and insights will be deeply appreciated :smiley:

1 Like
2

In my experience, it all depends on the type of projects you’re delivering and generally speaking, unless you’re delivering systems where the backend is very complex; ie lots of entities/services/endpoints/rules/logic, which usually is not the case if you’re not a data-centric startup or an enterprise, the largest time wormhole proves to be the frontend.

I’d say get 1 backend-focused generalist, whatever that means for you, for me it is a solid backend engineer who sees frontend frameworks as lumps of libraries as opposed to cult followings and times new roman as a perfectly acceptible typeface, who can make sure your overall codebase is tiptop, 1 or 2 ui-focused generalists and 1 ui expert.

As you grow your company, you can repurpose the backend/ui experts across 2 (or even 3) projects at a time, but mind you that requires very good planning because context switching has hight costs.

Designers (and markup/style coders) often can serve a handful of projects simultaneously, unless, again, there’s a very demanding project where the ui/ux has extreme importance and attention to every little detail.

Whatever you do, make sure your teammates are both mates and a team before assuming bringing their individual qualities will amount to productivity. There are great solo developers who can hinder a team’s overall performance while there are devs who look like they won’t be much help although they all they need is a nudge and support from team mates.

Finally, don’t limit yourself to Meteor because Meteor itself does not limit itself any more. Imho, Meteor is an amazing build tool that should get you a good and consistent full stack javascript development environment with pubsub/accounts/data sugar on top.

Any good javascript developer who has the will and ability to read documentation will pick Meteor up in no time.

Oh and that being said, make sure all your team mates are keen on reading documentation, carefully! People write them for a reason :slight_smile:

6 Likes
3

Awesome, thanks for sharing those insights. We’re indeed not building a technically very complex product, and I’m already spending the majority of my time on the front-end (except for When our CI pipeline Breaks down…). So we’ll definitely try to focus our efforts there.

To be honest, when I started building our product I didn’t properly pull out meteor as much as possible, so we’re pretty tightly coupled to meteor (which i try to do less and less, and regret more and more). I wish there were a few more write-ups/articles on how to build a meteor-agnostic meteor front end. Will probably start paying that debt soon.

1 Like
4

Mark Zuckerberg has some great thoughts on hiring in general on this Reid Hoffman “Masters of Scale” podcast:

http://podcastapp.io/bonus-uncut-interview-facebooks-mark-zuckerberg-e22723797/

5

Sure thing, I’m glad if I can help relieve any of your hiring anxieties :smiley:

There certainly are strategies that can get your codebase into a layered structure where Meteor specific parts are seamlessly switchable to something else. Namely you can minimize use of pub/sub, create a single point of source for accounts methods/data, abstract away the data layer behind a more universal solution like redux or some other sort of client storage, and on the server, transition into methods or even rest or better yet graphql.

Although, all this will just be developer-porn unless any of them strictly addresses a problem that’s genuinely caused by Meteor itself.

As much best practices decoupling and abstractions are, they might not be the best for your use cases.

For instance, couple the hell out of a prototype, mvp or internal business app.

Imho, these theoretical/academic discussions important to get your overall awareness high, but they all have their right/better circumstanes to their implementation and none of them are carved in stone.

1 Like