Prior to playing Factorio, I never got a chance to plan, build, and operate something myself. Having to do so with someone else’s help should in theory be easier, but that itself came with its own set of challenges.
While this blog post is able to be read on its own without any prior knowledge, it is a part of our Lessons in Factorio series, so if this is your first time reading one of this series’ blog posts, I recommend starting from the first one and working your way through them. The first post can be found here: Why I Learned from Factorio: Lean Networking
Working as a Team
The first time I played Factorio with my friend (who is now my business partner in e-Mayhem by the way), we ran into a lot of problems in having to collaborate. We couldn’t agree on certain designs, so the things we built often conflicted with each other’s plans. Since we were newer to the game, we had both different and bad designs and solutions. There wasn’t always enough resources for more than 1 person to work with, so we often got in the way of each other. For example, one of us would take all the iron so they can make belts, but that would leave the other with nothing to work with leading to obvious problems.
Over time, we started adopting shared standards or designs we could both agree on. This allowed us to work together without stepping on each other’s toes.
Some of the main rules we created:
- Standard train length – Number of engines and wagons.
- This prevented issues with an overly long train jamming the train system.
- Rules for belting materials.
- Only transport 1 material type per belt.
- If you need to mix on a belt, just keep it to 1 material per side of the belt.
Sometimes we would get into arguments about specific designs we had. As we got more used to working with someone else, we got a lot more comfortable with just letting go. Even if it’s not solved the way you envisioned, you need to be cognizant of and content with the results it would eventually produce rather than worry about how it got there.
We started developing specializations. For example, my partner would handle all the trains and fluids. I would handle most of the development in getting the newer sciences working and making sure there were enough materials available to build with. My partner tended to streamline or expand on what I’ve built afterward.
Having a larger factory definitely helps allow enough room for both engineers, but surprisingly, we’ve gotten pretty good at working together even at the start of a new base. The biggest thing that helped is we have shared goals to work towards. Even if the solution isn’t what we would have done, that doesn’t matter since we’re fully focused on the outcome and working towards our goal. Running our factory this way, we were able to synergize with one another a lot quicker and better making us more efficient and productive, therefore increasing the productivity of our factory.
Without realizing it, I’ve taken a lot of these learned skills back into network engineering and even running our company as a whole with my business partner. Looking back now, I can see that I developed the skills below.
Collaborative Creativity
Collaboratively creating something with someone else is a difficult skill. When neither person knows what the end result will look like, yet we’re moving forward to create something is really difficult if you haven’t done it before.
In order to do this, you need 3 things: A shared vision or goal, guidelines, and ability to let go.
Shared Goal or Vision
When creating something, there’s too many possibilities. To help us agree upon a direction we want to move it, we need some sort of shared vision or goal. We can use this as our compass to determine if we’re moving in the correct direction or not.
In Factorio, our goals were apparent. We needed to get a rocket off of the ground. As long as we got closer to our goal, any progress made in that direction was good, unless we broke everything. If that happened, we’d need to rethink our strategy and come up with another plan.
Guidelines and Limitations
There are actions that are detrimental to the long-term plans we had in mind. They could directly affect our goal, such as disrupting each other’s plans. Stepping on each other’s toes creatively. There could also be social consequences that can impact further collaboration in the future. If I were to insult someone I’m working with for example, they may feel less inclined to try new things in the future.
Whether expressed or not, these actions definitely still exist. If not expressed, we’ll have to find them organically through trial and error. It becomes harder to become creative because you’re not sure where the actual boundaries will lie, so you may end up being more conservative than necessary.
If we express these limitations as rules, guidelines and standards we’re free to be as creative as we want within these confines.
Letting Go
The whole point of making something with someone else is that you can mix your own good ideas with theirs and discuss/change the bad ones. If done well, the end-result should look nothing like what anyone involved had originally envisioned.
By nature, a lot of us want to defend the ideas we have, regardless of if they’re better or not. When less skilled at collaborative creativity, we try to fight so that our ideas win, instead of seeking the best solution, or coming up with a better solution together.
Holding our own ideas loosely allows us to discard them for better ones as soon as they come up.
Just remember your shared goal or vision and measure the value of the ideas based on that. Our goal is always to move forward, regardless of if it was with your idea or not.
Tying it Back to Network Engineering
What did I actually learn in Factorio that I took back to networking?
- How to collaborate with other engineers.
- Being able to communicate properly with the other engineers I’m working with is an immense benefit. The ability to get my point across in an appropriate manner does nothing but benefit the entire team.
- Having an open mind to any ideas they might have is a great way to improve anything we’re working on.
- Having shared standards you created together gave us more creativity, not less. What happened was that instead of feeling throttled by the guidelines, they let us know that we were free to do what we wanted as long as we stuck to the guidelines.
- It also helped provide some context to when we intentionally ignored the guidelines. “I made something really horrible. Don’t look this way, but just know we have roboports being made now lol.”
- I’m a lot more comfortable delegating tasks now. Before, people might have ‘ruined’ my base if they didn’t do everything exactly how I would have done it. Seeing everything through the lens of the goal of “does it get us closer to launching a rocket?” really helped me let go of that control and just allow engineers to solve problems in their own way.
- There are still times that I get a little annoyed when engineers solve problems in ways that I would never have done. Ultimately though, I’m able to let it go because the problem is solved and we can move on. I really don’t see enough benefit or even care enough to go back and re-do that work my way.
Thank you for checking this out. I hope you learned something new or enjoyed reading this. If you had any comments, questions, or just wanted to share your thoughts on this article, you can contact me at blog@e-mayhem.com
e-Mayhem helps companies successfully deliver business projects. We also help companies avoid losses associated with IT disruptions and security threats. You can learn more about our services at e-mayhem.com or by emailing sales@e-mayhem.com
Comments are closed