Paul Furio speaks on the Video Game Break Podcast about V.Next, the Apple Watch, and Lifeline.
Paul Furio speaks on the Video Game Break Podcast about V.Next, the Apple Watch, and Lifeline.
Last night I attended a “Shark Tank” type event sponsored by the Zino Society, a Seattle-area Entrepreneurial and Angel Investment group. By attended, I mean I dropped in uninvited, handed over a business card and paid out of my corporate account (because it’s a write-off, right?), and no one asked me to leave. I got to stick around for a few hours, do a Scotch tasting, network, and listen to some pitches.
As a technical leader and former full-time software developer, most of the first 15 years of my career was spent getting better at writing code. I learned about design patterns, architecture, dove into the nitty-gritty of TCP/UDP networking, UI implementation, efficient data structures, multithreading, and so on. All of that is important in order to deliver solid software that performs well, doesn’t crash, and delivers a compelling experience to customers. After 15 years, I never considered myself an expert, but mostly because I was always comparing myself to much more senior developers. Looking back at the Jr. and Mid-Level developers, I was a super-efficient coding machine.
However, I didn’t really think much about leadership, management, business functions, or the other questions that get asked when deciding in what direction to take a project. Over the last five years, I’ve found that these have been far more important in driving my career, teams, and projects forward than constantly trying to find new ways to level up as a developer. In fact, I would argue that the difference between a midlevel-to-senior developer and a high-level architect or Director of Engineering is not that the high-level person is an order of magnitude better developer, but that they have broader experience and are able to forsee the business impacts of their decisions far better than an IC developer.
The key experiential differentiator between the solidly employed and the highly successful is that the latter have mastered two different skillsets. Business and Software. Engineering and Design. Art and Commerce.
This is why, now, when I have the chance, I don’t attend engineering conferences. I don’t hang around with too many other game developers. I’m actually more interested in how other CEOs think about their business and their problems. How do investors think, and what questions do they ask? How do leaders hire great people? How does marketing work?
The Zino Society event was uncomfortable. Despite my love of blogging, I’m still an introvert at heart. A great night for me is sitting with my wife on the couch, drinking wine and watching a movie together. But I got out, and met a few great and talented CEOs. I spoke briefly with the keynote speaker, who was seated beside me for the Scotch tasting. I listened to the business pitches and grilled them on their mitigation strategies. Yes, my initial questions were technical in nature, but I’ve learned to ask about their business, their pivot points, how they grow, their market share, runway, revenue stream, and so on.
I have become used to being a stranger in a strange land. It’s something I recommend for everyone who is looking to grow personally and professionally. Get out of your comfort zone. Get off the couch. Meet people in a different industry, but one that interests you. Stretch. Grow. Be uncomfortable in the short term, so that you can be very comfortable in the long term.
When I was at MSFT, working on Forza Motorsport and 1v100, there was a time around mid-March of every year that I grew to hate. I called it “the E3 Lie”, and it was a kickoff time of six-to-eight weeks of working on code, effects, images, videos, and sounds that in all likelyhood would never make it into the final game because they were meant entirely for the press and advertising at the Electronic Entertainment Expo, the largest (at the time) conference and trade show for showing off upcoming video games.
As a developer, I hated it because it felt like we were throwing away valuable time making things for a very short term gain (Press! Publicity!) when that time could be spent improving the actual game that we would sell six months down the road. Every game development process includes hundreds of bugs, countless “nice-to-have” features, and weird audio-visual glitches (AKA low-priority bugs) that we want to polish off to deliver an amazing, consistent experience. I wondered, why were we spending this time and money making things that were throwaway, instead of making our shipping product as close to perfect as possible? I never really got an answer past “this is important.”
Now that I’m a CEO and a business owner, the tables, of course, are turned. What I realize now is that business is not the smoothly running ship that we idealize it to be as mid-level IC developers. Many leaders do a very good job at hiding the turmoil, and certainly I’ve been as guilty of (and praised for) this as the next manager. Perhaps my exposure to startup-land has prepared me for this more than my time in the seemingly safe ship of corporate America, but the metaphor of changing the tires on a car that is rushing down the highway at 100MPH is often all too appropriate.
Right now we’re looking for software developers, who we would love to hire full time, but we can probably only afford to pay for half a year, unless we raise money from Angel Investors or do a successful crowdfunding campaign, which we’re also pursuing, while simultaneously writing code and designing our product. Failures and setbacks at any one of these disrupt the others, and will cause us to pivot on some strategy. The safe move, the big company move, would be to smile and say “we’re killing it!” or “everything is great!” which is of course never true. Moving in the right general trajectory, yes. Great? I just read Ben Horowitz’ “The Hard Thing About Hard Things”, and I wouldn’t describe any of his Loudcloud or Opsware days as “great” until he exited.
Are we in trouble? No, not really. But in the efforts of Being Relentlessly Transparent (one of our Company Values at SyncBuildRun), we understand that running a company is a risky endeavor, and that there will be a hundred things going on at once, for which we have to march forward with the right seventy, knowing that if 30 of those go wrong, the rest are in jeopardy. But that’s how it goes.
Why did we live the E3 Lie and build throwaway work? Because we needed to understand the customer interest in the final product, which would feed back in to how we focused our efforts to the rest of the game. We had to sell a vision of what we thought we should build, without actually building it, and see what resonated most with potential players. We also needed to know there was actual interest, and that we shouldn’t just assume all to-date effort was a sunk cost, and cut our losses by shutting down the project. As an IC developer with total trust in The System, having a big budget project like Forza cut nine months from release doesn’t even enter one’s mind. But I now assume it was on the minds of the MGS leadership every day.
What’s the takeaway here? It’s that as a business owner and leader, your worldview will be very different than as a team member at any other company. Crazy decisions from past roles will suddenly make sense, as you shift to a survival point of view. Your decisions affect not only your life and your family’s life, but the life of everyone on your team. There are crazy, seemingly counterproductive things that you have to do, but the insight that they will give you into the health of your business, and the preparation for launch and success, are absolutely necessary. Assuming the channel is deep and sailing blindly ahead is a great way to run aground. Better to send some sailors ahead in a dinghy with a weighted measuring line and barely enough drinking water than to doom the whole ship. These are the hard decisions you will have to make, and when you do, the insanity is clearly understandable.
If you’re not already on the V.Next mailing list, we encourage you to sign up at the V.Next Website. Every Monday, we send out a behind-the-scenes look at our progress on the game. A few weeks ago, we sent out clips from the soundtrack of V.Next. These were composed and recorded by our friend Tom Shear of electronic bands Assemblage 23, Surveillance, and Nerve Filter.
V.Next Theme Track : The music from the Teaser Trailer, and the theme that will play at the beginning of every episode of V.Next!
“The Factor” Theme 2 : One of the versions of the theme for the character “The Factor”, a former soldier-turned-hacker who assists Vivienne on her quest to right wrongs and punish the corrupt via cyberspace manipulation.
Vivienne Theme 2 : One of the versions of the theme for our main character, Vivienne Denue, hacker extraordinaire and all-around bad-ass grrl.
We sent out a new update today with more recent information, but only to subscribers of our mailing list. If you want to be kept up to date, subscribe now for the inside scoop ahead of the rest of the crowd. Thanks.
There are just a few things we want to share this week:
1) If you haven’t signed up for our mailing list on the V.Next website, please do. We’re releasing music samples, art samples, screenshots, and more info about the game every Monday, but only to the subscribers on our mailing list. If you want to be in-the-know early, please sign up.
2) There’s a great article on PocketGamer.biz about the “Netflixificaation” of games, that is, ad-free and microtransaction-free high quality gaming delivered on a subscription basis. Our first game won’t be a subscription per-se, but once we have several games available, we’re considering this path if it’s something customers might like.
3) We have some more interviews and podcasts coming up, and there’s a gameplay video in the works, but we’ll get firm announcements about those as they get closer to release.
4) We’re looking for a software developer, preferably in the Seattle Area, but remote is fine. We’ll have an updated job posting on our website shortly, but if you’re interested in games development and have shipped at least one title or customer-facing software product, please send your resume to firstname.lastname@example.org.
We have been getting a little bit of press lately. Here’s an article on GeekWire about our founder:
IndieGames.com did a little preview based on our concept art and teaser video:
We’ll keep you posted as more media becomes available.
I spent the last week doing a lot of reading, as well as getting our game site updated. If you haven’t seen it, check it out at http://www.vnext-game.com/ I’m really proud of the work our team did putting that together and publicizing it. We had some stalls, namely that we promised an update by Mid-March, but didn’t hit it until almost the last week of the month. I take the blame for that, as I didn’t communicate the expectations to the team, nor drive the proper results. We got something great out, but it was behind schedule. As an organization that will deliver content on a set schedule, this is something we need to fix, and we’re going to fix it before launch. That’s our promise to the customer.
As for the reading part, I started with Peter Thiel’s “Zero to One“, and am currently finishing up Ben Horowitz’s “The Hard Thing About Hard Things.” One thing that strikes me about both of these books is the idea that to be successful, a company must do something ten times better than the current best implementation on the market. It’s something that resonates with me highly, because of the two things we’re trying to do with our first game.
I’ve gotten a lot of pushback about the idea that we’re going to release episodes weekly. Some have said that the only way to do this is to burn out the team. Others have recommended that we scale back to twice a month, or every other week for an episode. Still others have simply said “it can’t be done.” Don’t ever tell me it can’t be done.
Television shows put out content every week, some, like talk shows, every day. Radio, podcasts, comics, newspapers, and plenty of other media have solved the weekly cadence problem. Why should it be impossible for games? Right now, DLC for large AAA games is released about three months after game launch. The best episodic content out right now is about 10-12 weeks between every episode. Every other week is only a 5x improvement. We have to be weekly to hit the 10x goal. If television can do it, so can games.
We also know that there’s that emotional and psychological benefit to a weekly cadence. When every morning, the same day of the week, kids in the cafeteria or coworkers in the break room are talking about what they saw on the latest episode the night before, they build a routine, and that builds an interest in those around them. It’s an organic audience builder. The in-group is having a shared experience and people want to be part of the in-group, so they start watching or playing too. If the content is great, and regularly released, the audience grows. If we can back that same experience with some technology that can help us figure out what people like and dislike, we can improve every episode, until the actual released final episode is far better than we could have created if we did so without audience input. Then we have a loyal fan-base that is incredibly eager for the next season. It’s what every creative team craves.
Going from Zero to One means making something that no one else is making. It’s not just some tiny efficiency. It’s building something that no one else has built. And it’s not just one game, it’s an entire series of interactive experiences that are delivered on a predicable cadence. If we do this right, we can be the AMC of interactive gaming. That’s the goal. Maybe that makes us a media company instead of a technology company. That’s fine.
Is it impossible? No, we’re not trying to turn Lead into Gold. Attitudes can change. Stories can be told. Player and customer bases can grow over time. Now we need to build it, and get our players talking. Never tell me something is impossible, unless you want to see it accomplished beyond your wildest expectations.
When I was at AMZN, an App Analytics company called me requesting a phone screen. I wasn’t really looking to leave my team at the time, but I usually take any opportunity to learn what another company might have to offer, and to understand a bit about their culture. They were based out of the Bay Area, with a local Seattle office, and I guessed (correctly) that the regional Director was looking for someone to take over the day-to-day management of the local dev team so that he could focus on more strategic issues. That Director and I had a nice conversation, and I stated that I wanted to do a little more research before getting back to him about possible next steps.
I opted not to leave AMZN at that time, but in my research, I discovered that the CEO of this company took pride in the fact that he still wrote code on a regular basis. I found it curious that someone with high level responsibility for an entire company, the P&L, and the broad vision, could actually still contribute to product. Perhaps he was only writing prototype code, or working on side projects, but still, he was coding, and that was impressive.
One of the earliest job postings for a role at AMZN, back when it was called Cadabra, stated that the company was looking for developers who “should be able to do in about one-third the time [what] most people think possible.” Jeff Bezos himself stated even while I was there that he wished the company could just move faster. It’s something I struggle with every day. On the surface, most features seem simple and straightforward. “We just need to be able to make a person run around the screen,” or “we just need to load a level and display it.” To someone who hadn’t done this, but had seen it done a hundred times before, it seems incredibly easy. It’s been done in countless games, why shouldn’t it take less than a day to get working?
But the devil is in the details, in covering all the edge cases. How do we ensure that the player doesn’t fall through the floor when they move? How do we keep them from running off the screen? Are they playing the right animation when they move? Are they sized correctly? What if they fall off a ledge? How do we load the levels? What if the level data is corrupt? What do we do then? Then, actually coding this up, testing the code to ensure that it works in every possible case and combination of cases, the complexity and amount of code quickly spirals and expands, and what seems like a 3 day task actually takes 9 days. No wonder Jeff wants people to do things in one-third the time.
This isn’t a problem unique to software. I have several friends who are actors, and if I use the Way-Back Machine, I can see a time when I acted in several High School theater productions. To an outsider, acting seems easy. Speak a few lines, look pretty, and then make tons of money and bask in fame. However, that’s not the reality at all. Actors have to focus on the meaning and purpose of every line, for there are at least a dozen ways to read “Hand me the keys, you -!” (That’s one of my favorite scenes from The Usual Suspects.) Which word gets the emphasis? Me? Keys? Hand? What’s the tone? Who is being spoken to? What’s their reaction? Actors also need to present a continuity of emotional state across a scene, which may take several days to film. Alternately, they may need to present a range of emotions across a 90-minute live theater production. They have to be realistic, believable, react appropriately without giving away anticipation (they know what the response to their line is, after-all), and usually with a potentially distracting live audience or film crew watching. As I learned filming and directing a music video for the Seattle band SMP, 3 minutes of on-screen footage might take two days of filming work. And the devil is in the details, in every frame, every motion, every mood, every line.
As the CEO, one of my advisors told me I only had two jobs: Keep the money flowing, and set a broad vision. Personally, I think I have a third job: Unblock my team, and enable them to create the best work possible. Understanding the complexity of their roles and tasks, finding ways to remove bottlenecks in ways that are not hand-wavy management speak, means diving into the details and keeping one hand in the code. Right now, I’m both Leader and Developer, but I can see my role shifting more towards the former and less towards the latter. Still, I don’t think I can ever step entirely away from the code, even as I hire up a development staff. Keeping an eye on the details means ensuring the right experience for our customers, and that’s the path to building great products and a great company, no matter how many devils have to be stepped on.
(This post has been edited to correct the quote from The Usual Suspects.)
We’re going to be a little quiet here for a week or two while we focus on some stuff for our announce. Don’t worry too much, we’re just working diligently in the salt mines. You may want to check back or visit our website (http://www.syncbuildrun.com/) on March 9th. Just sayin’.
Six months ago, I left a six-figure job as a Software Development manager at Amazon.com so that I could start my own Video Game Studio, SyncBuildRun. I walked away from an amazingly productive team that I loved working with, a supportive manager, and opportunities for career growth at a top tech firm. I had over $100k in cash and stock saved up, a supportive wife, an ambitious idea, and a plan. Here’s what went right and a little less-than-right over the previous six months.
What went Right?
Mentors – Before I started this adventure, I set up a series of recurring appointments with industry veterans that I respected, who had a history of success. I’ve met with startup founders, technical experts, game designers, public speakers, and more than a few accomplished VP and C-level executives. Keeping these conversations going, getting their opinions, asking the right questions, and keeping abreast of the problems right around the corner has been invaluable in making sure we’re always marching forward. I am deeply in debt to every one of my mentors, and thankful for the time that they spend with me.
Great Hires – Hiring is difficult. It’s easy to hire poor performers, but very difficult to hire solid contributors. I’ve been lucky with the three contractors that I’m working with most closely, in that their contributions have really raised the bar for what this project can be. So far, we have defined the look and posture of the main characters, the overall themes and tone for the soundtrack, the title sequence for each episode, and the setting and story arc for the overall game. I’m happy to work with this great team, and I hope to be able to continue to work with them as the game progresses, but I wouldn’t hesitate to recommend any of these guys for another project.
On Budget – When I started, I estimated that I had about 18 months to 2 years of financial runway. Given the low figure I’m paying myself (enough to cover the mortgage and pay bills), plus other business expenses (paying the team, legal costs, overhead), I’m currently somewhere between 20% and 30% through my overall budget. In other words, I’m right on track for where I thought I’d be at this point in development.
Solid Concept – When I tell people about the game concept and about the Episodic format, the result is always the same: amazement and enthusiasm. The people with whom I speak about this game are excited to see it and play it, and when they ask the hard questions, they’re impressed by the answers. We’ve thought this through, considered the edge cases, and we’re doing something that’s really unique in gaming. I think people are going to love it.
What could have Gone Better?
Overly Optimistic Development Schedule – Like all software developers, I was highly ambitious with what I thought I would be able to accomplish in time. My initial goals were to have three game modes fully prototyped by the end of December. Not only did that missed milestone make a lovely wooshing sound as it flew by, but I decided to add a fourth game mode. The upside is that I prototyped the most complex, risky, and difficult game modes first, and am currently running pre-alpha tests with a small number of players to get further feedback and refine these risky modes. The remaining modes are known quantities that will be familiar (and fun!) to many players, so I’m less worried about surprises there. Still, I wish I were about one month further along.
Some Hires Taking Too Long – Finding a production artist has been the most difficult challenge, and it’s not for lack of trying. There are lots of talented artists out there, but finding the ones who have art plus 2D animation skills, who are versatile enough, employable in the US, and available has been a challenge. We’ll also need some developers soon, but I’m less worried about that. Still, it would be great if everything regarding team building moved a little faster. I have found that this is true everywhere, so at least I know I’m not alone.
Marketing & Business Surprises – The biggest miss to date was not having a solid Go-To-Market plan, and this includes a strategy around how we announce, whether we do a Kickstarter and how we do it, how we get press coverage, how we determine our customer base, and so on. We’re about to sign a contract with a dedicated PR person, and we’ll have a nice website with plenty of pictures, video, and information on it pretty soon. This area is difficult because there’s no “one right way” of doing PR and becoming a known quantity, but six months of stealth mode seems like an eternity, and it’s time to emerge from the cave and show the world what we can do.
Various Little Problems – Then there are all the little issues. Problems with Code Signing Certs. Problems with various business people who are late, or don’t return phone calls. Problems with contract revisions. Problems with web databases. Problems with code that works in one environment but not another. They’re all solvable, but they become death by a thousand cuts if they’re allowed to pile up. Such is running a business, and honestly, at least here I have control over what to focus on and what problems to swarm on. That beats the seemingly random tossing and turning that can be endemic at larger, more bureaucratic companies.
We’re weeks away from announcing our game, figuring out a Kickstarter strategy and timeline, doing a Steam Greenlight campaign, and ramping up our team to full production capabilities. If we’re smart, diligent, and focused, by this time next year we should be about midway through the first season of our first episodic title. We’re super excited to announce and make players happy, and while there will doubtless be more bumps along the way, I think we’re in for a really great adventure.
I often wonder if I’m repeating myself with some of the stories I share, since I share them so regularly with different groups of people. However, a former CEO reminded me that it can take up to six times of repeating something for the message to really sink in, so I don’t lose sleep over it as long as I’m not boring my audience.
That said, there are a few key lessons that I learned from various leaders that I would like to share.
Shotgun Your Success Strategies
The first strategy is from a CEO who spoke at the World Business Forum in NYC. Her advice was, when approaching any goal, don’t just try one approach at a time. While it’s the scientific method to alter a single variable through multiple iterative approaches, time is too critical to waste running linearly thorough strategies. Instead, do many many approaches at once, like ten. Shotgun a bunch of methods, so that if seven of the ten fail, at least three will drive you towards success.
Big companies do this all the time with interviewing. When they post a job, they don’t just talk to one person at a time, make a decision, then move on to interview the next person. Often, they’ll interview several people in the same week, perhaps even in the same day, for the same position. Some will inevitably have other offers, will bow out, or won’t make the grade. But of the many people interviewed, one or two will at least be qualified and a good fit, assuming the prescreening process at the company is decent.
At SyncBuildRun, we realized we couldn’t just work on code all the time, we needed to also think about title videos, concept art, music, marketing, financing, etc. About half my time every day is spend writing code, but the other half is spent talking with my contractors, reviewing their work and providing feedback, handling legal and financial issues, speaking with advisors, interviewing potential partners, and doing forward planning. Even if one of these areas falls behind, I know I’m making progress on the rest of them, so overall, we’re okay.
Aim Higher Than Everyone Else
This one is from film director James Cameron, also at the World Business Forum. Jokes about his supposedly enormous ego aside, Cameron had it right when he was talking about how he approached making truly groundbreaking films. “I aim high, really high, way higher than anyone else. Then, even when I fail at a few things that knock me back, I’m still succeeding at a level well above where everyone else was even aiming.”
Amazing for both it’s hubris and it’s brilliance, this strategy has also served us well. While other game companies are eager to make the next Match-3 or Angry Birds clone, we’re aiming much higher with a long-term customer engagement strategy of multi-episode games that last for months, with content at a continuous weekly cadence. Sure, a one-off game would be easy, but we want to aim big. If we fail, we release a one off game. Going the other way would be nigh impossible. Our goals are actually a lot bigger than that (a lot), but I don’t want to spoil everything here.
Which leads me to my one bit of cautionary advice about this strategy: Aim high internally, but meter your external communication with your customers so that you don’t disappoint them. It’s far better to under-promise and over-deliver than the other way around, and if you’re aiming high internally but being conservative with your promises outside the company, you’ll be set up for success when you ship.
Cross Coverage is Critical
It’s great to have subject matter experts on staff, but it’s better to have folks around who know a bit about each others job, so that they can contribute constructively. Lane was one of the most fun, and most talented guys I ever worked with, and he had the role of “Technical Artist”, which meant that he made content and wrote code, basically did whatever needed to be done, to get some weird cool effect on screen. When we were trying to relaunch the Space Quest franchise at Escape Factory, Lane was tasked with Roger Wilco’s vacuum cleaner “weapon”, which needed an animated cone in front of it to display the area of effect. The cone didn’t track the player correctly, and was animating oddly. Sure, an artist and developer together could have worked this out, but Lane jumped in, fixed the content, and wrote the code to make it work the way the designers wanted.
This isn’t a call to hire people who are jack-of-all-trades. Rather, it’s a statement that your team should know enough about each others job that 1) they can contribute constructively about various topics that come up and not just the easy to discuss topics, and 2) they can cover for tasks outside of their direct area of expertise when someone is inevitably out sick or away on vacation. At AMZN, we had a rotating on-call system, where every dev would be on-call for a week and would have to handle whatever external or customer crisis came up. It always sucked, especially for the new hires who rarely knew what to do. I solved this by starting an on-call wiki for our group, where every time a problem came up that was new, the on-call person was required to document what the problem was and how they fixed it. Then, we would review the documentation as a team, and ensure everyone was on the same page. Stress around on-call immediately dropped, because instead of being a source of tension about the unknown, it was now a learning opportunity and a chance for cross pollination. Junior devs learned from senior devs, and senior devs got to watch junior devs automate away their ten step process with a 20 line Perl script. Everyone learned something.
The final bit about Cross Coverage is that it shouldn’t just apply on your production team. Ensure that you have this on your board, across your advisors, and on your executives. Have multiple people who know finance, not just your CFO and directs. Hire musicians, so that lots of people can discuss the feel, mood, and tempo of your soundtrack in actual musical vernacular, instead of just telling your contract musician “I don’t know, it needs to sound more purple.” Having groups of people who speak the same language is critical for successful and productive communication.