-2

This question is inspired by How can I learn to care less because it makes me sick? I recognize a similar scenario as described within this question. However, not with my self, but with my fellow employee.

To give some context: I work at a company which makes software. We are a team of 10 man strong, and enjoy the benefits of having a flat hierarchy. This means that besides not having a boss reigning supreme over us, we are pretty much appointed to do any step in the funnel from obtaining clients till creating and delivering the software. As an incentive, this company offers all employees options in the company once they get their permanent contract.

This team of 10 people consists of people with several backgrounds and skill levels. However, we have 1 developer which is significantly more skilled then the rest, due to his prior experiences, aka, seniority. It is worth to note that he did rich the permanent contract, and hence enjoys the benefits of options in the company.

Due to his seniority, this developer is often consulted for a lot of things. Ranging from very simple questions in regards to his knowledge, up fairly more advanced topics.

However, this very same developer has a tad of a flaw. And that is that he always feels personally responsible for everything and anything that happens within and to the team. And attempts to shelter people from any form of mistake that could be made. Ranging from making a wrong impact, to simplistic typos.

This leads to simple questions become very elaborate stories. Sometimes deviating significantly from the originally asked topic.

He feels so responsible for all of this, that he pushes and forces himself to work significant amounts of overtime for extended periods of time, to pull everything up to the very highest and best standards he can possibly imagine. And to prepare almost everything you could imagine ahead for you.

This somethings leads to scenario's where he almost builds a full framework. After which, he needs to elaborately discuss said made framework with every person in the team involved in said project. Elaborating on each and every design choice made in said framework, just to make sure we have the same high standards as him.

In the beginning everybody in the team let this slide. If he wants to dedicate spare time, who are we to stop him. All though not paid directly, it will earn him some profit through the means of options after all. However, it has reach a point where he dialogues a significant amount of time with nearly everybody in the team. Leading to a lot of close deadlines due to the time wasted on dialogues.

After consulting this colleague several times he himself also stated that he is starting to suffer, both physically and mentally. And mentioned that he is unable to let it go until everybody reaches the same high standards of quality in every part of the funnel. As an alternative he mentioned that he could also step out of every bodies cycle by no longer involving himself with any of the other projects, besides his own.

From a team perspective, his input is very valuable. Hence to fully exclude him would not be feasible. However, we would like to help this teammate to feel less obligated to the point he needs to work himself 90 hours a week.

I should mention that we have tried to talk to the person in question. And most of the things he points out are actually points of improvement that are either being applied to our way of working, or scheduled to be. He is also very aware of this, but seems to be unable to detect it as such.

Hence this question. How can we help our colleague care less? Before he works himself to the grave?

MX D
  • 1
  • @Fattie And what if there is a large project with an unreasonable deadline? Fire everyone who works harder to complete it? – Twyxz Feb 19 '19 at 13:52
  • @Fattie In this case it's not so much a programmer being slow. To put it in your surgeon perspective, it's surgeon A taking additional extra time to investigate the patient Surgeon B will be doing surgery on, to ascertain the chance of failure to be as low as possible. All though give the fact, Surgeon A tries so hard at this point, he might be unable to surgeries himself soon. – MX D Feb 19 '19 at 13:58
  • Apologies for the gab here; I put in an answer reflecting one chain of thought - so! Cheers – Fattie Feb 19 '19 at 14:09
  • I would kill for more developers that apparently care as much as the developer you describe. Sounds like he is well compensated to care. As long as he leaves the problems at the door, at the end of the day, you should be fine with it also. – Donald Feb 19 '19 at 17:54

5 Answers5

5

Stop treating him as a star employee and make it clear that he needs to change his ways, because the net effect of his actions is actually a drain on the team.

This somethings leads to scenario's where he almost builds a full framework. After which, he needs to elaborately discuss said made framework with every person in the team involved in said project. Elaborating on each and every design choice made in said framework, just to make sure we have the same high standards as him.

This simply isn't good practice. Working those hours, exhausting himself, writing frameworks from scratch rather than using existing ones - these are not good trademarks.

Flat hierarchy or not, his boss needs to make it very clear to him that while he appreciates the intent here, the outcome isn't one of a star employee - the net effect is actually a drain on the team (your question shows that just from the fact you feel you have to ask it.)

If I were managing him, I'd pull him aside and say that:

  • Overtime, beyond a certain point, is banned. If he's caught doing it often, that's grounds for disciplinary. He's not some wonder employee because he's pulling overtime, he's actually letting the rest of the team down by raising expectations too high and being constantly exhausted.
  • Code quality is a great asset, and that should be formalised into a written, documented code review structure so that everyone can hold everyone accountable - not just him.
  • Frameworks should never be written from scratch unless the team decides there's no other option. Otherwise it makes it hard to bring new employees on board, and moreso creates an ongoing maintenance burden to the rest of the team.
  • If a few deadlines have to slip in the short to medium term as a result of the above, then that's fine, let's re-schedule what we need to.
berry120
  • 34,738
  • 20
  • 90
  • 127
  • This is all totally, 100%, correct. However, people rarely change, so it's best just to let him go today. Time is money. If there's a problem, fix it today. In this case, let the bloke go elsewhere. – Fattie Feb 19 '19 at 15:07
2

Well, you might want to show him This story here

Your coworker is starting to burnout. If you have no single authority to tell him to slow down, you will need to approach him as a group. You may also need to focus on upskilling the group so that he feels less pressure. If not, it will be very bad for your company, your team, and your coworker.

As a team, you need to stop going to him as a first resort, and only go to him when you are truly stuck. Stop taxing him as a resource.

For the dialogues, set up rules about them. No longer than X minutes, no more frequent than X times a week.

Old_Lamplighter
  • 159,693
  • 108
  • 436
  • 585
  • Indeed - as well as for the sake of the company, for the sake of the person as a person it has to stop. – Fattie Feb 19 '19 at 14:08
1

Nothing you can do. He won't listen to you. If there's a boss, CEO or something like that you should demonstrate to them how this behavior is negatively influencing the team and then it is up to them to put a stop (or not) to it.

Your colleague, as you made clear, is well aware of all sorts of problems this is causing, so someone with more "power" needs to talk to him.

undefined
  • 5,413
  • 5
  • 21
  • 28
0

Are you the boss? If not, this is not really your problem.

If you are the boss, you should have a word with this engineer. Have him voice his concerns to you, which might include things like:

  • Code quality: Institute a code review process. It takes off his plate the responsibility to fix everyone else's code, and replaces it with allowing him to flag other people's bad code so that they can fix it (and he can do other things). It also allows him to teach others how to write good code so he has less problems in the future.

  • Tools are insufficient: When you start a new task, the team should be responsible for scoping the project, at the beginning. That way, you don't have to spend 90-hour work weeks catching up, because your deadline was set beforehand to account for that.

As the boss, you should make it clear to him that the amount of overtime he is working is not acceptable, and disciplinary action will be taken if he continues to overwork himself. He needs to go home and sleep and not worry about work. He also needs to be comfortable with the idea that the task can wait for tomorrow, and as the boss, you should set project deadlines appropriately. Startups (which I presume you are because you said your company is 10 people) tend to have a quick release cycle irrespective of project size, and this could be contributing to this engineer's problem. Extend your release cycle to give the project more time to breathe.

Ertai87
  • 45,600
  • 9
  • 73
  • 144
-3

I suppose I'll put in an answer, expressing one train of thought:

  1. There's simply no place at all in modern, serious, professional software engineering for the "early-days" style of "long! hours!" "cowboy! code!" "heroic! efforts!" work style.

Again - quite simply - there's just no place for it.

Thus the only solution is

  1. Tell the person to dead-stop it as of this morning, and act like a normal modern, professional.

Or, leave.

Just run the team in a serious, business-like, professional manner. (This will flow down to every detail of the technical work.)

So, that's one viewpoint. Vote as you wish!

A point:

OP mentions a couple of times that the Person has excellent technical skills, advice. I'm afraid I just dismiss this. (i) Who cares? You can make a phone call and hire many of the best experts in any speciality on an hourly basis. They'll tell you everything you need to know in a professional, businesslike manner. (ii) I'm afraid, on the face of it, I don't accept that anyone with a 40-years out of date attitude to professional practices in software, would really have that much to offer about exquisite technical details.

Oh - here's a point. The person is (understandably) wanting the company to have high value. If the software department is a total shambles, tht drastically lowers the value. Any serious company that buys you out wouldn't agonize over it, they'd just thrown out a "works all night!" type.

Fattie
  • 32,594
  • 12
  • 67
  • 99