up vote 15 down vote favorite
4

Today's news is that a developer hacked github. He found a vulnerability in Ruby on Rails, reported it and since nothing had happened - he was ignored and considered as a troll -, he used the vulnerability and hacked the second most famous service which uses Ruby on Rails (github).

Although, this incident has nothing to do with project management, it got me thinking; there are lot of developers who lack the necessary communication skills and they act instead of talk. I know a handful of developers who would act the same way as the guy who hacked github: they would cause harm, just to prove that they are right. Their intention is questionable for sure, but they are good at what they are doing, but they lack some useful soft skills.

So my questions:

  1. How would you help (coach) such a developer so that he won't act and will do the right thing? I used help on purpose, because firing someone is an easy answer.
  2. Let's say that you find a critical error in your customer's application, but she doesn't listen. What is your best practice to persuade her so that she'll take the problem seriously?
share|improve this question
  • 5
    @Zolt - I was going to move your very awesome question to Programmers SE as it at first seemed more relevant to that site, but at the end, you tie up your background information with two very pertinent and on-topic questions. +1 Not only does your question cover coaching, but I'm sure someone could use this topic to come up with some great questions about project risk, leadership, motivation, and more! – jmort253♦ Mar 6 '12 at 2:53
up vote 7 down vote accepted

1: First of all, make the right thing as easy to do as you can and make sure it's well understood.

In this particular instance a Github spokesman responded:

We haven’t been as clear as we should have been on how to responsibly disclose security problems, and for that I’m sorry.

Also, think about what the wrong thing would be, and consider that there may be different degrees of right thing. For instance, you could invite people to come and hack your site in a safer environment, for reward or prestige. Or you could just be forgiving to people like Egor - who didn't really cause any harm, though he could have.

I don't think it was Egor who lacked the necessary communication skills in this instance. He was providing information, for free, and the Rails community didn't have the communication skills to encourage him to share. The onus to communicate effectively is on the person who will benefit.

2: Be persuasive. Do other things to help her trust you. Tell stories about other people who didn't listen. Then, if talk doesn't work, act.

share|improve this answer
  • Still, if the person did damage, and that damage was intentional, I can't see keeping that person around. You can still like that person and still wish him or her the best, but that person has outlived their usefulness at your organization. Accidents are always forgiven, but not malice. – jmort253♦ Mar 6 '12 at 2:59
  • 1
    Meh. He broke the letter of the law. You'd have to be really, really mean to prosecute him though. He made a commit message for goodness sake. – Lunivore Mar 6 '12 at 6:14
  • 1
    I'm wondering what Egor has learnt form the story. What will he do differently next time. Honestly, I've never heard about hime until yesterday, but he may not publish his findings next time. I think we should keep him around, because nobody cared about this critical issue - which was published in 2008 -, and show him a less harmful way of raising voice. I see this a manager/coach challenge. – Zsolt Mar 6 '12 at 20:27
  • 1
    After reading more about what happened, there is a lot of good that came out of what this guy did. He may have saved companies a lot of revenue who rely on GitHub and who could have lost a lot had Egor not motivated the team to fix the issue. Now, from what I understand he wasn't an employee of GitHub. If he was an employee, then I stand by my "he has to go" statement. :) – jmort253♦ Mar 7 '12 at 3:04
  • 1
    If he does it in his own time, already works for the company, and causes no harm while he does it, then it's just information. Information is one of the most valuable things you can have, and the leaders of the org don't even have the choices available to them to make without it. Additionally, if you fire him, you're actively sending out a message that people shouldn't escalate risks or use their initiative to discover them. I agree that it would be very different if he had actually done something damaging, but he didn't. – Lunivore Mar 7 '12 at 14:14
up vote 7 down vote

So the developer felt ignored when he escalated a threat, so he showed 'em and showed 'em good? Organizations have every right to either mitigate their threats or simply accept them and continue on. It's a business decision based on threat level and costs to mitigate and other considerations. They do not need to have a risk escalator prove them wrong by making a threat with a probability that is less than certain into a reality.

Can you imagine replacing developer with TSA agent and hacking into a bomb? 'Boom!" "See, I told you!"

Fire him.

share|improve this answer
  • 1
    +1 Great analogy, and I agree with you 100%. There is no room in an organization for that behavior, and even if you kept him around, you'd likely have trust issues with that person, both from management as well as other team members. – jmort253♦ Mar 6 '12 at 2:56
  • 2
    The TSA engages in self-tests constantly. Comparing this to a bomb is hyperbole. This is the equivalent of a TSA agent sneaking in a bottle of water. – user3384 Mar 6 '12 at 9:36
  • 1
    A bit of a hyperbole. But the point was, it was not his job to test vulnerabilities. – David Espina Mar 6 '12 at 11:57
  • 2
    I agree that it wasn't his job, but nowadays those, who are willing to make that extra mile, are very rare. Unfortunately, he made two miles. He was honest, and tried to warn the community and he made his exploit afterwards. If it had been the other way around, I would fire him as well. – Zsolt Mar 6 '12 at 20:32
  • 1
    It is like gold plating. Great intentions but it usually causes issues for everyone down the road. With every product on the market there are a host of known vulnerabilities that are simply accepted. You cannot have your staff triggering them because this one threat is important to him and his feelings were hurt because management did not pay any attention. – David Espina Mar 6 '12 at 20:45
up vote 5 down vote

If I were Egor's project manager, I would consider myself to have failed Egor.

My second principle is "Communication is 100% of your (the project manager, scrum master, coach) job." This issue falls right into this maxim.

As project manager's it is our job to understand everyone on our team. In any endeavor with creative minds (software coding is definitely one of those) you are going to have brilliant people who are not good at communicating in ways that most people will follow. As project managers we can't demand that the team all talk in one syllable worded PowerPoint slides that the CEO will understand. Instead it is our job to listen to the team and translate.

I've made use of the DISC profile system for this, with great effect. In a hyper nutshell, DISC is a communication model based on people's "default" communication style. Ds are your storm the hill Generals, short, to the point. Is are your glad handing sales persons, "enough about me talking about me, why don't you talk about me". Ss are the team mom, "can't we all get along?" And the Cs are the data crunchers, "That would be illogical."

My bet is Egor would rate as a High C with High S tendencies. He's going to provide you with a twenty page written report on everything he's found wrong with Ruby. He also won't start with the point, instead he'll start at the very beginning and explain everything, step by step. Your average CEO's head would have exploded by page two.

Project managers (scrum masters, coaches) have to be better than your average CEO. We have to learn to listen in the way that our teams communicate. We have to know how to take that information and then translate it into something anyone else can understand, "Hey, CEO, loss of customer trust resulting in total revenue meltdown and negative press that will leave the company without enough money to fund your golden parachute."

If I were Egor's project manager, I would feel I had failed both my team mate and my company.

Note: This is a hyper condensed and generalized concept of DISC and communication translation. This is not a specific recommendation of action.

share|improve this answer
  • +1 for this: "f I were Egor's project manager, I would feel I had failed both my team mate and my company" – Zsolt Mar 6 '12 at 20:34
  • Although I disagree with the category boxing strategy, +1 for the same as Zsolt. PM's are the team's mouthpiece. – Andrew Clear Aug 26 '12 at 5:28
up vote 3 down vote

Question 1:

After the event, you may have limited scope to "help" the developer, especially if he has acted in any way that could be considered illegal. In such a case, the best you can hope for is to talk the issue through with the developer, show what damage has been caused to your company as a result of the developer's actions, and ask him to give his perspective on the options that are available to you. You may still have to part company with him, unfortunately, to protect yourself and your company, no matter how reluctant you may be to go down that route.

To prevent a similar situation in future, consider introducing an acceptable use policy within the company, which explicitly states that such behaviour is not acceptable and, importantly, explains why. Make sure this is communicated to all existing and employees, and that they have the opportunity to discuss this at team meetings / one-to-one sessions, or whatever feels right to you. Explain that this is to protect them as well as protecting the company, and encourage your employees to talk about the need for this. Cover this at induction sessions for new employees too.

Question 2:

I believe that the first action is to put your concerns into writing, and raise a formal project risk if that is possible. That should get her attention. Follow it up with a phone call or even a face-to-face meeting, in which you spell out the worst that could happen if the error is not fixed. At the end of the day, it is her responsibility to act to repair the fault, but you have a responsibility (which you have already recognised) to communicate this. However, having made your case as strongly as possible, and suggested solutions if you can, the final responsibility lies with the customer. You have one further decision: if the issue is so serious that it could also damage your reputation, you may wish to walk away rather than being associated with the issue, but hopefully it won't come to that, and your alternative might be to quote for a fix for the problem.

share|improve this answer

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.