There were many times over the past 5 years in my life where I was the ONLY person who was good at using a particular technology among a team. Just as many times, if not more, I was the dumbest person in the room.
Through working with many styles, here's some common ones that I see:
But let's get down to it. What's the best way to lead?
Before every single group technical endeavor I bring others into, I create a design document.
Here is a video game design template I've created.The purpose of this document is to communicate a clear VISION of what is being created, and WHY it matters.
This means that at any point, someone should be able to look at this document, and understand how they can help.
Everyone is Empowered in the process, and is able to make creative decisions if they fit within the unified vision.
The benefits are numerous - but most companies fall to understand how to use them.
Not convinced? Read this: Article by Nicole Tietz-Sokolsaya
A clear vision is one of the most important parts of making quality creations.
By having a clear set of goals that you wish to accomplish, a clear set of restrictions you cannot cross, and a clear idea of what to do next, development becomes a process rather than a guess.
Before I make any video game, I write about what I want to make and how.
I dive into the creative aspects, the gameplay loop, and then technical implementation.
I understand my system before I make it.
Before I start any research project, I write about what I want to analyze and how.
I dive into a literature review, and see the gaps in knowledge.
I analyze a specific problem or case study, then think about how I can fill it.
Afterward, I try to understand how my technical pipeline can come together - before I implement it.
This has caused a lot of conflict with other skilled creators, as they strongly believe in "seeing where it goes"
As an individual, this may work. But as a leader, having a solid plan is paramount to success.
You cannot drag others along with you, if you don't even know where you're going.
This is where standups/responsibilities come into play. A lot of game companies start off with a "sprint" to make a prototype fast, so every team has a base that they can work from. I find this useful, as it means every team is able to gain a good sense of turnaround time for development.
Teams use software, like Jira, CONFLUENCE (big one), Trello, Mira, Notion to continuously update living documents.
For larger 10+ person projects that will be available for more than a couple of years, entire wikis - like github wikis - are sometimes made.
Don't simplify. It's a good thing that your team is spending extended amounts of time understanding what they're doing. This only becomes a problem with tight deadlines - and at that point your team needs to reduce scope. Remember, even if you take away time from the design phase, you still have to complete design tasks.
Almost all of your clients, business partners and stakeholders don't really care about the low level implementation of your code/products.
They only care about one thing: Am I paying money for a service that adds value?
Finding value only your company can provide is exceptionally difficult (especially in this ruthless business environment), and you'll be fighting against businesspeople who lie about the services they offer.
I find that being forthright with the people you work with is the best way to build long-term trust, and make sure they understand your design goals and principles.
Be honest about the problems you'll be facing, and plan for the worst case scenario. Afterward, make sure that worst case scenario never happens.
Book recommendation: Getting naked by Patrick Lencioni (I read this when I was 17, and over 5 years later I still go back to it).
You'll run into MANY short-term problems where potential clients will dislike how you always underrate yourself.
But in the long term - you'll be able to build consistent and high quality relationships that last.
Don't sacrifice short term profits for long term growth. Plant the seeds ASAP.
Here's an important question to ask as a leader.
Typical leadership philosophy says: NO!
The team is ONLY AS GOOD AS THE LEADER!
I find this PROBLEMATIC!
As a leader, I want to bring out the best in my team - not sink them down to my level.
Why?
I have many gaps in knowledge and understanding. We learn from each other - or better yet - they teach me, and I teach everyone else.
Every person I've ever worked with brings a large part of their soul into a project. It is my duty to respect that, and make sure they're able to succeed.
Sometimes people want to deviate from the documentation - or they try to pivot it to another avenue that doesn't fit the vision.
This is where soft skills come into play.
Identify what ails your teammate - and solve it. If you can't, then minimize their problems. If you can't, then minimize their involvement.
We have these things called "game jams". Basically, in a short amount of time (typically 24 hours), a group of developers make a video game, from scratch.
These are incredibly, fun, difficult and intense. Creating something as complex as a video game in a short amount of time is incredibly difficult.
This means that the planning stages are fraught with wild guesses, and the documentation is shoddy.
As a result, the team naturally diverges when they create their work.
When leading these projects, I always try to have "vision checks", in which we all analyze our original vision and look if it needs to be changed at all.
For Cactus Calvary ( Play it here ) our team wanted to have a complex narrative focus in the game.
However, as time went on, this wasn't feasible.
As a result we went for more explosive Anime/Comic book styled character designs and personalities in the short amount of cutscenes we were able to fit.
Instead of complex characters with subtle writing, we went for big moments and easily-understood archetypes.
This made the game much more "cringy", but our narrative ideas were still able to be implemented into the game successfully.
The point is: Sometimes you'll have to massively pivot, and that might be for the worse. Still, "done" is always better than "not done".