What are you trying to persuade other technologists to do, and what are some of your best strategies? ►► Know your options! Access my FREE data hub for the top 25 software industry roles, TechRolepedia → jaymeedwards.com/access-techrolepedia/
To fully understand the process which is being supported by the development, but to forget how it's done today and build requirements based on what's actually needed not what the as is looks like.
Work from empathy (put yourself in their position, learn about what motivates their decisions). Don’t just bring up the pro’s, but be brutally honest about the con’s. Be consistent (when you believe in refactoring, actually do it)
Depending on how big the change is, I usually just write a separate branch implementing the idea for only a single feature or service and demo it to the team in my personal test environments. If you can't get a 30 minute meeting scheduled to do the demo and have a conversation, this is indicative of a bigger underlying problem than whatever the demo seeks to explore. Even the most internally competitive, aggressive, top tech companies encourage and facilitate attempts at innovation from all levels of employees.
A saying goes: “it’s easier to ask for forgiveness than for permission”… One way I lean towards is to make a working prototype and bypass all forms of asking for permission, and then gradually gain support for it. It depends on how controversial the change is of course. I made a super simple feature flag implementation which I showcased by toggling off newly deployed features when they made our service buggy. Then the sell for future development was really easy
Unfortunately management does not understand the difference, in most organizations, between what I can do in a demo, and what can be safely deployed and supported in a large organization or a large complex web of commercial end users, and still less, what the effect of a change can be, when it breaks the product in unforseen ways. I have seen this "torpedo everyone by demo" go very wrong, when you have to support an idea that breaks your product being forced on the team by one developer who broke ranks and went right to the CEO with an idea, without discussing its impact on the team, the product, and the end user base. I write software that deals with 5-10 million line of code codebases, having 500-1000 features in it that nobody even remembers are there any more, and evaluating risk and making changes to a product without breaking it, are non trivial, and the new guy, frankly, if he bypasses the entire team's wisdom and knowledge, is an A---hole.
Command and control structures suck, frankly, but they exist, for the same reason that brakes exist on trains. Because the history of trains shows that momentum can kill you, a lot faster than sitting there on the tracks going nowhere. That explains most Organizations, if you ask me. Sadly, paralyzed by our own fear and our own technical debt. We might fail, so we won't try.
@@WarrenPostma yep that's been something I struggle with too. Organizations need courage to do anything meaningful. You can't do anything meaningful without risk.
@@WarrenPostma ok I agree 😉 As all these things, there are more nuance to it than what can be explained quickly. I think though that management should understand the concept of a shallow/non integrated prototype, it’s their job to manage the team and the product, the least you can expect is them knowing the nature of what they manage. I’ve had the privilege of managers that understand when I emphasize “this is a prototype, built with mock data, etc etc”. But yea, you need to know what’s viable to make a prototype out of in your specific situation
To me a key in acting ‚persuasive‘ is staying absolutely calm, when others start yelling or get loud. Let them yell or argue, don’t react to that, but always get back to your clean argument. This worked out for me in a very well manner. Yelling can’t beat the clean argument. Don’t fall for yelling, stay convinced. I opened closed doors everywhere.
it depends on the organization. i worked in a company where yelling, sucking rooster, manipulating, sabotage and other dysfunctional tactics work. when that happens, my advice is to just leave that company ASAP.
@@guidosalescalvano9862 You can wait the yelling people out, and leave the room, without quitting your job. If the yelling person IS YOUR BOSS, yes, quit.
As much as I tell myself "business goals should not be held back by personal relationships (or lack thereof)", most humans are not cold, calculating business machines- personal relationships DO matter in almost any context. Something I just didn't get for the longest time. Reality is not a mathematical ideal.
People are pretty well conditioned to immediately say no to things if somebody asks them for something. No becomes automatic, a reflex, especially when people are in a much higher demand for their approval or support. So phrase your requests in such a way as to make "no" the answer you want to receive, instead of a "yes". "Do we want to get stuck on this obsolete technology that's costing us x amount of time every quarter when we're trying to grow quickly?" vs. "Hey boss, can we completely overhaul our system in a way that'll speed us up down the line?" Either way, you'll still need to go into more detail, and explain the change you want to make, but the first way of broaching the subject gets a "no" answer pretty easily, which you can agree with and propose your solution. The second way might also get a no simply because it sounds like a big ask even if they're inclined to want the same thing you want, and then you won't even get a chance to explain what you want to do and how it might benefit the company because the person doesn't want to have to commit to a "yes" or spend a lot of time and energy thinking through every implication of the question. As a bonus, people generally weigh a loss, or risk of loss, much more than they do a gain, or potential gain. The first question creates a sense of loss, which people want to avoid. The second offers a gain, which is less of a motivator for taking action. These are both the same exact question, when you break it down, but one gets the other person on your side a lot easier, and creates some urgency. It's important to get people on your side, and not make it an adversarial process. If you can convince somebody that you're both on the same side of a problem and you're working together to solve it, then your negotiation is really a collaborative effort with the other person invested in you both being happy at the end of it. And two heads are better than one anyway. The other person you're negotiating with might have ideas that are even better than the ones you were bringing to the table. If you come at it as you vs. them, where you're trying to impose your will on the other person, you'll be less likely to convince them and be less likely to get the best result you could have gotten.
In my team we have something called the "Developer Forum". Which is a special meeting only for developers where we can freely discuss and share knowledge for technical aspects of the work and propose potential improvements. Meaning if there is an idea that needs manager approval it will typically be backed by team through the developer forum, which makes it much less likely to be denied. I can highly recommend having a developer-only meeting like this.
I find it really sad that typical managers need to be "persuaded" into "allowing" developers to take actions that they believe are best for a project. I find it infantilizing and reductive. The job of managing people shouldn't be so much about "controlling" human assets as much as trusting them and giving them the support structure they need to do their best work. This mistrust stems from most managers being non-tech people and having no insight or understanding of what coding is and for them, code is black magic and coders are not to be trusted. The truth is that working around this requires interpersonal skills that most devs don't have or that they will only develop over many years of dealing with this kind of issue. I'd even go so far as to say that in some instances you might end up learning some manipulative behavior to deal with non-tech managers and this, imho, is bad and risks affecting your personal life negatively. I touched this point in my last comment the other day but I do firmly believe that the best management for devs is former devs or at least people with a proper grasp of what coding is so that they will be able to trust their team to make the right calls and do the right things and fix their mistakes when they make them instead of feeling the need to either take the decisions or at the very least veto tech decisions. I get that this is mostly a pipe dream and that the next best thing is for devs to learn to work around it and develop the proper interpersonal skills to deal with non-tech managers and avoid much frustration, but I still feel it's a shame. On the other end of the issue is non-tech considerations that have to be taken when making tech decisions. You flip the problem on its head because then devs aren't necessarily aware of or sensitive to business or logistic issues such as costs, deadlines, impact on other projects, customer requests, etc. The only difference is the power dynamics in this case because the traditional model has managers being the "bosses" of devs - which is in my opinion the root of the problem where instead it should be a collaborative model where there is trust, open comms and full cooperation between devs and a person acting like a communication funnel between tech and non-tech. I really enjoy your videos, they make me reflect on my own career and I'm glad to see that the issues I've identified over the years haven't been unique to my own experience. Thank you!
Some great thoughts and points here. I pretty much agree with your conclusions. Since i find many people are dealing with command-and-control management structures, I try to help them succeed the best they can, even though it isn't optimal for our line of work. That doesn't mean I'm not an advocate for more trusting environments though, absolutely!
Not true, it's not developers lacking interpersonal skills or emotional intelligence or whatever bullcrap people cook up. Reality is that some managers are garbage at their jobs, and when they don't know anything about the subject, they rely on their "gut instinct" i.e prejudice, bias and discrimination to decide competency and trustworthiness.. This of course means they trust manipulative, incompetent fools while distrusting talented and good devs who don't match their prejudiced image of a person should look/behave/act. There's a reason a lot of software is garbage, it's because the decision makers are bumbling morons, they just get rewarded for it anyway.
I agree, but I've also been on both sides of this. Recently my friend started working with me on my project, with the plan for him to take over architecture. His very first act on the codebase was to create a folder named "v2", thereby by implication relegating all prior work, many years worth of effort as "v1". Keep in mind he had no knowledge at all of the existing architecture, or any idea of what was good or bad about it. He just knew we needed v2. He then spent several weeks working on his open source architecture template to generate the v2 scaffolding. When that was done, he had a semi-working demo that could make a call to a weather forecast API (pssst, it's not a weather forecasting app). He then spent the next 6 months trying to get that to run on Kubernetes (we're a 2 person development team with no customers, but he wanted to make sure it could scale). If I said boo to a goose about any of his work, he complained that I was micromanaging him. All of his work was on a branch too. If I begged him to check in what he had to master he would say it wasn't done yet and flippantly respond with "I'm not gonna work off master." So any effort on my part to try to rein this back in would be "infantalizing" on my part? No. The sword cuts both ways.
@@HealthyDev Well yeah, in a real company that's what would happen. In this case its a startup, just him and me. He lives overseas and we were separated by a 12 hour timezone difference, which made things even harder. I've concluded it's too difficult to do heavy, early-stage architecture remotely like that, so I'm not doing that any more. I need people here with me in Austin, TX. I'm looking for partners actually, if you have any ideas, but I know you think I'm too crazy and probably would be hesitant to send anyone my way. I'm a decent guy if you got to know me.
What in the BADASS new studio backdrop is going on here 👏 Is this the same room? Jayme, 12/10 on the production quality and content; really love the new visuals, and the buttery smooth guitar transitions as well. Love how by playing the guitar you are actually "speaking" to one of your own points, allowing your audience to get to know you better, thereby creating a more authentic connection with us. And of course, great content as always! What a gem. All this is really good stuff that I would have loved to know much earlier in my career. With regard to what I have done.... in the distant past, I tried to hammer an idea through, just because I "knew it was right." It took me a long time to realize this really isn't an effective approach. I have found the most important piece is exactly what you focused on primarily in this video: building relationships. Building strong human relationships build on trust, empathy, kindness, an authentic desire to connect with your teammates and make their lives easier, and being a professional who consistently delivers and has a great attitude are the things that I strive for to help me gain support for ideas.
Ha! Thanks Brian. 😊 Yeah it’s the same room. Great to see you on here and appreciate the feedback. I didn’t realize how important relationships were on software projects until 12 years in. Oh well, better late than never!
Thanks Jayme. In college, I studied Business and I was basically on track to go into marketing. However, this didn't happen because when I graduated in the 1990's, there was a really severe recession. In southern California, the aerospace industry was downsizing and jobs were really tough to come by. So, I enrolled in a networking course at a tech school and was able to get a job in the IT field. Fast forward to today and I am working as a QA Automation Specialist. Regarding becoming more persuasive, in college, I read Tom Hopkins', "How to Master The Art Of Sales" which taught me that you must always remind your audience of the benefit of the proposition that your are pitching. Hopkin's book has helped me in my career even though I do not work in sales. But, we (and by we I mean all those working in IT) should at least know some basic sales techniques. Take Care.
Thank you for making this. I learned it the hard way. Basically do your job well enough that people start taking you seriously. Try to know people better, what they think is important, and what their pain points are. Using that information you can now sell whatever you want, as long as you can present it in a way that will benefit them.
I truly enjoy joining in all these comprehsensive curated courses out there which do so much to help us with dealing with persuasion techniques for the Modern Programmer, unlocking peak creativity, optimizing our health and wellness, forgiveness and meditation, avoiding vulnerability in the workplace, getting more done in less time, even if we've haven't had enough restful sleep or a healthy nutritional breakfast because in the typical workplace these days, you're expected to get online early and start signing and returning documents, renaming all files in folders, and have them all done well in advance of COB (whatever that is anymore). Fortunately, many of these courses are brown bag lunch and learn events, which allow us to grab a sandwich while while we learn more from the life lessons learned by the host. Thank you Healthy Software Developer for caring and sharing and helping us to LEARN MORE.
good discussion. one thing i would add is get some allies. persuade from the inside out. persuade your immediate team mates sso that when you end up in a meeting you're not talking at cross purposes. also just to reiterate one of your points, break it down into a good meaningful chunk that you can demo. use poc's to get buy in while redducing risk if possible.
And the final step is to go into business for yourself and then you will only have to persuade subordinate developers! (Perhaps investors if and only if it is not lean or you need to raise capital at some stage. Of course you will always need to persuade customers to buy also.)
I'm by no means a Software Developer. I recently took up learning introductory Python data analysis. It opened up seeing an opportunity for major process improvement in a business process in my organization. Instead of giving a sales pitch to my supervisor, I prototyped my idea and sent it for review. This solution reduces a high visibility several hours to multiple day process to answering a few basic questions and a 3-5 minute wait. Sometimes it's best to just do it especially if the person has no knowledge of their problems.
Sometimes it’s also that we end up persuading the wrong person and then realise the person doesn’t really have the influence needed to support our idea. Always important to recognise the right people who can help realise our ideas and provide that support. This can only be possible by good working relationships
Understand the stakeholders and decision makers. You need to do your research before any negotiation, and get the important people in the room as soon as possible and negotiate directly with them.
I pitch it, then leave it with " you should listen to me on this. If you don't you will probably regret it". Then walk away and not mention it again. That always strikes fear. I get the Macaulay Culkin (home alone, hands on the face reaction) once they see what I am talking about.
Good to have you back Jamie, I'm in a situation that's actually quite the opposite of this video. My fellow consultants are very good at persuasion, very entertaining and cracks a lot of jokes , asks engaging questions but I have reason to believe that they faked their resume. I'm seeing the trend of a highly experienced dev 20 yrs+ experience with no idea of the basic of programming, investigation and debugging. 6 months in and they have almost 0 output (and sometimes asked support from 2-3 diff. devs and compiled their work as theirs) During daily scrum: They come up of all sort of BS for being unable to deliver. like watching a 1 hour video for 2 weeks, reading the documentation, blocked and not proactive enough to investigate/push, and basically stops working on any impediment they encounter. If you have encountered and dealt with a similar situation in the consulting/contracting industry, I would love to see a video regarding 'Fake resumes and how rampant it is in our industry.'
Join the club. I have managers never listen to me or tell me I don’t know what I’m talking about. Months later they say “oh you were right” smh. What’s the point 🤷♀️
the trick is to do it once or twice and rub it in a little, and then hopefully they'll wizen up. If they don't, switch jobs because that's too much narcissism/ego, or they're too disengaged from the actual priorities of their job... both of which tend to be pretty stressful situations as time goes on
As a freelance programmer, I noticed the skill I must most use is my salesmanship. Sometimes people don't even see my porfolio/ask questions, it's all about closing the sale and using psychology. Nothing to do with coding skills lol
This would be the dream scenario for me: 1) To work with competent, curious, like-minded people who I have things in common with and can communicate well with, 2) To have a strong, authentic relationship with my manager based on trust and mutual respect, 3) To be given reasonable assignments that make sense and are doable. Challenging sure, but not so challenging that they are damn nearly bloody impossible, 4) For the work to be organized in a structured, methodical way, preferably with good supporting documentation, 5) To have my own personal space, not work in an open office environment. It seems so simple, but sadly, I have never found that. It frustrates me.
Really nice tips here great vid, often is hard to persuade but its part of the role i'd say, if we never tried to change anything for the better we'd be stuck
These are all really fantastic tips. This is a video I wish I'd had two years ago. I see how some of these strategies may have facilitated better outcomes.
I have a hard time with being upfront regarding what it will take to transition from, say, a Wordpress setup to something more JAMstack oriented. I can sell on the pros really well, but the cons I tend to overlook because the goal is so enticing to me. Definitely learning how to be better about that.
These are great points, that touches on many things i'm currently experiencing, however keep in mind that even if managers will listen, it does not guarantee that action will be taken. In my experience action is rarely taken when initiated by the developer even when persuasive, but I think your points will increase this possibility. There are several realities one must understand, that have nothing to do with software development, even if your manager is a former developer. Managers are beholden to internal politics, which has a high possibility to derail your request. When money is involved, like ROI, SAAS license, external developer tooling, things get shutdown quick. Managers will only listen and take action when things go sideways, ie, they experience the pain themselves while you resist the urge to say "I told you so". Your manager is risk-averse and will stick to what they are comfortable with, which is death in the ever changing world of software development. I'm sure there's more but those are the points that come to mind in my software development environment.
Definitely. No guarantees, but I can say from experience I often get things moving a lot of other people can’t when they don’t try this. Hopefully this will help people in the right circumstances!
I've requested that I take a lead role for our app dev team. A role that currently doesn't exist and that traditional went to my manager or was completely overlooked or just not done at all. I made a list of all of the responsibilities I imagined this role would have and have actually started implementing some of them. Additional when given the opportunity I speak up and out for the app dev team so that those who will be making those decisions can think back about what I'm already doing.
My favorite model is the Smart/Ethical CTO/Architect centralized model. This gets rid of the arguing up and down the chain of command problem, it makes co-ordination and technical decision making and centers it somewhere where an architect/CTO can have some hope of success. The Architect or CTO for a project or company, needs to be a brilliant technical communicator, and a people person. Unfortunately 90% of my previous job's CTOs were narcissists. The Narc CTO is a huge anti-pattern in our industry. My current (awesome!) boss is one of the few sane ones out there. He's a tech lead/CTO and department manager, and he's approachable, and rational, and technical. Most prior jobs I've had, the CTO was none of those things. 2 or more "equal" developers on a project, where nobody has the right to call the shot, is an untenable product and project execution model.
Yeah, I've only ever seen narcissist CTOs. All of them are incompetent too. It's just idiot execs/managers hiring people based on whether or not they look or sound smart.
I have concerns regarding your 2nd point : I wouldn't recommend establishing personal relationships with your co-workers because it becomes increasingly difficult to set boundaries and manage expectations.
Having an authentic relationship isn't the same as being a close friend. Peter Block's book "Flawless Consulting" which I read about 10 years ago talks about this. But that if you have no relationship beyond work, it's all transactional. What are some of the places where you're concerned about setting boundaries and managing expectations?
@@HealthyDev Thanks for pointing me to that book, I'll sure have a look at it. Regarding what I was trying to say, my issue is more with the word "personal" because its definition is too broad ; Earning the trust of a colleague, sharing niceties and showing a genuine interest in someone opinion and personal values is one thing but I wouldn't trust a co-worker with personal information if that make sense, I had issues in the past because of it.
@@pingoo9693 I think I got you now. You shared something a little too personal and they used it against you. For sure. There's some discernment needed to decide what is and what is not appropriate to share with other people at work. In my experience though, there is a lot more we can share about ourselves than we think that actually builds up the relationship. But as you experienced, sometimes we learn the hard way when we go to far!
@@HealthyDev You got that right. I made a list of topics that shouldn't be discussed at work just to be safe : - Health conditions - Family issues - Politics/Religion - Negative feelings about your job/colleagues (unconstructive criticism) - Discussing about your love life - Money - Personal ambitions
@@pingoo9693 that's an excellent list. Thanks for sharing that with us!
2 года назад
Being open to change our original plan including the ideas from others that will support you that will make that them feel also owners of that plan and actually the results are better because they could see things that you haven't
My number one priority at work is to persuade people to leave me alone. I don't care what tech is used, whose ideas win out etc. I just want to be able to do my portion of the work, and then be left alone. I actually do this by proactively communicating. I have no problem bringing up a quick update meeting but hate when people ask me how things are progressing (mostly because probably just told you). Anyway .... its been working for me. I work on a small team on a long term project and this after just wrapping another long term project. My manager and director generally leave us alone and we update as needed. Its probably the best job I have ever had because of that. Also helps that the 2 other devs on my team I've known for a while and have zero ego
man that sounds like paradise. I'm the same way but haven't managed to find a place compatible with it, did have a stint where I got to do work that way when the high profile projects were slowing down, but unfortunately I guess I was too successful for my own good and it seemed like it didn't grant me enough clout for the autonomy I desired. Do you know if there's any signals I could possibly look for when job prospecting?
@@GrandpaRanOverRudolf it took me a while to find that. It wasn’t possible when working at startups. Now I work at a bigger corp. it’s not fast paced and exciting but I trade that for more of a personal life and time for hobbies
@jamessullenriot Proactive communication is very professional. This is the kind of stuff I’m always trying to tell people. If you want the job to be different, you gotta step up in some areas. It sounds like you did and now you’re reaping the benefits. Nice job!
@@HealthyDev Well my career has changed in the past few years. I'm not a better communicator than I am developer, and honestly, My life has gotten better as a result. Again, its part luck being that I am at the company I am at. I always have the option to make more money, but its not life changing money, and my time and sanity is more important.
@@jamessullenriot great attitude! Work is never worth sacrificing our life and family for. I feel like people either swing towards "work sucks, screw it, I'm doing bare minimum" or "I give it all, it's all that matters". There's a happy medium somewhere in there. It's hard to find for all of us!
This is advice I got as a manager. I can say if I like a dev it makes it all the easier to get things done. Just let the PMs know what you can do and they can sell that and run with it.
@@83hjf the key in his phrase is "if I like the dev". If you try the things in this episode, you improve the relationship with the manager. Which is the point. We all like to think we're purely logical, but we make decisions on emotion and likeability WAY more than we care to admit.
@@HealthyDev in my particular company there is no career path for a developer other than becoming a "leader" and then a "manager". there are seniority pay scales but not different roles, to avoid ego fights. you can become the person "people can ask questions about technology X" but you cannot TELL people to use technology X. when code reviews were proposed a few years ago, management rejected the idea as they thought "no you're not going to criticize each other's code because you'll be fighting all the time". so if we can't even review each other's code imagine something as wild as "forcing people to use something ". (recently the architecture team decided that Plain JS is the way forward and when I proposed TS I was flat out rejected. TS is not up for discussion at all, as the architect said "it provides no value" PERIOD. so I asked to be transferred out of that team after only one month. if after 7 years I get told that the architects decisions are not up for discussion, then I'll never be able to learn anything. i want to be more than a "code monkey")
@@83hjf that's really unfortunate. Typescript has tons of benefits. It seems like you'd be able to extract the strongest arguments from Microsoft's literature and medium articles to make a convincing case. Did you present anything, or was it just a verbal request?
I get a lot of pushback in the form of "that's too big and we're never going to have time for it", so I've developed the muscle for turning large projects into something that can be done a little at a time. The dishes do themself if you grab one dish every time you walk by, and the huge js repo converts to ts mostly automatically if you just have "change the file to ts/tsx" as a req for every incoming PR. There eventually reaches a point where I'll finish whatever's left as a one-shot, but that's way less work than halting the whole team to do a megaproject all at once. Management is way more open to doing it this way.
Depends on the size of the company too. Much easier to persuade people when you have vision on the strategic goals of the company and who is pushing for what amongst your superiors. Which is way easier in a medium company than a large one.
I work for BIG CORPORATION and in 7 years there they have never, ever listened to any of my suggestions, except when some manager comes up with the "same exact great idea" that i proposed before, months or years later, and my boss greenlights it. So, for pushing new stuff, i just go ahead and build it.
Nice job. It's always about relationships. Always. Also, think about this: Your job is to make it easy for someone to do what you want. The points made here are really flushed out from these two big ideas.
I've completely stopped trying to convince people about better methods. If you have to convince a tech lead or a CTO about the benefits of CI/CD, automated tests, or just writing tickets/user stories that don't require a developer to spend days trying to get answers from a stakeholder, they're not qualified for their job and time spent trying to convince them is time wasted on nothing, and I start looking for another job with a few more questions to grill the next possible job about.
I’m just curious, what was your persuasion strategy you gave up on? Every company I’ve ever helped had people who needed convincing. I’m interested in this company you found where you never need to convince anyone of anything to keep a project on track.
@@HealthyDev Most of the companies I've worked for have had this guy that "gets things done" that ends up as a tech lead or a CTO but has little or no knowledge of any structural form of development - just the next quickfix. Once he's moved to the CTO or tech lead role he effectively becomes a gatekeeper, nothing is allowed to change because everything he did was perfect. At one company I was we had around 80 developers on multiple projects but every single project was blocked from even having tools to do basic CI/CD because the tech lead "didn't believe in using Jenkins" so introducing changes incrementally wasn't possible - as no one had the needed permissions to make even the smallest changes. There were multiple strategies tried by me and quite a few others, small increments, developer meetings, talking to the CTO, I even calculated the amount of time some developers were spending on manual work that could easily be automated. Everything was just ignored. In the end (after five years) I gave up and left. About a year later the tech lead left and slowly the teams started getting permission to make changes to their work. The job before that I tried to lead with example, started writing unit tests for my code just to show how effective they could be. I wrote a bash script to make deployment a single step process (was a two page step-by-step word document before). A year later I was still the only developer that had written any tests, I was the only one that even ran the tests and the team lead had removed the test running from the deployment script several times. My current job, which I'm leaving after only a year, didn't have any of the tools either (even though they told me they had them during interviews). I sent an e-mail to my boss (I've only once met him in person even though we work in the same office) pointing out that it was probably not a good idea that I was the only person in the company with knowledge of the system I'm working on. He asked me to write down some suggestions, which I did. That was about six months ago and I never got a response. Now my replacement has told me that she was shown a future strategy for the project and it was literally word for word the e-mail I sent to the manager but never heard anything back on. I've had similar experiences at other jobs and that's what lead me to leave my current job without attempting anything more. I want to spend my time on programming, not playing mind games with people that are either on a power trip or just lack the competence to lead development projects.
@@gullijons9135 man, I'm really sorry! That sounds like an incredible run of bad management. I've had many bad managers too but most people don't go onto as many projects unless they're consultants like me. I hope things are better for you now.
I think you forgot a very crucial element: MONEY. How does your idea make more money for the business or save money for the business? It can be a bit tricky to measure, but you can at least try i.e. “If we have automated tests instead of manual ones, QA will spend just 10 hours per month testing instead of 60 hours per month”. Or whatever. This “ money argument” reaaally works wonders for managers ;)
They aren't forgetting that, pretty much all of the suggestions are for saving the business from bankruptcy and saving HUGE amounts of money. It's just that most managers and execs are too stupid to see it. They just don't know what they're doing, screw things up without ever being held accountable or being punished for it, and just get rewarded all the time. There's a reason tech is so garbage.
It's a difficult process dealing with humans. I have found it useful to focus on interpersonal skills and developing an emotional intelligence to be more persuasive. At the same time I also find it time consuming and annoying: some people don't want to be convinced and will waste your time and effort. You have to know when to pick your battles and who you're dealing with before taking the time to engage.
I really think this depends on the mindset of the person you're trying to influence. I've had good managers and team leads that are more open to new ideas and learning about their staff. Then I have my current set of managers - who either are on a rail with their own mindset for control purposes or have absorbed some other management style from a former/current boss or the company line. I was almost better off not knowing more about my managers and getting to know them better! I learned instead to just provide an honest evaluation of what's in front of me and have them make the decision (and they love making decisions!). I just make sure I note the decision made in case I need to hold them accountable later.... From a coaching perspective you may want to check out Robert Kagan's theory of adult development; I found it useful simply as a framework and not a blunt tool. "Changing on the Job" by Jennifer Garvey Berger is an easier read on the subject with the same caveats, if you're doing more personal coaching with your consulting.
often the skill of persuading is more important than technical one, because having a brilliant solution doesn't mean you will be able to establish it. In large organizations I often face many conservative people and it's a hard job to persuade all those of mangers and architects up to the certain person in the hierarchy. Last time I gave up. In another organization however it was easier, people were more open to listen. In general, it depends on the organization culture, and for me it's more important if people in an organization are open than how perfect their technical solutions are. Changing people is much harder than changing technology.
What if everyone took a few minutes every day to make the entire system better? What if when you see a log line could be clearer you just fix it? What if when you see a coworker struggling you help them (pair, ask, off-load, etc)? What if you are trying to fix a bug and spend 3 hours being confused by some code before figuring it out; and instead of just fix the bug and move on, you actually took 30 minutes to refactor so that the next person don't have to spend 3 hours trying to understand the code? What if everyone did that and the organization became 0.5% better every week? How much better would the organization be after a year? 20-25%? More than that! The effect is compounding (like interest rates) since every improvement leaves more time for the next improvement. And it also has an emergent property: it changes the culture to be one of **How can I make the life of my coworkers better** instead of **What's in it for me**
Definitely a good mindset and attitude. Not always realistic depending on the circumstances but I’m a battered idealist at heart so it has my stamp of approval. 👍😉
This is good advice, but it will only work if your organization is relatively healthy. I feel like this has to be said, for the sake of those devs who are NOT in a healthy organization. Sometimes there is nothing you can do. When the person making a decision is 1000 km away. When they havent programmed in 15 years but have the title of Architect simply for being with the company so long. When they got a position for being someone's nephew. When they simply don't have a KPI and all you are to them is a source of risk with no possible reward. Sometimes the only thing your can change is you employer.
Jamie, Great advice as usual. No matter what the highly-paid management consultants try to tell you or the enlightened practices that your IT Management pretends to do, we are all just sitting around a campfire 50,000 years ago trying to figure out the strategy for tomorrow's hunt. So it always makes sense to make friends with the decision makers sitting around the campfire with the rest of the tribe. But I would like to add one more strategy that I call the "Build It And They Will Come" strategy. This entails exploding an atomic bomb in front of those sitting around the campfire. Sometimes, this strategy works and sometimes it does not. It depends on how hungry the folks around the campfire are. If the participants are very hungry, it will work, but if they are fat and happy, it will not work. Let me explain. Back in 1985, I was in the IT department of a major oil company. At the time, this major oil company was using the "Command and Control" management style that all corporations of the time used and was inherited from the hierarchical management structures that were used by our military to successfully win World War II. The "Command and Control" management style demanded that all innovation must naturally come from the Top and proceed Down to the troops. Now we all know that times have supposedly changed since World War II, but the fact that the "Command and Control" management style being used today by the Russian military in the Ukraine to refight World War II is causing them to lose a war in 2022 argues otherwise. People always pretend to change, but they never really do. Anyway, I had been a geophysicist for this major oil company, and I figured that if you could apply physics to geology, why not apply physics to software? So I came up with the idea of softwarephysics. It seemed to me, that as an IT professional, all you had to do was punch a large number of buttons in the right sequence, at the right time and with zero errors. How hard could that be? Well, it is very difficult because of the second law of thermodynamics. There are just too many ways to punch the buttons wrong. Worse yet, our Universe is largely nonlinear in nature and that means just pushing one wrong button can cause catastrophic results! So in 1985, I began development of my own mainframe-based IDE called BSDE (Bionic Systems Development Environment) at a time when IDEs did not exist. The BSDE IDE was used to "grow" applications in a biological manner from an "embryo" and from 1985 - 1992 BSDE was used to put several million lines of code into Production by about 30 programmers. BSDE was an early mainframe-based IDE at a time when IDEs did not exist. BSDE was used to grow several million lines of production code by growing applications from embryos in an interactive manner. BSDE would first generate an embryo application for a programmer by reading the genes for the application. The application genes were stored on a sequential file containing the DDL statements for the DB2 tables and indexes that the application was going to use to store data. The embryo was then grown within BSDE by the programmer injecting reusable BSDE skeleton code segments into the embryo and by turning on the embryo's genes to generate SQL code and screens on the fly. This continued on until the application grew to maturity and BSDE delivered the completed application into Production. About 30 programmers in the IT department used BSDE to put several million lines of code into Production. The IT Management of this oil company gradually became aware of what was happening down below and soon embraced the whole idea. IT Management actually created an IT course on BSDE and actively began to train all IT developers to use BSDE. But in the early 1990s, the Distributed Computing Revolution hit and the demand for interactive mainframe applications crashed. So IT Management then went on to trying to survive in the new environment. But when BSDE first came out, the price of oil was very low and IT Management was very hungry for a way to improve IT efficiency at the time. I tried this same "Build It And They Will Come" strategy around the year 2005 when working for a fully-enlightened credit card company that had "empowered" all IT employees to become innovative on their own This time, I developed the MISE - Middleware Integrated Services Environment that automated all of the functions that MiddleWare Operations needed to perform. Again, I got about 30 IT workers in Middleware Operations to use MISE, but this time I did not get any support from IT Management. Instead, IT Management was quite hostile. I believe this was because, at the time, the credit card company was very fat and happy with an ROE of about 25%. The bottom line is that it is much easier to make changes to a desperate company that is very hungry than it is for a very large company that is fat and happy. Regards, Steve Johnston
You can try to dodge it, but the brutal reality is that managers see it all as business. And in a business world, the more you cost, the more the managers will listen to you. Best strategy to be a decision maker is to cost a shit ton of money. Then they'll listen. Everything else is secondary. Cherry on top: if they don't see above your head your price tag, then they're not good managers.
While having a higher cost does help (I charge a pretty high rate for consulting services), I find it's not a silver bullet. I sure wish that were the case! That's why I learned to do the things in this episode. YMMV 😊
At first glance it looks like: Developer is hired to do his job but he can't until he goes through the 10 circles of hell. I am exaggerating a little bit, not all of 10 steps are related to hell and are just normal BAU but some for sure are. I understand it would have sense if developer would try to push his own startup which would bring him some really big benefits in the future but going through something like #2 (which is just humiliating) only to be able to do your job - I don't see the point. It would be interesting to get some numbers (even approximate) around this. Me personally I never observed happy ending after usage of these 10 steps by others. Like never. I can't say I saw huge amount of such tries so may be I just really was "unlucky". That's why I am just curious how often this works at all. Just real life case: In the past in a project where I was working there was an architect who was doing all of these steps for many years and it gave like nothing. Project manager continued to ignore him. So he just left the project and found one where he could do his job normally without need to go through the circles of hell.
You don't have to be right, if you get the other person in a collaborative mood. They might be right, and have a better idea than you did, and then you can implement that instead and be happier for it. It shouldn't be adversarial. It shouldn't be you trying to convince the other person that it's your way or the highway. The goal should always be to get the best possible result, and get the other person invested in the same goal. In practical terms that means getting the other person to agree with you that there's a problem and that things can be better for both of you as the result of some action. The details of that action will come out during negotiation, as you collaborate on figuring out the best possible deal. Never be so focused on getting what you want that you won't take something better instead.
Hi Jayme! I appreciate the videos/podcasts you're putting out, it's been really helpful. I was curious if it would be possible/low-level effort to put out a "raw" podcast/audio of these videos without the guitar transitions? I notice that it is really hard for me to listen and take in what you're saying and then being surprised with the guitar transition then back to words. I am neurodivergent and it could be in how I am processing the information, but I notice the switch from music to words to music is really difficult for me. Thank you for this consideration!
Hey manny, thanks for the suggestion. Unfortunately there isn’t a low effort way to do that. I do have all my episodes on Spotify and iTunes as well but they include the guitar, sorry.
So… 1) Honesty 2) Authentic relationships 3) Provide clear success metrics 4) Clearly explain benefits Clear, short, sweet, brilliant. Agreed, developers need to learn how to manage up and sideways, because obviously your manager is not managing, your SDLC has been trampled into an unrecognizable “standup” meeting, and you can only afford to spend the small hours of the morning coding before your team and managers wake up and start scheduling more meetings and war rooms. So: 5) Become a manager in responsibility only and see how long you can maintain being an under appreciated coder, manager, dev op, technical writer, and PM/PO since no one on your team is getting job satisfaction as just one of those things without competent support, and you can’t get authorization to hire the roles your project actually requires because the budget was set last year by a recent college grad in Finance that used Excel to divide the yearly budget by the number of projects approved by the board for the year, and Marketing already spent three quarters of it for an unapproved “emergency” project so convincingly sold to them at hole 3. If you can actually do all of that: 6) Use the authentic relationships that last to go lead somewhere else that pays more, because your managers (probably plural) that haven’t parleyed your success into promotions or better jobs elsewhere are rightfully threatened by you for doing their job, your team is resentful that you got a “lead” title with no raise, the other department heads are still ego-bruised that they didn’t get to buy and force you to create custom integration for the “out of the box solution” that was so convincingly sold to them via a drunken bet on hole 9, and you can’t stand waking up every weekday and weekend to go back to that cess pit. 7) Repeat 6 until: 8) Caffeine is your life anyway and you’d rather create something that matters, so start your own business. 9) Sell it to Google or Amazon and retire to see if anything is left of you or your family to enjoy. 10) Play exceptionally beautiful guitar outro
Let's be VERY clear here: People don't want "personal relationships" with their managers for many good reasons, starting with the fact that they will - and I do not care how "good" you think those people are - use that relationship to take advantage of you every single day you work for that organization. WRT "measurable benefits," there's no "measurable benefit" to picking up your trash in the forest -- it will not ever benefit you for the duration of your life -- but we expect people to clean up after themselves when they go camping. That applies to software development as well. Doing things the right way is non-negotiable. It doesn't matter if there's an immediate, measurable benefit. The benefits of writing clean self-documenting code may not be seen for decades. WRT "future pacing" -- this works in small and mid-size orgs. It does not work in large orgs. Large publicly-traded companies work on the span of profit over quarters. They do not operate on years or decades, and the executives and mid-level managemers in those orgs certainly do not operate on making workers' lives easier.
If you feel managers will take advantage of knowing you to get the most from you as an employee, why wouldn’t you do the same? If you hold people at an arms length all the time, there’s nothing truly exciting to expect from work. Much like marriage, without the courage to lean in and be vulnerable you can’t expect anything substantial out of a relationship. If that’s all you want, that’s cool. I’m not here to force my values or worldview on anyone. But too many times I’ve been hurt, shut down, and get bitter and protective. At some point that bitterness and those walls I put up only hurt myself. Without the courage to forgive and try again, work becomes shallow, meaningless, and limiting. If we have decided that’s all it can ever be - then of course that’s all we’ll ever get.
Actually writing clean code is immediately beneficial, whether you're starting out anew or fixing up an existing garbage heap. It's just that managers are idiots who refuse to look at the thousands of hours of developer, QA, support time you just saved. They only see how much time the developer will spend on it now. They all have this idiotic idea that doing it the right way takes longer, which means they're idiots who don't know what they're talking about. They just what business talk from influential/famous person and think it means something.
@@FlabbyTabby maybe try one of the suggestions in this video. Create visual assets to show the savings. Get to know the manager. Pitch the improvement aligned with what they even care about. I see so many people NOT do this, it's depressing. We can either spend hours fuming about our manager, or we can accept that we have to step up our game and do the work if we want things to change. Persuasion is not a guarantee, but it definitely isn't going to happen if all we present is verbal arguments that are immediately forgotten, to someone we haven't even tried to build a relationship with.
@@HealthyDev Thanks! Yeah I definitely tried, in my case it was just that the manager wasn't interested in improvement at all, and there were other problems going on. Nothing I tried would've worked in that situation.
@@FlabbyTabby ah OK I hear you. Yeah I work with IT pros through career coaching and sometimes we're able to repair difficult relationships with people. Sometimes it's just not possible no matter what though - the other person has some growing up to do.
Love the video! Question about incremental persuasion, and I'll watch that section again. So you want to make a change, you break it up into 5-10 steps, and focus on the first step. Do you share your multi-step roadmap at any point, or kind of "keep those cards close to your chest?" I'm curious if you think it might be better to show the whole roadmap and say we're going to focus and measure step 1 only right now. Or if you think it's too "scary" or big to show your whole plan right at the start.
Excellent question. There’s no hard rule there, trust your judgment. I’ve not revealed the entire change up front when I’m in a lower trust relationship. If I already have a higher trust, established relationship I might share more of where things are headed. The idea isn’t to withhold or be deceptive. It’s more about reading the other party and working through the change however you think will be most comfortable and successful for them. Hope that helps!
Uhmmm, I do truly recommend study Chriss Voss (Black Swan) Tactical Empaty. Most of the arguments that developers do are technical arguments, but bosses are often emotional beings. You should connect and sell anything in emotional relationships.
That’s really weird reading comments… as CTO of small (~130 employees), I’m open to new ideas every single day, nobody knows everything, technology change daily and this is the only way to keep up… never thought that the management will actually need to be persuaded.
It sounds like you're a more realistic and open person than some in that position. I will say though, we all have our blind spots. I'm sure there are some things others have wanted to do, that you turned down. Probably because they didn't do some of the things in this episode! We all lack self-awareness, and I'd love to say we make decisions purely logically. But if there's one thing I've learned the hard way over many years, it's that our comfort and emotions steer our decisions more than we'd like to admit. In this episode I'm trying to help people who may be really frustrated, with leadership not as open as you, and to not feel like there's nothing they can do. There is. But it requires stepping up our game, not just complaining. Thanks for watching and offering your feedback!
I've been developing free software for surveying. How do I find people willing to fund development? I also have written a low-discrepancy sequence generator. I know there are people who use such sequences; how do I find them?
Here I disagree for a first time with the author. Not saying he is wrong, just different attitude after 10 years of watching ignorants being ignorants. Sorry. I want to say I like your channel, wish you happy times and I am going to continue to watch your great vids.
@@HealthyDev Then you might really like their sound! They're considered a metal band, but in actuality their music is much more than that. Check out the "Damnation" album, I think you'll quickly notice what I meant.
What about when the other dev on your team doesn’t want to move to a library or pattern that you know will speed up development or make the developer experience better?
@@richardhaw9757 yeah that’s sort of what I’m trying to help with by this episode. If you’re the one with the idea, I hope some of the things here may help you make a stronger case. I’m not trying to advocate for methods of persuasion that are manipulative or ignore facts. Quite the contrary! I just know the human element is a bigger part of the equation than some realize. Hope that makes sense.
I once talked to my coworker, who had many more years of experience, to convince him about using a new framwork. He said he liked it and it was a good idea. Then I talked to the boss so he called my coworker to ask him. The f..er then said if wasn't that good and we weren't gaining much. Be careful with those people.
I quit software developing. After 25 years. Industry is full of egos with shiny object syndrome. Industy lost a Senior Java developer and Im sure the all happy about it.
Usually, your videos have some great information, but this time, I think you focus too much in how to convince others about what you want, instead of how we can work together better, so that all ideas can be considered and we end up with a better solution for all parties. Lots of devs know better, but from experience, they mostly see it from only one perspective, and while their idea is good from that viewpoint, it's often terrible from other aspects. I do appreciate you mention that honesty is oh so important in communication.
Interesting. I’m literally telling people how to make something you want a win win for everyone by seeing it from their perspective. Did you watch the whole thing?
Another thing is to recognize when you cannot win. Some people are just plain obstructionist, and you cannot use logic to get past them. If you can’t engineer a safe space for them to have their own little fiefdom while you innovate, get out.
Someones been into the mushrooms again. Solid advice for fantasy land. if you do this so you can convince people to listen to you they will see the in incongruency immediately
What are you trying to persuade other technologists to do, and what are some of your best strategies?
►► Know your options! Access my FREE data hub for the top 25 software industry roles, TechRolepedia → jaymeedwards.com/access-techrolepedia/
come with proof of concept first
To fully understand the process which is being supported by the development, but to forget how it's done today and build requirements based on what's actually needed not what the as is looks like.
Work from empathy (put yourself in their position, learn about what motivates their decisions).
Don’t just bring up the pro’s, but be brutally honest about the con’s.
Be consistent (when you believe in refactoring, actually do it)
not. it wastes my time. : Just left as it. My own project my own way. Old times, we do hear what junior said and try to implement the same thing.
Depending on how big the change is, I usually just write a separate branch implementing the idea for only a single feature or service and demo it to the team in my personal test environments. If you can't get a 30 minute meeting scheduled to do the demo and have a conversation, this is indicative of a bigger underlying problem than whatever the demo seeks to explore. Even the most internally competitive, aggressive, top tech companies encourage and facilitate attempts at innovation from all levels of employees.
A saying goes: “it’s easier to ask for forgiveness than for permission”…
One way I lean towards is to make a working prototype and bypass all forms of asking for permission, and then gradually gain support for it. It depends on how controversial the change is of course.
I made a super simple feature flag implementation which I showcased by toggling off newly deployed features when they made our service buggy. Then the sell for future development was really easy
Smart move. Prototypes are awesome. Even better than visual assets!
Unfortunately management does not understand the difference, in most organizations, between what I can do in a demo, and what can be safely deployed and supported in a large organization or a large complex web of commercial end users, and still less, what the effect of a change can be, when it breaks the product in unforseen ways. I have seen this "torpedo everyone by demo" go very wrong, when you have to support an idea that breaks your product being forced on the team by one developer who broke ranks and went right to the CEO with an idea, without discussing its impact on the team, the product, and the end user base. I write software that deals with 5-10 million line of code codebases, having 500-1000 features in it that nobody even remembers are there any more, and evaluating risk and making changes to a product without breaking it, are non trivial, and the new guy, frankly, if he bypasses the entire team's wisdom and knowledge, is an A---hole.
Command and control structures suck, frankly, but they exist, for the same reason that brakes exist on trains. Because the history of trains shows that momentum can kill you, a lot faster than sitting there on the tracks going nowhere. That explains most Organizations, if you ask me. Sadly, paralyzed by our own fear and our own technical debt. We might fail, so we won't try.
@@WarrenPostma yep that's been something I struggle with too. Organizations need courage to do anything meaningful. You can't do anything meaningful without risk.
@@WarrenPostma ok I agree 😉 As all these things, there are more nuance to it than what can be explained quickly.
I think though that management should understand the concept of a shallow/non integrated prototype, it’s their job to manage the team and the product, the least you can expect is them knowing the nature of what they manage. I’ve had the privilege of managers that understand when I emphasize “this is a prototype, built with mock data, etc etc”. But yea, you need to know what’s viable to make a prototype out of in your specific situation
I really appreciate how you also address emotional intelligence issues in your videos. That's a very valuable content. Thank you
This 13 minute video gave me 10 of the most important lessons I learned and needed in my career right now.
To me a key in acting ‚persuasive‘ is staying absolutely calm, when others start yelling or get loud. Let them yell or argue, don’t react to that, but always get back to your clean argument. This worked out for me in a very well manner. Yelling can’t beat the clean argument. Don’t fall for yelling, stay convinced. I opened closed doors everywhere.
My first manager, who I followed to 3 different companies, taught me this 20 years ago. Absolutely golden advice. Thanks so much for sharing this!!!
it depends on the organization. i worked in a company where yelling, sucking rooster, manipulating, sabotage and other dysfunctional tactics work. when that happens, my advice is to just leave that company ASAP.
Leave if people are yelling. It's not worth it. Plenty of opportunity elsewhere.
@@guidosalescalvano9862 You can wait the yelling people out, and leave the room, without quitting your job. If the yelling person IS YOUR BOSS, yes, quit.
As much as I tell myself "business goals should not be held back by personal relationships (or lack thereof)", most humans are not cold, calculating business machines- personal relationships DO matter in almost any context. Something I just didn't get for the longest time. Reality is not a mathematical ideal.
Thanks for sharing your insights. Keep it going. Also, nice guitar playing.
People are pretty well conditioned to immediately say no to things if somebody asks them for something. No becomes automatic, a reflex, especially when people are in a much higher demand for their approval or support. So phrase your requests in such a way as to make "no" the answer you want to receive, instead of a "yes".
"Do we want to get stuck on this obsolete technology that's costing us x amount of time every quarter when we're trying to grow quickly?"
vs.
"Hey boss, can we completely overhaul our system in a way that'll speed us up down the line?"
Either way, you'll still need to go into more detail, and explain the change you want to make, but the first way of broaching the subject gets a "no" answer pretty easily, which you can agree with and propose your solution. The second way might also get a no simply because it sounds like a big ask even if they're inclined to want the same thing you want, and then you won't even get a chance to explain what you want to do and how it might benefit the company because the person doesn't want to have to commit to a "yes" or spend a lot of time and energy thinking through every implication of the question. As a bonus, people generally weigh a loss, or risk of loss, much more than they do a gain, or potential gain. The first question creates a sense of loss, which people want to avoid. The second offers a gain, which is less of a motivator for taking action.
These are both the same exact question, when you break it down, but one gets the other person on your side a lot easier, and creates some urgency. It's important to get people on your side, and not make it an adversarial process. If you can convince somebody that you're both on the same side of a problem and you're working together to solve it, then your negotiation is really a collaborative effort with the other person invested in you both being happy at the end of it. And two heads are better than one anyway. The other person you're negotiating with might have ideas that are even better than the ones you were bringing to the table. If you come at it as you vs. them, where you're trying to impose your will on the other person, you'll be less likely to convince them and be less likely to get the best result you could have gotten.
this is such an enjoyable way to learn, thank you for what you do!
It's really help mates. Btw your acoustic guitar is so relaxing. I like it
Delivered code always heals wounds, but sometimes getting an unexpected demo makes stakeholders very happy.
I like you experimenting with the music, and I think having the gradual should before and after helps a lot!
Thanks man, appreciate the feedback. 👍
In my team we have something called the "Developer Forum". Which is a special meeting only for developers where we can freely discuss and share knowledge for technical aspects of the work and propose potential improvements.
Meaning if there is an idea that needs manager approval it will typically be backed by team through the developer forum, which makes it much less likely to be denied.
I can highly recommend having a developer-only meeting like this.
Great idea!
I find it really sad that typical managers need to be "persuaded" into "allowing" developers to take actions that they believe are best for a project. I find it infantilizing and reductive. The job of managing people shouldn't be so much about "controlling" human assets as much as trusting them and giving them the support structure they need to do their best work.
This mistrust stems from most managers being non-tech people and having no insight or understanding of what coding is and for them, code is black magic and coders are not to be trusted.
The truth is that working around this requires interpersonal skills that most devs don't have or that they will only develop over many years of dealing with this kind of issue. I'd even go so far as to say that in some instances you might end up learning some manipulative behavior to deal with non-tech managers and this, imho, is bad and risks affecting your personal life negatively.
I touched this point in my last comment the other day but I do firmly believe that the best management for devs is former devs or at least people with a proper grasp of what coding is so that they will be able to trust their team to make the right calls and do the right things and fix their mistakes when they make them instead of feeling the need to either take the decisions or at the very least veto tech decisions.
I get that this is mostly a pipe dream and that the next best thing is for devs to learn to work around it and develop the proper interpersonal skills to deal with non-tech managers and avoid much frustration, but I still feel it's a shame.
On the other end of the issue is non-tech considerations that have to be taken when making tech decisions. You flip the problem on its head because then devs aren't necessarily aware of or sensitive to business or logistic issues such as costs, deadlines, impact on other projects, customer requests, etc. The only difference is the power dynamics in this case because the traditional model has managers being the "bosses" of devs - which is in my opinion the root of the problem where instead it should be a collaborative model where there is trust, open comms and full cooperation between devs and a person acting like a communication funnel between tech and non-tech.
I really enjoy your videos, they make me reflect on my own career and I'm glad to see that the issues I've identified over the years haven't been unique to my own experience. Thank you!
Some great thoughts and points here. I pretty much agree with your conclusions. Since i find many people are dealing with command-and-control management structures, I try to help them succeed the best they can, even though it isn't optimal for our line of work. That doesn't mean I'm not an advocate for more trusting environments though, absolutely!
Not true, it's not developers lacking interpersonal skills or emotional intelligence or whatever bullcrap people cook up.
Reality is that some managers are garbage at their jobs, and when they don't know anything about the subject, they rely on their "gut instinct" i.e prejudice, bias and discrimination to decide competency and trustworthiness..
This of course means they trust manipulative, incompetent fools while distrusting talented and good devs who don't match their prejudiced image of a person should look/behave/act.
There's a reason a lot of software is garbage, it's because the decision makers are bumbling morons, they just get rewarded for it anyway.
I agree, but I've also been on both sides of this. Recently my friend started working with me on my project, with the plan for him to take over architecture. His very first act on the codebase was to create a folder named "v2", thereby by implication relegating all prior work, many years worth of effort as "v1". Keep in mind he had no knowledge at all of the existing architecture, or any idea of what was good or bad about it. He just knew we needed v2. He then spent several weeks working on his open source architecture template to generate the v2 scaffolding. When that was done, he had a semi-working demo that could make a call to a weather forecast API (pssst, it's not a weather forecasting app). He then spent the next 6 months trying to get that to run on Kubernetes (we're a 2 person development team with no customers, but he wanted to make sure it could scale). If I said boo to a goose about any of his work, he complained that I was micromanaging him. All of his work was on a branch too. If I begged him to check in what he had to master he would say it wasn't done yet and flippantly respond with "I'm not gonna work off master."
So any effort on my part to try to rein this back in would be "infantalizing" on my part? No. The sword cuts both ways.
@@kdietz65 what about winning support with his superiors so they can support you in holding him back from a cowboy code rearchitecture?
@@HealthyDev Well yeah, in a real company that's what would happen. In this case its a startup, just him and me. He lives overseas and we were separated by a 12 hour timezone difference, which made things even harder. I've concluded it's too difficult to do heavy, early-stage architecture remotely like that, so I'm not doing that any more. I need people here with me in Austin, TX. I'm looking for partners actually, if you have any ideas, but I know you think I'm too crazy and probably would be hesitant to send anyone my way. I'm a decent guy if you got to know me.
What in the BADASS new studio backdrop is going on here 👏 Is this the same room?
Jayme, 12/10 on the production quality and content; really love the new visuals, and the buttery smooth guitar transitions as well. Love how by playing the guitar you are actually "speaking" to one of your own points, allowing your audience to get to know you better, thereby creating a more authentic connection with us. And of course, great content as always! What a gem.
All this is really good stuff that I would have loved to know much earlier in my career. With regard to what I have done.... in the distant past, I tried to hammer an idea through, just because I "knew it was right." It took me a long time to realize this really isn't an effective approach. I have found the most important piece is exactly what you focused on primarily in this video: building relationships. Building strong human relationships build on trust, empathy, kindness, an authentic desire to connect with your teammates and make their lives easier, and being a professional who consistently delivers and has a great attitude are the things that I strive for to help me gain support for ideas.
Ha! Thanks Brian. 😊 Yeah it’s the same room. Great to see you on here and appreciate the feedback. I didn’t realize how important relationships were on software projects until 12 years in. Oh well, better late than never!
Thanks Jayme. In college, I studied Business and I was basically on track to go into marketing. However, this didn't happen because when I graduated in the 1990's, there was a really severe recession. In southern California, the aerospace industry was downsizing and jobs were really tough to come by. So, I enrolled in a networking course at a tech school and was able to get a job in the IT field. Fast forward to today and I am working as a QA Automation Specialist. Regarding becoming more persuasive, in college, I read Tom Hopkins', "How to Master The Art Of Sales" which taught me that you must always remind your audience of the benefit of the proposition that your are pitching. Hopkin's book has helped me in my career even though I do not work in sales. But, we (and by we I mean all those working in IT) should at least know some basic sales techniques. Take Care.
Thank you for making this.
I learned it the hard way. Basically do your job well enough that people start taking you seriously. Try to know people better, what they think is important, and what their pain points are. Using that information you can now sell whatever you want, as long as you can present it in a way that will benefit them.
What you mean by pain points. Share an example please!
@@petarpopovic6487 basically a problem that costs them or annoyed them the most.
I truly enjoy joining in all these comprehsensive curated courses out there which do so much to help us with dealing with persuasion techniques for the Modern Programmer, unlocking peak creativity, optimizing our health and wellness, forgiveness and meditation, avoiding vulnerability in the workplace, getting more done in less time, even if we've haven't had enough restful sleep or a healthy nutritional breakfast because in the typical workplace these days, you're expected to get online early and start signing and returning documents, renaming all files in folders, and have them all done well in advance of COB (whatever that is anymore). Fortunately, many of these courses are brown bag lunch and learn events, which allow us to grab a sandwich while while we learn more from the life lessons learned by the host. Thank you Healthy Software Developer for caring and sharing and helping us to LEARN MORE.
good discussion. one thing i would add is get some allies. persuade from the inside out. persuade your immediate team mates sso that when you end up in a meeting you're not talking at cross purposes. also just to reiterate one of your points, break it down into a good meaningful chunk that you can demo. use poc's to get buy in while redducing risk if possible.
Absolutely! Persuasion by yourself is really hard. Winning over advocates is a big help. Thanks for sharing this. 👍
And the final step is to go into business for yourself and then you will only have to persuade subordinate developers! (Perhaps investors if and only if it is not lean or you need to raise capital at some stage. Of course you will always need to persuade customers to buy also.)
So going into business by yourself, you'll have 3 groups of people to persuade. Yes, it's important there too - as you just pointed out :)
I'm by no means a Software Developer. I recently took up learning introductory Python data analysis. It opened up seeing an opportunity for major process improvement in a business process in my organization. Instead of giving a sales pitch to my supervisor, I prototyped my idea and sent it for review. This solution reduces a high visibility several hours to multiple day process to answering a few basic questions and a 3-5 minute wait. Sometimes it's best to just do it especially if the person has no knowledge of their problems.
Sometimes it’s also that we end up persuading the wrong person and then realise the person doesn’t really have the influence needed to support our idea. Always important to recognise the right people who can help realise our ideas and provide that support. This can only be possible by good working relationships
Understand the stakeholders and decision makers. You need to do your research before any negotiation, and get the important people in the room as soon as possible and negotiate directly with them.
I pitch it, then leave it with " you should listen to me on this. If you don't you will probably regret it". Then walk away and not mention it again.
That always strikes fear. I get the Macaulay Culkin (home alone, hands on the face reaction) once they see what I am talking about.
Good to have you back Jamie,
I'm in a situation that's actually quite the opposite of this video.
My fellow consultants are very good at persuasion, very entertaining and cracks a lot of jokes , asks engaging questions but I have reason to believe that they faked their resume.
I'm seeing the trend of a highly experienced dev 20 yrs+ experience with no idea of the basic of programming, investigation and debugging.
6 months in and they have almost 0 output (and sometimes asked support from 2-3 diff. devs and compiled their work as theirs)
During daily scrum:
They come up of all sort of BS for being unable to deliver.
like watching a 1 hour video for 2 weeks, reading the documentation, blocked and not proactive enough to investigate/push,
and basically stops working on any impediment they encounter.
If you have encountered and dealt with a similar situation in the consulting/contracting industry, I would love to see a video regarding 'Fake resumes and how rampant it is in our industry.'
A lot of this boiled down to don't be a dick, be a real person, because relationships matter.
Join the club. I have managers never listen to me or tell me I don’t know what I’m talking about. Months later they say “oh you were right” smh. What’s the point 🤷♀️
the trick is to do it once or twice and rub it in a little, and then hopefully they'll wizen up. If they don't, switch jobs because that's too much narcissism/ego, or they're too disengaged from the actual priorities of their job... both of which tend to be pretty stressful situations as time goes on
Well, at least your people says that after some time. My folks come after as if it was their idea and I'm just a dude with dementia.
at least you got the acknowledgment for being right in the first place...
there is no point. just get over it. Not all about is work perfect + you can always leave.
As a freelance programmer, I noticed the skill I must most use is my salesmanship. Sometimes people don't even see my porfolio/ask questions, it's all about closing the sale and using psychology. Nothing to do with coding skills lol
Absolutely. Took me WAY too long to figure that out. Glad to hear you get it. 👍
This would be the dream scenario for me: 1) To work with competent, curious, like-minded people who I have things in common with and can communicate well with, 2) To have a strong, authentic relationship with my manager based on trust and mutual respect, 3) To be given reasonable assignments that make sense and are doable. Challenging sure, but not so challenging that they are damn nearly bloody impossible, 4) For the work to be organized in a structured, methodical way, preferably with good supporting documentation, 5) To have my own personal space, not work in an open office environment.
It seems so simple, but sadly, I have never found that. It frustrates me.
Really nice tips here great vid, often is hard to persuade but its part of the role i'd say, if we never tried to change anything for the better we'd be stuck
These are all really fantastic tips. This is a video I wish I'd had two years ago. I see how some of these strategies may have facilitated better outcomes.
Such great advice! Thanks!
I have a hard time with being upfront regarding what it will take to transition from, say, a Wordpress setup to something more JAMstack oriented. I can sell on the pros really well, but the cons I tend to overlook because the goal is so enticing to me. Definitely learning how to be better about that.
These are great points, that touches on many things i'm currently experiencing, however keep in mind that even if managers will listen, it does not guarantee that action will be taken. In my experience action is rarely taken when initiated by the developer even when persuasive, but I think your points will increase this possibility.
There are several realities one must understand, that have nothing to do with software development, even if your manager is a former developer.
Managers are beholden to internal politics, which has a high possibility to derail your request.
When money is involved, like ROI, SAAS license, external developer tooling, things get shutdown quick.
Managers will only listen and take action when things go sideways, ie, they experience the pain themselves while you resist the urge to say "I told you so".
Your manager is risk-averse and will stick to what they are comfortable with, which is death in the ever changing world of software development.
I'm sure there's more but those are the points that come to mind in my software development environment.
Definitely. No guarantees, but I can say from experience I often get things moving a lot of other people can’t when they don’t try this. Hopefully this will help people in the right circumstances!
I've requested that I take a lead role for our app dev team. A role that currently doesn't exist and that traditional went to my manager or was completely overlooked or just not done at all.
I made a list of all of the responsibilities I imagined this role would have and have actually started implementing some of them.
Additional when given the opportunity I speak up and out for the app dev team so that those who will be making those decisions can think back about what I'm already doing.
My favorite model is the Smart/Ethical CTO/Architect centralized model. This gets rid of the arguing up and down the chain of command problem, it makes co-ordination and technical decision making and centers it somewhere where an architect/CTO can have some hope of success. The Architect or CTO for a project or company, needs to be a brilliant technical communicator, and a people person. Unfortunately 90% of my previous job's CTOs were narcissists. The Narc CTO is a huge anti-pattern in our industry. My current (awesome!) boss is one of the few sane ones out there. He's a tech lead/CTO and department manager, and he's approachable, and rational, and technical. Most prior jobs I've had, the CTO was none of those things.
2 or more "equal" developers on a project, where nobody has the right to call the shot, is an untenable product and project execution model.
Yeah, I've only ever seen narcissist CTOs. All of them are incompetent too. It's just idiot execs/managers hiring people based on whether or not they look or sound smart.
I have concerns regarding your 2nd point : I wouldn't recommend establishing personal relationships with your co-workers because it becomes increasingly difficult to set boundaries and manage expectations.
Having an authentic relationship isn't the same as being a close friend. Peter Block's book "Flawless Consulting" which I read about 10 years ago talks about this. But that if you have no relationship beyond work, it's all transactional. What are some of the places where you're concerned about setting boundaries and managing expectations?
@@HealthyDev Thanks for pointing me to that book, I'll sure have a look at it. Regarding what I was trying to say, my issue is more with the word "personal" because its definition is too broad ; Earning the trust of a colleague, sharing niceties and showing a genuine interest in someone opinion and personal values is one thing but I wouldn't trust a co-worker with personal information if that make sense, I had issues in the past because of it.
@@pingoo9693 I think I got you now. You shared something a little too personal and they used it against you. For sure. There's some discernment needed to decide what is and what is not appropriate to share with other people at work. In my experience though, there is a lot more we can share about ourselves than we think that actually builds up the relationship. But as you experienced, sometimes we learn the hard way when we go to far!
@@HealthyDev You got that right. I made a list of topics that shouldn't be discussed at work just to be safe :
- Health conditions
- Family issues
- Politics/Religion
- Negative feelings about your job/colleagues (unconstructive criticism)
- Discussing about your love life
- Money
- Personal ambitions
@@pingoo9693 that's an excellent list. Thanks for sharing that with us!
Being open to change our original plan including the ideas from others that will support you that will make that them feel also owners of that plan and actually the results are better because they could see things that you haven't
I work in game dev and what I usually think about are our core tenets when being persuasive. It's simple but easy to overlook
My number one priority at work is to persuade people to leave me alone. I don't care what tech is used, whose ideas win out etc. I just want to be able to do my portion of the work, and then be left alone. I actually do this by proactively communicating. I have no problem bringing up a quick update meeting but hate when people ask me how things are progressing (mostly because probably just told you). Anyway .... its been working for me. I work on a small team on a long term project and this after just wrapping another long term project. My manager and director generally leave us alone and we update as needed. Its probably the best job I have ever had because of that. Also helps that the 2 other devs on my team I've known for a while and have zero ego
man that sounds like paradise. I'm the same way but haven't managed to find a place compatible with it, did have a stint where I got to do work that way when the high profile projects were slowing down, but unfortunately I guess I was too successful for my own good and it seemed like it didn't grant me enough clout for the autonomy I desired. Do you know if there's any signals I could possibly look for when job prospecting?
@@GrandpaRanOverRudolf it took me a while to find that. It wasn’t possible when working at startups. Now I work at a bigger corp. it’s not fast paced and exciting but I trade that for more of a personal life and time for hobbies
@jamessullenriot Proactive communication is very professional. This is the kind of stuff I’m always trying to tell people. If you want the job to be different, you gotta step up in some areas. It sounds like you did and now you’re reaping the benefits. Nice job!
@@HealthyDev Well my career has changed in the past few years. I'm not a better communicator than I am developer, and honestly, My life has gotten better as a result. Again, its part luck being that I am at the company I am at. I always have the option to make more money, but its not life changing money, and my time and sanity is more important.
@@jamessullenriot great attitude! Work is never worth sacrificing our life and family for. I feel like people either swing towards "work sucks, screw it, I'm doing bare minimum" or "I give it all, it's all that matters". There's a happy medium somewhere in there. It's hard to find for all of us!
This is advice I got as a manager. I can say if I like a dev it makes it all the easier to get things done. Just let the PMs know what you can do and they can sell that and run with it.
Unfortunately you are the exceptions and most managers won't listen to their own people, only the higher ups.
@@83hjf the key in his phrase is "if I like the dev". If you try the things in this episode, you improve the relationship with the manager. Which is the point. We all like to think we're purely logical, but we make decisions on emotion and likeability WAY more than we care to admit.
@@HealthyDev in my particular company there is no career path for a developer other than becoming a "leader" and then a "manager". there are seniority pay scales but not different roles, to avoid ego fights. you can become the person "people can ask questions about technology X" but you cannot TELL people to use technology X. when code reviews were proposed a few years ago, management rejected the idea as they thought "no you're not going to criticize each other's code because you'll be fighting all the time". so if we can't even review each other's code imagine something as wild as "forcing people to use something ". (recently the architecture team decided that Plain JS is the way forward and when I proposed TS I was flat out rejected. TS is not up for discussion at all, as the architect said "it provides no value" PERIOD. so I asked to be transferred out of that team after only one month. if after 7 years I get told that the architects decisions are not up for discussion, then I'll never be able to learn anything. i want to be more than a "code monkey")
@@83hjf that's really unfortunate. Typescript has tons of benefits. It seems like you'd be able to extract the strongest arguments from Microsoft's literature and medium articles to make a convincing case. Did you present anything, or was it just a verbal request?
I get a lot of pushback in the form of "that's too big and we're never going to have time for it", so I've developed the muscle for turning large projects into something that can be done a little at a time. The dishes do themself if you grab one dish every time you walk by, and the huge js repo converts to ts mostly automatically if you just have "change the file to ts/tsx" as a req for every incoming PR. There eventually reaches a point where I'll finish whatever's left as a one-shot, but that's way less work than halting the whole team to do a megaproject all at once. Management is way more open to doing it this way.
Depends on the size of the company too. Much easier to persuade people when you have vision on the strategic goals of the company and who is pushing for what amongst your superiors. Which is way easier in a medium company than a large one.
I work for BIG CORPORATION and in 7 years there they have never, ever listened to any of my suggestions, except when some manager comes up with the "same exact great idea" that i proposed before, months or years later, and my boss greenlights it. So, for pushing new stuff, i just go ahead and build it.
Nice job. It's always about relationships. Always. Also, think about this: Your job is to make it easy for someone to do what you want. The points made here are really flushed out from these two big ideas.
I've completely stopped trying to convince people about better methods. If you have to convince a tech lead or a CTO about the benefits of CI/CD, automated tests, or just writing tickets/user stories that don't require a developer to spend days trying to get answers from a stakeholder, they're not qualified for their job and time spent trying to convince them is time wasted on nothing, and I start looking for another job with a few more questions to grill the next possible job about.
I’m just curious, what was your persuasion strategy you gave up on? Every company I’ve ever helped had people who needed convincing. I’m interested in this company you found where you never need to convince anyone of anything to keep a project on track.
@@HealthyDev Most of the companies I've worked for have had this guy that "gets things done" that ends up as a tech lead or a CTO but has little or no knowledge of any structural form of development - just the next quickfix. Once he's moved to the CTO or tech lead role he effectively becomes a gatekeeper, nothing is allowed to change because everything he did was perfect. At one company I was we had around 80 developers on multiple projects but every single project was blocked from even having tools to do basic CI/CD because the tech lead "didn't believe in using Jenkins" so introducing changes incrementally wasn't possible - as no one had the needed permissions to make even the smallest changes.
There were multiple strategies tried by me and quite a few others, small increments, developer meetings, talking to the CTO, I even calculated the amount of time some developers were spending on manual work that could easily be automated. Everything was just ignored. In the end (after five years) I gave up and left. About a year later the tech lead left and slowly the teams started getting permission to make changes to their work.
The job before that I tried to lead with example, started writing unit tests for my code just to show how effective they could be. I wrote a bash script to make deployment a single step process (was a two page step-by-step word document before). A year later I was still the only developer that had written any tests, I was the only one that even ran the tests and the team lead had removed the test running from the deployment script several times.
My current job, which I'm leaving after only a year, didn't have any of the tools either (even though they told me they had them during interviews). I sent an e-mail to my boss (I've only once met him in person even though we work in the same office) pointing out that it was probably not a good idea that I was the only person in the company with knowledge of the system I'm working on. He asked me to write down some suggestions, which I did. That was about six months ago and I never got a response. Now my replacement has told me that she was shown a future strategy for the project and it was literally word for word the e-mail I sent to the manager but never heard anything back on.
I've had similar experiences at other jobs and that's what lead me to leave my current job without attempting anything more. I want to spend my time on programming, not playing mind games with people that are either on a power trip or just lack the competence to lead development projects.
@@gullijons9135 man, I'm really sorry! That sounds like an incredible run of bad management. I've had many bad managers too but most people don't go onto as many projects unless they're consultants like me. I hope things are better for you now.
I think you forgot a very crucial element: MONEY. How does your idea make more money for the business or save money for the business?
It can be a bit tricky to measure, but you can at least try i.e. “If we have automated tests instead of manual ones, QA will spend just 10 hours per month testing instead of 60 hours per month”. Or whatever.
This “ money argument” reaaally works wonders for managers ;)
Or at least, how does this make it easier/more reliable, and not cost us more money.
They aren't forgetting that, pretty much all of the suggestions are for saving the business from bankruptcy and saving HUGE amounts of money. It's just that most managers and execs are too stupid to see it. They just don't know what they're doing, screw things up without ever being held accountable or being punished for it, and just get rewarded all the time.
There's a reason tech is so garbage.
It's a difficult process dealing with humans. I have found it useful to focus on interpersonal skills and developing an emotional intelligence to be more persuasive. At the same time I also find it time consuming and annoying: some people don't want to be convinced and will waste your time and effort. You have to know when to pick your battles and who you're dealing with before taking the time to engage.
I really think this depends on the mindset of the person you're trying to influence. I've had good managers and team leads that are more open to new ideas and learning about their staff. Then I have my current set of managers - who either are on a rail with their own mindset for control purposes or have absorbed some other management style from a former/current boss or the company line. I was almost better off not knowing more about my managers and getting to know them better! I learned instead to just provide an honest evaluation of what's in front of me and have them make the decision (and they love making decisions!). I just make sure I note the decision made in case I need to hold them accountable later....
From a coaching perspective you may want to check out Robert Kagan's theory of adult development; I found it useful simply as a framework and not a blunt tool. "Changing on the Job" by Jennifer Garvey Berger is an easier read on the subject with the same caveats, if you're doing more personal coaching with your consulting.
Informative video. Thanks!
often the skill of persuading is more important than technical one, because having a brilliant solution doesn't mean you will be able to establish it. In large organizations I often face many conservative people and it's a hard job to persuade all those of mangers and architects up to the certain person in the hierarchy. Last time I gave up. In another organization however it was easier, people were more open to listen. In general, it depends on the organization culture, and for me it's more important if people in an organization are open than how perfect their technical solutions are. Changing people is much harder than changing technology.
Agree 100%! 👍
What if everyone took a few minutes every day to make the entire system better?
What if when you see a log line could be clearer you just fix it?
What if when you see a coworker struggling you help them (pair, ask, off-load, etc)?
What if you are trying to fix a bug and spend 3 hours being confused by some code before figuring it out; and instead of just fix the bug and move on, you actually took 30 minutes to refactor so that the next person don't have to spend 3 hours trying to understand the code?
What if everyone did that and the organization became 0.5% better every week?
How much better would the organization be after a year? 20-25%? More than that!
The effect is compounding (like interest rates) since every improvement leaves more time for the next improvement.
And it also has an emergent property: it changes the culture to be one of **How can I make the life of my coworkers better** instead of **What's in it for me**
Definitely a good mindset and attitude. Not always realistic depending on the circumstances but I’m a battered idealist at heart so it has my stamp of approval. 👍😉
This is good advice, but it will only work if your organization is relatively healthy. I feel like this has to be said, for the sake of those devs who are NOT in a healthy organization. Sometimes there is nothing you can do. When the person making a decision is 1000 km away. When they havent programmed in 15 years but have the title of Architect simply for being with the company so long. When they got a position for being someone's nephew. When they simply don't have a KPI and all you are to them is a source of risk with no possible reward. Sometimes the only thing your can change is you employer.
Jamie,
Great advice as usual. No matter what the highly-paid management consultants try to tell you or the enlightened practices that your IT Management pretends to do, we are all just sitting around a campfire 50,000 years ago trying to figure out the strategy for tomorrow's hunt. So it always makes sense to make friends with the decision makers sitting around the campfire with the rest of the tribe.
But I would like to add one more strategy that I call the "Build It And They Will Come" strategy. This entails exploding an atomic bomb in front of those sitting around the campfire. Sometimes, this strategy works and sometimes it does not. It depends on how hungry the folks around the campfire are. If the participants are very hungry, it will work, but if they are fat and happy, it will not work.
Let me explain. Back in 1985, I was in the IT department of a major oil company. At the time, this major oil company was using the "Command and Control" management style that all corporations of the time used and was inherited from the hierarchical management structures that were used by our military to successfully win World War II. The "Command and Control" management style demanded that all innovation must naturally come from the Top and proceed Down to the troops. Now we all know that times have supposedly changed since World War II, but the fact that the "Command and Control" management style being used today by the Russian military in the Ukraine to refight World War II is causing them to lose a war in 2022 argues otherwise. People always pretend to change, but they never really do.
Anyway, I had been a geophysicist for this major oil company, and I figured that if you could apply physics to geology, why not apply physics to software? So I came up with the idea of softwarephysics. It seemed to me, that as an IT professional, all you had to do was punch a large number of buttons in the right sequence, at the right time and with zero errors. How hard could that be? Well, it is very difficult because of the second law of thermodynamics. There are just too many ways to punch the buttons wrong. Worse yet, our Universe is largely nonlinear in nature and that means just pushing one wrong button can cause catastrophic results!
So in 1985, I began development of my own mainframe-based IDE called BSDE (Bionic Systems Development Environment) at a time when IDEs did not exist. The BSDE IDE was used to "grow" applications in a biological manner from an "embryo" and from 1985 - 1992 BSDE was used to put several million lines of code into Production by about 30 programmers. BSDE was an early mainframe-based IDE at a time when IDEs did not exist. BSDE was used to grow several million lines of production code by growing applications from embryos in an interactive manner. BSDE would first generate an embryo application for a programmer by reading the genes for the application. The application genes were stored on a sequential file containing the DDL statements for the DB2 tables and indexes that the application was going to use to store data. The embryo was then grown within BSDE by the programmer injecting reusable BSDE skeleton code segments into the embryo and by turning on the embryo's genes to generate SQL code and screens on the fly. This continued on until the application grew to maturity and BSDE delivered the completed application into Production. About 30 programmers in the IT department used BSDE to put several million lines of code into Production.
The IT Management of this oil company gradually became aware of what was happening down below and soon embraced the whole idea. IT Management actually created an IT course on BSDE and actively began to train all IT developers to use BSDE. But in the early 1990s, the Distributed Computing Revolution hit and the demand for interactive mainframe applications crashed. So IT Management then went on to trying to survive in the new environment. But when BSDE first came out, the price of oil was very low and IT Management was very hungry for a way to improve IT efficiency at the time.
I tried this same "Build It And They Will Come" strategy around the year 2005 when working for a fully-enlightened credit card company that had "empowered" all IT employees to become innovative on their own This time, I developed the MISE - Middleware Integrated Services Environment that automated all of the functions that MiddleWare Operations needed to perform. Again, I got about 30 IT workers in Middleware Operations to use MISE, but this time I did not get any support from IT Management. Instead, IT Management was quite hostile. I believe this was because, at the time, the credit card company was very fat and happy with an ROE of about 25%.
The bottom line is that it is much easier to make changes to a desperate company that is very hungry than it is for a very large company that is fat and happy.
Regards,
Steve Johnston
Love this! Great story and even greater insight. I absolutely agree - it’s hard to help someone so comfortable they don’t think they need help!
These are great tips for selling anything to anyone. There should be more training on these things on the job.
This is why I think programmers should make friends with sales reps and marketers and vice versa. We can learn so much from each other.
Agreed!
You can try to dodge it, but the brutal reality is that managers see it all as business.
And in a business world, the more you cost, the more the managers will listen to you.
Best strategy to be a decision maker is to cost a shit ton of money. Then they'll listen.
Everything else is secondary.
Cherry on top: if they don't see above your head your price tag, then they're not good managers.
While having a higher cost does help (I charge a pretty high rate for consulting services), I find it's not a silver bullet. I sure wish that were the case! That's why I learned to do the things in this episode. YMMV 😊
At first glance it looks like:
Developer is hired to do his job but he can't until he goes through the 10 circles of hell.
I am exaggerating a little bit, not all of 10 steps are related to hell and are just normal BAU but some for sure are.
I understand it would have sense if developer would try to push his own startup which would bring him some really big benefits in the future but going through something like #2 (which is just humiliating) only to be able to do your job - I don't see the point.
It would be interesting to get some numbers (even approximate) around this.
Me personally I never observed happy ending after usage of these 10 steps by others.
Like never. I can't say I saw huge amount of such tries so may be I just really was "unlucky".
That's why I am just curious how often this works at all.
Just real life case:
In the past in a project where I was working there was an architect who was doing all of these steps for many years and it gave like nothing. Project manager continued to ignore him.
So he just left the project and found one where he could do his job normally without need to go through the circles of hell.
I'ld say prefer to convince rather than persuade. And the first thing you do to achieve that is make sure you are right :)
You don't have to be right, if you get the other person in a collaborative mood. They might be right, and have a better idea than you did, and then you can implement that instead and be happier for it. It shouldn't be adversarial. It shouldn't be you trying to convince the other person that it's your way or the highway. The goal should always be to get the best possible result, and get the other person invested in the same goal. In practical terms that means getting the other person to agree with you that there's a problem and that things can be better for both of you as the result of some action. The details of that action will come out during negotiation, as you collaborate on figuring out the best possible deal. Never be so focused on getting what you want that you won't take something better instead.
Hi Jayme!
I appreciate the videos/podcasts you're putting out, it's been really helpful.
I was curious if it would be possible/low-level effort to put out a "raw" podcast/audio of these videos without the guitar transitions?
I notice that it is really hard for me to listen and take in what you're saying and then being surprised with the guitar transition then back to words.
I am neurodivergent and it could be in how I am processing the information, but I notice the switch from music to words to music is really difficult for me.
Thank you for this consideration!
Hey manny, thanks for the suggestion. Unfortunately there isn’t a low effort way to do that. I do have all my episodes on Spotify and iTunes as well but they include the guitar, sorry.
When is your book coming out?
So…
1) Honesty
2) Authentic relationships
3) Provide clear success metrics
4) Clearly explain benefits
Clear, short, sweet, brilliant.
Agreed, developers need to learn how to manage up and sideways, because obviously your manager is not managing, your SDLC has been trampled into an unrecognizable “standup” meeting, and you can only afford to spend the small hours of the morning coding before your team and managers wake up and start scheduling more meetings and war rooms.
So:
5) Become a manager in responsibility only and see how long you can maintain being an under appreciated coder, manager, dev op, technical writer, and PM/PO since no one on your team is getting job satisfaction as just one of those things without competent support, and you can’t get authorization to hire the roles your project actually requires because the budget was set last year by a recent college grad in Finance that used Excel to divide the yearly budget by the number of projects approved by the board for the year, and Marketing already spent three quarters of it for an unapproved “emergency” project so convincingly sold to them at hole 3.
If you can actually do all of that:
6) Use the authentic relationships that last to go lead somewhere else that pays more, because your managers (probably plural) that haven’t parleyed your success into promotions or better jobs elsewhere are rightfully threatened by you for doing their job, your team is resentful that you got a “lead” title with no raise, the other department heads are still ego-bruised that they didn’t get to buy and force you to create custom integration for the “out of the box solution” that was so convincingly sold to them via a drunken bet on hole 9, and you can’t stand waking up every weekday and weekend to go back to that cess pit.
7) Repeat 6 until:
8) Caffeine is your life anyway and you’d rather create something that matters, so start your own business.
9) Sell it to Google or Amazon and retire to see if anything is left of you or your family to enjoy.
10) Play exceptionally beautiful guitar outro
The guitar parts reminds me of Kings of Convinience if you know of them?
I do not. I’ll check them out!
Let's be VERY clear here: People don't want "personal relationships" with their managers for many good reasons, starting with the fact that they will - and I do not care how "good" you think those people are - use that relationship to take advantage of you every single day you work for that organization.
WRT "measurable benefits," there's no "measurable benefit" to picking up your trash in the forest -- it will not ever benefit you for the duration of your life -- but we expect people to clean up after themselves when they go camping. That applies to software development as well. Doing things the right way is non-negotiable. It doesn't matter if there's an immediate, measurable benefit. The benefits of writing clean self-documenting code may not be seen for decades.
WRT "future pacing" -- this works in small and mid-size orgs. It does not work in large orgs. Large publicly-traded companies work on the span of profit over quarters. They do not operate on years or decades, and the executives and mid-level managemers in those orgs certainly do not operate on making workers' lives easier.
If you feel managers will take advantage of knowing you to get the most from you as an employee, why wouldn’t you do the same? If you hold people at an arms length all the time, there’s nothing truly exciting to expect from work.
Much like marriage, without the courage to lean in and be vulnerable you can’t expect anything substantial out of a relationship.
If that’s all you want, that’s cool. I’m not here to force my values or worldview on anyone. But too many times I’ve been hurt, shut down, and get bitter and protective. At some point that bitterness and those walls I put up only hurt myself. Without the courage to forgive and try again, work becomes shallow, meaningless, and limiting. If we have decided that’s all it can ever be - then of course that’s all we’ll ever get.
Actually writing clean code is immediately beneficial, whether you're starting out anew or fixing up an existing garbage heap.
It's just that managers are idiots who refuse to look at the thousands of hours of developer, QA, support time you just saved. They only see how much time the developer will spend on it now.
They all have this idiotic idea that doing it the right way takes longer, which means they're idiots who don't know what they're talking about. They just what business talk from influential/famous person and think it means something.
@@FlabbyTabby maybe try one of the suggestions in this video. Create visual assets to show the savings. Get to know the manager. Pitch the improvement aligned with what they even care about. I see so many people NOT do this, it's depressing. We can either spend hours fuming about our manager, or we can accept that we have to step up our game and do the work if we want things to change. Persuasion is not a guarantee, but it definitely isn't going to happen if all we present is verbal arguments that are immediately forgotten, to someone we haven't even tried to build a relationship with.
@@HealthyDev Thanks! Yeah I definitely tried, in my case it was just that the manager wasn't interested in improvement at all, and there were other problems going on. Nothing I tried would've worked in that situation.
@@FlabbyTabby ah OK I hear you. Yeah I work with IT pros through career coaching and sometimes we're able to repair difficult relationships with people. Sometimes it's just not possible no matter what though - the other person has some growing up to do.
Love the video! Question about incremental persuasion, and I'll watch that section again. So you want to make a change, you break it up into 5-10 steps, and focus on the first step. Do you share your multi-step roadmap at any point, or kind of "keep those cards close to your chest?" I'm curious if you think it might be better to show the whole roadmap and say we're going to focus and measure step 1 only right now. Or if you think it's too "scary" or big to show your whole plan right at the start.
Excellent question. There’s no hard rule there, trust your judgment. I’ve not revealed the entire change up front when I’m in a lower trust relationship. If I already have a higher trust, established relationship I might share more of where things are headed. The idea isn’t to withhold or be deceptive. It’s more about reading the other party and working through the change however you think will be most comfortable and successful for them. Hope that helps!
Uhmmm, I do truly recommend study Chriss Voss (Black Swan) Tactical Empaty.
Most of the arguments that developers do are technical arguments, but bosses are often emotional beings. You should connect and sell anything in emotional relationships.
Thanks for sharing! I’ve come to the same conclusions but never heard of this book. Will check it out!
I would like a video on "How to measure success", I struggle with coming up with measurable metrics.
That’s really weird reading comments… as CTO of small (~130 employees), I’m open to new ideas every single day, nobody knows everything, technology change daily and this is the only way to keep up… never thought that the management will actually need to be persuaded.
It sounds like you're a more realistic and open person than some in that position. I will say though, we all have our blind spots. I'm sure there are some things others have wanted to do, that you turned down. Probably because they didn't do some of the things in this episode! We all lack self-awareness, and I'd love to say we make decisions purely logically. But if there's one thing I've learned the hard way over many years, it's that our comfort and emotions steer our decisions more than we'd like to admit. In this episode I'm trying to help people who may be really frustrated, with leadership not as open as you, and to not feel like there's nothing they can do. There is. But it requires stepping up our game, not just complaining. Thanks for watching and offering your feedback!
11:41 So true! I neglected this aspect and lost valuable time, should have moved on a lot sooner.
Great tips, thank you. 🌟🌞
You have a good voice sir.
Your guitar playing remind me of parts of Opeth songs.
I've been developing free software for surveying. How do I find people willing to fund development?
I also have written a low-discrepancy sequence generator. I know there are people who use such sequences; how do I find them?
What kind of surveying? Surveying people? Surveying land?
@@niles_5003 Land surveying.
Nice groove :)
The guitar point 👌
I got fired for challenging how something should be done, I guess I didn't go about it well enough
It’s taken me a while to learn how to give suggestions without sounding threatening. Sorry this happened to you!!!
@@HealthyDev I guess I learnt something with the experience
Here I disagree for a first time with the author. Not saying he is wrong, just different attitude after 10 years of watching ignorants being ignorants. Sorry. I want to say I like your channel, wish you happy times and I am going to continue to watch your great vids.
What you think about SAFE?
Are these Opeth riffs? They sound like a close interpretation!
Parts from songs I’ve made over the years. I’m not familiar with what Opeth is.
@@HealthyDev Then you might really like their sound! They're considered a metal band, but in actuality their music is much more than that. Check out the "Damnation" album, I think you'll quickly notice what I meant.
i see this more as a skill for supervisors or leads. you have to be a people-person to be in that position.
What about when the other dev on your team doesn’t want to move to a library or pattern that you know will speed up development or make the developer experience better?
@@HealthyDev he has to have a GOOD explanation. budget or otherwise. playing politics is the most toxic thing in the workplace.
@@richardhaw9757 yeah that’s sort of what I’m trying to help with by this episode. If you’re the one with the idea, I hope some of the things here may help you make a stronger case. I’m not trying to advocate for methods of persuasion that are manipulative or ignore facts. Quite the contrary! I just know the human element is a bigger part of the equation than some realize. Hope that makes sense.
I once talked to my coworker, who had many more years of experience, to convince him about using a new framwork. He said he liked it and it was a good idea. Then I talked to the boss so he called my coworker to ask him. The f..er then said if wasn't that good and we weren't gaining much. Be careful with those people.
Ouch sorry you went through that. It’s pretty hard to identify backstabbers before the knife is actually in your back! 🥲
I quit software developing. After 25 years. Industry is full of egos with shiny object syndrome. Industy lost a Senior Java developer and Im sure the all happy about it.
yeah. i'm the smart one. in the end we just get salary. If overdo it , nobody can't maintain it.
But... but... I like de shiny. It's so pretty!
Usually, your videos have some great information, but this time, I think you focus too much in how to convince others about what you want, instead of how we can work together better, so that all ideas can be considered and we end up with a better solution for all parties. Lots of devs know better, but from experience, they mostly see it from only one perspective, and while their idea is good from that viewpoint, it's often terrible from other aspects. I do appreciate you mention that honesty is oh so important in communication.
Interesting. I’m literally telling people how to make something you want a win win for everyone by seeing it from their perspective. Did you watch the whole thing?
Another thing is to recognize when you cannot win. Some people are just plain obstructionist, and you cannot use logic to get past them. If you can’t engineer a safe space for them to have their own little fiefdom while you innovate, get out.
Someones been into the mushrooms again. Solid advice for fantasy land. if you do this so you can convince people to listen to you they will see the in incongruency immediately
Lol! That’s a statement, not an explanation. What aspects of this process are you thinking cause incongruence and how? Thanks.
What I love about software developer channels is that there's never a line of code to be found. Ridiculous.