Ask HN: How to deal with incompetent people
I've been doing a lot of work to clean up the debt that was accumulated and, meanwhile, I improved the reliability and the efficiency of the infrastructure. I wrote common components and library to avoid duplication and shared it with wiki pages on how to implement certain things correctly.
On the other hands, my colleague, is more focus on building relationships and acting like he's the manager even tho he's not. In a couple of circumstances he event tried to give me orders which is not what he supposed to do. In meetings with our manager he brag on stuff that I did sharing it as a "we did", while when he does something alone (which most of the time asks to me as well) he would say "I did".
Most of the team members know it as they always asks technical informations to me. Most of the new architectural design has been done by myself same as the library that they use daily bases.
This kind of behaviour was ok at the beginning but since our boss left and he got promoted as manager is not sustainable anymore.
So here I'm asking for some advice. I started to look for a new job already, other than that I can't find a way to make my life easier has it might required some time (European market is not that good) and I got a break to travel a bit and clean up my mind.
138 comments
[ 3.7 ms ] story [ 210 ms ] threadEven if it's hard, just tell him how you feel. Take it easy (don't start by listing all his faults) and stay objective - as in "When you do ... I feel ...". Be honest and say that you're not sure if you want to stay, and that the situation needs to be resolved so that you can have a healthy working relationship again.
if the company does not promote meritocracy (in a sense that it gives more competent people more responsibility and vice versa), you are destined to become more and more at disadvantage.
life is too short to spend it fighting a localized idiot. go build something interesting that will benefit mankind.
I would also be careful to assume that your colleague is incompetent. Perhaps the two of you have just very different styles. I once worked with a "solution architect" who would over-engineer every project. Even the smallest utilities would become a "system" with lots of moving parts. Management lauded his technical abilities, but those who later had to maintain these "systems" he created were not as impressed. I could see how he might consider some of the other members of the team "incompetent" because they did not work in the same way.
Technical debt can build up for myriad reasons not related much to competence.
What I would suggest is not to approach this situation as how you can wall off or otherwise attack this person but, instead as a life lesson on the importance of interpersonal relationships and politics.
Politics are a fact of life. Humans are social creatures. All things being equal, and some ways even when not equal, those that are proficient in interpersonal relations will come out ahead. Grok that fact. There is no escape from it.
Good. Now that unpleasantness is out of the way. On to how to cope. Scratch that, /thrive/, in an environment of people doing people things when you are a technical person.
First, information. That is the lifeblood of many systems and politics is no different. Simply make sure important information is conveyed to the right people at the right time.
You use the example that this fellow was able to take credit for your work. Had you passed the information of what you were doing and why it was important to the right people, he would have simply looked foolish to try to take credit.
It can be uncomfortable, to toot your own horn, but it is necessary. Additionally, it can be important to the organization. Assuming you are creating value, it is important that decision-makers know that so they can make the correct decisions. Don't feel bad. Toot away.
Building relationships is critically important in almost every human endeavor. Get good at it. It is a skill like any other.
The target of your annoyance became a manager because he built up those skills and made it known.
Build your skills and make it known. It is just that simple.
I can build this skills as you said, true, but in my position now it would be impossible to get a promotion as the available spot has been taken already.
Since you’re already in the position where you seem to lead the technical efforts of the team, where would you like to go from there?
Unfortunately that's not true. If "shitty code that works" requires three days to be understood in order to make a small change that became a delivery issue and three days in a problem that can be solved in one hour are $$ that somebody is paying. In addition "shitty code that works" most of the time has scalability and performance issues sooner or later you need to address if you don't want it to implode.
> where would you like to go from there?
I can also keep staying in this position, I just don't like to have a manager that I'm not even proud of. And, by the way, I'd like to be in a position where decision making is more stronger also in a business perspective. There are a lot of ridiculous choices that some people makes that are not very effective in some ways let alone make data driven choices. As the organisations today claims to be "agile", most of the time they're not at all. They just use a new word but act as old school (long feedback-loop just to give you an example)
People outside your team won't understand your reasoning. They'll see code working one day and a random failure a long time after that, which might or might not be related to the previously working code. They're just like my cat.
If you want to act for "shitty code", act before it's in production. Afterwards it's very hard to dislodge. And even harder to pinpoint the blame, as the author will definitely protect his back, ethically or not.
I'd take the experience as a lesson in human interactions :)
I think you might be missing their point. From the perspective of a programmer, yes, these things are true. Code SHOULD be Good and Right™, and that is very easy to see and grok from a programmer's standpoint. But to a manager? These things usually have to be stated explicitly, and that isn't entirely the manager's fault. It is easy and pervasive in the industry to write crappy code that works for a variety of reasons (time constraints, incompetence, poor decisions from on high, etc...). Even the best managers have some degree of "out of sight, out of mind" because they rightly delegate the responsibility of making sure the code works AND minimizes tech debt to the developer. It doesn't become apparent to them (and by proxy, the business) that the code was poorly written until the shit hits the fan.
Also, it is unfortunate that you have to leave that job. In my experience in the industry, being able to go back and fix tech debt like you are describing is very uncommon.
I side with you on this because of something I see often: At the end of the day what the CIO (a purchasing manager or the budget signer) asks about is who killed the fire for the day. When you are the good fireman, no one wonders about the quality of hose you used ..
Nope. Silence is always less noticeable than noise.
Evil prevails when good men do nothing. Also, nonsense fluff prevails when good work isn't spoken of.
You have a professional duty to make sure nonsense is crowded out by important information. No one is going to do that for you.
Follow the rule of three...tell people what you are going to do and why it is important. Tell people what you are doing. Tell people what you've done. And not just anybody; decision makers.
It is no one else's job to tell people who influence your life of your good works.
No one has time to dig through everything you might have done to hold up the shining examples of your work. And now you have someone above you that might actually be interested in seeing it kept buried so it is even more critical that you do that interpersonal information transfer yourself.
You are a business, and like a business there is no worth in a product that the people who are in a position to buy don't know about. You're going to have to market and sell your value to the people that are buying. All of the time. Make it a habit. Your co-workers are competitors...don't expect them to sell your product for you. (though, keep in mind, part of your value-add is cooperating in your value-add chain so don't take this analogy too far).
Honestly, this is stuff that took me way too long to learn. They should teach it in engineering school. Hell, they should teach it in secondary school, for that matter, since there is really no one who is not running a business even if it is a business of one.
over promising and under delivering isn't a sustainable model
under promising too much and you won't get the chance to deliver
there's a sweet spot somewhere in there, which can be sometimes tricky to find
An interesting corollary: Find out what's bothering decision makers. What're their annual or quarterly (or whatever) goals? If you know what those are - not only can you say "Hey, by the way, I did what I'm being paid to do, but, by the way, it helps to address that thing that's been bugging you."
Often, when you do good work and are good at what you do, it actually looks like your job is easy, even when you are busting your ass to get results!
Some of the best engineers I remember working with did the over-communicating stuff you advise and I remember it was always very clear what they were working on versus other people. They also had a knack for communicating the work in the simplest terms for everyone to understand.
In short: “I did it all myself” is always a lie. It could only ever be true if babes were left in woods since the time of birth to fend for themselves, and even then, debatable.
Putting it into practice has been tough, but early results have been good. I'm less likely to get angry, and while I still am not necessarily getting what I want all the time, I feel like I'm getting more clarity and direct communication around why not.
[1] https://en.wikipedia.org/wiki/Nonviolent_Communication
The value you create doesn't talk about you except to people who know you're the one who created it.
Now, when's the last time you went out of your way to discover if and how someone screwed up?
The difference is just how people are wired. We are all kind of dumb.
As a fun exercise, track down someone responsible for having made your life better today, find out exactly how they did it and give them a piece of your mind about it.
> make it known
This was the hardest "part" of working in a company for me to understand and execute on, especially when reporting to a non-technical supervisor. The thing is they simply don't know where to look or what to lookout for to give us accolades. It isn't as hard as we make it out to be, either. It can be as simple as "I made the common components for the WidgetMaker uniform through out the system, increasing reliability and improving maintainability. This will help us avoid an outage during peak WidgetMaking season so we can continue to make Widgets and operate smoothly", which isn't at all horn-tooty, but gives credit where due.
And if you understood what total collapse will mean - the incredible human cost of it - you would not propose it even as a constructive step.
It's a cost I'm willing to accept... So long as that human is not me ;p
To understand why, ask yourself 'When's the last time I went out of my way to discover if someone else did well?'
I was rushing trying to explain two years in a few words. You might not know what happened is such long span. To give you some ideas of why I said incompetence:
- my colleague doesn't know yet how our infra works
- he has no clue of the application architecture has he still make unforgettable mistakes after two years
- in any architectural meeting where we have to discuss about something he got missed, and, when he's there, he will suggest an open source tool to do so even when it doesn't fit our needs
- in any meeting when somebody ask something to him, the first answer would be "just go in google and search for a library to do x, z, y" even when the question is very architectural specific and domain specific
- even after we implement something he still want to find an open source or SaaS to use for no reason, not understanding that we have a lot of integration cost that he doesn't even understand
- he only had front-end (only in small-sized companies) experience and less than 6 years of total experience when he was hired (he joined right after me, I was not the interviewer) and he never lead a team before.
I worker in multiple context during my career; mainly enterprise and consultancy and I had team leading experience before the role.
> when he does something alone ... he would say "I did"
> he got promoted as manager
Act like the stereotypical manager, get promoted to manager.
What's the business case for this?
Pretty much I don't like to do stuff for the sake of doing it
Inform somebody higher up about this. Do it more subtly instead of name calling. Usually people sitting higher up will take this into consideration on future decisions.
If you trust your employer and management chain enough, then you can use the normal reporting loop to file concerns and notes along the way - just try not to get emotionally involved as it could become difficult to separate your observations from your personal opinions.
Even more so don't let this person pressure you or change your decision-making in ways that could undermine your position.
And certainly, if the organization fails to take care of things, then it may be time to move on and find somewhere more progressive and healthy. It's the sign of a failing environment if it can't identify and deal with individuals who claim overdue credit by using others' contributions.
It seems to me like people skills are a weak spot for you. That's not unusual in our industry. But leading and managing people, sorting out the relationships to make large project work, that work is just as essential as technical skills are. Nothing big ever got built by a bunch of grumpy, resentful introverts.
Rather than hating his "incompetence", try to recognize him (and others like him) as valuable allies. Find ways to work together, to let them deal with the frustrations of relationships, and let you focus on the technology. Create a mutually beneficial partnership. If you can't learn to do that, to trust the "people persons", you're going to find yourself in this situation over and over again.
It's quite possible the other person did a lot of the "people" work that enabled the code to be written and distributed. In that case, it's a "we", not an "I", and focusing entirely on "I wrote the code", ignoring how it fit into the organization, is dismissing someone else's well-deserved credit.
I have seen the case you're wary of: a technical, but poorly communicating, employee that resents the success of a well-meaning, less technical but better communicating coworker.
I have seen good people like that, and I have seen snakes that pull the "we/I" as in the OP's story.
Generally, I don't see a lot of these "snakes" out in the real world, but I see a tremendous amount of misunderstandings, resentment, and righteous indignation. As I told the OP elsewhere, we're all the hero of our own stories, and everyone we disagree with is a villain. But ask the villain, and they think they're the hero. It's human nature. We don't want to admit that we might be wrong, that the people we disagree with might be right (or at least, the disagreement is not founded in malice).
So when I see situations like this, I rarely see snakes. I see misunderstandings that can be addressed with better communication and a good dose of humility.
I'm pretty sure this was simply because he thought it couldn't be done, and I just put the niggling thought in his mind so he tried and was successful.
Weirdly enough he was the introvert and I less so, and I got the promotion. No hard feelings on either end, as far as I know. We all have our quirks.
I have nothing to complain about. I've done very well career wise, and have no reason to beef with any of these people. But at the same time, I've concretely seen individuals lie outright, blackmail, threaten, insult, and bully their way to success. That you say you rarely see this makes me raise an eyebrow. I've gone through the "maybe I'm just seeing evil where there isn't any" thought process many times, but after watching multiple instances of negative actors take advantage of others while I was a disinterested third party, I can't but have conviction. People will abuse others when it serves them and they think they can get away with it, and in situations where power dynamics, visibility and relationships (so soft, highly non-fungible elements) drive your career, someone in power can get away with a LOT, even via only subtlety misaligning incentives.
Let me be clear, this is not some dominating majority of the population, and one should not start seeing enemies around every corner, but I've seen enough that instructing a junior engineer to watch out for those who would seek to take advantage of them seems very pragmatic to my eyes.
People who let bitterness rule their lives are far, far more common than actual snakes.
Assuming my observations are correct (I may be wrong, I'm often wrong), then what is the pragmatic advice to give? "Be wary of snakes!", or "Be wary of your own human desire to be the hero of your own story and make everyone you disagree with the villain"?
To me, this is a variant on the Pragmatic Programmers' advice that "SELECT isn't broken".
I think perhaps the issue here is that I'm coming at the discussion from over-correcting the opposite direction; I was raised with very much a "people are All Good(TM)" outlook, regularly being fed the "Things get better after highschool/people grow up" line as a child. I've found that these both gave me ineffective priors for navigating adult life, largely due to that if you assume people are acting with your best interests at heart, you may be less inclined to look out for your own best interests yourself, or at the very least how other people may be compromising it, consciously or not.
Framing it in terms of incentives also has the wonderful side effect of circumventing a lot of they "are they malicious or just self-serving" question since it hops right to "how do you fit your success into whatever equation everyone else is trying to route into"; my inquiry of whether they were TRULY malicious is usually made post-factum (or given sufficient evidence)
As a final statement (and to couch my own incompetence with tone over the internet, please don't let any of this come across as a You're Wrong!), I'm not sure I'd agree with your statement that people with bitterness outnumber those who would manipulate others, at least in my work context. In the lense of my "incentives" stance, both are continuums of behavior, but the bitterness continuum is counter-productive to career advancement while the "manipulating incentives" continuum is productive, so I'd logically expect to see more of the latter. (I guess the real crux here is "when does it become malicious," but that's a whole separate discussion)
This dovetails into your last paragraph, by way of saying that the fact that paranoid behavior is counterproductive is in no way inhibiting paranoid behavior. People believe it works. What people believe is far, far more important to them than what actually is. We engage in counterproductive, even self-destructive behavior all the time. And not just the "incompetent" people, but everyone I know. We are all stupid. (fwiw, I do not consider "smart" and "stupid" to be opposites, but rather different qualities that happily coexist. Just because you're smart doesn't mean you aren't also stupid.)
This is also aggravated by the human distrust of those who are different. How many employees think their managers are ignorant fools at best, and actively malicious at worst? A majority, probably. How many of those people really have a good understanding of their manager's job, and the pressures and conflicts the manager deals with? Not many, I'd wager. This is the root of racism, nationalism, and other forms of tribalism, if you think about it. Those feelings are irrational, but they're common as dirt.
This view of humans as stupid rather than malicious was reinforced for me recently, when I read Factfulness, by Hans Rosling (which you should definitely read!). Rosling, a doctor/professor/world health expert, tested thousands of people with basic multiple-choice three-options questions regarding well-documented facts on the subjects of poverty, global health, and the link. What he found was that every audience, no matter how smart, well-educated, caring, or involved in the field, actually performed worse than random chance. Start on his questions, without reading his book first, and you'll find yourself doing worse than if you'd just pulled letters out of a hat. Don't feel bad, the same is true of UN leaders, CEOs, med students, etc. Rosling went on to identify ten different thought patterns that lead us to misunderstand the world, even the most basic facts about it.
Read it, and then look around the corporate workplace, seeing it through Rosling's eyes. You'll see very few snakes and a tremendous number of idiots.
You don't seem to understand why the term is "snake" in the first place. Of course you don't see them. They're hiding in the grass, and you're not going to notice them until you step on one. That doesn't mean the people around you aren't getting bit.
I'm not saying it's great, but it also sounds like the OP needs to be more proactive about speaking roles in meetings when it comes to value of their practices, why things were done, etc. Now, would I work for a person if I hated them? Nope. Would probably be out of there.
In terms of "How can you!?", this stuff happens all the time all over the place and people work together. I think you can work through it with colleagues - it's not easy, but it's important if you think the mission / company are worthwhile. Otherwise, you're just going to dig deeper "into the box" on the credit thing and it won't be a good reflection on your work.
That's not true as I always hangout with the people in different teams, and, we get along pretty well. I just don't do kiss-ass to my boss and I don't take advantage out of situations.
> Find ways to work together
We worked together for two years on daily basis. And I overcome a lot of bad behaviours but I can't stand to report to him
However, if this:
> I can't stand to report to him
remains true... the only solution in the end that will leave you with day-to-day satisfaction is to leave the situation. It sounds like you are aware of this.
Life is not always fair but in general it is consistent.
I've been in your shoes - a peer got promoted to be my manager when our old manager retired. We were okay as peers, but very bad in a hierarchy, and I eventually got fired. I should have just quit instead.
Still, though, I think you're letting resentment blind you. It's easy to be the hero of your own story, and for anyone you're in conflict with to be the villain, but that doesn't mean it's right. We're all unreliable narrators.
Try this exercise. Repeat after me... "I may be wrong. I am often wrong." This is my mantra. Recognize your own fallibility. Try looking at it from the perspective of "What if I'm wrong?" It solves a lot of problems (or leads to the correct solutions). And the more you do it, the easier it is. Consider my earlier point, that what he did isn't incompetence - not if his goal was to get out of technical and into management. And since he's apparently good at those people things, he might well be recognizing where his talents are, doing the right thing for himself and the organization.
Consider also a telling bit of evidence in your response to me - "we worked together for two years on a daily basis". If that's true, is it also true that you did all the work and he unfairly claimed credit? What was he doing, if he wasn't writing code? Is "kiss-ass" a fair assessment, or an resentful interpretation of his useful work? Try to stop being angry long enough to consider that.
I think you're making a big leap saying "let them deal with the frustrations of relationships". Nowhere in OP's post does he mention disliking people. In fact he seems proud of the fact that people come to him when they have questions. You need more than pure technical acumen for people to feel comfortable coming to you.
Situations like these are complicated, and I'm not sure there's enough information to make a judgement one way or the other. I do think taking the "high road" here is not always the best course of action. If you're more interested in the success of your team or your product, you will remain ripe for being used by those more interested in their personal success. It's a toxic circle that's hard to escape once you find yourself in it.
My advice would be to heed the red flag and look for work elsewhere. If you are being leaned on as heavily as you feel, then it will likely become apparent once you move on to greener pastures.
As @eriktate said, you either make some noise because you care, or you realize that the people above this person don't understand what makes great technical leadership actually great, and you leave.
The more people in management that care about building well engineered products and that treat humans like humans and not resources the better off we are as a community.
Well, the Linux kernel did, but I think for the most part you are correct.
We have a new project coming up and I basically was the one implementing the initial architecture, I showed them how to use the linux terminal, gitflow.
I am the dev with the fewest number of bugs reported, they are always on meeting about issues. They take the most visible, interesting features.
Yet during meetings, people talk to them more because they are older, so they basically take most of the credit.
What should I do in that case?
And more broadly, learn how politics are played.
Or just find a sane work environment, which one is easier.
I'd start by writing emails detailing such or such feature you are working on, how it improves the system, etc. Maybe ask for feedback, or ask general questions to the business owner. Maybe suggest using some issue tracker where you could document over time what you are doing via comments, issues, etc. I'd expect your colleague might be the kind to distort truth, so such record is a good point of reference to set things straight.
Not only that would be good for you, since people will know that you are improving the system, but it will be good for the company since they'll know what's going on. They are lucky you're actually doing your job because another employee could have been slacking off and they wouldn't even know it.
The extent to which your ego is bound up in taking credit, having a certain reputation among your colleagues, etc, is the exact extent to which your coworkers behavior can "get to you".
Always the best advice is: do your job to the best of your ability and don't worry what anyone else is doing. Others will notice. And if they don't, then perhaps its not the kind of place you would want to work, anyways?
The business is almost never paying to you clean up technical debt. They are paying you to generate revenue (or save costs). Period. It could be the best architected system in the world, but if it takes 4x as long to build, and the "quick and dirty" version can ship and generate revenue earlier, then that is the way the business will want to go (even with an elevated error/loss rate). My takeaway: If you do not intimately understand exactly how what you do each day makes the business more money, or saves the business more money, then you need to pause and figure that out.
Nobody gets credit for building a system that never goes down. It does not speak for itself (much as I would like it to). As others have pointed out, it's critical to communicate the value (see point above) of what you are doing, and communicate it to the people who matter.
Dealing with Humans (incompetent and otherwise) is actually what most of us get paid for (or at least it's a big share of why we get paid). Dealing with bureaucracy, red tape, incompetence, things taking too long, etc... Sometimes I wonder why I have to wait for others who are slow, don't they realize how much money is being wasted?! But it's true, the human component of our jobs is the main reason why we haven't already been replaced by others/computers. Relationships trump even adding business value (point 1 above): if you are difficult to work with, but add value, you will still be marginalized (or even let go). However on the flip side, if you are great to get along with but do little-to-nothing, you may not thrive, but you will survive.
One of the senior engineers in my company once told me, "business is the dog, technology its tail", not the other way around. While I later argued with a completely different set of engineers that the analogy isn't great, the gist of the idea remains valid: we shouldn't be building beautiful technology just for the sake of it. Rather, we should be building technology that will serve the business best, while balancing out short-term and long-term gains.
> Dealing with Humans (incompetent and otherwise) is actually what most of us get paid for
This is so true as well. I often realize that the problems I solve at work aren't exactly rocket-science. However, I have learned a bit about effectively interacting with humans, and that is probably more important to my company than my pure technical skills.
I didn't have any of these skills and I am still learning. However, I'd HIGHLY recommend the following "The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change" for anyone wanting to learn soft skills.
You write version 1 quick and dirty to get it out the door fast. Version 1 is written to acquire customers. You write version 2 to patch over all the problems of version 1. Version 2 is written to retain customers, but it ends up as an unmaintainable mess.
In version 3, you finally get to throw out the old code base and take the time to write clean, architected, maintainable code. Version 3 is written to attract and retain developers. Once it reaches parity with version 2, you can do the "Big Migration", and then start adding features. Version 4 and up are all built on 3, but barely anyone ever gets that far.
Note that this won't match up with the version numbers written into the software. You can't do anything about those, because marketing and management tells you what they have to be. Anecdotally, most software projects never progress past version 2, no matter how high their marketing numbers go. This is because version 3 does not directly add to the bottom line. It adds to developer productivity, and if the company cannot measure the value of developer productivity already, there will never be a business case for it. We all want to work on version 1 or version 3, because version 2 is a never-ending nightmare slog of one problem after another, but version 2 is that gaping hole that businesses will just keep throwing their money into, forever. And version 4 is easy and boring, where the only hard work is in upholding the process that is keeping the less experienced coders from cluttering up the place.
OP's mistake was in writing version 3 before telling management why that would be a "Good Idea That Saves Money" and seeking their mandate, and in not owning the successful completion as a major accomplishment. OP's current manager always understood that people run the company, not the code. That's not incompetent; it's a competence OP doesn't currently understand.
>The business is almost never paying to you clean up technical debt. They are paying you to generate revenue (or save costs). Period.
So true. Once you're in enterprise nobody cares that you wrote the connection pool yourself (which I did and nobody gave a darn). I did 5 years in enterprise and decided that was enough for a lifetime.
>Nobody gets credit for building a system that never goes down.
This happened to me. I designed and wrote a subsystem that is used by every GM dealership around the world and that thing never went down meanwhile my colleagues project was always down yet folks from the other team were the ones that got promoted.
My advice is to a) leave asap, b) simply ignore him as much as possible while you're stuck there.
A new shared dependency is worse than duplication. Sometimes developers get carried away about doing it the right way and don't understand the trade-offs you need to do to make it tick. FYI - I am a fully hands-on manager.
If you truly aspire to be a manager you need to understand that tech side alone doesn't cut it.
If you don't think so, just use a plain language without any framework, module, library or third party component and let's see who target the release date first.
We are paid not to build beautiful or robust software, but, first, to deliver faster and without headache. Decoupling stuff and avoid redundancy is a huge benefit and we experienced it dropping down the delivery time by at least 20%.
Its about developers spending time on what they think needs to be refactored due to the engineering itch on an already functional and maintainable code. Most times by doing it they can be introducing instability to the whole system. In a larger code base with handful of engineers and teams it becomes a bottleneck to make quick changes since it can break others stuff so too much interaction and policy around it and so forth.