Guest post by thredUP CTO Chris Homer, http://butisntitjust.com

Think about the team you have at your startup. In the early days it probably looks something like 3 coders, 2 marketing/business experts and 2 user experience/designers – maybe 2, 1 and 1.  This “silo-ing” of skills is extremely common but what's crazy is the rigid set of walls people put up around their roles, especially the technical ones.

In the fall, I went to a great workshop on a testing language called cucumber. There the question of having stakeholders write user stories (as I user when I log in with incorrect credentials, I should see...) came up and the general sense seemed to be that while it would be great to have them write the stories, getting them to go the extra step of properly formatting them to run tests would be too much.

I disagree.

For some reason coders have this misconception that they are the only ones that can do what they do.  This is false.  I have the complete opposite view.  Programming is simply a recipe and anyone can be taught to do the basics.  You are telling a computer to follow your instructions.  The learning curve is steep but it is totally worth helping people get up it.  There are five major benefits from this:

1)   You get more of the company’s eyes on the product

When you are building your product it is so easy to get heads down in the day to day you are doing.  After launch this is even more crucial. As your company grows, the silo’s grow higher and stronger and pretty soon many people get disconnected from the product they are selling, planning or supporting.  Offering people a way to quickly implement small changes can go a long way to keeping your team engaged in the product and results in people that actively review the site and suggest/make changes.

2)   Increased productivity from your full-time coders.

As you build your product and show prototypes and halfway demonstrations of different features, it’s very easy to get caught up in tweak-mode.  Non-stop (and sometimes conflicting) feedback can result in a lot of wasted time making a feature “just right”.  I realize there is a subtle difference between a usable feature and a confusing one, however, the time and place for those tweaks is later.  By teaching people to make small changes, the long list of aesthetic requests gets shortened dramatically, and your engineers can focus on building towards launch.  As you get closer to a launch date it’s much easier push back with “is this tweak necessary for launch?” – no one wants to delay the product.

3)   Lower priority content/styling bugs can be fixed immediately

From the designer’s perspective to #2, having more people that can make basic changes to your site results in faster iteration on the design side.  Instead of continually putting off small (but time consuming changes), designers that can do some coding can experiment and iterate without involving the full-time programmers.  The leverage here from an improved usability standpoint is very powerful.

4)   You are helping your team build new, marketable skills

Professional development is crucial to the success of a company.  The people you hire early on (especially in your first real startup) tend to be very specialized and in need of skills that broaden their ability to contribute in an entrepreneurial setting.  While to you your idea right now is the best thing since the segway, don’t get too caught up in your own hype.  Your people are working tirelessly for you and probably at quite a discount to their market rate.  There’s a chance the product doesn’t succeed and their wildest dreams of riches from those option packages vanish.  What are they left with?  The experience you give them.  If all your team does is hone and develop their current skills to a new level of expertise, that’s one thing.  But allowing them the latitude to build horizontally and develop new areas of expertise is what results in a company that produces entrepreneurs that succeed time and time again. 

5)   The team grows to appreciate the detail work and time it takes to implement their ideas

I’m going to write a follow-up post on this one.  “It’s just” too important.  Throughout the product lifecycle, the product development team continually hears the same phrase, “but isn’t it just”.  For example, “but isn’t a just an additional image to give a custom button a disabled state?”.  The programmers out there know exactly what I’m talking about.  While something like a disabled state is very important to the usability of a part of your site, it’s implementation is time consuming and often involves a highly customized JavaScript function or similar.  By getting people closer to the code and they will build an appreciation for the time different tasks take rather than assuming that something that appears so simple actually is just as easy to implement.

The other-side

As with everything, there is also a downside and risk allowing people to make changes.  People may try to check in changes without running them by others first.  They may do something that “breaks” the site.  Programmers may end up distracted while they teach others.  There is an endless list of pitfalls but the implementation a few processes like automated tests and proper feature/change check-in can mitigate and even eliminate the risks.

Ultimately, every startup has to make it’s own decision about who actually works on code, and whether it’s worth it to teach people some basic skills in this area.  I strongly believe the benefits outweigh the risks and everyone that wants to, should be given the opportunity to try it out

What we have done at thredUP:

At thredUP, Peter and myself do most of the coding.  One of the other co-founders, Oliver, was a CS major back in college but hasn’t done any coding since. We have brought on Heidi, a third graphic designer that wants to build her technical skills. James, Karen and Carly have never done any html before thredUP.  Everyone’s skills are basically silo’d.  And that’s great.  You can’t do everything yourself and you need people with different skills.  The thing is, when it comes to a website, everyone wants their say and everyone wants to change something. There is always an endless list of changes to be made and more intense development grinds to a halt. 

Call me crazy, but here’s what we did.  I helped setup Ruby on Rails environments with Textmate for Oliver, James and Heidi.  At first there was some hand-holding.  Walking them through how to setup html paragraphs, divs and style them.  It does help that we are using HAML and SASS rather than straight up html, as they are more intuitive (I think).  But after a couple weeks they have all become quite capable of making changes to content and basic styling.  Instead of having me make the changes and deploy them to a staging server, they can do them locally and preview/test the changes.  I even setup some shortcuts so that if they decide they like the changes and want to commit them, it’s dead easy to do so.  I then spend 10 minutes, a couple times a day, merging everyone’s work and deploying to the staging server for review.

An unexpected byproduct of more and more people learning to do some technical work is that others want to as well.  Karen (our director of Marketing and PR), wants an environment on her laptop so she can make changes to landing pages and other content as well.

The individual workflow involved needs a little work in places but overall it has freed Peter and I up to continue our work building out the bigger pieces of the site rather than continually tweaking the styling and content.