Once you move past 1 or 2 people, organization makes a big damn difference.
In the early days of startup life, organizing is easy. You have one or two people and a single codebase so while life is hard, it’s also beautifully simple.
You can manage your project and do your releases any way you like and it won’t impact your team’s success at all. Maybe a little. As much as say, your haircut. As long as you’re not coming into the office with a mullet your choices aren’t going to cause much disruption.
But, one day you won’t even have time for hair. You’ll shave it off or shove it into a ponytail.
And as your tech team grows from 2 to 5 to 10 people, organization will make a big damn difference.
At Crew, we went through several different team structures and project management styles.
Some of them we knew were not for us. For example, Scrum was out immediately because I’ve always found it a dehumanizing process. (I am not a chicken. I am not a pig. I will not be there for a 15 minute ‘standup’ every day at 9am even though you promised me flex time.)
We work on the assumption that we are all adults and we treat everyone that way. On the flip side, we hold everyone to incredibly high standards like ‘don’t waste your time’, ‘always tell the truth’, and ‘don’t be a dick’.
In my career, I’ve been amazed how many folks I’ve worked with (myself included at times) who cannot live by even those 3 simple rules.
Give your team everything they need to make good choices and they will.
The point is: While we didn’t know what kind of structure we wanted, we had to start somewhere.
Method one: Single team; Big releases
As you add more members to your product team, the obvious way to organize is all in one … team! Of course. You’re still < 10 people so you can sort this out, right?
And because your product is changing in leaps and bounds while you search for product-market fit, feature changes don’t often make sense in isolation so you do big releases.
You may be thinking of this as ‘Waterfall’ releasing but we don’t like to put labels on a process because our processes are always being changed and refined just like our product. Not to speak ill of them though; if an off-the-shelf process like Scrum or Waterfall works for your team, great! Go by the book and never look back.
For those who don’t know how it works, the basic idea is that you chat with your CEO and/or sales and/or marketing teams and come up with a list of what the next release will contain. Then you write detailed specs. Then you pick an arbitrary deadline, say, June 30th, and get to work.
That’s what we did for the first 1.5 years of Crew. It worked brilliantly for a while. Until it didn’t.
Why it worked:
Easy to track what’s going on. With everyone on the same release, and everything being released all at once, tracking progress is simple. All you need is a single google doc with a single checklist.
The whole company can rally around a single date. Need a marketing push for the June 30th release? The marketing team knows when to do that. Are there new features to support for the June 30th release? The support team will know to get their processes changes sorted before then.
A strong sense of pride and accomplishment. As each new version rolled out, every team member was very proud and excited to get it out there. We popped champagne and took time to enjoy the moment.
Why it didn’t:
Small changes have to wait for the big ones. If you need a simple change to, say, change the label of a button, there’s no one to handle that sort of thing. Everyone is knee-deep in the major release and the major release is the king of priorities. After all, you have to hit June 30th.
Quality can suffer. When we put the deadline first, it seemed there were always bugs during the week following a release no matter how involved our QA process or automated testing suite was.
Little direct ownership of features. When a problem came up with a feature and we needed to find the expert, we’d often get this: “Well, I worked on it a little, and he worked on it a little, so I dunno who should fix this bug.”
Our product offering eventually became too complex and we found ourselves going a little too slow adding experimental features and iterating on the areas of the app we knew were here to stay.
That’s when we decided to change things up.
Method two: Many small teams; Many small releases
The next team structure we tried was several small teams all doing smaller releases.
So we still released feature sets on deadlines, but they’d be around a certain area of the product and would be released while other parts of the product where still in the middle of construction.
For example, our referrals and partnerships features would have a release in mid-July, while the messaging features could have their release at the end of July. Development, however, would overlap and be done by different small teams. So while one team was in crunch-time, the others were business-as-usual.
We had three small teams of 2-3 people each.
Why it worked:
Distributed responsibilities. Every small team knows what their specialty is and knows what their responsibilities are. When something goes wrong, it’s clear who should fix it and when we spec new features, that team knows the product area inside and out.
Staggered releases fix the issues list above of single big releases. Namely: the quality was better, we knew who owned what features and without everyone at the same distance from their release, there’s always someone who is around to fix the little things that come up.
Why it didn’t:
Mistakes were easy to cover up. Without everyone watching the entire development process, a small team could easily make a mistake without anyone noticing. Or worse, though we didn’t see any of this, they could cover their tracks if they make a mistake because they are policing themselves.
There wasn’t enough knowledge sharing. Team A would develop a feature that Team B could have used as well, but Team B simply didn’t know about it. And if your team split is front-end / back-end (ours isn’t) then you don’t breed full-stack knowledge as easily.
Loneliness and boredom. Always working alone or with the same 1 or 2 people just isn’t as fun. No matter how awesome that person is. We noticed how much more fun it was to all come together for a single goal, be it a feature we had to rush or a #makeday project
This method lasted for the next 8 months of Crew before we decided to change it up again. We decided in the end it was better to take the best of both worlds and add a spoonful of automation to do things the way all the cool kids are doing things: Continuous deployment.
Method three: One team; Specialty areas; Continuous deployment
Continuous deployment (CD) is a structure in which instead of doing one release every month, or one release every week, we do many each day. (In fact, we’re now averaging about 8-10 releases per day!)
You do this by automating the release process and tie it to a single button. Then you give everyone on the team access to that button and accountability for what happens after they press it.
So they can put their code live at any time, but if they choose the wrong time (when they think it works but it’s still full of bugs for example) they are ultimately responsible. Fortunately, with much less code going live at a time, mistakes are easily traced back and we can even do an emergency rollback at the press of a second button. Handy.
It took a little time to set up and build new processes around, but it was worth it. With CD in place, we were able to merge the entire team back into a single team of 11 amazing, happy, shiny people.
The pros for this method are basically all in the items above because we get the best of both worlds without the downsides. But there is one issue with this structure I will mention:
Management is less distributed. When you have small teams, they can do a lot of their management themselves. Three people can self-organize and work with their corresponding department (marketing, support, etc) to build a backlog and organize it. But when the people who work together are constantly switching up, the schedules get more difficult. “Well, we need Jeremy for project A, but Hugh is still busy with project B so maybe Jeremy can jump on Project C for now by himself.” It’s like fitting together a big puzzle, and that requires the time and effort of a project manager.
“Do you use Gantt charts?” you’re wondering. Well, as it turns out, there is something I find more dehumanizing than Scrum: Gantt charts!
Nothing says you’re a cog in a machine than a spreadsheet in which each person is referred to as a ‘resource’.
<Gantt charts, turning people into faceless numbers since 1982>
Don’t just do what we did or what someone else does
You can spend (read: waste) lots of time in your early days reading about how to build a team.
There are lots of cool ideas out there and who knows maybe reading this you even got inspired to try something different. But when starting a company you have to be laser-focused on the things that get you to revenue or profitability or the next financing round or the next million active users. And that’s the product itself, not how it’s built.
The process of building is only a problem you should tackle when it’s getting in your way and mucking up your team and/or what they can produce.
So when starting up and picking a development team structure (or language or process of any sort), do what we did: Stick to the one you know.
I had done big releases my entire career so that’s where we started. The processes were already well worn in my head by the time Crew came around. If you’re doing the right things, and you’re building a product that resonates there will be time to try new things later. If not, well, the hard truth is that it simply won’t matter.