Hi,
I work for an independant studio, and as is the case with most independant studios, hiring and keeping seniors can generally be a big challenge. Keeping them happy is not significantly harder than juniors per se, but they obviously have different needs. My intent is not to falsely generalize here, but let's be honest, a lot of seniors have families and thus require family insurances and certain things independant studios may not necessarily provide or be on par with larger studios.
The strategy of many independants is to invest in order to either get these seniors or compel them to stay, but this comes with a cost you cannot spend someplace else.
This is not the approach that I seek to follow. I feel that a studio needs to organically mature of its own accord.
Also, I am strongly turned off by my personal experience of larger companies where personal advancement appears nearly impossible and would be willing to encourage the promotion of resources from within the studio rather than draft from the local or even international population.
As you can imagine, I'm the kind of guy that plays NHL(insert year here) and draft my recruits carefully and follow their training closely. I'm more inclined to try to help my juniors get to the next level than go for that superstar. They certainly won't become seniors overnight, but might reach a better level of maturity, acquire more practical skills and develop their attitude.
Some will argue that experience is time, but while I agree partly (you get confronted to more and more situations) a lot of people don't make most of the time they're given, and they don't justify the experience they have whereas some juniors or veterans exhibit remarkable attitude, practical skills and maturity.
The question I'm trying to articulate is this: how do you help people making the most out of the experiences they are facing in order to turn it into efficient work experience?
The endgame that I seek to attain is to help my team (especially the leads) to become better at what they do, not from a technical standpoint (they know a lot more than me) but in every facet of production that can hardly be written on a job description. I want them to acquire the same attitude and become mentors for their crew. Basically, I seek to establish an enterprise culture that favors the development of the developers.
I realize that there may not be a lot of industry veterans around to help me answer this, but anything could really help, even if its just from personal experience, on how you felt you had your "I've just moved forward" moment.
Thanks for reading this far.
Seniority, and how to get there
I think the answer boils down to experience.
People need to have a vast set of experiences in different situations to draw upon to make good decisions in any field. This may feel like a cop-out answer and something that you can't affect but in fact you can help your team gain experience by providing them opportunities. It might be the opportunity to make a decision, or learn a new piece of tech. It might end up being a success or a failure but either way they'll have more data to draw upon the next time they're in a similar situation. It's a fine line between letting a young team run off and fall flat on their face and providing them with enough guidance and freedom to be pointed in the right direction while still making their own way.
One thing that you need to keep in mind is that not everyone can make it to the next level. Some people are bound to stay as junior contributors even as their tenure increases. That's just a fact of life and isn't a failing on your part. Not everyone will take an opportunity and run with it.
People need to have a vast set of experiences in different situations to draw upon to make good decisions in any field. This may feel like a cop-out answer and something that you can't affect but in fact you can help your team gain experience by providing them opportunities. It might be the opportunity to make a decision, or learn a new piece of tech. It might end up being a success or a failure but either way they'll have more data to draw upon the next time they're in a similar situation. It's a fine line between letting a young team run off and fall flat on their face and providing them with enough guidance and freedom to be pointed in the right direction while still making their own way.
One thing that you need to keep in mind is that not everyone can make it to the next level. Some people are bound to stay as junior contributors even as their tenure increases. That's just a fact of life and isn't a failing on your part. Not everyone will take an opportunity and run with it.
1. Some will argue that experience is time, but while I agree partly (you get confronted to more and more situations)
2. a lot of people don't make most of the time they're given, and they don't justify the experience they have
3. how do you help people making the most out of the experiences they are facing in order to turn it into efficient work experience?
... (especially the leads) ... in every facet of production that can hardly be written on a job description. I want them to acquire the same attitude and become mentors for their crew.
1. There's no magic. It does take time.
2. Those people won't advance as quickly. There's no magic for them. They need time, and that might not even do it.
3. Crazy idea? Give each one a week being in charge of, say, the whole project -- producer for a week (or a month). Or maybe president for a week, or a month. Those who can, will grow.
Author
I'm perfectly ok taking risks to help them learn, we always have "less critical" projects in the pipeline so I'm ok empowering them. Recently, we've put a long-term lead QA in the shoes of an assistant producer as she had expressed interest in that carreer path and that felt better than sending her to university getting a management degree.
What I'm struggling with is that I feel that what you're saying is true, but its "theory". I'm trying to find practical ways to do this and they do not jump at me (I'm not a senior myself, so I need to learn as well).
One of the "bigger plans" I've put into motion is getting a bit more SCRUM/Agile, so that people need to commit to sprints, not so we can tell them they've failed their sprints, but so they can learn to better evaluate the tasks and see the outcome of that (how off they were, etc).
What I'm struggling with is that I feel that what you're saying is true, but its "theory". I'm trying to find practical ways to do this and they do not jump at me (I'm not a senior myself, so I need to learn as well).
One of the "bigger plans" I've put into motion is getting a bit more SCRUM/Agile, so that people need to commit to sprints, not so we can tell them they've failed their sprints, but so they can learn to better evaluate the tasks and see the outcome of that (how off they were, etc).
I am right now a the brink to become a senior* developer in a small company, so here is my opinion about it. I work at a quite small company that is currently in a huge upward swing in terms of hiring people, selling products and growth in general. The growth in itself is a major factor in being able to have seniors and juniors at all. When I started at the company we were just a team of equals with different fields of experience in the development team and there was little need for any kind of internal hierarchy, but with more (and younger) people on board this changes now. Since I am there longer and have more experience I gradually grew into a new role by coaching newer and younger team-members and also by accepting broader responsibilities. And of course being a more central part of the company-machine gives me more job-security which for me (and especially for people with families) grew more important as I get older.
So how do I think I qualify for seniority: As the others stated, It took time and effort for me to get there. A lot of time and effort. Before I started with this company I already had finished my engineers degree leaning strongly towards software development and computer graphics and some five years work experience. Apart from the technical skills I gathered experience in handling people while organizing educational ("boot-") camps for future scout leaders as well as being an officer in the civil defense.
In the end I think a lot depends on personal attitude whether you will advance to senior developer or not. However some people are happy without the extra responsibilities.
* Of course the border to seniority is very fuzzy so my situation might not apply to other people and companies. So what we consider "senior" here might just be an "experienced junior" in an other place.
So how do I think I qualify for seniority: As the others stated, It took time and effort for me to get there. A lot of time and effort. Before I started with this company I already had finished my engineers degree leaning strongly towards software development and computer graphics and some five years work experience. Apart from the technical skills I gathered experience in handling people while organizing educational ("boot-") camps for future scout leaders as well as being an officer in the civil defense.
In the end I think a lot depends on personal attitude whether you will advance to senior developer or not. However some people are happy without the extra responsibilities.
* Of course the border to seniority is very fuzzy so my situation might not apply to other people and companies. So what we consider "senior" here might just be an "experienced junior" in an other place.
Author
First off, apologies Tom, I hadn't seen your reply sooner (we've replied barely 1 minute apart...)
I'm definitely not trying to cheat the curve here and I understand that time is required, but the situation has evolved in such a way that actions need to be taken:
Over the last few years, programmers (for example) have really grown in their own fields of expertise (which is, well, programming) but not necessarily in other fields.
The idea here is that I'd like to get some of them to become better at leading a team (obviously, not everyone is suited for that, but I doubt absolutely none of them have that kind of aptitude).
Similarly, I'd like for some of them to become more efficient with visuals, gameplay, etc perhaps become specialists in their own fields. Right now, they're pretty much generalists, and we're having issues with certain pipelines we're trying to establish (art integration, animation, etc).
So its not so much making them learn "faster" as allowing them to evolve in different ways.
President might be overkill, but it could be a fun experiment (I just don't have the clearance to do that, obviously). Producer is actually something we've done with a few resources just to see where they stand, what kind of mistakes they make and if they're producer-acceptable mistakes (we all make mistakes, we just seek to avoid rookie ones). For the most part, it works ok.
Just thought I'd point out, though I'm working for an indie, its actually a couple hundreads people large and growing considerably fast. Thus, at this stage, seniority becomes an issue to me that needs to be acted upon.
There is no disputing that, but I'd say we have perhaps a bit of an H.R. problem if the majority of our resources have this mindset. I don't think a studio can grow if everyone aboard the ship is quite content with where they stand right now, not looking ahead.
That's another problem too. One of my previous studios simply said "you're senior if you have 10 years in the field and have shipped at least one title on each of the platforms we're delivering on" (fyi, that meant: mobile (unity), ios, ps3, xbox360, pc, as3/web, facebook).
To me that's a lame attempt to make something vague more concrete but less accurate. You could technically linger in the field for 10 years, be transfered to each and everyone department of your studio and deliver crappy projects and still be considered senior by these standards.
I'm definitely not trying to cheat the curve here and I understand that time is required, but the situation has evolved in such a way that actions need to be taken:
Over the last few years, programmers (for example) have really grown in their own fields of expertise (which is, well, programming) but not necessarily in other fields.
The idea here is that I'd like to get some of them to become better at leading a team (obviously, not everyone is suited for that, but I doubt absolutely none of them have that kind of aptitude).
Similarly, I'd like for some of them to become more efficient with visuals, gameplay, etc perhaps become specialists in their own fields. Right now, they're pretty much generalists, and we're having issues with certain pipelines we're trying to establish (art integration, animation, etc).
So its not so much making them learn "faster" as allowing them to evolve in different ways.
3. Crazy idea? Give each one a week being in charge of, say, the whole project -- producer for a week (or a month). Or maybe president for a week, or a month. Those who can, will grow.
President might be overkill, but it could be a fun experiment (I just don't have the clearance to do that, obviously). Producer is actually something we've done with a few resources just to see where they stand, what kind of mistakes they make and if they're producer-acceptable mistakes (we all make mistakes, we just seek to avoid rookie ones). For the most part, it works ok.
I am right now a the brink to become a senior* developer in a small company, so here is my opinion about it. I work at a quite small company that is currently in a huge upward swing in terms of hiring people, selling products and growth in general. The growth in itself is a major factor in being able to have seniors and juniors at all. When I started at the company we were just a team of equals with different fields of experience in the development team and there was little need for any kind of internal hierarchy, but with more (and younger) people on board this changes now. Since I am there longer and have more experience I gradually grew into a new role by coaching newer and younger team-members and also by accepting broader responsibilities. And of course being a more central part of the company-machine gives me more job-security which for me (and especially for people with families) grew more important as I get older.
Just thought I'd point out, though I'm working for an indie, its actually a couple hundreads people large and growing considerably fast. Thus, at this stage, seniority becomes an issue to me that needs to be acted upon.
In the end I think a lot depends on personal attitude whether you will advance to senior developer or not. However some people are happy without the extra responsibilities.
There is no disputing that, but I'd say we have perhaps a bit of an H.R. problem if the majority of our resources have this mindset. I don't think a studio can grow if everyone aboard the ship is quite content with where they stand right now, not looking ahead.
* Of course the border to seniority is very fuzzy so my situation might not apply to other people and companies. So what we consider "senior" here might just be an "experienced junior" in an other place.
That's another problem too. One of my previous studios simply said "you're senior if you have 10 years in the field and have shipped at least one title on each of the platforms we're delivering on" (fyi, that meant: mobile (unity), ios, ps3, xbox360, pc, as3/web, facebook).
To me that's a lame attempt to make something vague more concrete but less accurate. You could technically linger in the field for 10 years, be transfered to each and everyone department of your studio and deliver crappy projects and still be considered senior by these standards.
I'm considered a "senior" at my work place, but I don't know if I really embody the meaning of the title. Certainly, I'm no newbie to software development, but at the same time, I don't have the decades of hard earned experience which the title implies. My recommendation is to stop being concerned about titles (which are meaningless and can be given out like candy), and be more focused on developing a rich and deep skill set. Pretty much every software project goes through a software development life cycle and needs someone to take ownership of the project (usually project manager, but that sometimes falls on the developers shoulders). To be a "senior" developer, you'd have to demonstrate a mastery of each phase of the software development process (requirements gathering, architecture, design, construction, testing, deployment & integration, training and maintenance.). You'd also have to develop a habit of introspection. How is the project going? how am I doing with regards to the work on it? What can I do to work more efficiently? what can I learn from my past mistakes and what can I do to avoid them in the future? what methods and processes are others using effectively? can I incorporate those methods and processes into my own business practices?
My most recent project failure was a good source for learning and introspection. The project failed in post production because there wasn't an integration plan for how the organization would change business processes. We gathered the requirements, designed the solutions to meet the reqs, constructed the product and tested it, but because there wasn't a plan to actually get people to change their processes and migrate to the new system, it failed to launch. We should have started talking about this right away in the planning phase of the project and gotten some sign offs to build buy in from all the stake holders.
Anyways, experience != time. Experience == mistakes made and learned from.
The best thing you can do is encourage people to be introspective about what lead up to a mistake and try to learn from it. Make it an org culture value and build ways/means to share that knowledge within the org (forums, wikis, weekly email distro lists, etc). That way, everyone benefits from the mistake rather than an individual.
You've decided to make one of your staff members an associate producer rather than sponsoring university education. I think that's a good move since OJT is far more relevant and valuable. If your associate producer makes a $1,000 mistake, that's just the cost of training one person. However, if you disemminate the lessons learned from that mistake to 10 people on the team, then it lowers the training cost to $100 per head. Financially, it makes sense to share mistakes made.
Also, that brings up a very difficult problem to solve: Getting people to admit to making mistakes. That's going to be a organizational culture issue to solve. If people are discouraged from screwing up (to maintain an aura of professionalism & expertise in their field), then your org as a whole will suffer and probably pay $1,000/head for the same mistake. That'll amount to a nice $10,000 training cost in my previous example.
My most recent project failure was a good source for learning and introspection. The project failed in post production because there wasn't an integration plan for how the organization would change business processes. We gathered the requirements, designed the solutions to meet the reqs, constructed the product and tested it, but because there wasn't a plan to actually get people to change their processes and migrate to the new system, it failed to launch. We should have started talking about this right away in the planning phase of the project and gotten some sign offs to build buy in from all the stake holders.
Anyways, experience != time. Experience == mistakes made and learned from.
The best thing you can do is encourage people to be introspective about what lead up to a mistake and try to learn from it. Make it an org culture value and build ways/means to share that knowledge within the org (forums, wikis, weekly email distro lists, etc). That way, everyone benefits from the mistake rather than an individual.
You've decided to make one of your staff members an associate producer rather than sponsoring university education. I think that's a good move since OJT is far more relevant and valuable. If your associate producer makes a $1,000 mistake, that's just the cost of training one person. However, if you disemminate the lessons learned from that mistake to 10 people on the team, then it lowers the training cost to $100 per head. Financially, it makes sense to share mistakes made.
Also, that brings up a very difficult problem to solve: Getting people to admit to making mistakes. That's going to be a organizational culture issue to solve. If people are discouraged from screwing up (to maintain an aura of professionalism & expertise in their field), then your org as a whole will suffer and probably pay $1,000/head for the same mistake. That'll amount to a nice $10,000 training cost in my previous example.
Author
My recommendation is to stop being concerned about titles (which are meaningless and can be given out like candy), and be more focused on developing a rich and deep skill set
My post was written from the perspective of senior == acquiring practical experience (not the title per se). When I refer to seniors, I have a very loose definition in mind, but it does not adequate with a title. Thanks for underlining this though!
To be a "senior" developer, you'd have to demonstrate a mastery of each phase of the software development process (requirements gathering, architecture, design, construction, testing, deployment & integration, training and maintenance.). You'd also have to develop a habit of introspection. How is the project going? how am I doing with regards to the work on it? What can I do to work more efficiently? what can I learn from my past mistakes and what can I do to avoid them in the future? what methods and processes are others using effectively? can I incorporate those methods and processes into my own business practices?
I understand this. The idea is how to practically get people to get 'there', or help them get there if this is their goal.
I've recently conducted informal interviews with some of the develops to probe the actual candidates that were looking for bigger responsibilites, and cross-referenced this with those that I believed were willing to do more (had potential and the will to work harder). I now have a shortlist of people that I believe are a good fit for the next level.
My most recent project failure was a good source for learning and introspection. The project failed in post production because there wasn't an integration plan for how the organization would change business processes. We gathered the requirements, designed the solutions to meet the reqs, constructed the product and tested it, but because there wasn't a plan to actually get people to change their processes and migrate to the new system, it failed to launch. We should have started talking about this right away in the planning phase of the project and gotten some sign offs to build buy in from all the stake holders.
I've started to put more emphasis on post-mortems in general. They 'were' in the company's culture, as everyone usually got their say in it, but no one actually ever consulted them. As a result, there was simply no archive for them, nor any quick reference guides of any sort. I'm considering building a bit more structure around project startups (defining requirements phase more specifically, where I would have teams consults on previous post-mortems that are related to the project at hand).
The best thing you can do is encourage people to be introspective about what lead up to a mistake and try to learn from it. Make it an org culture value and build ways/means to share that knowledge within the org (forums, wikis, weekly email distro lists, etc). That way, everyone benefits from the mistake rather than an individual.
I'm looking for a practical way to do this. I don't see the 'where I've failed this week' being a totally constructive element to add to a company, even if it does encourage introspection. I've discussed with team mates, and we've come to the conclusion that to promote forums, wikis, etc does not make people pay more attention unless they feel specifically drawn to them. We have fairly documented wikis just sleeping about.
Also, that brings up a very difficult problem to solve: Getting people to admit to making mistakes. That's going to be a organizational culture issue to solve. If people are discouraged from screwing up (to maintain an aura of professionalism & expertise in their field), then your org as a whole will suffer and probably pay $1,000/head for the same mistake. That'll amount to a nice $10,000 training cost in my previous example.
That's a good point you've got right there, and let's be honest, in game development business, a lot of people are scared for their jobs (at least, in the studios I've been). A lot of people won't speak up their own failures by fear of losing their jobs, yet, the most seniors members are those that admit to it.
A recent example from a particularly mature developer went along these lines:
(Code review)
Senior: That code is total bullshit.
Junior (scared): Actually... that's the part you did on the engine like a year ago...
Senior: I know, I get to make epic crap too.
(Lovely!)
[quote name='slayemin' timestamp='1347021346' post='4977600']
The best thing you can do is encourage people to be introspective about what lead up to a mistake and try to learn from it. Make it an org culture value and build ways/means to share that knowledge within the org (forums, wikis, weekly email distro lists, etc). That way, everyone benefits from the mistake rather than an individual.
I'm looking for a practical way to do this. I don't see the 'where I've failed this week' being a totally constructive element to add to a company, even if it does encourage introspection. I've discussed with team mates, and we've come to the conclusion that to promote forums, wikis, etc does not make people pay more attention unless they feel specifically drawn to them. We have fairly documented wikis just sleeping about.
[/quote]
There's a couple possible issues:
-It could just be a presentation problem/language problem which would make it a hard sell. Rather than calling it "where I've failed this week" (which sounds negative), call it "Valuable lessons learned" and put the dissemination into a format which allows it to be shared with other team members (informal, short meeting? A newsletter? email distro?)
-The second issue sounds like a problem of buy-in and usefulness. You can create the perfect framework for sharing lessons learned, but if the users think its bullshit, then thats what they'll post (buy in problem). Then, other users will read these baloney posts and think that's the standard/norm and won't get much out of it, and conclude that the usefulness is not there, and the problem will become self-perpetuating. It's not a systematic problem, but a perception and use problem! The best way (at least, what I've found) to build buy-in and usefulness for a product is to get the end users to build and use the system. Let your team figure out what has the best cost vs. benefit ratio for their needs. Your job is to inspire the need to improve processes -- get the horse thirsty, then it will drink the water!
[quote name='slayemin' timestamp='1347021346' post='4977600']
Also, that brings up a very difficult problem to solve: Getting people to admit to making mistakes. That's going to be a organizational culture issue to solve. If people are discouraged from screwing up (to maintain an aura of professionalism & expertise in their field), then your org as a whole will suffer and probably pay $1,000/head for the same mistake. That'll amount to a nice $10,000 training cost in my previous example.
That's a good point you've got right there, and let's be honest, in game development business, a lot of people are scared for their jobs (at least, in the studios I've been). A lot of people won't speak up their own failures by fear of losing their jobs, yet, the most seniors members are those that admit to it.
A recent example from a particularly mature developer went along these lines:
(Code review)
Senior: That code is total bullshit.
Junior (scared): Actually... that's the part you did on the engine like a year ago...
Senior: I know, I get to make epic crap too.
(Lovely!)
[/quote]
Here are some articles you might find useful:
Failing quickly
Fail Early, Fail Fast, Fail Quickly
Here is a philosophy I've adopted:
"An idiot will never learn from their mistakes and is doomed to repeat them.
A smart man will learn from their own mistakes.
A genius will learn from the mistakes of others."
So, ideally you'd want members of your organization to share their mistakes/failures and how to avoid them so that other people will not repeat them. It's a tough mental block for organizations to overcome and for people to personally overcome because failure is stigmatized and associated with incompetence. You should try to remove the threat on a persons job/livelihood based on failure rates, and instead tie it to deliverables output. (The only failure which is punished is consistent failure to deliver on time! (which itself may be a systematic project management/oversight problem as well!))
On a slight tangent: I play chess quite a bit. I used to be very concerned about losing games, so I'd get anxious about playing someone equal or better than me because the possibility of losing was frightening for my ego. I'd put extra mental effort into each move and decision to avoid losing the game. However, once I started playing chess every weekend for five years straight, I had lost so many games that I just stopped caring. Losing lost its sting. I got used to it. So, I just started putting in lots of time into getting good at playing the game, trying out interesting ideas and risky moves. It turned into a casual hobby which I got very good at (I once won 15 games in a row against three skilled opponents). The same thing happens in other games which I play competitively (Starcraft 2 ladder). The trick is to handle loss/failure as "no big deal" and just analyse the first error (which usually cascades in effect) and train yourself to avoid repeating it. The most important aspect is to put in a lot of time and effort into improving (or training, as athletes see it).
Since you're running a game dev company, it may be a good team building exercise to spend time playing games competitively with each other and using it as a way to disseminate a positive culture for handling failure, learning from mistakes, and fostering a mentorship mindset. Ideally, your team members would say "When I tried this strategy/technique/move, it failed. What did I do wrong and how can I avoid it in the future?". That kind of attitude towards failure can translate nicely into work. "When I tried this design pattern/algorithm/method, it failed. blah blah blah, please help me." or "When we used XYZ marketing technique, it had this effect which didn't meet our expectations (fail). blah, blah, blah, please help."
Author
-It could just be a presentation problem/language problem which would make it a hard sell. Rather than calling it "where I've failed this week" (which sounds negative), call it "Valuable lessons learned" and put the dissemination into a format which allows it to be shared with other team members (informal, short meeting? A newsletter? email distro?)
I can see this being interpreted as 'childish' for some of our developers. We don't just have juniors, there are a few seniors too, and how exactly do you draw the line? It would be judgmental to bring in people under 3 years and keep everyone else out because, there is just no radical line here that can be traced without hurting people's feelings I feel, and yet, some people will just get offended to be or not be a junior/senior.
I really like the idea of hosting some kind of a discussion about something that has been learned this week, but it feels either like kindergarden or a therapy group, and I'm looking for a more organic way to integrate this.
I've actually managed to raise quite the bar on post-mortems, but these occur only after a final delivery. I know some do end of sprint post-mortems, but I'm affraid I don't have all that much latitude with how much time I can consume with something like that (it is a hard sale for upper management).
So, ideally you'd want members of your organization to share their mistakes/failures and how to avoid them so that other people will not repeat them. It's a tough mental block for organizations to overcome and for people to personally overcome because failure is stigmatized and associated with incompetence.
Unfortunately, I'm not at liberty to remove that threat. It is very real, and higher management might not understand the impacts and ramifications of that, but they still need to run the business, and I can relate to some of these decisions. The downside is that, obviously, some other people onboard will feel concerned. That said, this isn't a terror-climate type of studio, so there is some latitude I can use there, I'm just not at liberty to alter the culture altogether.
(The only failure which is punished is consistent failure to deliver on time! (which itself may be a systematic project management/oversight problem as well!))
There's also always repeating the SAME mistake, which inherently means you haven't learned from your own mistake...
On a slight tangent: I play chess quite a bit. I used to be very concerned about losing games, so I'd get anxious about playing someone equal or better than me because the possibility of losing was frightening for my ego. I'd put extra mental effort into each move and decision to avoid losing the game. However, once I started playing chess every weekend for five years straight, I had lost so many games that I just stopped caring. Losing lost its sting. I got used to it. So, I just started putting in lots of time into getting good at playing the game, trying out interesting ideas and risky moves. It turned into a casual hobby which I got very good at (I once won 15 games in a row against three skilled opponents). The same thing happens in other games which I play competitively (Starcraft 2 ladder). The trick is to handle loss/failure as "no big deal" and just analyse the first error (which usually cascades in effect) and train yourself to avoid repeating it. The most important aspect is to put in a lot of time and effort into improving (or training, as athletes see it).
I can totally relate here. I was ranked Diamond on Starcraft 2 Ladder a while back, and it took me everything to muster the courage to play a game. The fear of losing was to elevated that I just waited until I was into my best state of mind with nothing around that could potentially disturb me. It felt like I was going into an interview everytime. Pretty much the same with chess: I'm a competitive kind of guy when it comes to these games.
Since you're running a game dev company
No, not running, I've been gently asked to assist developing better practices.
it may be a good team building exercise to spend time playing games competitively with each other and using it as a way to disseminate a positive culture for handling failure, learning from mistakes, and fostering a mentorship mindset
This is hard to implement. For starters, not every developer is a gamer. We have a lot of people that don't actually play games, but their skillsets are required. Also, not all people agree on types of games they want to play (obviously). Also, this is a large office, with masses of people. It is hard to coordinate this across the board. The best I could come up with is small-team gaming, and even so, the first issue soon resurfaces. In a unit of say, 9 people, very few of them actually share any interest in terms of gaming.
If the synergy was there, I'd employ it, but I'm having a rough time figuring out similar interests amongst peers.
There's always the option to create a 'studio-league' from the studio roster that's not directly tied to the studio itself, and get people to help one another get better. It isn't a bad idea, and I can see how some competitive games could help shape the attitude of certain people. That said, we're not really forcing anything, and just like anything else, people will learn at their own pace, or won't learn at all if they aren't interested. I'm not exactly sure about the real output of this method.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement