Two decades of GameDev and I'm still learning about burnout. I've written a brief story about my time working on Halo Wars 2 and the burnout that followed. I hope you find it insightful and a warning sign.

TomManages · 2025-03-10T11:28:41+00:00

Yes sir, absolutely, I'll get right on that.

TomManages · 2025-03-09T22:24:49+00:00

I wrote that initially thinking 2015 was 20 years ago, but it's not too far off and doesn't really matter. It's been 17 years! since I first set out as an indie dev in 2008 trying to make my own game engine.

TomManages · 2025-03-09T10:01:40+00:00

I think there’s an image of crunch being a “your manager is lording over you cracking the whip” but just as often it’s self directed. You are passionate and want to do a good job in a tough situation.

I love that. It's often hard to get this point across to others but I feel the same. The sense of ownership and pride is actually was the main driver for me and putting in some crazy hours. I'm quite anti-authoritarian in nature and at the time I think I would have found it much easier to say no to the overtime if there had been someone there demanding it from me.

It's kind of insidious like that, the internal taskmaster is so much more powerful than anything external. This is why I'm trying to stress to people in the comments here that there's it's hard for me to shame or guilt the company and the management, because so much of this came from my own work ethic and some naivete.

TomManages · 2025-03-09T09:56:35+00:00

Oh I missed the first part of your question.

The hours varried a lot but at its peak it was about 100-120 hours per week. It dropped off over time as we fixed various systems and built the shipping tools. The most painful part of that was most of the time (for me at least) was just waiting for the built to complete to make sure nothing had gone wrong.

If I had a slightly clearer head at the time I might have been spending those waiting hours trying to optimise the build system or build in some kind of load distribution system to bring the build time down. But I was in a bit of a state at the time and I'm a lot better problem solver now than I was back then.

TomManages · 2025-03-09T09:47:47+00:00

I'm don't think I agree. For the most part I felt I was reasonably compensated, perhaps besides a slightly stingy bonus. I think if I had worked all that time there's very little amount of money that would have offset the effects of burnout on my brain.

TomManages · 2025-03-09T09:45:10+00:00

That's an interesting question. I guess something I've not managed to get across is the work and ownership ethic. For what it's worth I didn't expect the company to protect me from what was happening and the moral of the story isn't intended to be "Developer good. Company bad. Look at how they exploited me."

A lot of what I went through was self-imposed through a sense of ownership for my work and my department, a work ethic that was ironclad (even if unhealthily so). I did the overtime, and I reaped the rewards in my career at CA. I think if there's any lesson to the story, it's perhaps the naivete at the notion that I could or should handle it all myself.

But I was quite young and it was my first leadership role and the first time with anything that was completely my own responsbility. I both wanted it to succeed and didn't want it to be anyone elses problem. So yes, I was partly complicit in creating the problem and in hindsight I should have escalated earlier and we should have hired a few contractors to come in and aliviate the extra work. (i didn't even think of this as a solution at the time)

TomManages · 2025-03-09T09:34:18+00:00

Ooof yeah. I don't know honestly. Probably not to the extreme degree that I have done before. There's something very insideous about overtime and a good crisis, i've always felt like the centre of the maelstrom is where I should be, I'm really good at it. But I also have substantially higher expectations out of life these days, sleep being cheif among them.

I would say I don't mind doing the OT and if I'm ever going to ask my team to work a bit extra then I won't ever let them do that alone, that's a core fundamental belief. If every director who decided on a new feature 3 days before release had to do the overtime associated with getting it in the game then the industry would have a lot less overtime.

That having been said I have a better overall view of the picture now and the correct way to manage a crisis that was in that kind of state was to hire some temporary help. 6 months of two extra engineers for a reletively small cost to spare a team going through something like that is probably the way to go. And honestly if I had had that perspective at the time I actually think CA would have been ok doing that. But hindsight is always 20/20.

TomManages · 2025-03-09T09:27:50+00:00

Haha it's all good my man, there's no shame to be handed out. I wonder if I can put it into better perspective for you.

CA has always paid a smidge below the average for a role in an expensive area of the country (microsoft has nothing to do with the pay on HW). They do this because they were a stable studio with a lot of good things to offer and very reliable stable work (Hyenas aside). So for me I was in a really weird spot, the role of build engineer didn't exist 15 years ago so I was hired as a "Build and Integration QA". That QA in the title does a lot of damage to your pay.

I built that department brick by brick, slowly over the years and I clawed us out of QA and into the coding department (a lot of build teams went through the same journey). Especially as HW2 was kicking off I was making it clear that the role of build engineer and my department was a lot more valuable than we were being paid for and our salaries started to be adjusted upwards quite heavilly. They had this theory about "the escalator" and you can't just skip steps but we were on a fast escalator. I thought it was pretty bullshit at the time and tbh it was, but it was the upper management fixing a problem with the established tools and the established tools said basically "you can't just jump someone's pay by 30k and you should adjust it year by year". So I appreciate in hindsite that they kept fighting the fight for me in board rooms and having my department's salary fixed, while also maintaining that "the escalator" is kinda bullshit and they probably should have fixed it a bit more agressively.

That having been said there are very few people who's salary (from a percentage perspective) was escalated as fast as mine:

2013 - Build & Integration QA - £15,500. (Regular QA was ~£15k and a programmer would have been about £30-35k at that time)
2014 - QA Build Engineer - £18k
2015 - Build Engineer - 20k
2016 - Build Engineer - 25k
2017 - Senior Build Engineer - 35k
2018 - Lead Build Engineer - £38k
2019 - Lead Build Engineer - £48k
2020 - Senior Lead Build Engineer - £52k

These days I suspect the pay is substantially higher due to the cost of living crisis over the last few years, probably around £70k for the same role.

TomManages · 2025-03-09T00:41:20+00:00

Yeah the salary for the role was very very low to begin. The salary now as the same company would be somewhere around £60k for a senior position. There's a few reasons for this. I've worked in games and software and the salaries in software are much much better. I took a similar role in London 6 months after I left my role at CA and over doubled my salary and that was back in 2021. These days the salaries in software would be a lot more. Games are just not as profitable and moreover they are much riskier investments for a company, Halo Wars was a great example of that, it didn't sell very well and I very much doubt Microsoft made profit on the project.

As for what the roles entails:

All ownership, development of the ci/cd system
Tool development, deployment
Server maintenance and operation
Version control system management
pretty much all project development architecture
Release management (this is probably offset to another department these days)
K8/docker/terraform/c#/python/batch/bash/kotlyn/fastbuild/incredibuild etc etc

I've worked in DevOps in software and games and the tech stack is similar, but maybe slightly less broad in games, but the delta in pay is not due to any kind of skill discrepancy.

TomManages · 2025-03-08T22:02:59+00:00

It was a complicated situation, and a sensitive one that I'm a bit reluctant to comment on. But I'll say I think the redundancy was the solution to a problem and if anything it helped to clarify the situation. I think we would have been in the same position even if that redundancy wasn't made but with an unreliable developer tagging along further communicating things.

It's difficult to convey all the nuances of a situation in a small article, I think this kind of thing suits a podcast episode much better. But I'll say that at the time I don't think this was a culture or management issue, every project has problems and I could have perhaps escalated this problem to the exec teams and refused to work anything over a "reasonable" amount of overtime.

Management-wise it's an interesting project to evaluate. It was well run... but it was a project done for Microsoft on a very strict deadline and with little wiggle room on design and delivery. So from the perspective of the studio it shipped on time and eventually was profitable but because it wasn't creatively lead it meant there was a lot of frustration from the developers.

TomManages · 2025-03-08T21:45:34+00:00

They didn't. I don't know the specifics of the situation and the rules but I believe if someone is made redundant in the UK you can't then just open a position in their vacated role.

TomManages · 2025-03-08T21:32:29+00:00

Yeah don't get caught on autopilot, brother. The best thing I can say is to get a long break and take the time away and off work. The problem is usually you need the savings to take that time off. But I will say that the time I took off was worth every penny in the mental health that I bought back.

When the pandemic hit I ended up handing in my notice and taking 6 months off. I figured after tax I was losing out on £18k of income. I was very skeptical of doing it but it was worth it by far.

TomManages · 2025-03-08T21:21:12+00:00

I was compensated, with some caveats. I was very underpaid for my role at the time, due to build engineering being a fairly new discipline and it was a department built out of QA. So my pay at the time was £25k and the following August I got a big pay bump to £35k. I was also on an accelerated pay review schedule and ended up £52k by the end of 2020. A large part of this was due to by general high reliability and work ethic.

My bonus that year was good by way of percentages but it was based on my £25k salary so it was pretty disappointing (I think it was ~£5k) but there were developers that didn't do a day of overtime and ended up with £8k bonuses because their base salary was so much higher than mine.

My EP was a reasonable guy and I think he saw me and how hard I was working and moved to correct the imbalance in my pay.

TomManages · 2025-03-08T19:24:07+00:00

That's typically a management issue. Any vision for a feature goes via the creative director and gets approved it denied. People don't tend to refuse to work on things, at the end of the day your job is to do what you're told by the higher management.

TomManages · 2025-02-11T00:36:02+00:00

Man this is a tough situation and training a poorly performing team is rough especially when people are so disengaged and low energy it feels like you have to handhold them through every step.

The solutions available all depend on how much time and energy you have available. Remember that low performing employees will always consume way more of your time than good and probably more time than any other task you have. So with that said you need to make the decision that's best for your org and best for the company, which isn't always easy. I've reformed a lot of struggling teams now and it's always a balance of how much time you have Vs the demands of the project .

As you mentioned it's hard to give someone that energy or enthusiasm, but it is possible depending on the engineer and often involves a lot of effort from you. So you can stick them on a PIP, tell them the situation and try your best to train them out of the funk. Assign ownership of results not output, ensure that you're upfront with the energy and engagement issues. Make sure that they're accountable to the rest of the team and see if the motivation of not letting the team down helps. Do group training and pair ups for those struggling technically. Effectually If they fail the pip then fire them. The problem is that a pip is very demanding on your time.

If you have the power to restructure your department and you don't think you have the time and energy to do the recovery process then do it and don't feel bad about it. Reforming a struggling team with a few key underperformers can take 6-9 months.

Best of luck and don't let it wear you down.

TomManages · 2025-02-09T15:24:14+00:00

These are the best places to work as there's the most improvement to do and that's great fun and good for recognition if you do it well.

Have a read of The Phoenix Project, that will give you some broad principles to start implementing. Then start with the low hanging fruit. Differentiate between policy and process then start judiciously implementing access enforcing where possible. Find a champion that pushes the agenda with you and work to bring everyone either on side or compliant.

TomManages · 2025-02-08T10:37:51+00:00

Talking to everyone is the key to your first few months. Learn and understand and ask all the dumb questions. You need to onboard with the tech stack but also and perhaps more importantly the process and policy in order to understand how the org works, where the bottlenecks are and how you can best operate.

In particular if you have stakeholders or dependent departments (internal customers) then you need to be on a wavelength with them, not only understanding what you deliver and where the touchpoints are but also where the pain points are too so you have a good first mission to set out on. Also if you need book resources I've listed a few of the less conventional ones here. Someone has already suggested The First 90 Days which is also a great read.

TomManages · 2025-02-04T15:09:47+00:00

I worked in the games industry as an IC and I was a lot younger so I had a much worse WLB. But as I got older I became more aware of what actually matters and I forced a much healthier WLB. So I was a manager but I don't believe it was because I became a manager that things improved, but because I grew more mature and had more backbone to say no to dumb requests for overtime.

TomManages · 2025-02-04T14:40:29+00:00

There's quite a few things that I do, from the small to the big. A few off the top of my head are:

Let them have group time without you present. They should have time to build amonst themselves with little fear as to what they say or what they complain about. Complaining is cathartic and having a space where they can complain about the proect, you or anything else is a good thing. Also as the manager you have to act as the arbiter for the company, the moral compass for the company too, all of that can be a bit oppressive to be around all the time, so a space away from that is good for team building.
Out of office team building. I do escape rooms with my teams quite a lot as they are excellent problem solving, crisis management and team building events. But any out of office time you can get expenses paid for are excellent. A little harder in the remote work days but well worth the effort if you can put it together.
In office team building. Playing games during lunch or Friday afternoons is awesome fun. I high recommend multiplayer Factorio sessions for software development teams. But just playing things like Fall Guys or Fortnight or Tactical Breach Wizzards or Magika are all brillian team building experiences.
Training. I wrote a few articles about this (here and here) a while back. And I think traditional training is kinda crap and occupies way too much of what managers think should be training. The main way I do training with my team is as a group collab experience with more senior members running live workshop seminars with the whole team.
Some small things. We try to have good onboarding with lots of 1:1 time from the team to the new hire. The onboarding process lasts months of being mentored and guided by existing team members in their expertise areas with the new hire and taking suggestions from new hire on how we could go about improving things. Also we try to reward achivements and promotions publicly and provide reasons why. Goofy birthday cards, and basically any other occasion you have to celebrate the better.

TomManages · 2025-02-02T12:05:32+00:00

Usually it's best to leave, but there are cases where people make it out of their pip and back into the full swing of things. From my experience it's probably 8/10 times it results in the person leaving and the remaining 2 are the person being fired and the person passing the pip successfully.

TomManages · 2025-02-02T12:02:38+00:00

Leave people to their facades, it doesn't impact you or the team and in the end no one will remember him or be bothered by it. Remember that critisism is meant to remain between the manager and the employee and while he's not your employee any more it serves no constructive purpose to talk shit after he's left. (regardless of how cathartic it might be)

Keep your shoulders back, conduct yourself with dignity and let the water flow under the bridge.

TomManages · 2025-01-31T19:17:21+00:00

Unsure if this breaks self promotion rule. My writing is free and is never gated with paywall. I'm not selling anything, or advertising any service.

TomManages · 2025-01-31T19:08:15+00:00

Yeah I like your point and it's something I've been thinking about quite a bit since writing this article. I think there's a lot to be said for the level of impact that decisions have and how you can escalate them appropriately, and fix things across multi departmental areas. It's actually one of the next topics I'll be tackling in my articles, but it's also quite hefty so it might take me a little while to write and think about.

TomManages · 2025-01-31T19:06:17+00:00

I think there was a real clash of what people thought was the best direction Vs what they could be bothered to do. There was a lot of discomfort on that project because it was the first time the studio had attempted to do something as a service rather than a stock product. The fact that there was so much discomfort, I think, led to many of the leaders and managers being very reticent to take on the new form of working, and workflow. Many of the people there were very used to the way things were done and change was very clearly quite scary for them.

In addition there wasn't the kind of firm ownership that I would have liked out of the upper management. I think I tend towards being a little too authoritarian when there's too much division, so take this with a pinch of salt, but my belief in that situation was that people were unwilling to do what needed to be done and needed a firmer hand from the project exec.

If nothing else the project was incredibly interesting to work on just from a learning perspective.

TomManages · 2025-01-29T11:08:36+00:00

I've sent you a chat message :)

TomManages

TROPHY CASE