15 Roles Every Startup Needs Filled


I’ve been thinking about how to prepare for Startup Weekend, which is approaching quickly. Part of the registration process was assigning yourself a “specialty”. Of the seven designations, I chose architect for myself, whatever that means. But the role-designation question might be useful, and I think it’s worth looking at all the hats to be worn and shared in a startup.

In my previous startup I tried to wear so many hats — too many — and we failed. Now for the big weekend we’ll get to distribute the hats broadly(!) and try to crank out the business in a mere 54 hours! There is a disconcerting lack of detail about how the groups are organised, but based on the number of specialties, I’d guess there are going to be 10-30 people per team. Being slightly unsatisfied with the roles prescribed on the registration page, I decided to enumerate the roles that I see as important to making a new site come together. Each includes some example duties/skills.

The Hat List

  • Visionary/Architect. Idea generation, shape features, repositioning, market fit, competitive landscape, research.
  • Lead Developer(s). AKA Hackers. A good place to have a pair of jelled programmers. Uses web framework, creates functionality; knows Python/Ruby, Javascript, AJAX, Flash(?), HTML, databases.
  • Sysadmin. Network, web server, NFS (for VCS/file sharing), caching, other infrastructure, data backup, backup hardware, performance tuning, scalability.
  • Toolsmith. Team is provided with: productive development environments (all users can say “apt-get install …”), frameworks, editors, interpreters, multiple browsers, GIMP/Photoshop, (D)VCS, wiki, maybe BTS, quick training/consulting on tools/environment, continuous integration.
  • Webmaster. SEO, analytics, domain registration, site hosting, Apache/lighttpd.
  • DBA. Helps developers plan schema, set up tables, design for scalability, tuning/optimising.
  • Graphic Artist. colour coordination, logos, icons, image libraries, etc.
  • CSS Designer. Usability, accessibility, layout, look-n-feel.
  • Content Creator. User-facing documentation, populate/organise wiki, design tutorial, usage studies.
  • Customer Support. Answers phones, forum voice, FAQs, knowledge base, help entries, problem solving.
  • Tester. Bangs on site, tries devious things, automates stress.
  • Marketer. Evangelism, blogging, advertising.
  • Manager. Coordinates all team member activities.
  • Lawyer. Business setup, guidance, law interpretation.
  • Chef. Handles all other (random) tasks to keep team functioning.

That list looks pretty corporate-like. And there will be a number of obstacles if you try and partition these roles to more typical small-team startup structuring. But the list is useful if you happen to have a bunch of heads (15 or more) to throw at a problem, and a somewhat diverse skill/background set. For Startup Weekend these roles may work well as a starting point, but I also want to think about the more typical startup team, for which these hats may be too small.

No matter how small your team, none of these critical roles (hats) can be completely ignored indefinitely. This picture also uncovers why so many one- and two-person startups have a hard time getting to successful launch — the extent of this work may not be obvious when you think simply about the task of setting up a website.

Simplify and Combine Hats

It turns out that many people believe that the best way to actually implement a web business idea is to put a few (2-4) highly motivated and capable hackers together to build their vision. This has a lot of implications for the type of hackers that are needed — I’ll talk more about that below. For the sake of minimalism, let’s think about how a scant two-hacker team can possibly accommodate for that daunting role-list. It’s quite a diverse set of considerations! Does anyone really have deep experience in all these things? Probably not, but maybe it’s not necessary.

First of all, some of the roles can probably just be thrown out, or at least incorporated much later. Working from the bottom up, let’s first throw away the Chef. He’s an optimization that anyone else can step up to cover for. What’s important is that some team members are organised enough to recognise when latent Chef tasks are accumulating. Then take the Lawyer. She’s nice to have, but expensive and definitely not part of your core. She can just be used as a consultant if the Visionary or Manager can’t figure out if the business is set up correctly. Speak of the devil! Do we really need a Manager? Let’s just do away with the caste system and put everyone on the same level. We’re agile, we all communicate daily, and we have a great Visionary to tie everything together and keep us in check. And consider the Tester. Isn’t testing already happening at every level? The Developers are writing unit tests as they code (hopefully even before). The Sysadmin has set up continuous integration, and Customer Support has automated the regression suite. There certainly are a lot more tests to be written, but this task can probably be shared by other members. So now the Tester is gone, too.

Next, many of the roles can be clustered, and then combined.

The first cluster I see includes Content Creator, Customer Support, and Marketer. There’s a lot of work being done by these members, but it’s a similar user-friendly type that can fit all of these. Our worker needs to be friendly, charismatic, focused on the user experience, a good writer, extroverted, and multi-faceted. Let’s just combine these into a single Marketer role.

The next two, CSS Designer and Graphic Artist have some overlap. Let’s hope we can train our Artist (a colour and visual expert) to write CSS. And the developers already know some CSS anyway. Besides, I consider someone who’s good at CSS also an artist. So now we simply have an Artist.

A good Sysadmin has probably been around the lab enough to have dabbled in setting up web servers, and understands a lot about hosting, so he’s already something of a Webmaster. And he’s surely enabled his users to be productive with tools, so he’s also a Toolsmith. He might even know a bit about being a DBA, and I think it would be within reach with some study. So I’ll simplify the back end roles of DBA, Toolsmith, Webmaster, and Sysadmin, singly into the latter. Anyway, some of the performance/scalability optimizations can come later. In fact, with EC2 or GAE, we have a lot less to worry about!

Now the Developer (Hacker) is who I see as the Surgeon, or Chief. She already knows how the major technologies interplay, and has had to learn a lot about about design (at least at the system level, but probably also everywhere from aesthetics to architecture). She can build things that are user-friendly. She knows best what’s involved in implementing every feature under consideration. She is the one to best see the big picture. And based all this glamorizing, I’ll conjecture that she should also be the Visionary. Of course, you’d want all of your members to have similar creative, big-picture abilities.

The Sombrero List

With all that simplification, the Hat List now looks like this:

  • Developer
  • Sysadmin
  • Artist
  • Marketer

That appears to leave us needing four team members with really big heads for five-gallon hats. For now, let’s call such members Surgeons. Can a single surgeon do all these things? What about two? How do you divide the work? Which tasks should you do in tandem, in serial, in parallel? If you’ve only got two members, should they have opposite skillsets — a developer-sysadmin and an artist-marketer? Are all of these roles part of the core? Do all the roles need to be addressed early on? Those are hard questions. There are plenty of startup examples where one or two people have done all this themselves. Most of the successful examples simply involve a couple surgeons who have figured out how to cover all the bases.

Becoming a Surgeon

Here are some thoughts on how to get Hackers to the level and focus of Surgeon:

  • Diversify your skillsets. Learn some high-level languages. Try out a couple web frameworks. Be able to satisfy any development role.
  • Learn about system administration. I don’t have much data to back this, but I’ve found that many of the famously successful hackers have at one time in their careers been sysadmins. E.g., ESR, Robert Morris, Tim O’Reilly, and many more. Try browsing resumes of your hacker heroes and see if any of them don’t have this qualification. Such work gives you an important practical perspectives on usage patterns, systems topologies, hardware limitations, lifecycles, automation, tool availability, user-friendliness, user-stupidity, etc.
  • Make use of infrastructure services. If you’ve made use of EC2 and other Amazon/Google services, you don’t need to figure out how to scale to hundreds of app, database, file, and web servers. Know what services are out there to avoid building your own data centre.
  • Get the administrative work out of the way early. Once you’ve got a somewhat scalable system in place, then your Sysadmin efforts can be cut way back, and you can take off the hat.
  • Outsource some of the artistry. Many sites are now available for you to shop for cheap graphics based on many criteria. And for logos, you can hire an artist inexpensively to do short-term, direct work with you. Icons are also a dime-a-dozen and freely available from various sites.
  • Learn something about colour. You can probably figure out CSS without too much effort, and get an artist to do some graphics for you. But you need to be careful about choosing a holistically attractive colour scheme that works well across fonts, icons, boxes, panes, images, and everything else a user looks at.
  • Start a blog. The detailed reasons to do this will be coming in a blog post soon. In short, blogging is marketing, talking to customers, SEO, documentation, administration, design, and a web app, all in one.

After making the Hat List, I was reminded of the traditional Chief Programmer Team, which is probably derived from Fred Brooks’ Surgical Team (hence the Surgeon designation). I hit most of the roles you see shown in that picture, but the scheme for web startups looks a bit different — the Hat List has added a few new roles specialised for web startups, and the Sombrero List has optimised away many some of them.

Attributes of Surgeons

If it’s really possible for a couple of surgeons to build a startup, we should figure out what some of the necessary surgeon characteristics are. Maybe the traits simply need to be distributed amongst the surgeons. Based on the roles above (and other assumptions), here are some qualities that would seem necessary of the special type of hacker who is fit for being a Web Startup Surgeon — one who would break many of the traditional geek stereotypes:

  • gets along with others, including users and programmers
  • understands users
  • good communicator
  • can find and recognise the right partner(s)
  • somewhat extroverted (to meet/find partners)
  • immersed in the real world (to see real problems worth solving)
  • up-to-date on most current trends
  • can generate good ideas
  • can see the big picture
  • good attention span, not too distracted by minutia
  • can implement ideas quickly (and thus uses the right tools)
  • multi-faceted
  • optimistic, and not easily beaten down


  • There are a lot of hats for startup founders to wear; consider the hat list when estimating the workload.
  • At the core of a startup are hackers.
  • It is possible to start a business with just a small number of hackers.
  • It is a unique type of hacker who is fit for founding a startup.
  • Diverse hacker skillsets are a must.
  • Some roles can and should be inexpensively outsourced; others can be postponed.
  • Some Sysadmin knowledge is important in a team, but much of the work can be done up-front and through services.

It’s an exciting time to be building a startup. Stay tuned to see if mine will have what it takes to succeed.

Disclaimer: This has been a thought-study on the various roles in startups, and on the hackers who play them. I don’t claim to be an authority on these matters, but I am hoping to understand the dynamics necessary to make a startup succeed.

(This post was originally published at Micah Elliot’s blog.)

NOW WATCH: Tech Insider videos

Want to read a more in-depth view on the trends influencing Australian business and the global economy? BI / Research is designed to help executives and industry leaders understand the major challenges and opportunities for industry, technology, strategy and the economy in the future. Sign up for free at research.businessinsider.com.au.

Tagged In

sai-us startups