We're a little company, so these ideas are very malleable right now. As we grow, that will probably change. A lot. Whatever happens, we'll keep the core of what's written here.
In most cases, you won't be on a team of acidlabs colleagues, but on a multidisciplinary team at a client site made up of client employees and contractors. You have responsibility to that team as much as you have responsibility to the team at acidlabs. While the way those teams choose to work may not align all that well with the way acidlabs does, or even to your preferences, you sometimes have to bend. And while you're at it, you can try
It’s hard to keep up with what everyone is doing and what it means. If you just watch the stream of latest activity scrolling along in Basecamp and in whatever tool your client team is using it’s a waste of time and source of stress to even try. Instead, we have two chief mechanisms for keeping everyone in the loop about the work that’s going on.
First, there’s the daily question of What did you work on today?, which supplies the nitty gritty details, but as a personal narrative. They’re a great conversation starter if you see someone working on something you either care about or want to learn more about. Put a little narrative effort in and please do use them as such! Aim to answer this at least twice a week.
Second, there’s the weekly question of What will you be working on this week? which answers the intention of your coming week at a slightly higher level. Everybody is obliged to answer. It's only once a week.
When you have an idea for something we should change or improve and the idea feels formed enough, it’s turned into a pitch. A pitch is a fully-formed definition of the problem as well as a proposed solution. We don’t pitch in person — we always write up pitches and post them to Basecamp for review.
Why don’t we pitch in person? For a few reasons:
We feel it’s better to write something up completely. This forces the floor — the person who’s making the pitch can’t be interrupted. They are guaranteed to be able to present their story completely, exactly as they wanted.
Further, we believe writing things out makes you consider them at a deeper level.
We’re big believers in asynchronous communication — write it down now and other people can absorb it later when they’re ready. Real-time communication in person or virtually forces synchronisation of schedules and is highly inefficient.
And last, when it’s posted to Basecamp as a message, all feedback and follow up questions are automatically attached to the original post — This keeps all communication about the pitch centralised in one place on one page so everyone has access to the same story. One version of the truth.
People work all sorts of hours and from all sorts of places at acidlabs. This makes it hard to enforce a lot of tightly-coupled workflows during the day, but that’s a feature, not a bug. Most of the work you do shouldn’t require you to be in constant communication throughout the entire day with someone.
It’s far better for everyone’s concentration and sanity if you collaborate as though most things will get an answer eventually, but not necessarily right this second. Your first choice of action should be to post a message, a to-do, or a document about what you need to explain or need to know. Then others can read it on their schedule, when the natural lulls of the day allow it, rather than being interrupted right in their peak flow time.
Don’t take that as a hard rule, though. Sometimes you really do need to collaborate with someone for an extended period of time and together in the same place, and that’s fine. Work it out and get together.
All that being said, you should still ensure that there is ample overlap with the people you work with most of the time. While most roadblocks can be cleared in 15-60 minutes, they become really annoying if it’s a one-day turn-around every time.
If it floats your boat, check the Style Guide for email .sigfile addenda and choose the "work flexibly" option.
Each client project is assigned a team. If we take on two client projects during the same period, we’d have one team working on one of the projects and another team working on the other project. Teams stay together for the full project. For most engagements, a team is ideally two or three people, though often we're required to be solo outposted specialists. That’s it. No teams of four, five, six. It's possibile that some new engagement may pick up the studio as a whole, but we haven't seen it yet.
We think three is the ideal size for most things — complexity begins to increase exponentially beyond that.
Exceptions happen for full-time outposted work, where you might be a solo acidlabs person on site with a client for an extended period. We'll do our best to make sure you get a day every one-to-two-weeks off-site to work with us.
Teams are assembled ad-hoc. Before a project begins, we ask each person what kind of work they’d like to do over the life of the project. Teams either coalesce around areas of interest, or we assign people to a team based on their preferences. Teams often change up after the project so everyone gets a chance to work with different people, but sometimes they stick together for a few projects. There are no hard and fast rules about this.
The lead designer on the team usually leads the project, but there’s a very close working relationship between that person and everyone else. They work together on everything. That said, you're a manager of one most of the time and you're expected to just get on.
That means setting your own direction when one isn't given. Determining what needs to be done, and doing it, without waiting for someone to tell you to. A manager of one will spend their time well when left to their own devices. There's always more work to be done, always more initiatives to kick off, always more improvement to be had. Work with your client to determine just how free you are in this; 99% of the time, it should be just fine.
That's a tough one, but we're a fan of three project lengths - six weeks for small projects, 12 weeks for large projects, and for those big government or enterprise projects where the client has the appetite for it, the full 20+ weeks for the mature GDS-style Discovery-Alpha-Beta-Live project.
Not in the sense that time on deck is tied to income. We do need to have an understanding of time consumed on types of work, though. We do this so that for new projects we can look back to see how to build price based on past work. And we track time internally on projects to make sure people aren't overdoing it and that the price of the project isn't exceeded by the cost of the people on it (this should never happen).
So, you'll (mostly) keep time sheets in Xero. But they don't need to be minute-accurate. 30-60 minute accuracy is enough.
We limit ourselves to a 37.5-hour (30-hour in the summer) work week. Keeping our hours at work limited forces us to prioritize the work that really matters. A healthy amount of sleep and a rich and rewarding life outside of work should not be squandered for a few more hours at work.
There are occasions where teams or individuals need to work off-hours for on-call, maintenance or emergencies. This time should not be in addition to your normal working hours. Use your discretion to take time off to make up for the additional hours you put in during the week.
Each client project gets its own Basecamp project. Every task, discussion, comment, announcement, deadline, note, and chat about the project happens in this one Basecamp project.
Every design task, research task, and QA item lives on a stream of to-do lists within the project we’re working on. This way the whole team — no matter what the role — knows where things stand.