Software Projects (only) Fail Because of People

I've said for many years that I have a highly developed sense for the Stench of Death.  Since 1995, I've been building very complex realtime software (video games).  I have not seen any fail because the disciplines involved were beyond the ability of the engineers, artists, or designers on the team.  Not once.  Sometimes the tech is lousy or misguided, the game design is garbage, or the art is simply bad.  These are symptoms, not causes.  I've seen projects get canceled, go into production before they were fun, ship before they were polished, and even ship after it was clear that nobody wanted it.  Exactly zero times were technical limitations of the team responsible.  It was always, always one or more people that created whatever team dysfunctions led to the utter loss of decades of man-years and millions of dollars.  

I don't believe in fate.  We are ultimately responsible for our decisions, and it's those decisions that contribute heavily toward success or failure.  In nearly every case, it was clear (at least to me) that failure was due to specific interpersonal issues that could have been corrected, saving the project in the process.

After seeing a lot of failures up close, I've grown sensitive to certain patterns, and work hard to correct them when I see them starting.  I'm going to mention a few here.  Maybe if more people start to recognize these anti-patterns and address them, there will be more successful software projects?  I'd like to think so.

Meeting Rituals and Team Alignment

Meetings suck.  As an engineer, even knowing there is a meeting scheduled later in the day affects all the hours preceding it; I won't start a complex task that will definitely be interrupted.  Even if it is later canceled, the damage is done.  People who scatter-shot meetings onto the calendar, inviting too many people or not including decision-makers, is a great way to zero out your development velocity for whole days.

Conversely, I worked at one company where meetings never happened and all communication happened through private Slack channels.  This extreme case of no-meeting teams is a different kind of disaster where information is largely disseminated through rumor and hearsay, where goals were flexible or left self-directed as an exercise for the IC to determine for themselves, "as a test".  It caused months of wasted effort, led to finger pointing and created tremendous animosity and uncertainty between team members.  Please never promote a lack of meetings as company culture.  It is an abdication of leadership responsibility and project management.

Meetings do serve a purpose: they create team alignment around objectives, set expectations, and solicit feedback on the viability of these goals.  When teams drift out of alignment from a lack of meetings, or a lack of useful meetings, it's common to see the wrong work being done.

Communication Breakdowns

It's common for teams to be split into multiple disciplines, whether front-end/back-end, data/features , or art/design/engineering.  There's also C-suite, management and individual contributors (IC).  All of these have to be in regular communication to set expectations and report progress.  The moment some toxic person enters the scene, they inevitably anger someone.  This is why the No Asshole Rule exists.  Sometimes it's just fundamental personality differences that flare up between leads.  In either case,  it happens a lot that productive communication halts.  From that moment onward, teams evolve their own expectations of others, and when those are not met at some future point, all hell breaks loose.

There is a concept called respectful dissent, which I think is a great attitude to promote.  It states that you can disagree but you cannot treat others as inferiors.   I had some great learning moments at a company where this was the norm.  In any case, disrespect is unprofessional and intolerable, and grounds for dismissal in my opinion, at any level.  Unfortunately, you can't fire the CEO for being a jerk, so some rules only apply to the rest of us.

Inadequate Leadership

Sometimes you have a strong project manager (we call them Producers in the games industry).  They are on top of all the initiatives, have a breakdown of work being done and delivery dates and some estimate of risk of being late.  Sometimes you have a strong Creative Director who has a clear vision for how the product works, can articulate and tailor it for the team member so they understand their corner of the universe where their work supports this vision.  Sometimes you have a strong C-suite that allocates a budget with sufficient resources to hire talent, responds to team requests quickly when legal agreements need to be signed, and pushes back enough on the project leads to make them defend their project's choices as it pertains to the business objectives overall.

When any aspect of these are missing, the risk of projects failing goes up.  Bad project management usually leads to missed delivery dates and cost overruns.  Bad creative direction leads to feature thrash and frustration in the ranks of the ICs.  Bad management performance in C-suite leads to conflicts with the team and if not resolved, often end with cancelation or removal of the Creative Director... or equally bad, backing away from responsibility to the project at all and simply blaming the team.

I hate to admit this, but veteran devs are not necessarily desirable because experience makes them dramatically better at the technical aspects of the job.  It's really because they have been through these cycles a few times, veteran devs can operate despite gaps in leadership.  The chances of a project being successful go up because of the micro-decisions that carry the project forward in times of uncertainty.

On Hope

When teams work too many hours, have no breaks, have too few team members without adjusting the expectations, you get burnout.  A lack of support often leads to--dare I use this term?--quiet quitting, followed shortly by actual quitting.  When key personnel leave, the project has a short window to promote from within or replace with a great hire, or risk not only losing traction but losing the rest of the team.  The secret ingredient of a software project is Hope.  It's what binds teams together, and they Hope what they do is meaningful and impactful.  When a project falls apart, it's often because devs lose Hope and they migrate to a new project where they can become emotionally invested.

On Trust

Anytime you accept a job, it's an agreement that you will fulfill duties assigned in exchange for remuneration.  Technically, yes.  But there are implicit expectations to that relationship as well:

• "I trust that I can meet the expectations of my employer if given appropriate equipment, time, and training."
• "I trust that my boss will forgive me when I fail, and give me more chances to succeed."
• "I trust that others on my team are trying as hard as I am."
• "I trust that my managers care about me as a human being, and balance demands for the project accordingly."
• "I trust that the company wants my project to succeed."
• etc.

Oddly, we normally enter into projects with these precepts and optimistically believe them to be true.  (This is quite different from how we allocate trust when meeting a new person, isn't it?)  However, when trust is broken, the employment relationship is broken.  From that point forward, I have not seen people recover and be capable of contributing substantially to the same project or work with the same team.

Suggestions

Right-size your meetings:  Feel free to say no to meeting invites, and ask if something can be an email or Slack thread that can be handled asynchronously.  As a lead, I often will take the place of several devs on my team if it seems like I can answer for them and give them that time back.  

Be vigilant about distractions: My team has a brief standup in the morning before they get too focused on difficult work.  Being spread over multiple timezones, the best we can do is 9am PST to give everyone the afternoon to work uninterrupted.  We try to keep everyone within +/-2 hours for this reason as well.  We have a no-meeting policy for my team Tu-Th, to allow three full days of focus time every week.  It was an adjustment but now everyone else knows we reject meetings those days, and our Mondays and Fridays fill up with communications.  It works really well.

New jobs: Interview people on teams before you join them.  If you smell smoke, there's fire.  Read Glassdoor, although it's full of ranting ex-employees, there's a kernel of truth to everything being said.  Listen for alignment among C-suite, directors, and team members; anything that seems out of place, call it out.  I noticed this once and declined the offer, and sure enough 1.5 years later the project was shut down due to the misalignment in expectations between C-suite and the project.

Identify gaps: Prompt your lead, director, or CEO for more regular, direct communication if you don't have any.  Ask hard questions (without being a dick).  You may not get any answer, or you may be disappointed with the answer you do get, but at least you made an effort to solve for deficiencies in the team.

Just remember, you have at most a working life of 45 years.  From what I can tell, most game developers don't stay in this industry more than about 10 years.  That seems like a long time, but AAA projects and MMOs take many years to complete.  You only have so many swings at the plate, and although having a flame-retardant diamond-encrusted thick skin is a minimum to work in games,  and shipping projects are the only ones that really count, when your threshold for bullshit has been exceeded, get out.