A very smart, somewhat of an alarmist, game designer just joined the team I've been assigned to.  Things are going fine enough but I'm starting to observe some patterns of behavior I would like them to correct and streamline their way of working.  For example, we run scrum for our teams and have been reactive to feedback in the community for our game.  During a backlog grooming session, we decided to shuffle some tasks around due to lack of supporting resources which included some small continuation work he was assigned to do.  He made a small scene and gave me some lip about it after I told him.  I decide that maybe we can support it, since a goal of his was tied to it.  He was going on vacation for a week and it wouldn't make sense anyways.  There have been some other times we have fallen out of dialogue in a similar fashion.  Though in the end, these situations are not that dramatic or don't matter.

Another symptom I would like him to change is his over analysis and large embellishing of design docs.  We move quickly on our game and iterate on ideas quickly.  Which means we go for the minimum viable for testing features internally.  If we get proposals from him they can be too detailed for the stage of dev and miss the mark.  He is spending time answering "what if" questions for things which may be cut.  

So it's two things: the knee jerk reaction to things he perceives not going his way and being too detailed on design at the proposal stage.  I do feel these are artifacts left over from previous jobs at publishers with maybe less than healthy work cultures and lots of front loaded planning for 3 to 4 year development cycles.  Again, this guy is really smart and capable, but I feel these little moments are holding him back and discredit him a bit.  It's hard to take someone seriously when their default response is crying wolf.

How have you approached a conversation like this with a difficult co-worker you worked with?  One who was not a direct report but you are responsible, in ways, for tailoring their output.

Agile development can be chaotic and frustrating to designers who - if they are doing their jobs well - are planning features for the future. While he needs to learn to be adaptable to changing requirements, you might consider whether it's possible to look further ahead and make sure that supporting resources are available when needed. Few features can be perfectly designed or developed in a vacuum so it helps to be seeing the big picture and giving people some assurance that the work they do today isn't going to be irrelevant or redone in 2 weeks' time.

Similarly with design docs, there is usually a compromise to be had. If design specifications are too lean then programmers either have to make guesses as to the intent (which is often wrong, and wastes time) or continually question the designer (which can distract people from their current work), plus decisions get made but not documented, which can lead to arguments further down the line, an inability to create correct test plans, "features" mislabelled as "bugs", and so on. Maybe he can be encouraged to produce a "minimum" and a "stretch goal" version of each feature. Or you just set time limits on his design tasks so that he's forced to make the necessary cuts himself. Sometimes we literally ask for a "one-pager", for example. This is unambiguous and if people deliberately ignore the requirements of a task then that is potentially something their line manager should be willing to bring up with them.

On 7/31/2019 at 4:10 PM, Tom Sloper said:

Just keep calmly pointing out to him that things are different on this project. Marge Simpson called it "gentle nagging." You say the guy is not a direct report. That means you can enlist the support of the guy's supervisor in dealing with how the guy expresses his opinions. 

Totally.  Since he sits next to me and we are developing this buddy sort of relationship; I feel there is a chance to frame this from that angle.  Everyone I work with I want to see succeed and grow.  Doing so means stretching in ways that challenge their status quo.  I feel that going to his supervisor (in this case the Lead Designer) feels like a politics maneuver.   I could keep this friendly enough with a firm backing.

My first move is to take him aside and let him know these things are worrisome and I want to see him flourish on our team.  Open the dialogue so I can get his feedback.  Of course I would loop in his lead to let him know we are chatting about this.  If it escalates or doesn't change, then I will have a bigger chat with the lead.  

On 7/31/2019 at 1:54 PM, Kylotan said:

Agile development can be chaotic and frustrating to designers who - if they are doing their jobs well - are planning features for the future. While he needs to learn to be adaptable to changing requirements, you might consider whether it's possible to look further ahead and make sure that supporting resources are available when needed. Few features can be perfectly designed or developed in a vacuum so it helps to be seeing the big picture and giving people some assurance that the work they do today isn't going to be irrelevant or redone in 2 weeks' time.

Similarly with design docs, there is usually a compromise to be had. If design specifications are too lean then programmers either have to make guesses as to the intent (which is often wrong, and wastes time) or continually question the designer (which can distract people from their current work), plus decisions get made but not documented, which can lead to arguments further down the line, an inability to create correct test plans, "features" mislabelled as "bugs", and so on. Maybe he can be encouraged to produce a "minimum" and a "stretch goal" version of each feature. Or you just set time limits on his design tasks so that he's forced to make the necessary cuts himself. Sometimes we literally ask for a "one-pager", for example. This is unambiguous and if people deliberately ignore the requirements of a task then that is potentially something their line manager should be willing to bring up with them.

I hear all of this.  I've been with the company for about a month but I see all of these artifacts of frustration from the designers.  That one feature has about 4 or 5 different design one pagers which, at the time, was a very important topic only to be left somewhere.

My push to have him focus on MVP will be a time box.  I'm glad to see its something you suggested too.  Depending on the relative size, I feel something like an hour of putting down the major beats and then follow up with a meeting with other stakeholders to weigh in could be a good answer.  

Of course this sounds ok to me, so I need to make it sound good for him too.