Ian Langworth started his career as an O’Reilly author and software engineer at Google. Today, he’s the co-founder and CTO of Artillery, bringing console-quality gaming to the web browser.
Not too long ago, I was a software engineer preparing to start my very first company. Obviously, there was a lot to consider, but what fascinated me most were the unknown unknowns — the unforeseen challenges that I knew would come up. And even though I was the tech guy surrounded by capable business-focused co-founders, I knew that building a successful company was going to start with a lot more than a command line. As you can imagine, there was a lot I didn't see coming. So, for what it's worth -- and for all the engineers out there aspiring to become founders -- here's what I wish I'd had on my list of unknown unknowns:
Direction and Faith
When Google offered me a job in 2006, turning it down wasn’t an option. Google is probably one of the best places to work as a software engineer; you’re exposed to some of the smartest people in the world and you have some of the most powerful tools in the industry at your disposal. It’s easy to get used to it.
This can be a mixed blessing, however. On one hand, I truly believe that working somewhere like Google takes you one step closer to joining or building something amazing. Google forces its best practices onto you, and its easy to take them for granted when you’re there. Since then, I've met founders who were surprised when I told them that quarterly objectives, mission statements, core values, and cleanly written code are all useful and important. Some of the basic takeaways from Google make you much more equipped to be a company builder.
On the other hand, it’s hard to keep pushing forward and being creative. Leaving Google to join Redbeacon was one of the best decisions I ever made. I was their first full-time engineering hire and I helped build out the team and set the agenda for product development. When you’re at a large company however, especially as a software engineer, it’s easy to get disconnected from the business side of the organization and its direction. Your primary responsibility is shipping high-quality code. But when you join a company as the fifth person, you’re suddenly exposed to everything that’s going on, and you get a front-row seat to setting priorities and making big decisions. Anyone who wants to become a technical leader should strongly consider joining an early-stage company to get this experience.
We know all too well that if we’re right and our technology works, we’ll soon be beholden to a much larger audience as well as all of the pressure and expectations that come with it.
Today, as CTO and co-founder of Artillery, I’m split between infinite freedom and infinite responsibility. Artillery is trying to do something incredibly ambitious (turning the browser into a high-quality gaming console). This speaks to my most creative impulses as an engineer — it’s the opportunity to draw our own roadmap as we go. At the same time, we know all too well that if we’re right and our technology works, we’ll soon be beholden to a much larger audience as well as all of the pressure and expectations that come with it.
At some point I decided that you have to believe that what you’re doing is the right thing. Flipping the mental switch from “I think we can do this” to “This is what’s going to happen” wasn’t easy, but I’m certain it’s what has made my particular evolution possible. Some people think it’s about confidence. I disagree. I think it’s more about faith.
Failures in Communication
A few months into Artillery, the other founders and I were already on each other’s nerves. I thought that because we were such a small team, communication would be a cinch relative to my experience at Google. I was wrong.
Three co-founders made for messy communication. One of us would say something to the other, who would proxy it to the third guy. As a software engineer, you’re usually part of a team made up of other engineers, which makes communication easy. When the team is multi-disciplinary or grows bigger than 10 people, communication can get a bit thorny. It’s much harder than you’d ever expect, and it’s critical that you get good at it.
So we decided to spend more structured time together, not less. We blocked off an hour to sit in a room and write out exactly what was going on.During that first meeting we took notes and recorded all our decisions. In less than 60 minutes we had solved almost all of the problems we could think of, and most of them were based on miscommunications (surprise!). This was the first of our now regularly-occurring weekly founder’s meetings. It’s the same format every week, and we continue to add to a single, long Google Doc so that we can refer to any decision later. It’s been transformational, and we haven’t had a serious disagreement since.
But it’s not enough to simply communicate more. You have to communicate well. When we first started our regular meetings, we often found ourselves locked in time-wasting debates. We’d get 30 minutes in before realizing we were arguing the same points with different words. Simple phrases like “needing a policy” could mean a ten-page handbook or a one-sentence rule. So now, before we have time to start disagreeing, we take time to make sure we understand where we’re all coming from. This saves hours.
We’ve established a few other rules along the way to get the most out of these meetings: First, they’re private so we can give each other open and honest feedback. This gives us permission to leave our egos outside the room and have frank discussions. This often results in one of us saying, “Oh, I didn’t think it came across like that.” Constructively critical conversations keep us in the mindset of self-improvement.
Also relevant: the problem with email. Email is one of the worst ways to convey emotion, and it turned out to be the root of many miscommunications early on. It’s too easy for someone to misread an email, decide they’re upset, and behave badly. An in-person conversation using the same words might go quite differently.
I’ve adopted a simple trick to convey mood in email: Whenever I find myself doubting how a message might be read, I’ll add something to the top like “[mood: agreeable]” to confirm that I’m actually in a good mood and not being passive aggressive. You’d be surprised how effective this is at keeping everyone calm and avoiding conflict.
Engineering Utopias Aren’t Easy
Early on we talked a lot about what we wanted working at Artillery to be like. We talked about empowering individuals and the types of perks and benefits that would make working for us convenient. We wanted to build something fun and worth looking forward to, and we wanted to use that to attract the best talent.
We decided on a list of perks and put them on our website: free lunch, good health care, public transportation reimbursement, unlimited vacation, a budget for workstation and peripherals, and a video game-related plushie hand-delivered from Tokyo. Unfortunately, defining these perks was the easiest thing about them. Implementing them and creating an engineering utopia was hard to pull off.
At first I thought unlimited vacation would be a good idea. After all, it was in Netflix’s famed “Culture Deck,” and it seemed to work well for them. However, this seemed to put more pressure on employees — the good ones might worry that they were taking too much vacation and not take any. Eventually we decided on a fixed amount of paid time off — an amount that would alleviate anxiety but still be generous enough so no one would worry about “burning” vacation.
The “build your rig” workstation budget was a good idea... at least until one of our new hires requested one. Who knew that a $20 Razer Goliathus mouse pad would be worth the money? (Now, I swear by them, but that’s beside the point.) Suddenly we had hires asking to use their own laptops and spend their budgets on expensive peripherals. Others wanted to assemble systems that were sure to be an IT nightmare and high-maintenance. And all the while I knew everyone should be using Mac OS X because it would be clean and simple.
The spirit of a perk may be obvious to you but no one else.
Our solution here was to explain the spirit of the perk. When it came to buying equipment, the purpose wasn’t to open an infinite tab to meet every little need. It was to provide a great work environment by making sure no one was stuck with an old, crappy computer. Getting everyone to understand the intention behind a policy or a benefit helps everyone make better, more prudent decisions.
The important thing about perks is that you can’t take them back (at least without suffering the consequences) so it’s important to think through all the implications. The spirit of a perk may be obvious to you but no one else. People who seem like they’re exploiting your kindness may not be malicious — they might just have the wrong idea. You may have to remind a few people they’re not gaming the system if the whole system is a small handful of people.
Leaving the Comfort Zone
I knew the CTO position would require more responsibility, but did that have to mean long board meetings and management bureaucracy? Yes, it turns out, and more. Start off as technical as you want in your career, but if you want to be a CTO you’ll do all the things we’ve come to expect of managers and executives: hiring the right people, firing the wrong ones, pitching and selling ideas constantly, and rallying the team around a central vision.
Suddenly I had to start wearing shirts without holes in them to big meetings where I needed to convince people I was going to do things that might very well be impossible.
The first time I encountered any of these more foreign CTO tasks was when we raised capital. Pitching to investors is a scary proposition, especially if you’re a software engineer used to sitting in a cube and communicating solely over GChat. Suddenly I had to start wearing shirts without holes in them to big meetings where I needed to convince people I was going to do things that might very well be impossible.
As an engineer, committing to deadlines weeks in the future is hard enough. Investors challenge you to commit one to two years of your life, and then question you every step of the way. “Really?” some of them asked, puzzled. “You’re going to build a AAA game? What EA does for $50 million with just $1 million? How are you going to cram 2 GB of assets into a browser? How are you going to make it fun?”
Luckily, years of software engineering gave me a valuable tool: intuition. I believed deep down that what we were doing was feasible. I was sure that browser technology was ready, and I knew we could build engaging games. Once I convinced myself that what we were doing was possible, convincing others became a whole lot easier.
Like rallying investors, galvanizing my new team was also a challenge. Many months ago, we committed ourselves to building a game — a pretty terrifying proposition for a bunch of rookies. We didn’t know what the game would be or how it would work, but getting started was imperative. We had to trust in our ability to learn along the way, and I had to get everyone to believe.
So I got creative. I’d been working with an artist to make some placeholder units for the game, and he had just sent in a concept shot of the units in a lush, grassy environment. I had the picture blown up to a 36” x 24” glossy poster and hung it on the wall. From then on, when anyone asked what they should work on next, I’d point at the poster and say, “Whatever gets us closer to this.” This was all our team of self-motivated engineers needed to hear. We all had a clear view — literally stuck on the wall — of what we needed to accomplish to meet our goal.
Choose the Right Technology
Web development is a creative and fast-paced world. Ideas evolve and tools emerge so rapidly that it’s easy to get convinced that some new framework or code will magically solve all your problems. But you must remember that there’s real money riding on your choice of technology. Later on, you won’t have the time or resources to rewrite everything.
At Artillery, we knew we’d be writing a lot of JavaScript, which is such a wart-laden language that we strongly considered alternative languages which would compile to it. We settled on CoffeeScript since we had used it before, it worked well, and we liked most of the decisions made by its author. The key was we weren’t already wedded to a particular language that we still had to be writing it. Additionally, using CoffeeScript seemed so lightweight that, if we decided to revert, we could compile it all to JavaScript and edit from there. The overhead was low and the backup plan was reasonable.
The decision for server-side wasn’t as easy. Node.js was the obvious choice so we could, in theory, easily share code between the client and server. However, Node.js was young at the time, and its ecosystem was still immature. Its package registry made it difficult to assess quality and reliability, and there seemed to be many packages with similar functionality but at wildly different stages of development.
This gave us pause. But upon further research, one thing swayed us: how fast it was improving. Node.js is based on V8, the fast and clean JavaScript behind Google Chrome. And if there’s only one company full of smart people I trust to work on language runtime, it’s Google. Relying on this framework seemed like a safe bet. New releases of the code were consistent, and a strong GitHub integration with packages allowed for frequent module updates. After a lot of deliberation we decided to use it, and we’re still happy with the decision. But the decision took time, and I’m glad that we put the amount of thought into making it that we did.
Harbor Your Resources
I enjoy side projects, and I always have at least one going — a game, a webapp, or some other tool. It’s how I scratch the itch to learn and try something new. But when Artillery became a reality, my hobby was suddenly my full-time job. What was I supposed to do with my free time?
In the beginning, keeping up with my day-to-day responsibilities was difficult enough. After a few months, I noticed strings of days where I felt like I couldn’t get anything done. And at the end of a particularly bad week, I ground to a halt. Here I was, sitting atop my new company, ready to do bold, amazing things, but I couldn’t get my brain in gear to do any of them.
Then it occurred to me. I had spent the previous weekend prototyping an e-commerce site with a friend. “It won’t take long,” I remember telling him. “I’ll just whip up something with Django and PayPal and a shopping cart.” It took two days, and that effort cost me my productivity for the whole week.
This is how I learned the hard way that mental recharging is essential. Spending brainpower on other projects made me much less effective. As CTO, it was my job to stay on top of new technology, so why did I still need to spend nights and weekends dabbling? Tackling all these outside projects was putting a dent in my capabilities as a leader, and it wasn’t fair to my co-founders.
I stopped the side projects, and my energy and productivity shot up immediately. That said, I’d still run into short streaks of days where I couldn’t fix a bug even if I really wanted to. Someone finally explained to me that productivity comes in waves, and you have to accept that streaks of uselessness are inevitable. Once you accept that you can worry less and plan around them: If you know you’re on a down-cycle, acknowledge it, communicate it to the people who rely on you, and see if there’s something easier to take on. This is much easier than panicking over being unproductive and missing deadlines.
And if you really can’t get anything done, beat procrastination with a simple trick: think of something you really don’t want to do. Working on whatever you were avoiding will start to look pretty good.
Trust your gut
Trust your gut. If you know something is true, even if you don’t immediately know why, go with it. And the corollary is that, if something doesn’t feel right, including hiring, managing, negotiating, or making decisions, listen to your senses. This CTO gig is tough work and it uses all your brainpower and intuition — but there’s nothing else I’d rather be doing.