Your Job Posting Sucks

The other day I received an email from a recruiter asking me if I was interested in a job. This is not out of the ordinary, I get a lot of these emails. It got me thinking about how many companies approach hiring developers and the stark contrast to our methods at DevMynd. Not that we have it all figured out, but in our short lifespan we’ve been quite successful in building a talented team.

As I read through the job description in the recruiter’s email, I was struck by how incredibly fake it sounded. Phrases like “you’ll get to work with some of the best and brightest”, “solve challenging problems in a fun environment”, and “deliver web-scale solutions to users” made me roll my eyes so hard I got a headache. This kind of sensationalism doesn’t appeal to me at all, and I don’t know anyone in my circle of friends who would be ensnared by it either. I’d bet real money that this description bears little resemblance to reality and that there are hundreds more just like it out there on the internet.

So why do companies allow this drivel to represent them in a such highly competitive marketplace? In doing so they abdicate responsibility for arguably the most critical part of their business: the hiring of great people.

The alternative to terrible job postings and obnoxious recruiters is both simple and incredibly difficult - the alternative is relationships. Every person that we’ve hired on to the DevMynd team has been someone we cultivated a relationship with prior to making an offer. This takes time, a lot of time. Our hiring cycle for one person can last anywhere from 6 weeks to 3 months or even more. In that time however, we’re able to really assess whether this is an individual that will fit with our values and our culture.

We can do this because we don’t hire for a specific need or to fulfill a client request. We hire good people when they’re available and ready to make a move. As a small consultancy we have the luxury of this kind of slow-play but I think every organization can find ways to decouple hiring from the urgency of daily operations.

What does this look like in practice? It starts when we meet a potential candidate at one of our events, a user group, or a conference. Of course, at this point, they’re not a candidate they’re just a person - we don’t like to think of people as “candidates”. From here things flow organically, we hang out, we invite them to come by the office and see what we do. We have an open-door policy at our office, host occasional coworkers, and host user groups, so this is a very easy thing. We will likely see them at subsequent events (maybe 5 to 10 times) and eventually if we feel they might be a good fit we start discussing whether they’re interested in working with us.

If there is interest in a possible job then we begin our interview process, which also isn’t like at most firms. We ask people to come in to the office for a half-day and pair program with a couple team members. If we get thumbs up from those folks, then we bring the individual back in for a full day of pairing, followed by dinner or drinks with some of the team. At this point, nobody has even “interviewed” the “candidate”, we’ve exposed our real work environment to them and observed how they fit into it. If things look good, we have a short conversation over coffee and make an offer.

This process isn’t for everyone, it requires a lot of time and care and it may not address the anonymity and fairness concerns of large firms. The outcome, however, is a team full of people that mesh well, carry our values to our clients, and remain engaged in the team’s success. This cannot be encapsulated in a job post, and it certainly becomes risky when outsourced to a recruiter.

Check Yourself Before You Wreck Yourself

Brad and I, in our roles at DevMynd, get to spend a lot of time speaking with startup founders. That bit of sage advice from our good friend, Ice Cube, applies to much of those conversations.

Starting a company is risky and you should do everything you can to mitigate the risk to a tolerable level. The following is a list of things that we ask startups to help them avoid wrecking themselves. Consequently, as a consultancy, these help us avoid the collateral damage.

Do you have any money?

Despite the fact that this question is phrased in such a way as to elicit a binary response, the answers we hear are surprisingly varied. I typically interpret the following as squarely falling into the NO camp:

  • “Well, we’re seeking funding right now”
  • “We are currently bootstrapped”
  • “Would you be interested in taking equity”.

We’d prefer folks to just be honest and say, “No, we don’t have any money, but we have a killer idea and an amazing team”. We can work with that. Magical unicorn jelly bean money is harder to make payroll with ;)

What problem are you solving for people?

If you can’t clearly articulate a problem that you’re product is solving then you don’t have a product. Further, you need to validate that it’s a real problem. Too many times people approach us with an idea that seems like it might solve an issue but in reality individuals and business have already found creative solutions to the challenge and need no additional tools. You absolutely must have data to back up the problem space you’re addressing.

Who are your competitors?

Chances are, if you have an idea, someone else with more resources has had it too. There are very few completely novel and emergent business concepts out there so don’t kid yourself into thinking you have one. That said, one of the best ways to know if your idea has legs is to take a good look at the successes and failures of businesses in your sector. Are your competitors crushing it? If not, then why. It could be that they just suck at it, or it could also be that the business model just doesn’t work. If you find that you have no competitors, you should consider that to be an opportunity AND a red flag.

Do you know your customers?

When I say “do you know” I mean “have you talked to them…lots of them”. Customer development does not require a product, it doesn’t even require a landing page. Customer development requires Google, an email address, a phone, and persistence. Go out and meet people, share your idea with them, gather feedback, hear horror stories, and then re-evaluate your idea. When we talk to a founder we want actual concrete stories and data, not just “I’ve talked to a few people and they seem to like the idea”, give me data. People will generally lie to you when they think they may offend so be very observant of their impressions.

Do you need massive numbers of users to be successful?

If you use the phrase “social network” in your elevator pitch, I translate that to “I won’t make any money until at least a million people are regularly using my app”. If you need tons of users to be successful, then tell me how you’re going to get them. What is your marketing strategy? What is your user retention strategy? What’s sticky about your product? What strategic partnerships and alliances are you pursuing to gain exposure? This situation becomes even more daunting when you have a product that is built around a dual-network - now you have TWO marketing and retention strategies you need to develop and align.

Have you defined a truly minimum viable product?

“Minimum viable” doesn’t mean that you took out a few of the difficult-to-implement features. It means that you’ve stripped down your well thought-out 2 year roadmap down to what can be built in the next 3–6 weeks by 1 or 2 engineers. You have to fail early to learn anything and you can’t spend a ton of money for that education because chances are you don’t have much to spend. Make sure that you’re idea is small and solid and then prepare to iterate rapidly. Before you start though, you have to know how you’re going to measure. What are they metrics you will use to determine whether your idea worked or bombed?

Do you sound like a car salesman or a cartoon character?

This one is clearly a tad subjective, but in this business a high degree of self-awareness is essential. Of course, we don’t ask this question point-blank, but we do ask it internally when evaluating who we want to work with. Authenticity is the key to connecting with people. A fancy slide deck isn’t necessary, although if done well it can’t hurt. We’ve heard amazing pitches from people in jeans and t-shirts sitting in Starbucks with nothing but the back of a napkin for illustration. If you can pull that off then you’ve accomplished something the MBA types spend years trying to perfect.

The startup community, especially in Chicago, is vibrant right now and there are tremendous opportunities available. At DevMynd we’re all about helping startups build great products and bring them to market - and a big part of that is making sure we’re building something that has value to users. If you can answer these questions as they relate to your business idea then you’re off to a good start.

Nobody Wants to Steal Your Stuff

Over the course of my career as a consultant I’ve been party to many sales meetings and negotiations.  There’s one theme that’s an ever present thread linking these encounters: the group of documents known as non-x (non-disclosure, non-compete, non-poach, etc).  It may be subtle, but behind these documents is paranoia, a fear that someone you are engaging with is out to get you.

I’m sure at some point in the history of industry a service provider took advantage of sensitive information acquired while working with a customer.  However, I believe that the world of corporate espionage and intrigue is much smaller than the movies would suggest.  I think it especially rare in the world of software products, and at the very least, uncommon among consulting agencies.

The unfortunate side-effect of these documents and their underlying anxiety is that the partnership is damaged.  It’s very hard to build trust with someone when they start the relationship by attempting to document all the ways you could injure them.  If any such document is necessary it should be something so standardized so as not to have any personalized connection to either party.  Further, most of these agreements are unenforcable or so poorly constructed that they would not stand in court or arbitration if tested.

The fundamental reasons I find that these documents frivolous are fourfold:

* The apocryphal story of Facebook’s origin aside, in reality nobody wants your idea, they want their own.  Even if they do, there’s nothing you can do to protect it once it’s out in the public eye.
* The value of being “first to market” is an illusion.  Consumers have time-and-again tought us that what they really value is community, experience, and service.  In many ways, being first can be a handicap.
* It is very likely that your technology is commonplace and easily reproduced.  These days, any development team worth their salt is using open source frameworks and well documented techniques.  Furthermore, two good engineers will find similar ways to solve problems.
* Lastly, your people, your greatest asset, will be loyal if you treat them well and maintain an agreeable culture.  There is no need to defend against someone luring your employees away if they have no desire to leave in the first place.

Protecting ideas, technology, or talent with flimsy contracts seems almost like an admission that you don’t deserve them in the first place and haven’t earned the right to keep them.

It is of course a fantasy to assume that this practice will end any time soon.  In the exceedingly litigious society in which we live business will continue to be conducted using linen letterhead and Mont Blancs.  I do hope however, that for DevMynd and our clients, we are able to find a way to minimize their necessity.  I believe our approach to the process of building software is one that stems from partnership and trust which in hindsight makes heavy contracts seem rather silly.

I look forward to finding new ways to make such contracts a thing of the past and I welcome any insights from the community on how to do so.

Nested/Bound Collections in Backbone.js

We use Backbone.js as the base framework for a lot of the JavaScript in Crew and it’s really great.  One awesome thing about it (partially because it’s just JavaScript) is that it’s very extensible.  We needed to add a few things to Backbone and I hope to release a few of our extensions on Github over the next few weeks.

One thing in particular that we needed was a way to nest collections and relate them.  For example, all the cards in a project in Crew are in one collection, but each needs to appear in a separate column.  We achieved this by adding a createChild method to the base collection object which takes a name and a filter function and returns a new collection that’s linked to the parent collection.  The filter function will determine which models should end up in which child collection and it will be executed each time an add or remove is performed to keep all the collections in sync.

The code needs little explaination:

This could probably be tightened up a bit and when we release our collection of Backbone extensions we’ll add tests, etc.  But I wanted to get this out there since a few people have asked how we are managing this in Crew.

Testing Rails Engines (sans dummy)

A few months ago I started a new project which required some bit of internal modularity and a Rails engine seemed a good choice.  Unfortunately it became immediately apparent that the accepted wisdom for testing Rails engines is kind of lacking.  Doing a quick Google search for “testing rails engines” returns a slew of results which mostly tell you to: create a dummy Rails app within the engine’s spec directory.  To me, that seems like a squashing a flea with a sledgehammer.

For some engines, you’ll need that sledgehammer.  If you need to test controllers and views (which admittedly might be most engines) then there’s no reason to bring in most of Rails.  In my case, the engine in question was there to house some shared models, library code, background worker jobs, etc. and didn’t need to expose controllers, routes, or views.

So, back to testing.  The primary reason you need that “dummy” Rails app is so that you have a Rails environment loaded in test mode.  The main thing you get with this is the loading system.  So, if we don’t need to test all levels of the Rails stack in our engine we can just use a little piece of the Rails loading approach and fake it out.

The solution is to add something like this to your spec_helper.rb file in your engine:

Obviously you’ll want to add app/ and whatever other directories you’re putting code into in your own engine.  If you extract this out to another file you can also get convenient console like behavior.  For example, I have a load.rb file in my engine that I can require from IRB which will give me access to all the models and classes within my engine as if I was in a Rails console.

The Joy (and benefit) of Small Teams

I’ve had the occasion recently to work on some projects in very small teams, just 2 or 3 others at most.  This experience has rekindled in me a joy for this kind of working environment and atmosphere.  There’s just something about not being lost in a sea of teammates or (even worse, leading a giant team) that really appeals to me.

As I thought through this more, I began to realize that this isn’t simply something that I enjoy, but something that has that “right” feeling about it - it just clicks.  The following is a list of things that I believe are beneficial about operating in small teams and some of the things that flat out cannot be duplicated within a large team structure.

Note: Most of this will be obvious to people and I’m sure it’s all been said before, but let me have my fun and blog about it…golf claps at the end would be appreciated.

Low Tolerance for the Silo Effect

When teams are small it’s almost impossible for silos to develop.  Even in the face of explicit attempts to make silos, in a small team they just don’t materialize.  Whether this is a result of a smaller domain or the low communications barrier, the benefit is clear.  Smaller teams have a much easier time cross training because they hardly have to do it at all, it’s a natural phenomena that occurs when living so close to someone else’s code.

Nobody Hides Behind the Wall

On large software teams I use the phrase “throw it over the wall” to describe the interaction that often occurs between one part of the team and another.  They don’t really care who’s on the other side of that wall nor what they’re throwing for that matter.  Status just needs to be reported as: We made something, and we threw it over that wall.  The wall could be the one between development and QA, between the business and the BA team, or between the BAs and the developers…point is, it’s a wall, and stuff get’s chucked.

Clearly this is a terrible way to work and it reduces overall quality because people rely on the shleps on the other side of the wall to complain before they’ll deal with their mistakes.  This cannot occur in a small team because the walls are too short for you to throw something over it and still retain the comfortable anonymity that a higher wall would provide.

Sorry: Took that analogy a bit far!

We Don’t Need No Stinking Managers

While this is not strictly true all the time, my point is that with small teams the oversight tax is quite minimal.  As a team grows in size the amount of overhead incurred by management rises logarithmically.  By the time you have a team of 20-25 developers you have so many tech leads, architects, and project managers installed that your 2 for 1 pizza coupons are no longer valid.

Management and oversight is important but not at the expense of agility and direct (peer) accountability.  Small teams rarely have this problem and often a single manager can provide adequate oversight for more than one semi-self-governing project.

We Built [more of] That

This one is just my opinion, but when a large team builds an enormous software product the “I made that” quotient per individual is very low.  When a small team builds a substantial software product for their size that same metric goes through the roof.  It is profoundly more satisfying (for me anyway) to be part of a 4 person team who accomplishes the work of 7 over being part of a 23 person team who comes in over budget and delivering less scope.  Again, just my opinion.

Craftsmanship and Apprenticeship <3 Small Teams

This one may be a bit controversial but I believe it’s more difficult for mentorship to occur on big teams.  It can happen of course, but the ratio of highly skilled craftsman to more junior developers forces those highly skilled individuals to be spread too thin on large teams.  On a team with one seasoned journeyman and two apprentices the two junior team members will learn a lot more simply because they have more concentrated contact with their mentor…and visa versa.

That’s it…I’m sure there are loads more benefits (and joys) that people can identify from working in small teams but these are the ones that came to mind at 1:30 in the morning.  I’m very much looking forward to continuing the trend of working in smaller groups and delivering better software for it.