This Is Why Managers Don't Trust Programmers...
ฝัง
- เผยแพร่เมื่อ 17 พ.ค. 2024
- Have you ever seen another programmer who wasn't as skilled as you get promoted? Did you tell yourself management was making a mistake?
Earlier in my career I didn't realize I was doing some things that caused managers to lose confidence in me. I would spend all my time writing code and never think about how I came across to other people.
In this episode, I share some harsh truths I've learned about how being a software engineer can cause us to do things we think the company wants - that actually hurt our reputation in the long run.
Companies are actually paying you for confidence as a programmer. And this episode is full of practical strategies for making sure you don't fall into traps that stop you from getting recognized for the great code you write as a programmer - before your career is really getting started!
Support me on Patreon:
/ healthysoftwaredeveloper
TechRolepedia, a wiki about the top 25 roles in tech:
healthysoftwaredeveloper.com/...
The Healthy Software Development career guide:
healthysoftwaredeveloper.com/...
Learn about one-on-one career coaching with me:
healthysoftwaredeveloper.com/...
CHAPTER MARKERS
0:00 Introduction
1:19 1. What Companies Really Want From Programmers
2:12 2. How To Build Employer Confidence as a Programmer
2:22 2.1 Minimize Communicating Problems and Doubt
5:42 2.2 Repeat Management's Desires
7:46 2.3 Anonymize Blame on Dependencies
10:57 2.4 Reduce Your Throughput
14:52 2.5 Elevate Your Coworkers
17:05 2.6 Over-communicate Status
20:11 2.7 Highlight Discovered Shortcuts
22:20 2.8 Document Verbal Decisions
26:58 Episode Groove
#programmers #managers #trust - วิทยาศาสตร์และเทคโนโลยี
Did you make the mistake of thinking just writing good code is what management really wants? How are you building confidence in you at work?
►► Know your options! Visit my wiki about the top 25 job roles in tech, TechRolepedia → healthysoftwaredeveloper.com/techroles/
There is one flaw with this video though: Everything is presented as if this was always the case, but it's been escalating as computers took over the world.
Every industry has some disconnect between management and workers - the question is, can you step over the pothole or is it ravine?
@@TheExileFox interesting thought.
that was awesome…kinda calling their baby ugly. that’s a sub 💯 lol
@@DeanDavisMarketing lol yeah after I used that analogy I wondered if it was a proper choice. Welcome to the channel!
HOW CAN YOU JUSTIFY TELLING A DEV THAT JUST WANTS TO WORK MORE TO GET INTO FUCKING MANAGMENT. How can you sit there and describe the state of development like that without busting out laughing. Our main job is to anonymize accountability and play best buddies? Youre describing a DEI nepo shit hole idiot fest dude. Why would I even want to be born on a planet next to this stuff let alone commit and work on it as if this was value. This is value to a ceo looking to score on indan dev work. Jesus FUCK.
I hate all the points raised in this video, but most of all I hate the fact that he's completely correct.
Its a sad world we live in where productivity and efficiency are held back by mismanagement.
Thank you. I don’t enjoy having to share this stuff. I do this because I genuinely care for developers. Coaching them is my job. If you heard the stories I do of what people are going through, you’d do the same.
Blaming management without taking your own responsibilities toward it is creating more problems than solving it. As IC, we have way more power in changing things around us than we care to admit, and when we do, we often expect our managers to do it for us. Why do we need a scrum master to change a status update into an effective meeting? Why do we need the PO to wait for the PO to clarify a story? Why waiting for the team manager to write down an onboarding manual for review guidelines?
If you think that the improvement is worth it, then there shouldn't be a problem doing it as part of your role, as long as you don't neglect your priorities.
Who woulda thunk that management destroys efficiency?
When dealing with idiots, you have to be diplomatic, especially if the idiots wield a lot of power over you and pretend you're bending into their dogma. Of course, this can backfire and when the shit hits the fan YOU will be the one getting fired, because they will never take the blame, but that's another story :)
@@theravenousrabbit3671 Not all management is counter-productive, just most.
Everything described in this video is more commonly referred to as “Playing the game”. I have often been told “If you want to last at this company, you gotta play the game.”
If you haven't already, check out the episode I did on the first software project in my career. I got screwed over by politics so bad it was incredible. Nobody tells you how the game is played until it's too late. I'm trying to change that, but man people don't want to stare the harsh truth in the face.
th-cam.com/video/d4hFQyuKVhs/w-d-xo.html
@@HealthyDev The most important advice imho is the one about leaving the paper trail. This will not only save you politically but also legally in the long run, because any verbal agreement in court is only worth the paper it is written on. I do a similar thing, but in the form of a Jira comment on the ticket, "how we decided in the standup to handle it". Make it a habit.
I would agree that some of it is "playing the game", but that's just what we have to do sometimes!
Playing the game of however destroying the company. Everybody is too afraid to speak up.
@@markusjohansson4949that’s the definition of politics. As Patrick Lencioni says in his incredible book “The 5 Dysfunctions of a Team”. It’s when everyone tells each other what they want to hear - and not the truth.
That’s definitely dysfunctional on a systemic level and different than what I’m advocating here - measured communication of problems. If anyone asks me point blank whether there’s a problem with something I always tell them the truth.
I predicted all of the numerous problems we encountered but my Manager did not want to listen or believe me! Managers have a lot of trouble with that!
Warning management about problems is always a mistake, they will think you are causing it when you end up being right. Rather than preventing it, you are better off preparing a solution and letting the problem happen then fixing it.
@@pcap8810 th-cam.com/video/BKorP55Aqvg/w-d-xo.html
@@pcap8810 "you are causing it"
@@pcap8810This is dumb because there are some problems you clearly cannot fix. They just don't care about reality and are bad managers. They need to fix themselves instead of me fixing them.
@@pcap8810 This is totally counter-culture for me, I'm caring about the customer too much. But on the other hand I totally see no other way as long as it's not my own company...
The "don't highlight problems" is so true and only becomes more true as you move up the management chain. In most businesses, it's better to let a dumpster fire continue to burn rather than be the one that points out the fire. It's not healthy or good for the business but in terms of career advancement, you'll never be rewarded for pointing out problems unless you've already solved them. If you need help or it requires cross-team effort to fix...just don't say anything. The safer path is to let things fail and have enough documentation to prove it wasn't your fault.
Jesus this is why I’m so burned out in IT. What you are saying is true, but for someone that can’t ignore issues, it’s constant stress. It’s also the reason IT systems keep getting less secure and less reliable over time.
You're absolutely correct. I wish it weren't the case, but it's reality. Unless your job is to be actually responsible for the cross-team efforts, trying to take responsibility for them is just setting yourself up for being blamed for things outside your area of control.
@@HealthyDev I learned this lesson the hard way. Dev team ends up being Tier 3 support for everything but nearly 100% of our outages were infra or DB related. I tried to fix them and while those teams were easy to work with and willing to engage, they had skill issues that negatively impacted the business's perception of me when they couldn't execute. Lesson learned the hard way but better to learn it now.
Exactly, positive thinking!
I may be a rookie about this but to me it's just sounds like bad ego of the management/those that are responsible so why should I respect that? If you buy hardware from an external supplier and they don't deliver on time or in the quality they promised, you expect damages, discounts or cancellation too.
I have made this mistake. I predicted a 18 month overrun on the project. I was given a warning letter for "negativity." I told them they were punishing good engineering knowledge.
BTW the project overrun 2 years so I was overly optimistic in fact
Hang in there. “I told you so” rarely gets received well in most companies.
At my former corporation, a Fortune 100 food delivery company, several people who pointed out based on math that the sap conversion would not work.
They were all fired. We were explicitly told that we had to run at the problem fast enough to overcome the hurdles instead of identifying risks and eliminating them. And that we needed to maintain a positive attitude that the conversion would be successful.
After the 10th conversion, they laid off most of the existing IT staff and replace them with infosys. 6 months later the entire conversion failed and they changed to another Consulting Group and rolled back the entire sap conversion and sued sap.
@@macmcleod1188 wow! That's the most extreme example of refusing to accept reality I've heard in a long, long time. Hope you're in a better place now.
@HealthyDev I retired at 51 in 2012. I was extremely lucky. They laid everyone off one day before I was going to give notice. So I got 12 weeks severance instead of the 5 weeks vacation time I was waiting to vest.
But it was pretty bad. My blood pressure was 166 and we had several heart attacks plus one Deloitte consultant in his thirties was taken out unconscious by paramedics and we never saw him again.
In the end, they realize that they really did need big iron and the cloud computing wasn't going to have the processing power they needed. The whole project was supposed to save 100 million dollars per year in salary costs but the cloud computing estimate for a complete conversion was a billion dollars per year.
And the HR department became extremely leaky about facts after the layoffs were announced.
@@HealthyDev the longer version is at 30 I had testicular cancer and had 5 months off work with pay. I realize I didn't get anything out of working at all and I just wanted the money so I started Living on half of what I made and after 21 years, I made my numbers. But the last two years were brutal. I literally slept in my car in the parking lot more than once and we had to work over 80 hours a week several times per month for the last 12 months.
"Elevate Your Coworkers", number one best piece of advice. This is the best "long term gain" technique in my experience, in the short term, it may or may not pay off, but in the long term it always pays off.
Agreed. Too often we try to take credit and pass blame. Part of maturing is to pass credit where it’s due. Most people know the key players anyway and their strengths and weaknesses.
As a consultant I started to coach the customer's technical team to present my findings at the end of my gig. This was after one of my earliest gig where the CIO asked me "Why did my people not know this?". This had an effect that I didn't anticipate. From here onward, teams wanted to work with me more because they were learning so much more. A lot of consultants think they walk on water and keeping the information is the secret to the next gig. It's actually the opposite that works best.
Meh. Sure your coworkers will know you are a rock star, but that stroking never makes it up to the Directors etc. So instead of helping your teammember finish their story while yours doesnt get done, your burn chart shows you are not a contributor to HR. And at the end of the year, everyone on the team has helped eachothers fickle a 100 times each... so when HR has to let someone go, its the guy with 76% completion rate.
I can't stress enough how accurate and valuable some of these advices are! As a software developer, I often voiced concerns only to be dismissed as negative or naggy. Over time, I learned to play along and celebrate our disastrous projects as if they were brilliant. Ironically, this facade earned me promotions and respect. It's a sad and ridiculous truth.
😂😂😭🤦🏾♂️
This can be subtitled, "How to survive in a dysfunctional organization." I also see a lot of overlap here with Robert Greene's book "the 50 laws of power." Finding that book opened my eyes to why I was being constantly passed over in promotions at work despite getting positive reviews and completing a reasonable workload.
48 laws of power is a great book for understanding the Machiavellian tendencies in people. And some of my advice does pertain to dealing with it. I hope it's clear I'm trying to advise people to deal with it by using strategies that still help us to be ethical in the face of it though. I don't think we should be employing many of those laws directly as a way to manipulate people. That's just my position of course.
@@HealthyDev A lot of your advice is directly in alignment with many of the laws. Minimize imperfections, praise others, don't outshine the masters, vye for visibility (court attention), etc.
"Reduce throughput". That's a tough one to hear but it is very true. I use to "over-produce" and it just bites you in the arse. Management begins to believe every code-change, feature, bug-fix, should be completed in a few days. When I recognized
this, management was asking me to complete mid-size projects in one - two weeks - managers who have ZERO s/w development experience. This is where I began to negotiate lengthier commits to "train management" that writing quality code takes time.
My BIGGEST gripe being a software developer is when someone (Management) with NO s/w experience says, "It's an easy change, right? It's 'just'.....".
I was a big over-committer. Got called out on it by my management because it made them look bad.
You really need to match it to your team; going too slow makes you look incompetent.
@@doughboy_6439 you mean like match their story points per sprint or something? That's a really bad metric. No two story points are the same (you probably know this). On top of that it encourages people to release low quality code to game the numbers.
@@HealthyDev how do you work around that then? How do you not look incompetent and reduce your throughput and commitment?
What he is describing is basically bad management. Sadly there is too much of it in the software industry. The real problem is that there are not enough managers with over a decade of engineering experience under their belt. This is a symptom of a young industry. Imagine an oil and gas firm, say Chevron, where all the people managing engineers and engineering projects have zero engineering experience. The result would be a disaster, from a safety hazard standpoint and commercially. Maybe it was like that back in the "wild cat" early days of oil and gas, but not now. Look what happens when an established engineering company is managed by non-engineers. I give you Boeing. What happened to the share price this year? ... I am sure you get the point.
You're absolutely correct. I'm suggesting solutions given the imperfect system we all work in. I'm an optimist at heart (believe it or not lol). I've just found sometimes it doesn't help people to sell them on how things could be better if they're suffering right now. Hope that makes sense.
@@HealthyDev Thanks Jamie. Good to know we’re on the same side.
Scroll way down to find this. If you coded well and the management promoted the "confidence" guys instead, that's their problem, not yours. If they didn't encourage you to have work life balance instead of burnout on an overscoped project, that's bad motivator and bad planning. Find the good manager instead of "playing the game", or become the manager yourself and change how it works for others.
The best example, for me, is HP and Carly Fiorina. How the hell did she get that job?
Been in this industry for nearly 20 years. I can't agreed more.
typical sprint cycle at my old job:
> get assigned task for an idea that clearly won't work
> tell boss your boss that an idea won't work
> write an essay why it won't work
> still get assigned the task
It took just 5 years of this for the hair loss to set in
Also: very typical for organizations to have "sprints" that are nothing like actual name-brand Scrum. Like, fundamentally a) your boss isn't part of the Scrum and b) you don't get "assigned" things in the sprint.
I think these things go together a lot. Shops that have "sprints" that are _exactly the same thing_ as two-week deadlines.
I've worked on so many projects where something unexpected comes up for any number of reasons. All too often managers yelled at me, called me incompetent, and much more as a result. This was even showing them what the issue was, potential solutions, and decisions that need to be made. As for "Jamie isn't responsible for Operations" - the lazy manager would typically come back and say "well, that's still your problem and you need to work with them to figure it out!"
Thanks for providing an opportunity for me to offer some clarification, this is great feedback. I consider a dependency someone who has ownership for something you're dependent on. If you have to do part of the work with them, you're a collaborator. And absolutely management will hold you accountable if you don't make sure the collaboration happens.
@@HealthyDev Yes - collaboration is important. I've had a couple of managers who refused to help out or otherwise assist with escalation, so I had to much of the leg work myself. Learned a lot from that process.
@@HealthyDevReally depends. If the manager cannot get the side-api team to fix a bug that's blocking you, how can you as a random coder?
My advice is to line up another job. The behaviour of your manager is absolutely unacceptable. You should never accept being a doormat.
@@ForgottenKnight1 Agreed. That's what I did - found a better job and better boss.
An old saying is "if you surface a problem, also propose one or more solutions."
It's a bad saying because not all known problems have a known solution. If they would have, they would have been solved, making them a problem no more.
@ForgottenKnight1, all problems have a solution. If you include time passing, it's no longer relevant. 😂
@@ForgottenKnight1 Not all problems are worth solving.
@@ForgottenKnight1 It goes back to the "The customer is always right[.]" quote. Everyone seems to forget the engineering process and skips from [issue] to [done] rather than brainstorm to discuss ideas before coming to any possible solution.
@@drno87 Those wouldn't be actual problems then, real problems need to be solved
Oh man, it's like you have done this video for me. I'm really getting frustrated with my management not seeing value in what I do, the several languages and technologies I have to juggle with, the problems I communicate.
Hang in there. I hope this year you can find some ways to let go a little bit and focus only on what you can actually control. Easier said than done, I know.
@@HealthyDev 🙏
@@HealthyDev Wise words no matter your field. I work in hardware development but many of your videos still apply.
@@erikyoung5139 good to hear. Yeah I figured some of this is just corporate culture advice, couched in situations programmers understand best.
- have a solution before you present the problem
- record all verbal decisions
Great advice, especially the second one. I have inadvertently been saved by doing the second one, just by coincidence of me preferring to communicate in written/typed form, from some scary situations that I had been directly involved in.
A good developer tries to understand a problem well before trying to find a solution. But this is not how managers are usually thinking. They don't want to hear much about problems, they want solutions.
All true, but then they could attack us about our time, when did we have time to think about the problem and the solution? We should have been doing something else.
@@ReneHartmannofc not, they are like brats that like having everything handed to them. They are not used to think much.
@@andrejszasz2816 If the problem was something about the product or the company, they are dumb. Just. Dumb. And the shouldn't be managing anything anymore.
These are good tips but always apply them In balance. I've seen people super successful at playing this game for a year or so until they got let go with adjacent reasons: "Not delivering enough", "Not highlighting problems early enough", "Not ambitious enough - cause they are not committing to enough things" and even: "Lack of leadership material" because of the fact that they were not specifying which dependencies were acting as blockers.
Those are all real problems. I said not to state the person specifically responsible for a blocker, not to avoid raising it at all. Unscrupulous people can use any excuse in the book to justify letting someone go, so at the end of the day there are no guarantees. I'm just trying to offer some practical tips that will increase the likelihood that you don't do something that gets you looked at negatively that could be avoided. Hope that makes sense.
Here’s one lesson to take with you: management is going to do what they do regardless of the games you play. If you want to stay employed don’t play games, don’t react to gossip, just keep your head down and do the best you can for your customers and teammates.
@@HealthyDev Yeah, reasons are sometimes made up. I've once heard "acting weird" but there was no answer for "Could you please provide me some examples, so that I could work on that?". And the question was not in the context of negotiating to stay, I just genuinly wanted to know what was that "weird" behaviour. I believe it was getting sick for a month though.
I recently figured out that people don't like being told their ideas are bad. When assessing risk or disagreeing with a topic, I found it better to ask questions addressing your concerns and essentially place confidence in their statement on them. I.e. "you have revealed the risks and are willing to pay the price of the fallout". I'm still trying to practice this in my day to day job, but it essentially is a game changer when dealing with leadership, especially upper management such as directors.
GREAT strategy.
Networking consultant for 7 years here, can fully understand and agree. Item i woult add in my profession: You have to determine, if the mangement wants actual security (and/or HA) or only on paper. Makes a huge difference when it comes to ressources needed for system + process integration. (Test environments are basically no topic since the hardware (+suscriptions) are insane expensive.)
Thanks for speaking up! This is some awesome actionable advice that I wish I had been given at the start of my career. Also these are unspoken rules that no one ever says out-loud because it would make them look bad, but you NEED to know them if you don't want people to make an enemy out of you in less than 3 months time.
Top best video you made. Important to be authentic, but be aware of interactions with people. Sometimes you forgot the rules and this was a good thorough freshup of things you can forget when busy in the project. Thanks!
Thanks! I only learned this stuff by doing it so wrong, so many times first...
Dang! Everything you say I can so relate. In the past I took on the role of being an all-in-one IT guy (e.g. IT and network support and Software Developer). I never had to deal with most of the things you talk about until now. Great stuff man, keep up the good work!
Thank you! So if I understand correctly you were a "one man IT guy" and now you're on a team, running into some of these issues? That makes sense. It's a very different experience on a team, for sure. Hopefully you're adapting to it OK.
This was a super useful video. I definitely often struggle with status updates because the problems I'm working on can be so specific that I'd have to provide a huge amount of context. I really like the point about highlighting other people's achievements. I do that with my friends all the time and it does absolute wonders, I should do it more in work. It sounds absolutely worth it to use the time gained from reducing your throughput to do things like writing status updates, crediting people and building team morale. Spending time building morale is the sort of thing that is very easy to sacrifice when in a rush, but you're right that it pays huge dividends in the long term for both you and the team / company.
Absolutely. I'm getting too many comments that people think I'm saying to just do these things I recommend and then not do any work. It's not an either/or thing. It's totally possible to do both as long as we account for it in how we estimate and commit.
You are doing a tremendous service to people in our industry! Thank you!!
You're too kind. Thank you!
For me, I have done a lot of this partly due to my autism. I communicate directly. I don't naturally see hierarchy. I point out issues and problems in the code, standards, processes, etc. I don't know how many times I'm told "Well, no one else is bringing this up." I even try to relate my behavior back to company standards (which as one might guess, doesn't go over well). It's really hard for me to see value in doing anything but direct communication and it's exhausting to "mask" all day at work.
I am thankfully working now for a company that encourages neurodivergent people and I've had managers take a different look at how I present myself when it comes to these things. There's still some on the business side that aren't always ok with it, but when they see the results I deliver they usually accept it since the results I deliver for them make them look good.
There is always room for improvement for sure, but I'm glad companies are becoming more aware that for people on the spectrum, this is who we are and we don't do these things to be abrasive or confrontational.
This was such a very practical career advice, thanks so so much.
Just remember that most adults are not really adults. They are young children in larger bodies. When you are lucky enough to work with a true adult, treasure it.
'Document verbal decisions' was one of those I had to learn the hard way - how many of us have spent hours grinding, grinding, grinding, only to be told later "that's not what I said" - AWFUL!
'Elevate your coworkers' is something I've been doing more of, and it has definitely shown results. It's hard because our industry tends to be sort of individualistic and competitive, so it feels like you are going against the grain, but I think teams thrive when they can know 'when to compete' vs 'when to compliment'
I actually got fired over one of those verbal decisions that didn't get documented. The guy actually using the feature said they wanted this automated email feature to work one way, so I did it that way, and then months later I got a performance review that said I screwed up that feature. What was actually wanted was never documented anywhere either, but I got all the blame for it.
Also try to do prototyping and let the Product Owners see how it's going to work early. Then they can say that's not what was meant and have them rewrite the ACs. Also change ACs with the permission of the PO and suggest ACs in a text.
Great video mate, I've worked in software QA for 7yrs, so worked pretty closely with devs, you're spot on and great advice, keep it up :-)
Gem of a video and wealth of information.
Exactly what I’ve experienced.
Thanks and keep up the great work!
Even if I learned some of those points the hard (and long) way, I still find extremely hard to cope with the fact that most of those problems exist only because in the business world people are way more often concerned by the way they look like than figuring what's best for the project and the company they are working for.
I’m right there with you. This wasn’t a fun video to make, in that I knew it would possibly raise visibility of some negative aspects of work culture. Ultimately I hope it helps people keep their job and the confidence of people that care too much about appearances, which turn out to be many of them.
@@HealthyDev Don't worry, your video is very useful. Knowing the truth is valuable especially when it is ugly. It took me about 20 years to realize some of those painful points.
Now I probably need two more decades to accept it.
@@Marcus_613 definitely. I’m still struggling to accept it everyday!
There's nothing worse than logging in, getting into the flow while trying to make sure you don't get So productive you work right through the stupid daily standup.
The moment you really get going, right There you know, mentally, you learn the hard way - it must be because it's 3 minutes past 9, and you're getting Slacked by 4 different people on the bridge.
So you stop everything so you can tell everyone that doesn't need to know, exactly what you're doing.
Then you can barely refocus the rest of the morning, to update a clueless vapid scrum master thst barely listens to your update - you describe a problem in detail, their response: "So you are blocked right now?" gee thanks so helpful.
I hate Scrum with a passion.
Definitely frustrating. This is why I recommend to reduce your throughput in the video. If we know we're dealing with this, we've got to cover our reputation with serious buffers.
Am sorry that you live that: you are clearly not working as a team, not listening to each other, and not feeling the need to do so. No methodology will help you there, you are better all on your own, take a contract, do it, get paid, and hope a new one is coming your way. If you don't want to work and engage with others, that's the only way you can do it without hurting everyone around you. But don't complain about others who's job is to make sure you're still getting pay next week.
That’s not scrum you are doing then. Scrum is all about reducing the number and length of meetings by scheduling the necessary ones, but if you are using the daily scrum for status updates, you aren’t doing it right. (There’s the Kanban board for status.) The standup should be all about asking for help/removing obstacles. But I am dreaming I know 😂
Man so true! And then you have the ones that will report every single activity - even attending one of my meetings where I simply told them on Teams there is no meeting because I just solved the issue with the client in 30 seconds and then didn't want people wasting their time waiting for the meeting to start. It's a deluge of micro tasks blurbs to no end that is difficult to sit through when you have this algo you are anxious to write and test.
The "vapid scrum master that barely listens to your update" made me laugh because I lived it as well.
Wow this is such a valuable perspective. Tysm
Very interesting, thanks for sharing these valuable insights!
Thanks again! Your videos help me critically think about my career progression. I’ll be applying this my next job role!
Thank you Jayme. This was just what I needed to hear today.
Thank you for this wonderful lecture. I am working at my office for 4 years and I did some bad mistakes. But over the time I realize that I need to overcome these situation and move forward with my career. This lecture just clarify what I actually need to do. Lastly THANK YOU so much. Love it.
You're so welcome! I've made everyone one of these mistakes myself (sometimes many times). Hang in there.
I’m not an IT-related Engineer, and all the recommendations you provided apply 100% to my role, and completely align with my own personal experience.
You probably already know this, but you still chose to direct this to just programmers, because you don’t want to make assumptions, and you are cautious and humble about your own knowledge and wisdom. This actually says a lot about you as a person and the level of consciousness you have developed.
I subscribed.
Welcome to the channel!
This video is really important! Thanks for sharing these great insights
Great content. If I end up with a difficult manager, I hope to remember some of these points.
Actually, I have been warned about a toxic culture in US companies. Allegedly, there is a usual "game" in big tech where the middle management tries to attack the messenger (the one who reports issues in their deliveries) and downplay the issue, while at the same time their engineers are already secretly working on a fix; when the downplaying works then the fix is released secretly, and if not (and the issue is escalated to higher management) then there is a good chance that they can present themselves as those who found a solution "just overnight".
My understanding from talking to them is this is just as prevalent in Indian companies.
Correct, these things are all signs of bad management with a poor attitude. They don't trust engineers because they essentially look down on them.
My wife and I are both in tech, but not programmers... all of this advice is still completely relevant to our positions.
Good to hear!
Wooow this video was shot at the right time, I am precisely at this moment in my career. We are starting a new project and we failed and lost a client using the methods they are using now. I been voicing a lot lately and. it was all in a bid to get architecture better. Been in a meeting with management and the CEO approved a solution I provided but I think I lost some peers to the solution. Given I am fulltime frontend I think I been telling backend to up their API games a little, I may have got me some less friendly peers based off it yet all I was trying to gun for was a smoother way for the project to actually have life.
This is terrific advice! Thank you 🙏🏽
On the first point, i had a conversation with a friend a long time ago, where i was complaining. He said something like this:
"No one cares if you find tons of problems, our problems are infinite and our time is not, so what are your solutions to the problems you deem most important?"
And that really struck me.
So if you see a problem but don't have a solution you should not mention it at all?
I am a manager and have some coders reporting to me. The thing that people have to realize is that there is set budget, priority, deliverables, timelines, and client relationships that all have to be considered in context with these problems that are being brought up. It's a delicate balancing act and there's no such thing as perfection. There is such a thing as an "iron triangle". Let's say I do want to fix some of these issues that are being brought up, I may need to go get funding first to be able to do that. And before that I need to deliver on certain commitments that have been made. Management isn't about having absolute control, It's about achieving balance between multiple competing factors.
Management is also about transparency, if your team isn't aware of what you have to do to make things happen, you can't expect someone just to assume or realize this out of the blue. Communication is key to get everyone aligned.
Most devs will understand all your dependencies towards other teams, clients, upper-management or budget etc. The usual problem is, that devs are treated in a "need-to-know" fashion about these things. Include them as much as possible in the whole process or at least offer it to them repeatedly. It will decrease friction and increase developer happiness.
In an ideal world sure. In reality devs have the least leverage, the client has the most and the company in between.
It's not about leverage, it's about making sure everyone is on the same page so you can collaborate effectively.
Those things are all irrelevant to whether someone should point out all the problems they encounter. Whether there is time or money to address them is a separate matter. What the video refers to is a bad management culture where employees are seen as troublemakers for discovering and mentioning problems they encounter.
You could definitely package shit nicely and with a ribbon. You are absolutely right about the difference between our perception of ourselves snd company’s perception of what value we bring.
Amazing advices and I love the guitar riffs interlude!
Once upon a time, as a newcomer to a project, I wrote a document describing 40+ problems and their proposed solutions. The team acknowledged it and even thanked me for "bringing it to their attention". But nobody did anything. In the end, it was I who fixed all those problems in the course of year and a half.
Understanding the problem is half the battle won. When you have people under you, perhaps you can communicate what you need from them to solve these problems. But most of the time, I think it is healthier for the team to just work on solving problems they find. Difficult to develop this culture but so far my teams that I have managed work this way. We do our best in our roles and we seek to fix the problems we see. Even if the rest of the world doesn't. We complain like it is a sport but we enjoy each other's company.
lucky you, I got fired for describing the 30+ problems.. the head of the branch did not want to change the obvious problems and having someone point out those problems put his competence on the line.. which transformed into a big target on my back! what a terrible company that was
@@and_I_am_Life_the_fixer_of_all hmm sounds like you dodged a bullet of a company.
But I think you should have just fixed the problems and then if they still did not accept it, then leave.
Undermining the trust people have of the people around you will not help the team unfortunately. I'm sure you've had times you went back and realised what you've built was not the most efficient or may have been over engineered. But that was the best decision you could make at that point of time.
I'm sure there will be people that appreciate the thought that went to it, but you wouldn't want those decisions to affect the trust that people have in you. Especially if 100s of people need to trust you to make a decision in order for the project to continue smoothly.
Did it benefit you in least when completed though?
@@and_I_am_Life_the_fixer_of_all You dodged a bullet - an incompetent and insecure manager making the workplace a mined field
I agree that a good skill is being diplomatic about how you make criticisms or explain technical complexity to the corporate overlords.
But I also think that needs to be STRONGLY counterbalanced with honesty. I see a lot of devs who either avoid saying anything or just outright lie about things to make management and other devs happy.
That is shortsighted in my opinion and while it does initially inspire confidence, months later when the problems they concealed come out, it erodes overall trust.
Being diplomatic, getting them in a receptive mode, presenting the findings as being for the collective good (although with a mature management it may also payoff for personal good, but most likely it may cause personal harm) is the way to go. I would not hesitate in presenting critical bugs, even though I have lost one job for the same.
And it happens at home too. The spouse/parent saying don’t think negatively.
Thanks for your feedback. My intention with this episode is definitely not to lie or be dishonest. If you watch any of my other episodes I'm constantly calling people to higher ethical standards even if it makes them look bad. When we overcommunicate problems or doubt, I don't think this is being more honest. It's not respecting that people have real thresholds of how much negativity they can handle. When we act like we can just spout endless problems (no matter how valid) and people should just "deal with it", we're not being sensitive to human nature. That's just been my experience.
@HealthyDev I get that too. And I wasn't advocating for the person who is just brutally honest and calls out everyone's mistakes all the time. That is exasperating.
The thing is, I think that person, the quiet ones and the yes men all have a common trait, which is an attitude of superiority and a lack of trust and respect for other people.
And I agree with your point that we need to show confidence in our work. One of my weak points has been a tendency to overshare about my own struggles which does sometimes lead to a decrease in the confidence other people have in my work (especially from that guy who loves to call out everyone else's mistakes).
All I am saying is that it needs a balance. We need to be able to be honest while still building a healthy rapport with our coworkers.
@@darthkreggles3798thanks for elaborating. That makes perfect sense. Appreciate your perspective!
That's inevitably what happens. You can't know how much is too much or when is too soon to raise concerns, so people eventually just keep quiet and make sure nothing can get blamed on them.
I wanted to say thank you for this video. For me personally, it's a banger and really hits home.
I decided to move to freelancing to deal with all this, but I can see at least some points to practice when I talk to less technical people. With my, hopefully, clients.
And also I'd like to add, that developers can relate in a way. Suppose we use some library, or framework or whatnot - and it keeps breaking, reports compilation errors even if we did everything according some tutorial or quick start guide. Or it is poorly documented. We would hate to work with that library even if it's greatly written in our favorite stack.
So yeah. Thank you. It took me a while to get to finally watch this video, but I'm happy that I did.
this is some real good insight. Thanks for this content
Yes, the advice is healthy for a career, but some of it is toxic for delivering value. At the end of the day, my job is to deliver value to a customer: that the customer hands over money and doesn't sue us is the only thing.
I hear you. Unfortunately you can’t deliver value if you’re not trusted because you’re unaware of the optics of how your work impacts other people. That’s my intention here. Delivering value is the goal. Often it’s being done in an imperfect system.
@@HealthyDev this is true. As a minority developer, you find this out alot sooner which enabled me to see this and adjust for it. Gaining trust is absolutely essential and it's easier to understand human nature than to be a purist, you may never find a "perfect" place for that.
Thank you for this video! I have identified myself in each and every thing of what you are saying!
It is hard and frustrating that we developers need to do those things, but it seems to be the harsh truth 🤷
Your video was a great reminder for what I should be doing better in my career and I will try to keep your advice in mind. 👍
I really need to hear this. Damn near every week.
I have always thought that bringing up problems is doing my job properly. And it's gotten me in stuck spots before. It worked well at my first job where I had years of trust built up but it is not working well as a default position when I start new projects with new clients.
oh boy that's hard advices. it makes the work place a little grim. Like, tech company are not following the scientific code of ethics, management just want to hear good news. thanks for your insigth, i feel less naive. Awesome content ! and nice guitar :
Thanks! Humans in general like to say we're virtuous and ethical, then do whatever is self serving in reality. As soon as you can embrace this, things get a lot easier. I choose not to play dirty like many do (did a video about this a few weeks back). But I also have just accepted you're going to run into bad actors.
You highlighted very well the politics of risk avoidance (aka non recognition).
This starts from the top down, everybody dodging away from this toxic sth.
However, Risk Management is pivotal for mature project delivery.
When you have to constantly firefight to get stuff done and deliver projects, there is sth fundamentally wrong.
In my experience, software projects have a much larger volume of issues and risk than many other types of work (I talked about this in another episode on forecasting and commitments). I think this causes people to get overwhelmed and start to shut down. You are correct that in theory people would have the emotional intelligence to know they are going to have to fight against the temptation to write off real problems. In my experience, it's more common that people can't deal with the volume of problems and so we come across negatively. I guess that's where I'm coming from in this episode - trying to help people do the best they can given an imperfect system. There's definitely a balance, and I appreciate your perspective it's perfectly valid.
@@HealthyDev and many are emotionally committed to the project, which is commendable, HOWEVER, may lead to a very toxic (actually toxic) project team incl. all of the antics.
Keeping a team together is a real skill and not many project managers/directors can pull this of.
I was brpught on a project where I am tasked to be the "glue", advocating for open communication about risk and change.
One thing that is clear is... NEVER take ANYTHING personally, even if people try to teach you your job. You just do your thing as intended, but take abort good ideas and stakeholder needs.
@@theaccountant666 oh wow, congratulations to you for pulling that off. I took a contract a few years back where I was hired to be the "glue" as well. I had no idea though until I was deep in it. I would never take that gig again. What they really wanted, was for me to be superman and tolerate the toxic behavior of pretty much all departments in the company. No wonder they needed "glue". They needed a fall guy. Hopefully that wasn't the case for you.
@@HealthyDevThank you.
I learnt my lesson a while ago on this very thing.
Just walk away from toxicity. They can not pay enough for this kind of BS.
Honestly, I got very lucky.
The project is very large and quite complex, but also has a human as a PD.
However, I also turned down many opportunities that just were not right.
I see age as a blessing.
@@theaccountant666 me too. I really struggled with aging during my late 30s, but sitting here approaching 50 I'm coming to much more peace with it. It's helping me to see things a little more neutral. I can totally understand how younger people resist some of the stuff I share, I would have too at their age. Sometimes I feel like I'm shouting into the wind. But if at least 1 person heeds it and it helps them avoid some of my stupidity, it's worth it.
I love that this video got recommended to me just now. I have a talk on Friday with two managers about the situation in the team and with the applications we operate. Some serious security issues that can potentially lead to data loss. Those issues were created by simply lack of skill. We have team members were you have to guide 1to1 where they have to click and they pause you all the time so they can take screenshots for their 1000th word document which they will never find again for that specific thing you showed them. These guys stage also productive servers with way to loose security settings.
I already knew that I can't just let my frustration onto them and have to be factual so I have written down some of the worst points I saw. Tomorrow I am gonna rewrite that and already have ideas how to make it more positive. Great video 👍
This is so heartbreaking to watch, but I can see how it's all true, and why I didn't get the promotion I wanted at my last job. Thank you for spelling it out - the cynical view is that corporations are lying through their teeth about what they want. The compassionate view is that they don't *know* what they want. Thanks for peeling back the curtain and showing us how we can *actually* get ahead when our technical skills aren't what's holding us back.
I have a huge problem with overcommitment. Then I get burnt out and quit. I've always been afraid that if I promise less and deliver less, I'll get fired or "be the weakest link" - but working as hard as I can and putting in overtime hasn't been helping me get ahead either.
Overcommitment was my calling card the first 15 years of my career. It's OK, we all learn at different times. I still have to practice setting better and more realistic boundaries.
Great advices. Thanks for this content!
I retrained to became a developer after almost 20 years, of which a decade was as a people manager and stalk holder on projects. Unfortunately this is mostly true, but I can say with confidence this is mostly a symptom of bad management rather than the way it should be. And it is not just an issue in software.
It is a frustrating reality that we need to "play the game" until you are promoted to a position where you can actually implement changes, but at that point it no longer benefits them (and may even hinder the own management targets).
I would say these issues are more prevalent in US based company cultures in my experience, and some European businesses have been a lot better; however it more usually comes down to the relationships you build with individuals around you. When those good people leave, it is almost always time to start looking too.
all management is bad management
Amazing content. Subscribed!
Welcome to the channel!
Just found your channel, love it. Thank you so much.
Any tips for dealing with tight deadlines and crunch time?
Here are a few episodes that may help:
Are Programmers Really To Blame for Bad Estimates?
th-cam.com/video/m5A1Wg8hYGo/w-d-xo.html
How Agile Teams Grow Toxic: Ep. 3 Forecasting
th-cam.com/video/4c7tXGIhavA/w-d-xo.html
How Agile Teams Grow Toxic: Ep. 4 Commitments
th-cam.com/video/p6VUHGe1HuU/w-d-xo.html
Can User Stories Make Software Projects Late?
th-cam.com/video/NavlPobhj7A/w-d-xo.html
Accepting What You Can't Change on a Software Project
th-cam.com/video/e8fYY0bYBDE/w-d-xo.html
Why Are You Making Programming Harder?
th-cam.com/video/s87Y-6EgwFI/w-d-xo.html
Programming Estimation: Estimate Software Tasks With Caution
th-cam.com/video/1aIENDoGmdA/w-d-xo.html
@@HealthyDev thanks so much.
I don't necessarily see the "reducing your throughput" as a problem of management. It's simply part of the job to try to include unknown unknowns which are more likely to arise in different scenarios. It only really becomes a problem if management starts pushing back on an estimate, at which point I'll be frank and offer to spend time coming up with a more concrete estimate.
Do you remember in the Old Days of NASA launches when they would stop the launch countdown for a Programmed Hold? It infuriated me as a kid "whats that for, everything is OK! why stop the clock???" and I never understood why those were there. Now I'm older and I sure wish I could have baked in some Programmed Hold time to some of the projects I've been on. It would have saved alot of Managment heartburn/untrust when the inevitable "unforeseen problem" cropped up. There needs to be a structured/trusted/accepted way to add that time to a project.
Well that's supposed to the PR review process, but usually product just wants you to go go go!
Just found your channel, this is some great insight that really resonates with me (unfortunately). You are 100% correct in every point you raised here. I am subscribing now and will go through the other videos you have kindly provided us, thank you very much!
AAA plus content. You made me see through the management's lens. IT veteran here, and boy, did I learn. Thank you so much.
Glad I could help! Thanks for the feedback. 👍
13:46 this is all the real job
It’s way more talky-talky than typey-typey
I've been out of the industry for close to a decade, but I've been thinking about returning. Hearing this video triggered a lot of memories in me that frankly... "make my blood boil". It helps me to realize why bums would rather eat cold expired soup out of a can than go to work.
I love coding, but I hate everything to do with business politics and kissing ass. I refuse to do it. I guess might just have to stand on the side of a freeway off-ramp with a cardboard sign that says, "will code for food".
This video is pure gold and applies to many other aspects of what it means to work and collaborate with people in the workplace. I have this bookmarked for life.
I think you're amazing at telling people hard truths. I'm not sure hearing this when I was a Junior engineer would have helped though. Sometimes you've got to see it.
When I became a manager, I saw how little people care about the parts of the product I worked my hardest on, but how something I think is trivial would help them. It's eye-opening.
Kudos to you for making this video!
You're very welcome. I'm not sure how much I would have listened either...
Great video. Thanks.
2:25 oh boy. I think a lot of programmers would struggle with that. Especially when so many are neuro atypical, and brutal honesty is a key trait.
I have coached several people who are neurodivergent and you are correct, they tend to be especially susceptible to doing things that get them in trouble from a visibility standpoint in our industry. My heart goes out to them, and I do what I can to help. But I'm of course not qualified to help them with their underlying challenges there, and I am up front about it.
@@HealthyDev As somebody with ASD I can only say that I have to REALLY HOLD BACK on 90% of the stuff I think and notice during my work and somehow filter and trickle it into meetings etc. I love my job but I can only do it from home fully remote anymore, where I can give myself all the comfort and healthy coping strategies to deal with it all. In an office building I would probably have regular meltdowns nowadays. The way neurodivergent people are handled/treated in tech is quite... desastrous to be honest. I choose to not disclose my disorder to my employer as I have done it in the past and I was either the "token acoustic genius" or immediately put into some kind of "must observe constantly" category and seen as problematic.
@@bassstorm89 I’m sorry to hear what you’re going through. Programming being already a high cognitive load activity combined with the social dynamics must be really difficult for you. Glad to hear you’ve found some strategies that work for you. Those of us who are not struggling with what you are already find it baffling and difficult. Hopefully things go better for you as you discover more strategies.
Reporting problems is super touchy, and that's a very good point. Just that can be a 2h video. Who to talk to, when, how, why...
Really good points. This resonated with me big time. I used to worry about problems that weren't my own all the time.
Ultimately gaining the perspective that I can share the burden with others and continue on with my own duties is what led me to salvation.
Also a healthy amount of uncertainty in my own worries, that theres a high chance it wont be a problem.
Other people aren't in my head. When they evaluate my productivity, they measure it by what I am supposed to be doing and accomplishing, not based on whether or not I'm completely content and at peace with what I'm doing and how I'm doing it.
From a burgerking burger flipper perspective, your manager evaluates you by being on time, and being dependable in your burger flipping duties. The manager doesn't care if you found some neat way to make the burgers tastier or theoretically safer. That isn't your job, and you will be evaluated on performing your job.
Yeah but if you are told to cook burgers with a piece of glass instead of the flat top grill....
Unfortunately I experienced the same thing. I want to face the problems head on, but it seems like people would rather ignore it and just collect as many checks as possible before SHTF.
Yep
6:38 this point is CRUCIAL
Spot on great advice!
This looks like good advice, and is similar to what I was thinking, hough some of it is new. Thank you for it.
You're very welcome! Glad to hear. Sometimes people think I'm whack for saying this stuff, though I get it.
17:43 over communicating status is a good idea and it has helped me in my career. However, isn't part of the status go against some of the advice you mentioned earlier? If your status is that you now see a big problem ahead then shouldn't that be communicated? If one takes the 'dont be a debby downer' approach. You'll just say everything is fine and then screw yourself when inevitably your deadlines slip.
Good question. I'm suggesting bringing up ongoing problems that still aren't resolved that you haven't already made them aware of. An ongoing status report is not appropriate for surfacing NEW problems. Hope that helps.
This is good
I 100% use some of these tips quite a bit. Especially when communicating to management about a question, or concern you have. Always, EVERY TIME reiterate your concerns by email after your talk with management. This is incredibly helpful when you have a manager who is either incapable of accepting responsibility for a mistake, or the type to always deny everything. In my line of work its called "Cover your ass." I could not tell you how many times a written account of a meeting has saved my skin over the years.
I think the biggest problem that we have with management and bosses in general is that they do not have the time, or energy to fully understand the work of the people they supervise. They only see a small section of it and forget about the iceberg effect. 10% of your work is highly visible to your supervisors, while they in general have little to no idea about the other 90%.
Thanks for the video! This is so accurate. I'm actually on the other end and devs who don't know how to do this drive me nuts lol.
It's amazing how many developers are gamers in their free time yet totally fail at the corporate game. Me included.
Games are just another problem to solve. Meanwhile, the corporate game has rules that don't even make sense.
@@View619 think of it like every time you level up your character, the enemies get harder exponentially. Then you get the idea ;)
@@HealthyDev Watching your videos makes me realize, even though we haven't been in the same companies, not even in the same continent, they more or less work the same. And with every video on your and other channels, I also realize the game is more about people than rules. That's probably why so many of us struggle with that, because we're too focused on tech skills and often neglect people skills.
@@View619they don't even "not make sense." It's much worse. It's Calvinball -- the rules are constantly changing in unpredictable ways.
Important topics that maybe some people don't want to hear or think about, but I am glad you address them, as they may make a difference in someone's career.
Exactly what went through my mind when I recorded it…thank you!
Thanks for this video. I used to not think much about my scrum updates, but at my new fully remote job, I learned too late that I wasn't exuding as much confidence as I thought I was. And by the time I heard that from my tech lead, it was too late, I already built that negative reputation. It's been a year and I'm still fighting it.
I'm so sorry. I've done this several times earlier in my career. Old habits die hard!
But that's a sign of a problem with them. No-one should be expecting shows of confidence. Agile updates should be just the cold hard facts.
best tech video that I needed 10 years ago
25:35 if you're saying this to your boss, aren't they going to think that you're the guy that points out their bad decisions and actually documents them so they're really on the hook. Doesn't this create a relationship where they know you're right, but see you as a potential adversary?
What's important is the positioning. As I said in that section, you need to front load the "bad news" reminding them that you can empathize with their frustration. And that you want to help the project be successful. If you just throw it in their face without those, yes that's not a good look.
this has happened to me. I saw vendors lying about product capabilities and warned the purchasing executive. when he ignored me and I ended up being 100% correct the result was that we wasted hundreds of thousands of dollars and he and I both knew I warned him about it, which put the crosshairs right on my forehead.
@@pcap8810 Isn't that crazy? I had a similar situation on a project 3 years ago. It's a little too hot for TH-cam but once the statute of limitations expires I may share it lol.
@@HealthyDev it’s a whole side to this business that most people seem to discover the hard way and you are doing a great service by talking about these things openly
I find it fascinating to hear this explanation expressed from the mindset of a developer. Hearing such a stark contrast of how things work/what people want (not wrong, just expressed from a radically different perspective) is an interesting exercise in empathy.
It’s almost as if, the more this resonates with you, the more the fundamental issue lies in how we communicate - and yet the more important it is to hear this message expressed in this way.
Really like this video. Everything you said is so true. Learning the politics of your industry is key to your career growth.
RE: Don't highlight problems...
This is hard to accept. I'm currently working at a place where the architecture is objectively horrible. Litteraly a multi-million-line code base that could have 80-90% of it's code reduced with basic DRY principals. And this is mostly by design from the lead architect, who desinged each page to bascialy be a seperate applicaiotn onto it's own, with duplicates of the CSS/JS and much of the backend processes and db queries repeated. I'm tempted to suggest to his superiors that the whole application should be rewritten, and let them know that it takes exceedingly long time to make simple changes.
As soon as you said "mostly by design by the lead architect" I think you know the right answer. Have you built so much trust with the architect's superiors by delivering reliably, and being right in the decisions you've made, that they are ready to trust you over the architect? It's not about who's right in that situation (hard lesson, I know) - it's about who's earned the trust.
@@HealthyDev Unfortuately, I've had little to no chance to contribute; in my first 6 months I've modified only a few dozen lines of code. The role was advertised as a developer position but it's turned out more to seem more like a business analyst, atttached to the largest and most problematic customer to fix issues that come up. Most days I do no work outside of meetings; I'm actively looking elsewhere.
Iam in a similar situation and I can tell you simply pointing out he setup a bad architecture to managment is going to get you nowhere. They are going to side with that lead architect.
Do suggest concrete solutions that help the project move forward though. Maybe the lead architect will disagree. If so ask about his reasoning. If he doesn't have good reasoning that will expose him.
Help and support your teammates. Be the teamplayer. Focus on the positive things you have influence on. This gets you the trust of not only the team members but also management.
And lastly changing this, even if succesful, is going to take alot of time. Maybe too much time, if so question yourself do you want to stay here? Is it worth it?
@@HealthyDev, earning the trust is so important. We all want our news and feedback from reliable sources. But fortunately there are leaders (although few) who believe there are no stupid questions, good ideas can come from anyone, etc.
It is all about being diplomatic, as well as speaking up if we spot critical bugs, and generally there are many good suggestions also in the comments section of this video. Thanks for talking about this topic. I am a recent subscriber to your channel.
@uvideo100 welcome to the channel! Appreciate your participation and insights.
Managers dont know what the hell they are doing and I see that *every* *single* *day*
You're speaking the truth, darn :) subscribing
Welcome to the channel!
Only a few min into this and i'm already mindblown lol. I've been having issues with my tech lead lately because he's been saying he wants me to work independently, with little pairing or requests for help. I see now that what he wants is confidence from me - instead i've been too open about my limitations or challenges in the codebase.
This is politics, not programming. This is sex work!
Dont find problems find solutions
Why are you working on that? Putting in place a solution. Why? Err, well, I found a problem.
You'll still get blamed for being negative in the sort of culture where you can't bring up problems you find.
very very good lessons, i can already notice that im understimating how long something will take so the reduce troughput fits.
Heres 1 lesson of my own though, the number one company confidence booster you can get is to have a customer or a business partner praise about you to the management. The tone-shift after was almost ridiculous.
It goes both ways
I have an episode about the other side of this relationship (if you haven't seen it already): th-cam.com/video/BN9BF0PyXHc/w-d-xo.html
Actually kind of got section 2.1's effect from the show "Adam Ruins Everything". Like he pointed out tons of valid problems in the world but never any solutions. You just get tired of hearing about problems with no ideas on how to solve them.
like those people who whine about climate change
@@monad_tcp The thing with climate change is that often they aren't actually point out the problem in order to fix it. They point out the problem to get "points" for their political side.
Knowing Adam, his solutions would actually create worse problems than the problem was in the first place.