2

In a software technology startup team, there is a colleague who is perceived to resist this desired workflow:

  • Use self-hosted GitHub:
    • Open issues
    • Regularly comment/update on in-progress issues
      • Specially when stuck in a problem
    • Submit pull requests
  • Provide requested APIs for developed packages
  • Follow test-driven development i.e. TDD
  • Be active in sprint talks
    • Provide agenda and talk in detail about work in-progress
  • Document your efforts
    • Seek help by sharing the progress
    • Let everybody know what you're up to
  • ...

For some reason, the colleague resists the above workflow. Trying to push the colleague has a negative effect, due to self-reported motivation loss.

By resist, I mean, he:

  • Doesn't use the workflow
  • Doesn't test
  • Doesn't provide requested API
  • Doesn't communicate regularly with the workflow tools
  • ...

The colleague is a knowledgeable one. But our guess is that he focuses too much on distracting details. For example, he starts using a tool, right after he studies its whole specification. But he doesn't need to get to know every detail.

The colleague is a student in graduate school and is very involved in academic studies.

I wonder what might be a fine method to approach him regarding our workflow?

Improve this question
10
  • Define "resists." I am not clear on how the bit about the tool is resisting.
    – Matthew Gaiser
    Commented Jun 17, 2020 at 15:07
  • 2
    How would you rate their contribution aside from the aspects you mentioned?
    – nicola
    Commented Jun 17, 2020 at 15:38
  • 2
    Have you asked him why he resists? Have you explained the reasoning behind each of the tools/workflows?
    – Benjamin
    Commented Jun 17, 2020 at 15:52
  • 1
    @user3405291 is this workflow desired? As you want to achieve it, but dont have it yet. Or is everybody else already using this? You say startup, that sounds smallish. How many people are there? And how many are using this/not using this? Is there a company culture around this, one way or another?
    – Benjamin
    Commented Jun 18, 2020 at 9:11
  • 2
    "For example, he starts using a tool, right after he studies its whole specification. But he doesn't need to get to know every detail." - have you considered whether it would be better to hire an apprentice rather than an academic student? Getting to know things inside out isn't an unreasonable habit or inclination for an academic. If you want someone who gets on with things despite an incomplete knowledge, then in general you want someone who is loath to think things through much, and is therefore likely to be less academic and will be less knowledgeable.
    – Steve
    Commented Jun 19, 2020 at 15:41

2 Answers 2

Reset to default
2

You might want to read a book or two on making change in the workplace happen. The direct order method from boss can work, but often is suboptimal: People might follow the rules to the letter, but when their spirit is not in it, productivity suffers.

Your workflow isnt the standard in the company, but has mixed adoption. Why is that? Are there force working against that? Pressure from Stakeholders to work faster and just ignore rules that means something is finished a day later? even when those rules mean saving days down the line?

Having 1 guy who resists in a company is different case to having 1 guy resist in your team, when this guy can also see that its totaly accepted in other teams to resist.

Having the same standards for everybody can be cumbersome, because some rules may make sense for some teams but not for others. But having a baseline of quality makes sense.

You mentioned that you made a Readme, that's a good start. But maybe some kick off presentation or something to get people on board is a good idea? So that people understand what problems your workflow solves.

You resisting guy is a student and has lots of things to learn. Learning all those tools on top of programming can seem daunting, I still remember that feeling! Especially when you dont understand what those tools are good for. One big difference a new developer has to learn: Developing alone and developing in a team needs different form of organizations. That takes time to see and understand!

If I were you, I would talk to him and say that this is superimportant, not for the individual alone, but for the organization as a whole. Then offer to explain and coach him on each part separately. Learning TDD takes a while, learning how to make good commits takes a while, etc... Also ask him why he resists and how you can help overcoming that.

One big obstacle to change is that people wanting change often focus to much on what they want, and to little on why others resist. I know I certainly did that in the past, and it still happens to me sometimes. But from experience I can tell you, patience, an open mind and lots of explaining can change a lot of things!

Improve this answer
1
  • Thanks! I think this answer suits my situation better =)
    – Megidd
    Commented Jun 19, 2020 at 8:36
7

I wonder what might be a fine method to approach him regarding our workflow?

If his resistance is detrimental to the projects that he works on then his manager needs to sit with him and show him how his "resistance" is hurting the project and remind him that he has to follow the established workflow or there will be consequences. If the colleague continues to refuse, he should receive the appropriate consequences.

Improve this answer
2
  • 3
    +1 If he doesn't test, and he doesn't deliver what's been explicitly asked for, then he's not just being a bit awkward or idiosyncratic; he's not doing the very basics of the job. He needs to be absolutely clear that that's not acceptable.
    – Fiora the Ferret
    Commented Jun 17, 2020 at 20:18
  • Sorry! I wish I could accept more than one answer :(
    – Megidd
    Commented Jun 19, 2020 at 8:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .