Summary:

• Use documentation.
• Solve design problems before implementation (but don't box yourself into a corner)
• Make sure everyone is bought in/ready to go. Everyone needs to understand design goals.
• Don't be afraid to make massive reductions/pivots.
• Remote work requires unique solutions.
• For an old-school throwback: Underpromise and overdeliver. ....?

A Unified Philosophy.

There were many times over the past 7 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:

• Basic Professional (White Collar work): You come into work with a specific mindset, and you're expected to adhere to high standards of ethics and keep the business as your main focus. This works for a lot of people - but a lot of people want to emotionally reach out to others, and you'll run into hierarchy issues (people feel like they can't speak up because they might lose their jobs).
• Tyrannical (Steve Jobs): These leaders are rude, rigorous - but have uncanny insight. It's good that they're able to stay important things and get people out of their comfort zones - but it's so emotionally draining to be treated like this. Our industry has an issue with churn - lets not make it worse.
• Friendly Casual (Google): These leaders are extremely nice, and fun to work for. Think a great employee campus, good food, cozy accomodations and a general personable atmosphere. While this style works for Google, extrapolating this out to less-entrenched teams doesn't work. Before everything goes wrong, you want your teams to make iterative and repeated improvements on their work.
• Pure Chaos (Palantir): Look, I've never worked at Palantir, and my experience with it is limited to interviews and second-hand books - but holy crap, they have an INTERESTING way of running things. Instead of having a boss/manager that tells everyone what to do, the teams are lean and extremely flexible. Instead of asking for feedback from an out-of-touch PM, engineers go directly to their clients and ask for improvements. While this has a wide variety of benefits, this style can easily fail. If the team isn't equipped and if members aren't motivated enough, work can quickly death spiral and products can exist in strange limbo states where everyones overworked but nothing's being done.

But let's get down to it. What's the best way to lead?

The design document

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.
Here is an in-depth design document for a video game I want to make.

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

What's vision? And why Should I care?

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.

Story time.

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.

What are the problems present in managing a team? How are they solved?

• How do we make sure remote employees are accomplishing what they need to?



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.

• Documentation changes way too much over time. How can this be addressed?



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.

• My team is spending too much time on simple documentation review/writing. How can we simplify this process?

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.

On negotiation & sales (Under-promise and over-deliver):

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.

Update Mar 17th 2025 Counterpoint: This is deceptive. Now that I know more about small buisnesses, I disagree with this statement - but on a deeper level. I need to think about this further.

Here's an important question to ask as a leader.

"If I step out for a day, would my team succeed?"

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.

Some friction is necessary. Conflict is inherent in group work.

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.

1. Why are they deviating from what the group decided?
2. Maybe they learned something that changed their mind. Why not understand them better?
3. Maybe they don't find personal satisfaction/fulfillment for working on this project - in that case make sure they don't suffer long by finishing quickly.
4. Maybe they see a vision that calls to them so strongly, that they must deviate. In that case, consider them - and make sure they feel heard. Even if they get a "no", make sure that they are heard.
5. It's all about one-on-one communication and discussion. Working in large groups/remotely makes this difficult, but it is still required.

Identify what ails your teammate - and solve it. If you can't, then minimize their problems. If you can't, then minimize their involvement.

Servant leadership is a proven method of success.

Story time:

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".