My first few months have flown by pretty fast, so I wanted to get a few of my early thoughts down before they become not-so-early. I had a lot of trouble linking these disconnected impressions into prose, so it’s now just a list of interesting differences between Dreamworks and my previous employers.
From pre-revenue startup to established company
Ok, so RTW wasn’t quite pre-revenue – I guess we brought some money in from Crackdown – but we were pre-revenue in our ultimate endeavour, to build an online self-publishing outfit with a lot of VC money.
Revenue obviously makes a huge difference to the way you can treat your staff. RTW’s heart was in the right place, but ultimately early startups need to attract and retain employees by passion and opportunity alone, not a life of luxury. So I feel very, very spoiled at Dreamworks! Sure, they provide breakfast, lunch, snacks and drinks, the best gym I’ve ever seen, and a train pass, all for free.
But the thing I like best is all the extra-curricular stuff they put on: lunchtime classes (figure drawing and screenwriting recently, improv just now), talks about film-making from internal and external speakers, and a movie screening every week. I suspect you become somewhat used to food etc over time (when I met someone at breakfast early on they said “I wish I could taste the breakfast like it was my first day again”), and that the artistic development stuff holds the real long-term value. Learning is tremendously important to me.
From secrecy to openness
Coming straight from the world of RTW’s secretive and bumbling management, it’s refreshing to be part of somewhere far more open. Part of that’s down to being publicly traded (quarterly earnings reports!), and part of it’s down to the public availability of box office receipts. It’s more than that, though. I particularly like Jeffrey Katzenberg’s ‘blog’. Closer to a text message than a blog, with its hurried, highly abbreviated style, and the blurriest photo attachments I’ve ever seen, it tells everyone, pretty much every day, what he’s been up to – who he had ‘bkft’ with (seems like he can’t eat without working!), how our projects are going, deals and partnerships he’s working on, thoughts on the future, and general company news. He is absolutely relentless and it’s wonderful to get some insight into what’s going on at the top level. Along with the fact that he is very good at dishing out praise where it’s due, it’s one of the reasons I’ve noticed unusual fondness towards him here, compared to a lot of executives.
(there’s an example here – leaked by someone naughty!)
Rules and procedures
My biggest fear of going to a larger company was bureaucracy and an environment where people can’t use their initiative. Dreamworks pretty much exacerbated those fears with the welcome pack they sent alongside their offer letter – including a fair amount of “corporate policy”, some of it on some pretty trivial topics, like taking “rest breaks” and filling out weekly timecards.
Thankfully, it seems to be an incredibly relaxed place to work in practice, and people apply common sense over policies – in fact, many people seem to be unaware some of the policies even exist. I’m not sure why they’re there – was it just the done thing when they started the company, a legal necessity, or are they a result of having some unionised staff? Whatever the reason, I’m glad to say I haven’t filled out a timecard yet, and in several ways, I’d say Dreamworks is actually more relaxed than RTW, where we continued to use a clock-in/clock-out system to the end.
The biggest downside I’ve seen of our size, so far, is when it comes to centralised software services (source control, bug database etc). It seems like it’s hard to choose such software and configure it in a way that keeps everyone happy. This was already a problem by the end at RTW and it’s an even greater magnitude here. I do miss the days of 40ish people when a few of us could agree to switch source control and get it done fast.
I’m not a big fan of their choice of Accurev here, although the more I use it, the more it seems like the server is robust and fast, and it’s the client that’s awful (unfortunately that includes the command-line interface, not just the GUI). Over time I seem to be collecting the necessary quirky recipes to get things done, and it’s becoming less of a problem. If there were 30 of us I’d still want to change, but for a few thousand? No chance!
When it comes to the local development environment, things are much better. It’s been fun getting back into Linux development after years on Windows – simple pleasures like the shell We’re free to choose whatever open-source tools we want here, and we have a couple of proprietary options on top; I’ve already seen at least 3 different choices for each of compiler, editor and debugger in common use. I got frustrated with a couple of the default options and am now on the tried-and-trusted gcc+Emacs+gdb.
Most of the code here is either C++ or Python. Sadly, the stuff I’m working on is in the former. I was going to say I’d forgotten just how awful C++ is, but I think it would be more truthful to say I never knew this last time I used it – it’s taken using C# heavily for a few years to see the difference. Waiting to build is horrible, even though we have pretty short build times by C++ standards. Simple changes seem to take so much typing – change the header, change the source, change all the constructors, copy constructor, assignment, destructor … ugh. Just to add a member! The lack of breadth in the standard library and the lack of sugar (foreach!) and power (lambdas!) in the language adds verbosity everywhere. Sure, 0x adds some of that stuff, but I dread to think when it will be widely usable, and I won’t be surprised if it brings all kinds of new ugliness too.
The *one* thing I like compared to C# is deterministic destruction. Oh, I guess const can be useful sometimes, although you learn to live without that pretty fast.
Anyway, back to Dreamworks.
Cross-site development that works
I realise my past experience isn’t a lot of data, but VIS and RTW both struggled with the relationships between their various offices, with a similar pattern of tension and distrust across geographic lines. With VIS it wasn’t too bad with just the occasional flare-up, but with RTW it was rife.
Dreamworks have managed to avoid that, and I’d love to understand better how. One thing I’ve noticed that’s probably important is the way teams are organised: while VIS and RTW reinforced the site division by letting it affect the org chart (e.g. keeping teams entirely within one site), here it’s the opposite. Many teams are simply spread across both sites (explaining why so many of their job openings are advertised at both locations). They make so little of the division that I have a very poor awareness of who is at which site, at least for the people I deal with less frequently.
Something that struck me early on here was the sophistication of their approach to managing assets. They need to: the sheer number and size of assets made for a show makes even the biggest of games look tiny in comparison, and there’s a big focus on eliminating inefficiencies in the production pipeline. Of course, they have the benefit of many years’ experience doing this, and a great deal of stability in their toolchain over that time compared to constantly-changing game technology.
The other thing that’s interesting is the Technical Director (TD) role. They have programming skill, but are part of the content production team – so they can do technical things such as setting up character rigs, writing shaders or setting up simulations – but they’re also available to help organise assets, and do scripting, automation and tools to improve the pipeline. As part of the content team, they understand what the artists are doing far better than central tech teams. While I’ve met people with this skillset in games, not every team makes best use of them – I’ve seen them treated as interchangeable with core technology programmers – and I think game art teams are too often left to organise their own assets, or struggle with managing their budgets. I have seen some game teams make good use of someone like this, but I don’t think it’s always recognised or hired for as a skill in its own right. I’m certainly not one of the “games should imitate films” brigade that you sometimes come across, but this could be a useful idea for some teams.
Lots to be excited about
2010 was a tough year in many ways – severe sleep deprivation, losing a job and leaving our beloved home. But I also see it as a wonderful one – bringing the triplets home from hospital in good health, starting at Dreamworks and moving to California.
With 2 to 3 films a year, and several years’ worth of original projects at various stages of development, there’s a lot going on here and quite a buzz around the place. It’s opened up whole new areas to learn about and lots of amazingly talented people to meet. I’ve thoroughly enjoyed my first few months, and I hope 2011 is just as good … perhaps with a bit less of the upheaval