51–60 of 112 posts
I think this article misses the important point - you should be able to trust the coworker’s expertise. Present the facts, but leave the decision about the person’s domain to that person.
This works well in situations where the cost of a mistake is low and reversible. But often in software the cost is accumulating technical debt that will rarely, if ever, be paid off and driving a potentially successful project to the ground. I don't believe you can have a successful software team with individuals who can't take a code review well. Edit: That being said, there are definitely tactful ways to deliver a…
Hello there! Author of the article here. I love the point you've made. Often there are long term costs in e.g. technical debt. I assumed in this article that the stakes are low (and they are more often than we think) but I have a future article in mind about how to make team decisions when the stakes are high, and it'll be something along the lines of: Have a strong process, and make it the responsibility of one pers…
For those stuck lower in the org chart, they can rest assured knowing the more good ideas they contribute, the quicker they will rise up the ranks in decision-making authority. When job mobility is also meritocratic and has efficient review processes, those middle managers should be correctly rewarded or punished for making good or bad calls.
The problem arises for confrontation more frequently in startups because org-structure is often very loose. It's seen as "undemocratic" to force an issue because of seniority, even if someone may have more experience in a topic. Startups generally the traditional business hierarchy as being inefficient for decision making, because many institutions also fail to properly reward decision-making, or punish bad managers.
If Kara's emotions and defensiveness can't handle a clearly articulated, rational, objective argument against design decisions, then for the sake of the product and the company, she probably needs to find another job. Avoiding discussions doesn't work for me. I'm happy Steve Jobs didn't read this post.
So from Kara's point of view, you're getting just as emotional and defensive about, and ignoring clearly articulated, rational, objective arguments for, the decision as you claim she is. Which is the point of the article - if someone goes into a discussion assuming they are the only one who is "objectively correct", they've already failed.
I've used the method outlined in the article very often in my career and it almost always works. Often it turns out I was right and we shouldn't have done X - but sometimes it turns out that Kara knew something I didn't, and X worked out way better than I expected.
Earlier quoted context omitted.
Of course. The obvious answer is always to just fire people. Improving your own communication skills couldn’t possibly be the solution.
It's a two way street. Improving one's listening skills and not reacting emotionally is just as important. The general tone of the article sounds to me as if it does not give much priority to the latter. This strikes me as an expression of an over protective approach to people's emotions that limits rational discussion. I see this often and in my experience I find that it has negative effects on organizations and rel…
Kara’s manager can encourage her to work on this, but colleagues cannot realistically. And even the manager’s ability here is extremely limited.
In situations with clear org structure the final decision between product disagreements can always be handled by the chain of command. When two product people disagree on a feature, the one higher up the org chart can then make the final call. Feelings are saved because roles are clearly defined, and those with greater product knowledge have the authority they need to "make the call", making the product better overal…
Passing decisions up the chain of command doesn't really sidestep the issues in the article though - cause you still have to decide when to escalate something from "hey, what about this?" to "hey, you are wrong". If anything that's a more drastic step now that you are bringing an issue to An Authority Figure.
I do agree that a lot of problems fester because of a lack of clarity about RACI-matrix. That can happen in any size organization, definitely worse in smaller ones.
If Kara's emotions and defensiveness can't handle a clearly articulated, rational, objective argument against design decisions, then for the sake of the product and the company, she probably needs to find another job. Avoiding discussions doesn't work for me. I'm happy Steve Jobs didn't read this post.
The thing is, Kara almost certainly has clearly articulated, rational, objective arguments for the design decision in question. If she didn't, she wouldn't be making the decision in the first place. (If she's prone to making decisions willy-nilly with no idea why they're being made, that's a different issue.) So from Kara's point of view, you're getting just as emotional and defensive about, and ignoring clearly arti…
In situations with clear org structure the final decision between product disagreements can always be handled by the chain of command. When two product people disagree on a feature, the one higher up the org chart can then make the final call. Feelings are saved because roles are clearly defined, and those with greater product knowledge have the authority they need to "make the call", making the product better overal…
The point is to avoid getting to a situation where a manager needs to step in and make that call in the first place, because despite its simplicity autocratic control (especially in creative fields!) is a pretty craptastic way to run a company.
Your point that "feelings are saved because roles are clearly defined" just doesn't work in practice. And anyone who's ever been overruled by a boss can tell you that.
This works well in situations where the cost of a mistake is low and reversible. But often in software the cost is accumulating technical debt that will rarely, if ever, be paid off and driving a potentially successful project to the ground. I don't believe you can have a successful software team with individuals who can't take a code review well. Edit: That being said, there are definitely tactful ways to deliver a…
i'm a pretty mild mannered personality, very reluctant to get angry with other people. i try to be diplomatic with people, at least, in person. one of my worst experiences working on a dev team was checking in code that broke the build. the alpha came into my office and got quite angry with me. it left new emotional wounds and reopened old wounds. it didn't help me become a better programmer, just more fearful and st…
The interesting thing is that we programmers still make just as many mistakes -- but there are no angry feelings or animosity when they do because it doesn't hurt anyone else. If I make a pull request that fails linting, or breaks a bunch of tests that I forgot about, it won't affect my teammates, won't get to production, et cetera. It transitions the interaction from "You broke my stuff!" (which causes hurt feelings) to a robot (callously? uncaringly?) informing me that I have more work to do before my stuff is of a caliber that merits merging with the rest of the codebase. Somehow, that doesn't hurt feelings nearly as much.
This also requires the codebase to have extensive enough test coverage that you can trust the tests to catch any breakage -- which requires code review to notice if one forgets to add a test for functionality. The upside is, having that kind of coverage means that you can refactor fearlessly, and can really trust an automated deployment workflow.