2

This question already has an answer here:

I've recently been promoted to a management position in a medium-sized digital agency. One of my first tasks will be either to make two members of the development team more productive or fire them.

Both of them are technically brilliant but they have a lot of trouble delivering working functionalities. Many times they waste account managers time by sending over things that they say are done and tested, when they clearly aren't even looked at properly (e.g. A form that handles simple data and doesn't submit or leads to a PHP error). They are also really bad in communicating and sometimes have a bit of an attitude.

If I do help to decide to fire them, this may cause a ripple effect on the rest of the team, as everyone's been there for quite a while. To be honest I believe that's what I'm more hesitant about.

For anyone who had to handle this sort of situation, how did you go about it?

PS: This is not a "What should I do" question. I'll draw my own conclusions after analysing other people's experience in similar situations. I just feel it's better to have a second opinion from other people who've been there.

|improve this question

marked as duplicate by gnat, Dukeling, mcknz, Michael Grubey, Mister Positive♦ Jul 17 '17 at 11:39

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 2
    This is a Q&A site, not a discussion forum where people tell stories. It's probably better to just ask "what should I do". – Dukeling Jul 15 '17 at 20:36
  • I've had a question put on off-topic due to asking "What should I do?". Forum rules also refer to this. – user932132 Jul 15 '17 at 20:37
  • 2
    I take it you're not a developer? Something can be well-tested on one machine but not even run on another, or something seemingly obvious can get missed despite a good chunk of testing. If you're expecting to receive first-attempt bug-free code, especially on a tight schedule, you're bound to run into problems. People typically have QA departments. How are these issues typically resolved? What reasons do they give for the things not working? Does "bad at communicating" mean "explains things in a highly technical manner that the rest of us don't understand" or do they just not say much? – Dukeling Jul 15 '17 at 20:49
  • 6
    How are these clowns brilliant? – Kilisi Jul 16 '17 at 8:26
  • @Dukeling I am indeed a developer. Answering to your questions: 1. Don't have a QA department - these issues aren't very well handled tbh as things go back and forth until they work, which makes a huge loss of time by both the dev team + account managers and sales 2. For what I've seen, the reasons they use for things not working are throwing in technical jargon, saying the project brief is not good enough, etc. 3. Bad at communicating means both of what you said. Too much tech jargon plus not really being honest in questions like "How much will this take?" Thanks – user932132 Jul 16 '17 at 11:22
20

Programmers that don't deliver at least slightly reliable code aren't brilliant, no matter how accomplished they are within their technical skill niche.

Creating software for money comprises several complementary skills, and having intimate knowledge of a programming system is only one of them. Therefore, by all means try to improve their contribution to your business value, but if they don't improve and cite technical knowledge as an excuse for not getting things done, they shouldn't be here and you should fire them.

|improve this answer
  • 6
    In all fairness I would say that he needs to set a standard that says "Do not bother submitting work unless all these things are done. It's a veritable cliche where a programmer builds a brilliant engine, is obliged to show it to management so they do a 5-minute job of horking on a slapdash UI, which sucks of course, and management transfixes on the duff UI and misses the underlying quality altogether. – Harper Jul 16 '17 at 3:26
  • +1 Additionally, in my experience often the perceived brilliance is not so shiny when you look closer at the code. – tymtam Jul 17 '17 at 5:54
7

"Many times they waste account managers time by sending over things that they say are done and tested, when they clearly aren't even looked at properly (e.g. A form that handles simple data and doesn't submit or leads to a PHP error). "

Well, that isn't the sign of a "brilliant" developer.

I have had the pleasure to work with one developer who was genuinely brilliant, and also troublesome. He would do things that were highly beneficial for the company, whether that was what his manager asked for or not. The company figured out that they would tremendously benefit from letting him do what he wanted to do. As I said, genuinely brilliant. (And being a genuinely nice person helped).

But this guy would never tell you "this is done" and then it turns out he didn't even look at it. That's not brilliant. If you don't deliver, you're not brilliant.

So have a serious talk with them, and tell them that they need to up their game. If they feel that requirements are not precise, then what a professional developer does is go back and make sure the requirements are made precise before they start work.

|improve this answer
1

If you have a test team then that should be a check and balance to this. The developer testing their own code and saying it's good is a great way to develop buggy products. Make it mandatory that all functionality be tested by a SQA person and if you don't have any of those (might want to hire some) then at least tested by another developer unrelated to the code. If your looking for quality having a single point of failure whether that is a genius or not is a bad way to operate a software company.

This should prove if they can adapt to improve code or not. You set the deadlines and stipulate successful test passage of the product in order to complete the task and they either hit it or they don't. If it fails 30 times and they finally make it, then next time expect <30 times and so on until it's acceptable. Either they start producing quality functionality or you fire them with objective proof that others deliver but they don't.

This should be a product quality improvement with an objective goal. They either hit the goal or they are gone, just set the timeline expectation. Also you want your other developers to do this too as an over all process improvement and not single out just those poor performers. If the others write good code like you imply they should have no problem hitting the mark and the extra testing will only help to take their good products to a better one.

|improve this answer
  • @JoeStrazzere True, but the other person already has "poor quality code" and based on the post doesn't seem to have QA in place really. Every project has to start somewhere and having at least a measure of quality is better than none at all. Having someone who is focused on quality only helps promote that across the board. This post is attempting to meet the person where they are and not give them a perfect world situation. If they don't want to fire the developers who are not writing quality then they need a way to keep them in check. Thus the answer... – mutt Jul 16 '17 at 14:39
  • @JoeStrazzere My point is based on the post, QA is missing. That may be incorrect, but it read like a dev manager trying to improve some code that is from dev to management with no testing or quality at all. The point is that "there is no QA manager to accept the code or not" involved. Not sure where you are getting that there is already a process with QA in it from the other person's post? It sounds basically like its the developers directly to management in which case there is no second party check...also why I said if they don't have QA to at least get another developer to test it. – mutt Jul 17 '17 at 2:46
1

It sounds like you've got a couple of great problem solvers who don't care too much for detail (e.g. they lack discipline). In my own experience, these types of engineers are let go eventually as they ultimately hinder team productivity.

You could always try to inject/enforce engineering practices to get around this, like unit testing, test driven development, etc, but these are hard to get buy in from whole teams. You'd have to throw out some feelers to see if the team overall is receptive to these practices and go with the flow.

Besides that, it would be best to have an open talk about these issues and come up with a solution to address these problems together. From your perspective, they are not delivering quality solutions for the company, but perhaps from their perspective, there lies an issue that needs to be resolved as well. Now that you are manager, it's your responsibility to resolve these kinds of problems the best you can before you decide to make the tough decision to let go members of your team

|improve this answer
0

No, I don't think anyone should get fired because the feature was incomplete or broken, it's the side effect of other issues in your organization/department.

It depends on your teams structure and the delivery process itself. My suggestion is to discuss the situation with the team and what they propose to reduce the waste. (any work that gets rejected is a waste).

Things to tackle:

  • Make the definition of done clear and get buy-in from the team. (unit tests, acceptance tests, green build, ...)
  • Encourage pairing and other XP programming practices.
  • Encourage team members to hold each other accountable. (Not blaming each other!)
  • Engage the team in regular meetings with possible stakeholders. Ask the team and stakeholders to openly express their concerns without blaming each other.
  • Focus on user stories to have clear acceptance criteria. Ask the team to challenge those before committing to it.
  • Are estimations realistic?
  • Is the goal and usefulness of the feature understood by the team?
  • Is there any hand-offs in development process? (like QA, ...) if there is consider removing them.
  • Is there automated build and test pipelines? Introduce one if not there.
  • How is the test coverage for unit tests? Encourage team to keep it above 95% (occasionally you may have different level for different products)
  • How is the Integration/User tests? Try BDD, every feature that's being developed should have accompanying test (not unit test) to be considered done.
  • If they are trying to move too fast slow them down and make sure they understand the work that goes back and forth is only waste of everyones time and energy.
  • Build visualization boards and show daily statistics on how many features are green (complete) or red (rejected)
  • Visualize WIP and make sure each person works on one single task (at most) at any given time.
  • Visualize the lead and cycle time of the stories. And

Study more on Lean and Agile practices and improve continuously.

|improve this answer

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