I’ve decided to write this following discussions and things I’ve observed with some of the startups (in the Bay Area or on the other side of pond), as it just occurred to me that occasionally simple (yet very effective) aspects of a startup are being missed out entirely. Sadly, these results in most cases in either a sluggish operation of a startup or, even worse, in totally slowing down to a halt the actual product development and operations of the business.

One would argue that simple and/or small details surely don’t matter that much — it’s all about the big picture, right? However, if you ever played rugby — though I’m sure this applies to a lot of other team sports — you will hear often, during the training sessions as well as during the game, the coach iterating to the player over and over and over again: “Do the f*** basics right, that’s how we win this game!”. I was puzzled myself initially at the simplicity of these shouts advices — but having played (well, if you can call that “playing” I guess) for a while, it started to make sense:

• you will not win a game if your players passing to each other is sloppy and the ball gets dropped at each phase;
• you will most certainly not win if your players can’t win their own lineout and scrum;
• you will not win if your players are giving away penalties;
• you will not win if your players can’t ruck and defend the ball properly at breakdown;
• … and the list goes on — all of these being nothing but very simple set plays that you practice over and over and over during training.

You can have a Dan Carter in your team, but if no one else can pass to him, you’re screwed. So, despite what you might think, it turns out that indeed it is the case that you have to do the basics right in order to be able to do the advanced too and concentrate on the bigger picture — think of it if you will as a Maslow pyramid, with the basics being (derr!!) at the base, right? 🙂

So with that in mind, the reason behind this post is the tendency for startups to occasionally spread expand their teams very early and very quickly across multiple locations. Beneficial as it might be at time, this comes with a very high cost and in most cases, it’s something I’d advise against in the early stages of a startup. I’m going to refer here to 2 startups that I’ve known of — I say “known” because they both don’t exist anymore, one of them due to an acquisition, the other one, unfortunately due to becoming another statistic on the sheet of failed startups. (You’d argue that I could disclose the names at this point, however, knowing some of the people who put a lot of blood, sweat and tears into these, I don’t want to be seen as putting down their work, or rubbing the success of some in face of the others, so I’ll skip such arguably minor details from this post. Also, on the same subject, the names I’ve chosen are made up — as it happens I know a few Brad’s but none of them are actually techies, so they’ll know right away I’m not referring to them :P) Anyways…

One of the companies I was going to mention started ages ago in a small room somewhere in Europe — the little funding they had was enough to hire (less than) a handful of techies and a couple of business guys to help develop their commercial partnerships and start pushing their product “out there”. Arguably due to the lack of funds, they were all crammed together as I said in a small room. That turned out to actually be a blessing in disguise for them — while the space was tight, it turned out that communication in between everyone was free-flowing and very easy: you wanted to find out when feature XYZ will be live so you can sign up a customer? Simply turn around and ask one of the guys. You want to know if this piece of functionality is more important than this other bit? Raise your head and ask one of the business owners of the functionality. Want to demo quickly some prototype for something that you thought it might be interesting to the business? Take your laptop to one of the guys and showcase quickly and let them mull over it. In particular, there was one guy, who I’m going to refer to as Brad, whose case makes a good argument for being in the same room:

Brad was a techie, arguably not the best one — a lot of startups will sympathize with the fact that the seed funding hardly ever enables you to hire top talent, apart from yourself of course! — but at the very least very decent. Due to his scripty talents (he was very quick at setting up very quick useful scripts helping build small one-time tools to diagnose or investigate various parts of the system or the data), he was tasked with building an “admin UI”.

In case you don’t know what an “admin UI” is, I’ll expand here briefly: at some point in your startup development, if you’re in the software industry, you will find out that for your app to perform what it’s supposed to, you need to feed it some data, in 99.9999% of the cases. In fact, I don’t know if there’s any apps that don’t need data to function, but that’s a different matter. For now, assume your app needs some data of some sort to function — this data is typically classified in configuration and input data — while the “input data” is data gathered dynamically somehow at runtime, when your app runs, for instance, profile of the user logged in, purchase order history for a client etc, configuration data is data that is set before the app runs. Such config data can include paths and directories where certain files are being saved and loaded from, list of clients, username and passwords for various backend services used by your app and so on. The “admin UI” is a component which allows manipulation of this config data — it can be as simple as an Options dialog in a desktop app, or a fully-fledged web-based UI which allows the management of your client list for instance in the case of a web app dealing with purchase orders and shipping. The list of examples really is infinite, but in a lot of cases an “admin UI” is a tool used internally, not visible to the outside world.

Getting back to Brad, he was tasked with building such a UI — it was supposed to be a small tool, never to see the outside of the office, which would allow configuration of certain aspects of the product on a per client basis. When tasked with it initially, bearing in mind that this was at the time looked upon as a small tool, only to be used internally, he was told that timing of getting this tool to the team was more important than look and feel, scalability, portability and technologies used, and he was left entirely in charge of writing it whichever way he saw fit. Based on the fact that at the time Visual Basic was a pretty decent RAD tool, he decided to put together a small VB application — which he produced in about half a day. He sent and email around and put together a small wiki page with a link to a network share where he would upload the latest version of the executable. His release process was very simple: he’d make code changes, test it locally, once satisfied with it, run this simple script which compiled the executable and copied it to the public network share, overwriting the previous version; the network share was referenced in the wiki page and as such anyone following that link and/or using the network share to run the VB app straight from there would always have access to the latest version Brad put together. On top of that, being in a single small office (all on one floor), it meant that Brad could give a proper shoutout around the office to say “hey, lads, there’s a new version of the admin UI, I’ve fixed that bug xyz… or I’ve added that bit of functionality to do with abc”. That was enough for anyone to “get” the message and start using the new version right away if they needed to. Occasionally, though, Brad would introduce bugs in his code (don’t we all?) — this is not a big deal, what was interesting though is how these were dealt with in this startup: someone would (literally) shout at him: “Dude, this bit is crapping out now!”; Brad would walk to his/her desk and observe what actions were taken and what was happening, then he’d go back to his desk, knock up a quick bug report and get onto it. Once fixed and a new executable was on the network drive, Brad would go back to the person and they’d go together through the same actions and make sure it worked. All of these would often happen within a matter of minutes for a small bug — sometimes, it might take Brad more to fix it, however, the actual investigation and checking that all works at the end was always a matter of minutes. The process was very quick and painless for both the users and Brad himself — there was a lot of feedback both ways and progress was easy to observe and measure.

Following this pattern with their core product, the startup Brad was part of went through very many quick iterations and they shaped their product very quickly and shipped it live. Brad was working on the core product as well as having total ownership of the admin UI, which stayed as a VB app for more than a couple of years. (In fact, it was only by the time the company was opening a 3rd office that they decided the admin UI tool was use widely enough in the company to deserve enough attention — and a fully-fledged team was tasked to writing a “proper” admin UI, web-based so it can be easily accessed from anywhere, scalable so parts of it can be offloaded to the customers themselves and all the good stuff. However, by that point, the company was already mature enough and so was their customer base in order to justify such a move.) Point here being that having the whole team in one single room, allowed for very effective communication and collaboration around this tool as well as very fast turnaround on this admin UI; has to be said that having that admin UI available to the business team meant a lot of time was free’d up for the tech team, as a lot of things could now be done by the business team themselves.

I’m sure at this point I will get a lot of agile advocates jumping up and down to tell me that it is by employing an agile process this startup managed to turn around so quickly — and yes, that is part of it. But the whole feedback loop process typically found in an agile process was hugely accelerated by having everyone in one room! Imagine if all the communication had to be gathered one day and summarized, so then it can be presented in the standup meeting next day. While this would introduce a more rigorous process, it would slow drastically the iterations and “releases” that Brad used to go through with the admin UI. And the quicker the admin UI was “shipped” (to the network drive), the quicker Brad (and the others) could concentrate on developing the core product!

Now in contrast with this, the other startup I’m going to bring into discussion, was fortunate enough to raise a serious pile of cash for their seed funding. As such they spared no expense in terms of the talent they hired, the office location and facility, the hardware, software and so on. Even more, really early, they decided they need to expand in a few more geographical areas and they need to start building the commercial relationships ahead of the product, safe in the knowledge that the product is in capable hands of geniuses (that bit was actually true!) and it will be shipped on time (errrr…. I’ll get back to this one). So they opened about 4 other offices in centres they thought to be of interest commercially. They hired people there, mostly for business development. They spared no expenses again for office space, location, facilities. However, as it happens with offices, there needs to be an IT person to make sure the email is working, printer hasn’t got a flashing light, connectivity is up and so on. So they hired these IT guys in each office. Spare no expenses again.

They realized very early too, like the previous startup, that they need an admin UI too — and they set up a team to build it. It was built from the grounds-up to be web-based, scalable, uber-fast and all the usual malarkey. All good, but here’s the difference here: because one of their offices was considered to grow into being the epicenter of the company from a business point of view (which made sense, since most of the foreseeable opportunities were gravitating around the geographical area where the office was — that’s why they opened an office there after all!), and because the admin UI was mostly to be used by the business dev guys, they made the decision to build the admin UI team in that office, so to be as close as possible to the business guys and their requirements. They shipped part of the team from the initial location there as well as hired some more from the local talent — ultimately, the team they assembled was not one to be sniffed at from a technical point of view. Yet, despite all that, that product had the most trouble-some history in the company, and while not responsible for it, its trajectory affected somehow the company’s end.

What happened is that now the technical team was spread across 2 offices, the business team was spread across 4 offices and the products were still being built. Each time the business team came up with a new requirement, they could not simply walk to the developer’s desk, have a quick chat and decide quickly on prioritizing the functionality and way to move it forward — now, it has to be a process: send an exploratory email, wait for the tech guys to think about it, then try to arrange a meeting with both business and dev guys plus the project manager, weight this functionality against others in the pipeline, provide estimates and finally schedule it in the queue. And about 2-3 months later on get back to it once it’s live. What made it even worse, these office locations were spread across different time zones as well, so agreeing on a time for a meeting was challenging and occasionally it would take 2-3 days before everyone could agree on a time for a call. Then the business guys had to talk to each other to make sure they are all on the same page before they start making requests to the tech team — that in itself again took time.

Lastly, the admin UI had to be in sync with the work the core team was doing — so the admin UI guys had to sync up every day with the team in the other office. Whereas in the case of Brad that meant simply working next to them and with them and knowing what stage feature XYZ was in, or occasionally standing up and asking someone quickly — in the case of these guys this meant having regular meetings each of about half an hour providing updates to each other about state of things. And on top of that each team had to have regular calls with business teams in different offices to provide updates on progress. And also have the above-mentioned calls with business teams, QA, project management and so on to discuss functionality and roadmapping… And before you know it, each of the techies was spending half of their days dealing with meetings, phonecalls, emails, skype calls and messages and all sorts of forms of communication trying to provide to everyone across all offices a clear understanding of the product, where it is, where it’s heading, issues encountered and so on. Left with half a day for development, they then had to divide that in between fixing bugs (we all introduce bugs, don’t care what anyone says) and then a tiny bit for making progress on building the product. Sadly, this meant that progress became slow in terms of both the admin UI and the core product. Occasionally it meant progress stopped at times for a couple of weeks. It ultimately meant that despite raising some more capital later on and opening yet another office, this startup decided it a very long while ago to call it a day and closed down.

Now, the moral of the story, as far as I’m concerned, is exactly as the title has it: keep your shop on one floor! If you’re a company just starting up, keep everyone together, in one single location — spread out before you have a product and you’re f***d! You won’t have the same communication flow as you would if everyone was in one room / location — and that will bite you in the ass! It’s much easier to walk to a desk, or even go up/down a couple of floors (if you really grew so big so quickly to expand on more than one floor!) and ask a question than it is to send an email, ask for a phone call conversation than have to agree on a time convenient for both parties then have to take a few minutes before the call to refresh your memory and prepare and finally take the call! It will simply slow you down — and if you’re a startup, you have to develop quick and develop fast, and can’t afford any slowdowns. You slow down, someone else will come from behind and eat your lunch, right?

And as such, getting back to my earlier point about rugby: do the f*** basics right, that’s how you win the game! And keep your team in one location at the beginning — and your shop on one floor!