Wednesday, June 15, 2016

Marek's reading list - Endless Frontier: Vannevar Bush, Engineer of the American Century

I try to make time to read a variety of books, articles, news, and more. I’m especially interested in learning about how others have successfully managed and completed scientific projects, and one figure always left me feeling curious: Vannevar Bush. Bush is credited as one of the people who won WWII for the U.S. by bridging the gap between civilian scientific research and the military. Bush worked as President of the Carnegie Institution for Science and later Chairman of the National Advisory Committee for Aeronautics (now NASA). He also single-handedly convinced President Roosevelt to establish the National Defense Research Committee, allowing for effective coordination between civilian scientists and military researchers, and served as Director of the Office of Scientific Research and Development. Most importantly, perhaps, he oversaw the Manhattan Project. All of his efforts during the WWII era went towards leading thousands of scientists to develop groundbreaking technology in a very short period of time at a critical moment in history.

Vannevar Bush
Together with our Head of PR, JoEllen, I looked into Endless Frontier, a book by G. Pascal Zachary about Vannevar Bush’s life. The text explores all aspects of his adulthood, especially his triumphs and failures in the pursuit of a technology that revolutionized the American approach to scientific research.

Please keep in mind that this blog is not about my opinion on nuclear technology or the military. Rather, I am interested in how Bush managed a sizable and often remote research team. In general, here at GoodAI we want to maintain our distance from military research. However, I see that Vannevar Bush led a team with a strong sense of urgency (or even danger), and with a high potential for reward if they succeeded.

I think a lot of how he became successful can be applied to how we can organize our research and teams at GoodAI and Keen Software House.

Personality as a leader

  • Vannevar Bush was a strong-handed leader. He wasn’t afraid to take risks when the chance of reward was high, and he was certainly self-assured when it came to making big decisions. Knowing he had as good a chance as anyone to solve tough problems, he thought of himself as a ship captain, requiring “loyalty, even deference, from subordinates” but being “fiercely loyal and protective” of the people who worked for him. 
  • He refused to take “no” for an answer when he felt it was important.
  • It wasn’t easy to work for him – he was known for being both tenacious and belligerent. He liked to tell people to “Justify the space you occupy.” On the other hand, he was both skilled and self-aware, so he always tried to pair himself with another leader who was more sympathetic and generous than himself.
  • Most defining of all, he wasn’t afraid to work hard. He had grit

Personal knowledge of research

  • In additional to reserving time for his own experiments and pursuing his own ideas, Bush strongly believed that any good researcher has to reach beyond their own field – to business, the free market, finance and economics, and more. 
  • He also believed that a good scientist needs soft skills – to be able to teach others and explain high-level concepts to them, and to have a strong sense of the “needs and aspirations” of the people they serve. For Bush, a scientist can’t be isolated in a lab, removed from reality.

Approach to research

  • When designing a machine, Vannevar Bush always started with a specific end goal. He then went back to the beginning and outlined specific steps for getting there, highlighting any part that might cause difficulty. He also wasn’t afraid to go back and revise as he moved forward in the process. Versatility was critical for Bush.
  • His goal was to “dream in a rather definite way.” He knew what he wanted, and always had a plan for how to get there. 
  • He worried about over-specialization in science, and was sure to stay involved in politics and business. He even moved to Washington D.C. to be closer to the action of the day. This proved a successful strategy for him, as he earned money by working to make things that people genuinely needed. 
  • He wasn’t bound by custom – he was as likely to speak his mind to the U.S. president as to his subordinate. He even compelled the army and navy to cooperate and coordinate, poising himself as a fixer and a middleman, willing to tackle any problem. He even set up the NACA to connect the military with civilian research.

Organizing the team

Team organization was the self-described “greatest challenge” for Bush when it came to conducting research, but he had a number of strategies to ensure things ran smoothly.
  • He believed that clear structure could overcome crises and conflicts of personality – however, this sometimes made his teams overly bureaucratic.
  • He knew his researchers and their needs – he praised them for improvements, regardless of how small they were. He saw that researchers were motivated by pride, money, and patriotism, and ensured that they received precisely those rewards. 
  • Questions he asked at meetings included: What’s new? What are our alternatives? What are the pros and cons of each? This ensured there was always a full discussion and awareness of facts and alternatives, but he was the one to make the final decision.
  • The 1st principle of management for Bush was “hire good people and put them in key positions.”
    • His top people always had a direct line to Bush himself.
    • His team was diverse but balanced as a whole – he had the loyal man who really worked for the organization, but also one with more enthusiasm and creativity, etc.
    • None of his researchers ever quit, despite his demands. He always supported his inner team publicly, but was critically honest with them in private.
  • Bush didn’t staff only his own employees. Instead, he contracted with research institutions, universities, and industrial labs. This meant scientists could stay in their own labs, and that he could more easily put together a national network of the very best researchers, hiring rock stars from MIT, Harvard, AT&T.
  • Finally, he often held informal “teas” for his staff in the afternoons – he saw it as a morale booster and a way to share information informally.


  • Overall, his most significant achievement was bridging the gap between science and government, compelling government to put scientists’ knowledge to effective use
  • He managed to maintain an agile approach to research and development, though the organizations he oversaw were very large and widely distributed. 
  • He was never afraid to tell people what he thought (even the president of the United States), and successfully ensured continued government funding for science and engineering after WWII, contributing in a major way to American post-war supremacy.


  • However, Bush was elitist – he was an enemy of participatory democracy, so failed to build mass support for his ideas about how research should be conducted. Instead, he relied on a limited number of key decision makers to push his ideas through.  
  • He failed to understand how competition could inspire and drive creative innovation, and was partial to centralization. While he contributed to the U.S. rise to power during and after WWII, he also played a strong role in feeding the military-industrial complex and bureaucratic government institutions. 
  • Given his self-confidence which often proved to be an asset, he pledged himself to nuclear proliferation, but had little idea how to keep the technology contained or in safe hands. 

Our takeaways

  • We need to maintain balance in the team
  • As a team, we need to remain committed to agile development, and not become a sluggish corporation. 
  • It will also be critical for us to stay committed to continuously refining our thinking on the safety aspects of the artificial intelligence we’re building, and how AGI will impact the future. For this, we will likely need to reach out and cooperate with others who know more about economics, sociology, government relations, and more.
  • We should remain focused on design details for research, just as Bush did when designing a new machine – setting out a roadmap where each small step is specified as much as possible. We also shouldn’t be afraid to remain agile, changing our plans as we learn more and more. 
  • Finally, we should be wary of over-specialization, as it may distract us from our goals. 

In general, reading the story of this successful leader confirmed that we’re on the right track in many ways. There’s always room to be inspired, however, and I’m always looking for ways to improve how our team works together.


Thanks for reading! Let me know in the comments if you have more recommended reading, especially about science, research, engineering, and development – I’m very open to suggestions!

Marek Rosa
CEO, CTO & Founder, GoodAI
CEO & Founder, Keen Software House

Twitter: @GoodAIdev

Tuesday, May 24, 2016

KeenSWH Team Structure + New Medieval Engineers Leadership

Today I’m writing with news about our Keen Software House structure and especially the Medieval Engineers team. We’ve made a few changes that are aimed at helping us reach our short-term and long-term goals, so we can deliver the amazing games our community deserves as efficiently as possible.

Earlier this month, I wrote a blog post explaining that in the last 1-2 years we have transitioned from an indie studio of 5 people to one of 50+. We’re growing fast and the growth continues. We’ve experienced some growing pains (like any expanding business does). We’re solving this by constantly improving our organizational and management processes, and by finding strong leaders for each project. We were working to find the right person to lead Medieval Engineers and help us scale up so we can continue to bring you quality, awesome, fun, polished games with big features.

Today I’m happy to say that we’ve found that person – Tim Toxopeus. I’ll tell you a little more about him later on in this post.

Team Structure

We’re definitely no longer a small indie studio of 5 guys. These days, we have over 50 people split into various teams (a few people are on more than one team). We’re publishing this organizational info because we never actually explained what our team looks like to our community - now everyone can have a clear picture of how development looks at KeenSWH:

  • Space Engineers – 14 people (led by Petr Minarik, who’s been with KeenSWH since the beginning)
  • Medieval Engineers – 10 people (programmers, artists, testers) - led by Tim Toxopeus
  • Music – 1 composer (Karel Antonin)
  • Sound – 2 sound designers (one of them - Lukas Tvrdon - has been with us since the beginning and worked on Miner Wars, Space Engineers and Medieval Engineers)
  • VRAGE engine – 4 programmers - led by Jan Nekvapil, a young and very talented programmer
  • VRAGE-RENDER engine – 3 programmers (led by Jan Hlousek, a newer member of the team with years of experience in game development and render techniques)
  • Backend – 2 people
  • Space Engineers Xbox – 1 programmer + one external development company with significant experience porting PC games to consoles
  • Testers – 5 people
  • Game Design – 2 game designers (led by Tomas Rampas, one of the original Space Engineers designers)
  • HR – 1 person
  • Finance – 2 people
  • PR – 3 people
  • Business development – 1 person
  • Office Management – 1 person
  • Other projects 10 people

This list doesn’t include 30 researchers working at GoodAI - a general artificial intelligence R&D company I started two years ago.

How is this different than before? We’ve always had dedicated teams of people working on SE + ME. The biggest difference now is that while I’m still the head of Keen Software House, it will be up to Petr and Tim to drive Space Engineers and Medieval Engineers forward. Improving our management structure means that we can scale up in a serious way - the studio can now be run by the game teams rather than by me directly. I can now focus more on the general vision of our games and projects (the big picture), like what can we do better, where we want be in 1 to 5 years, etc., while each game team and its leader devotes 100% of their attention to a single game. 

New Medieval Engineers Leadership

You’ll hear a lot more from the Medieval Engineers team lead and producer, Tim Toxopeus, in the coming weeks. Known as Deepflame on our forums and Discord server, Tim is an experienced programmer and an avid player of both SE and ME. He had a cumulative playtime of 1000+ hours before he even applied to join Keen Software House. Bringing him to the Medieval Engineers team as lead producer is the next step in optimizing things in the game and at Keen Software House.

All hail King Tim, 3rd from the right

One of Tim’s first actions as team leader is to release a new stable (and default) branch on Steam with today’s Medieval Engineers update. In addition to returning area building to the game, we’ve made some fixes and quality of play improvements that will make gameplay generally more accessible and pleasant. 

With the release of this stable branch, we have decided to temporarily pause weekly updates (though video updates will continue as usual). I want to stress that this period will be different from the feature freezes and bug fixing periods we did in the past. We want to do much, much more than just stabilize the game – we want to bring it back to life.

Without the pressure to release something new for players every week, we can direct all of our energy towards getting Medieval Engineers in a more intuitive state and fulfilling our original vision for the game. You can read more about my original vision for the game in my previous blog post, but essentially, we want to refocus on engineering and building in the game. We want to implement a more intuitive interface that teaches new players what they can do. Survival, multiplayer, and single player will become a priority once again.  You can think of the current version of Medieval Engineers as a demo – just a taste of what’s to come.

We want players to keep in touch with what’s going on week-to-week in Medieval Engineers development, so weekly video updates will continue. They’ll be a little different than before, since we won’t be announcing new features every week. Instead, you’ll hear a lot more from Tim, programmers, artists, and testers about what’s going on in the game behind the scenes. So keep an eye out for upcoming Tuesday interviews, dev diaries, modding guides, and more!

Finally, we also want to implement a small reward in the game for those players who stuck with us through the early stages and this rocky period of development. If you have ideas about what that reward could look like (perhaps a custom model or hat in the game that would mark you as one of our earliest community members), let us know in the comments!


Thanks for reading!

Marek Rosa
CEO and Founder, Keen Software House
CEO, CTO and Founder, GoodAI

Medieval Engineers on Facebook:
Medieval Engineers on Twitter:
Space Engineers on Facebook:
Space Engineers on Twitter:

Tuesday, May 3, 2016

Medieval Engineers: Short-Term Roadmap + New Approach to SE/ME Updates

Today I’m writing to give Medieval Engineers players a better idea of where we are heading with the game and the new features that await them. I want to clarify our big picture plans for the game, so players will be able to see weekly updates as steps towards the awesome game that Medieval Engineers deserves to be.

The original vision for Medieval Engineers was solid (medieval technology, sandbox, physical interaction, realism, survival, intuitive and easy manipulation of volumetric environment, etc.) but during the past year we diverged from these core principles. I’m not satisfied with the current state of the game, and it’s time for us to refocus and consolidate.

It’s time to make Medieval Engineers more exciting, fun, and streamlined. Medieval Engineers is challenging to play in its current state (especially for new players) and we need to streamline it before major features can be added. 

We need to find the most intuitive design for the original vision for Medieval Engineers, one that extends to building, construction, deconstruction, crafting, harvesting, fighting mechanics (sword and crossbow), and so on. These elements are and will be the focus of the game.

So how will Medieval Engineers look after these big changes? Imagine your character spawning in the world. You will harvest, cut trees, build houses and castles, design protection against barbarians or other players, hunt and get food to sustain yourself, etc. It will be easier to build with blueprints, so you will be able to bring resources to a blueprint (for example, for a catapult) and the catapult will simply pop up. Hardcore players will always have the option to do it themselves, but the game will be more accessible for those who aren’t interested in spending a lot of time building something in particular.

However, these changes will take time. We know that weekly updates can frustrate players, because what happens behind the scenes in our studio is not always obvious to the public. It can seem like we focus on non-essential things (i.e. working on sounds rather than multiplayer), but the reality is that certain features and fixes take much, much longer than others. We always have multiple programmers, sound designers, and artists working on many things in parallel, and when a feature is complete we release it. Other projects take more time, but we definitely keep working on them.

Moreover, in the last 1-2 years we have transitioned from an indie studio of 5 people to one of 50+. We’re growing fast and the growth continues. We’ve experienced some growing pains (like any expanding business does). The way we’re solving this is to make our management processes better and by finding strong leaders for each project. I assure you that we are working to find the right person to lead Medieval Engineers and help us scale up so we can continue to bring you quality, awesome, fun, streamlined games with big features.

New approach to SE/ME updates

Streamlining our games also means optimizing our development, management, and update process. For this reason, in the coming weeks we will start updating both Medieval Engineers and Space Engineers on two branches – one stable branch, and a second development branch.

The development branch will continue to be updated weekly. However, these updates might not make sense every week, and there may be a number of bugs or problems with playing on the dev branch. Rest assured, though, that all updates to this branch are part of a long term plan.

We will also have a stable branch that will be well-tested and run smoothly for players. It will receive very important hot fixes, and will provide players with a more comfortable game play experience. Every month or two, we will update the stable branch with new stuff from the dev branch.

Having two branches will allow us to finish these major and radical changes without breaking the game every week or releasing features in their prototype phase before I can personally review them. Both games are in a very different stage of development than they were a year or two ago. They are more complex, and we simply need longer periods to make significant updates.


1) The stable branch will be the default branch. In other words, if players do nothing, they will be playing on the stable branch. If you would like to access the development branch, you'll need to change to it on Steam (instructions for how to do this will be posted when the change is made).

2) Weekly update videos will continue!  :-)

3) Remember that we still need to test this idea to make sure it benefits everyone - players, modders, and us as developers

4) The development branch will go through the same testing process as today's main branch (internal testing at Keen Software House, testing by our Closed Testing Group, then releases on Tuesday + Thursday)


In general, Medieval Engineers will be much more fun, coherent, exciting, and definitely more streamlined. Put simply, Medieval Engineers will become the awesome game that we all know it can be :-)

Thank you for reading! And many thanks to the Medieval Engineers players out there - we’re grateful for your patience and especially for your feedback. We definitely can’t make this game without you.

Marek Rosa
CEO and Founder
Keen Software House

For more game news, follow us on social media:

Medieval Engineers on Facebook:
Medieval Engineers on Twitter:
Space Engineers on Facebook:
Space Engineers on Twitter: