7 ms·

This is the hardest lesson I had to learn in my consulting work. It is is especially important if you are not familiar with the full context - which is almost n

This is the hardest lesson I had to learn in my consulting work. It is is especially important if you are not familiar with the full context - which is almost never the case. The main insight for me was that yes, things can be "wrong" due to lack of knowledge or incompetence. Sometimes. But more often than not there is a good reason. Like: * we know this is stupid, but we had immense time pressure and this was the only way to get it done for the deadline; we never got the time to fix it * external system constraints (like legacy applications, legal/certification requirements, ...) * particular domain constraints that you might not be familiar with, and that only make sense if you know the details * important senior engineer X designed this and no one had the guts to call it out as flawed * the company paid a lot of money for product Y, so we just had to use it * a manager read a blog post on how technique Z is awesome, so he made us do it this way * political infighting between parts of an organisation (redundant work, refusal to work together, deliberate sabotage) * ... But you will usually not hear these reasons right away. And being critical can easily put others in a defensive stance and make it very hard to get that information at all. So my best tip is: if you spot something "wrong", don't react immediately and don't interrupt. Let the other party finish. Make a note. Gather more information. Ask why it was done this way, who is responsible, if it has been effective or not, and whatever else could be relevant. You can still be as critical as required later.

johnwalkr 5y ago
I’m always surprised at “refusal to work together.” The entire point of a company is to organize people to work together, how do workers like that get promoted?
- pavs 5y ago
  This happens so often, I am surprised that anyone gets surprised by this at all. The entire point of a company is to make money, with the people/resources they have. More often then not what they want is not the best available to them. Most people are horrible, managing a bunch of highly egotistic but talent people is hard.
- 0x008 5y ago
  Usually it is management culture which is fueled by stupid controlling and has team competing against each other.
imwillofficial 5y ago
Stealing this workflow! Thanks
vmception 5y ago
The other side of this is how nearly every engineer is going to trash talk the prior coders, when they inherit a codebase. So I already know to ignore it.
- cmckn 5y ago
  > trash talk the prior coders This is one of the things that make the software life worth living! It's even better when you realize that the prior coder was, in fact, your own damn self.
  - vmception 5y ago
    Its so embarrassing Junior engineer logic
  - tbrownaw 5y ago
    > It's even better when you realize that the prior coder was, in fact, your own damn self. That's really about the only time you can actually be sure that the prior coder deserves to be trash talked.
- strken 5y ago
  One of the nicest things anyone's ever said to me is "Feel free to blame all the problems on me once I leave." Whenever I leave a team now, I make sure to give everyone explicit permission to do so.
sklargh 5y ago
I now use the discovery of something obviously stupid as a fairly reliable detection mechanism for either a broken system/process and/or a context cue that I am missing some larger, typically organizational, part of the picture. I also often use my internal voice to say "shut up and listen to myself," when I want to immediately engage in a conversation or correction.
- jameshart 5y ago
  The problem with this heuristic is that every nontrivial piece of software contains something obviously stupid. Which sounds like a refutation of the validity of this inference altogether, but—no, take heart: It still works, because it turns out every organization has a broken system or process or larger organizational dysfunction. So in a sense yes, this logic works, but you can save yourself some steps.
  - hinkley 5y ago
    > The problem with this heuristic is that every nontrivial piece of software contains something obviously stupid. Sturgeon's Law has entered the chat. 90% of everything is crap. Everyone has blind spots. What makes them 'stupid' is when you're the one who ends up suffering (or someone you empathize with does). If you sniff a pattern you should probably keep looking Once is happenstance. Twice is a coincidence. Three times is a conspiracy. -- Someone paraphrasing Ian Fleming
  - sklargh 5y ago
    I don’t know where the shoal is but I know it’s there.
austincheney 5y ago
When I was a strategy consultant there were only two important lessons to learn: 1. Be a manager. You are not there to be their friend. You are there because they are horrible and their leadership needs you to clean up the trash. If you are not there as some form of management with a title and ownership you will quickly become their bitch, which leads to my second learning. 2. Don't get sidelined. As an outsider operating under contract the problem people want you gone but cannot remove you. Their best weapon is to sideline you. If they cannot own you they will ignore you. They will rearrange their meeting schedules and ensure you are not invited. They will create and release prototypes and delivery plans without your involvement. They will write reports and opinions to their management with all kinds of complaints and fictions and you have nothing because you are out of the game.
peoplefromibiza 5y ago
> if you spot something "wrong", don't react immediately and don't interrupt. Let the other party finish. Make a note. Gather more information The problem is that people doing the " wrong" thing (with varying degrees of wrong, which I did too and still do) will think they are right, they will usually do a presentation of their solution to people that are less knowledgeable than they are to win the "this was the only practical way given the time we had and also it works" (kinda, if we don't count when it fails) argument, lure them in their teams, keep pushing out half baked solutions that they will then rewrite "to improve them" for karma points, wasting everybody's time and company money. It works because there are always processes that are worse than bad software. So bad software usually is not the worse thing you can find in a company and can always blame some other department for being horribly inefficient, everybody wins, salaries are paid every month and 2 years later nobody knows what "the thing" does and why. But it's an excuse not not do better when it's possible. a task that takes half an hour can't take 12 days and 6 meetings "so we can talk about it" they say, truth is they are simply pushing their view. I get people are different and have different incentives, but we don't let people like me go into space just because we shouldn't point out a problem when we see it Software development is about being as thorough as possible while also being flexible. I always wonder why we keep asking people who see the problem to stay quiet while people causing them are encouraged to keep making them, so they can learn. What if people doing the "wrong" thing start listening and do what they are told and if it doesn't work they can blame who said them they were wrong? Saying no sometimes makes you the lonliest person in the office, but somebody gotta do it or nothing will ever change.
- galaxyLogic 5y ago
  I think it is most often wrong to use the word 'wrong'. That implies there is the right way and the wrong way. But in fact there are only better ways and worse ways, to do things. The "right way" somebody envisions to be THE right way can be worse than something even better. So instead of saying "Hey you are definitely doing it wrong" you can say "I can see an alternative way of doing this which might be better in some cases, for some purposes, for some users".
  - 5y ago
hinkley 5y ago
> we never got the time to fix it The older I get the more convinced I become that this is Learned Helplessness. "We didn't have time." is essentially the same dodge as "C'est le guerre" was in France. "We don't have time" is a conversation killer. "We are working on that bit by bit" is essentially the same statement once you've subtracted the helplessness. Nobody is ever gonna schedule time for you to have integrity. If your self image depends on blaming fate or having a scapegoat elsewhere in the organization then you really should take a hard look at yourself, your team, and your motivations. Sometimes, the only way for things to get better is if you can get consensus from the developers that tasks that look like X really should take 3N units of time even though historically we've been quoting 2N units. On some teams you can't get that consensus, and you're going to have to be okay with that or move on. But the power of No is there you just have to use it. If you don't at least try, then shame on you.
- cottager2 5y ago
  The goal of writing software is rarely to produce a piece of well-engineered software. More commonly, the goal is to produce a product in a given time frame using the team of engineers available, which may be of variable quality. If you’re trying to make the software perfect, you’re likely doing something very wrong.
  - hinkley 5y ago
    Businesses are in business to stay in business. Frequently nobody notices how much decline in capability the team is struggling with because 1) the change comes slowly, and 2) people are getting 'better' at taking calculated risks that keep the tempo up, masking the real situation until the company hits a brick wall and all estimates go from 3 weeks to 3 months overnight. As a customer these sorts of changes in behavior are hard to accommodate. It's almost always better to set an expectation that things take just a little bit longer than the customer would prefer but the software actually works when we do get it. When you have a date driven 'emergency' you deliver a small increment that handles the particular situation the customer actually has. Everyone mistakes wants for needs. When you foster that then you become part of a codependent relationship at best, exploitative at worst. Also if you swoop in and clean up everyone else's mess every time, they never experience any backpressure and you end up burning yourself out while they learn absolutely nothing. See earlier reference to The Power of No.
Litost 5y ago
This is really good advice, to which I'd add: 1) Don't lose track of the outcome, "being critical can easily put others in a defensive stance and make it hard to get that information", this also applies to the phase after you've gathered all the necessary information and need to fix it, if you've been too fast and loose with the blame cannon, good luck getting anyone's help afterwards fixing it or earning any respect for future work. 2) From the OP "This is when we should take a pause before pointing out something is wrong", this might sound weird bringing this up, but Mindfulness techniques as often also employed in CBT, which encourage you to observe the immediate thoughts, e.g. in this case fish out the blame cannon and let rip, but instead acknowledge them and don't act on them are great for developing this "pause". 3) From a Systems Thinking pov, complex adaptive systems often evolve in many small steps, rather than are designed so I'd extend your "But more often than not there is a good reason" to more often and not there may be many good reasons all bubbling away in the melting pot of despair. As an example my last company tried to implement the Spotify Squad model and it was a disaster, but it wasn't just one decision by one person that sunk it, it was a whole combination of decisions taken over time and feeding off each other, many taken by people who didn't even work there any more.
buzzard1 5y ago
flower-giraffe 5y ago
This is very good advice if the goal is to retrospectively find stuff that is wrong and how it came about. I think there a counter point that if someone else had not deferred or neglected pointing out something was wrong there would be less wrongs to discover. It’s certainly socially easier and nicer to avoid pointing out flaws but it doesn’t always result in better technical solutions.
codesnik 5y ago
calling many of those a "good reason" is.. I don't have a word. Something brittish probably. But yeah, just calling it out straight away sometimes shuts down communication, people become combative, and that's not good if you want to fix something eventually.
- harry8 5y ago
  > calling many of those a "good reason" is.. I don't have a word. I'm going with "Heroically empathetic"

johnwalkr 5y ago

I’m always surprised at “refusal to work together.” The entire point of a company is to organize people to work together, how do workers like that get promoted?

pavs 5y ago
This happens so often, I am surprised that anyone gets surprised by this at all. The entire point of a company is to make money, with the people/resources they have. More often then not what they want is not the best available to them. Most people are horrible, managing a bunch of highly egotistic but talent people is hard.
0x008 5y ago
Usually it is management culture which is fueled by stupid controlling and has team competing against each other.

imwillofficial 5y ago

Stealing this workflow! Thanks

vmception 5y ago

The other side of this is how nearly every engineer is going to trash talk the prior coders, when they inherit a codebase. So I already know to ignore it.

cmckn 5y ago
> trash talk the prior coders This is one of the things that make the software life worth living! It's even better when you realize that the prior coder was, in fact, your own damn self.
- vmception 5y ago
  Its so embarrassing Junior engineer logic
- tbrownaw 5y ago
  > It's even better when you realize that the prior coder was, in fact, your own damn self. That's really about the only time you can actually be sure that the prior coder deserves to be trash talked.
strken 5y ago
One of the nicest things anyone's ever said to me is "Feel free to blame all the problems on me once I leave." Whenever I leave a team now, I make sure to give everyone explicit permission to do so.

sklargh 5y ago

I now use the discovery of something obviously stupid as a fairly reliable detection mechanism for either a broken system/process and/or a context cue that I am missing some larger, typically organizational, part of the picture. I also often use my internal voice to say "shut up and listen to myself," when I want to immediately engage in a conversation or correction.

jameshart 5y ago
The problem with this heuristic is that every nontrivial piece of software contains something obviously stupid. Which sounds like a refutation of the validity of this inference altogether, but—no, take heart: It still works, because it turns out every organization has a broken system or process or larger organizational dysfunction. So in a sense yes, this logic works, but you can save yourself some steps.
- hinkley 5y ago
  > The problem with this heuristic is that every nontrivial piece of software contains something obviously stupid. Sturgeon's Law has entered the chat. 90% of everything is crap. Everyone has blind spots. What makes them 'stupid' is when you're the one who ends up suffering (or someone you empathize with does). If you sniff a pattern you should probably keep looking Once is happenstance. Twice is a coincidence. Three times is a conspiracy. -- Someone paraphrasing Ian Fleming
- sklargh 5y ago
  I don’t know where the shoal is but I know it’s there.

austincheney 5y ago

When I was a strategy consultant there were only two important lessons to learn: 1. Be a manager. You are not there to be their friend. You are there because they are horrible and their leadership needs you to clean up the trash. If you are not there as some form of management with a title and ownership you will quickly become their bitch, which leads to my second learning. 2. Don't get sidelined. As an outsider operating under contract the problem people want you gone but cannot remove you. Their best weapon is to sideline you. If they cannot own you they will ignore you. They will rearrange their meeting schedules and ensure you are not invited. They will create and release prototypes and delivery plans without your involvement. They will write reports and opinions to their management with all kinds of complaints and fictions and you have nothing because you are out of the game.

peoplefromibiza 5y ago

> if you spot something "wrong", don't react immediately and don't interrupt. Let the other party finish. Make a note. Gather more information The problem is that people doing the " wrong" thing (with varying degrees of wrong, which I did too and still do) will think they are right, they will usually do a presentation of their solution to people that are less knowledgeable than they are to win the "this was the only practical way given the time we had and also it works" (kinda, if we don't count when it fails) argument, lure them in their teams, keep pushing out half baked solutions that they will then rewrite "to improve them" for karma points, wasting everybody's time and company money. It works because there are always processes that are worse than bad software. So bad software usually is not the worse thing you can find in a company and can always blame some other department for being horribly inefficient, everybody wins, salaries are paid every month and 2 years later nobody knows what "the thing" does and why. But it's an excuse not not do better when it's possible. a task that takes half an hour can't take 12 days and 6 meetings "so we can talk about it" they say, truth is they are simply pushing their view. I get people are different and have different incentives, but we don't let people like me go into space just because we shouldn't point out a problem when we see it Software development is about being as thorough as possible while also being flexible. I always wonder why we keep asking people who see the problem to stay quiet while people causing them are encouraged to keep making them, so they can learn. What if people doing the "wrong" thing start listening and do what they are told and if it doesn't work they can blame who said them they were wrong? Saying no sometimes makes you the lonliest person in the office, but somebody gotta do it or nothing will ever change.

galaxyLogic 5y ago
I think it is most often wrong to use the word 'wrong'. That implies there is the right way and the wrong way. But in fact there are only better ways and worse ways, to do things. The "right way" somebody envisions to be THE right way can be worse than something even better. So instead of saying "Hey you are definitely doing it wrong" you can say "I can see an alternative way of doing this which might be better in some cases, for some purposes, for some users".
- 5y ago

hinkley 5y ago

> we never got the time to fix it The older I get the more convinced I become that this is Learned Helplessness. "We didn't have time." is essentially the same dodge as "C'est le guerre" was in France. "We don't have time" is a conversation killer. "We are working on that bit by bit" is essentially the same statement once you've subtracted the helplessness. Nobody is ever gonna schedule time for you to have integrity. If your self image depends on blaming fate or having a scapegoat elsewhere in the organization then you really should take a hard look at yourself, your team, and your motivations. Sometimes, the only way for things to get better is if you can get consensus from the developers that tasks that look like X really should take 3N units of time even though historically we've been quoting 2N units. On some teams you can't get that consensus, and you're going to have to be okay with that or move on. But the power of No is there you just have to use it. If you don't at least try, then shame on you.

cottager2 5y ago
The goal of writing software is rarely to produce a piece of well-engineered software. More commonly, the goal is to produce a product in a given time frame using the team of engineers available, which may be of variable quality. If you’re trying to make the software perfect, you’re likely doing something very wrong.
- hinkley 5y ago
  Businesses are in business to stay in business. Frequently nobody notices how much decline in capability the team is struggling with because 1) the change comes slowly, and 2) people are getting 'better' at taking calculated risks that keep the tempo up, masking the real situation until the company hits a brick wall and all estimates go from 3 weeks to 3 months overnight. As a customer these sorts of changes in behavior are hard to accommodate. It's almost always better to set an expectation that things take just a little bit longer than the customer would prefer but the software actually works when we do get it. When you have a date driven 'emergency' you deliver a small increment that handles the particular situation the customer actually has. Everyone mistakes wants for needs. When you foster that then you become part of a codependent relationship at best, exploitative at worst. Also if you swoop in and clean up everyone else's mess every time, they never experience any backpressure and you end up burning yourself out while they learn absolutely nothing. See earlier reference to The Power of No.

Litost 5y ago

This is really good advice, to which I'd add: 1) Don't lose track of the outcome, "being critical can easily put others in a defensive stance and make it hard to get that information", this also applies to the phase after you've gathered all the necessary information and need to fix it, if you've been too fast and loose with the blame cannon, good luck getting anyone's help afterwards fixing it or earning any respect for future work. 2) From the OP "This is when we should take a pause before pointing out something is wrong", this might sound weird bringing this up, but Mindfulness techniques as often also employed in CBT, which encourage you to observe the immediate thoughts, e.g. in this case fish out the blame cannon and let rip, but instead acknowledge them and don't act on them are great for developing this "pause". 3) From a Systems Thinking pov, complex adaptive systems often evolve in many small steps, rather than are designed so I'd extend your "But more often than not there is a good reason" to more often and not there may be many good reasons all bubbling away in the melting pot of despair. As an example my last company tried to implement the Spotify Squad model and it was a disaster, but it wasn't just one decision by one person that sunk it, it was a whole combination of decisions taken over time and feeding off each other, many taken by people who didn't even work there any more.

buzzard1 5y ago

flower-giraffe 5y ago

This is very good advice if the goal is to retrospectively find stuff that is wrong and how it came about. I think there a counter point that if someone else had not deferred or neglected pointing out something was wrong there would be less wrongs to discover. It’s certainly socially easier and nicer to avoid pointing out flaws but it doesn’t always result in better technical solutions.

codesnik 5y ago

calling many of those a "good reason" is.. I don't have a word. Something brittish probably. But yeah, just calling it out straight away sometimes shuts down communication, people become combative, and that's not good if you want to fix something eventually.

harry8 5y ago
> calling many of those a "good reason" is.. I don't have a word. I'm going with "Heroically empathetic"