How To Manage Your Boss! (Managing Up)

Подписаться 203 тыс.

Просмотров 23 тыс.

50% 1

Have you ever wished that your manager would allow you to do something? Do you know that you could do a better job if you spent more time on design, wrote better tests or fixed the technical debt at the heart of your system? This is a common complaint of software developers, software managers are often pointed to as barriers to progress. Leadership is seen as an impediment rather than a help. So how can we change things, how do we manage our managers to help us all do a better job?
In this episode continuous delivery and DevOps expert, Dave Farley explores ideas around how to manage your boss, convince them to allow you to change what you do or how you do it to get better results.
-------------------------------------------------------------------------------------
📚 BOOKS:
🚨 MY NEW BOOK! 👉 📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
Kindle ➡️ amzn.to/3DwdwT3
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-------------------------------------------------------------------------------------
Also from Dave:
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
➡️ bit.ly/DFTraining
📧 JOIN CD MAIL LIST 📧
Keep up to date with the latest discussions, free "How To..." guides, events, online courses and exclusive offers. ➡️ bit.ly/MailListCD
-------------------------------------------------------------------------------------
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Harness helps engineers and developers simplify and scale CI/CD, Feature Flags and Cloud Cost Management with an AI-powered platform for software delivery. ➡️ bit.ly/3Cfx3qI
Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️ octopus.com/
SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across the team and stakeholders. ➡️ go.specflow.org/dave_farley
----------------------------------------------------------------------------------------
CONTENTS:
00:00 Intro
02:30 Measure the Difference
07:40 Locate the Source
10:00 Fix One Thing

Наука

Опубликовано:

25 июн 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 49

@TheBackyardChemist 2 года назад

14:57 Sometimes I feel like my entire country is living by the inverse of that advice

@droohyen 2 года назад

This is quite important for each manager, to emphasize to his team that they are having real influence on their working environment, and they can change it. Most of the people think that manager is responsible for everything. Manager is to remove blockades and obstacles, but real drive of change/improvement shall come from teams. Great video, gives me confirmation that I'm on a right path!

@ContinuousDelivery 2 года назад

Thanks. I agree with you about the role of management and leadership in dev teams. Did you see this video I did on technical leadership? ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-jMpCF0Z623s.html

@droohyen 2 года назад

@@ContinuousDelivery Yes i've seen. Its again great and very concrete like all your videos. However the video which is my number 1 is about Cyberpunk and CD-projekt job descriptions (somehow i like it the most as I'm from Poland, but from automotive industry - not gaming - so i have no space for bugs at all :) )

@MrAbrazildo 2 года назад

@@droohyen But for software you code at "atomic level", not pieces with 0.000001% chances of errors. Bugs in software, unlikely in other activities, are inevitable.

@ssssssstssssssss 2 года назад

To add... from my experience, a lot of it is about perception and not so rational. I've seen bosses listen to everything narcissistic developers say just cause they perceive them as being great.. even if their engineering is low quality. So I think it is also important to work on those perceptions, which starts with communication. 1. Learn to communicate more directly. Software programmers tend to be introverts so they tend not to speak directly. 2. Learn to communicate in non-technical language. Software developers learn tons of jargon and skills that most people cannot comprehend so they need to take a step back and think how to communicate these concepts to the layman.

@mop2884 2 года назад

One of your best videos so far, thank you! The focus on goals instead of practices is at the core of pragmatic software development and it cannot be stressed enough. Telling your boss or your coworkers you want to do TDD "because it's good practice" won't convince anyone. Taking one or two of your coworkers to a pair or mob programming session as you do this makes them see the the benefits for software design for themselves. Also, so many devs I've met are stuck in this mentality of "I'd like to X but my boss won't allow it" - your emphasis on the things you CAN control is so important. If you want to do it, do it. If the results are great, nobody in their right mind will scold you for it. Even better - if they ask you how you did it, you can simply tell them, knowing you already (partly) convinced them it's a good thing to do.

@NilsElHimoud 2 года назад

Two books that I recently read shine through in your talk 😄Accelerate - you mentioned it - and 7 habits of highly effective people. I can recommend both.

@richarddawson8521 2 года назад

Thank you so much for the content on this channel. I've picked up Accelerate on your recommendation, I've been highlighting so densely that each page may as well be entirely yellow.

@ContinuousDelivery 2 года назад

Thanks! It is a very good book.

@ralftaraschewski6094 2 года назад

This was a fantastic video. This is a real problem in companies and most people don't know how powerful they are in starting change. One key issue with the trust is that you have to trust yourself. This trust can be obtained by success. So you need success to lead your team mates and to convince your boss. But doing something new, we call it "submarine mission", can be dangerous. If your change fail, your trust is gone and you have alot work to do to rescue the project. So doing small changes, you are experienced in, step by step is very important for you.

@JorgeEscobarMX 2 года назад

I stopped trying to make my voice heard a long time ago. I agree that for things like unit tests, test driven development, using git for version control or just writing technical documentation, we don't require authorization, our bosses don't even need to know.

@gullijons9135 2 года назад

I gave up on writing tests without having a CI pipeline after doing that by myself on two different jobs. No one else was running the tests so they'd never get the feedback. The next time I'd be working on the systems, many of the tests were broken. This meant that every time I was starting a new task, I first had to fix all the test that weren't working anymore and as the number of tests grew, the amount of time I was spending on fixing broken tests just grew. After a while I'd just stop trying. It is better if you have a compiled language that you can force to run tests when building but script languages can be a problem in that regard.

@JorgeEscobarMX 2 года назад

@@gullijons9135 I'm sorry for the broken tests. In some unit test libraries you may skip tests with a decorator or annotation. Still if there is no continuous integration pipeline, working with test driven development practices allows you to have way better code that is resilient. Even if nobody else runs those tests.

@rothbardfreedom 2 года назад

Jerry Weinberg's book Secrets of Consulting is very book about this. It talks about storytelling to convince people on software teams.

@N1ghthavvk 2 года назад

I am very grateful both for my Scrum Master and Product Owner, as well as our Division Lead. They're always open and on the lookout for better design, better productivity, even if they do like to prioritize or push for more features in the latter two cases. But it was a hard road to get there. And the company around us (including them) is still very much ... in the dark ages. We dug ourselves out of that hole as a team and are now proudly both technologically as well as in terms of dev ops the leading team here. Of course there's still more space to grow, and we will continue to push forwards.

@jacmkno5019 2 года назад

Such bold subject! Glad someone real can talk about these things! Congrats! And Thanks!

@bryanfinster7978 2 года назад

Awesome advice. Also, never take "no" for an answer, just try a different approach. Never go for a frontal attack against entrenched resistance. Flank them. :)

@paquetp 2 года назад

“This isn’t good, just true”. Golden

@jonathanaspeling9535 2 года назад

Excellent! Great points and thank you for doing a walk through of each. Touched on something near and dear to my heart and that's understanding stakeholder interest. You've put an interesting chalange forward. Thinking of a specific person to have a virtual coffee with haha

@mattiasbermellrudfeldt570 2 года назад

Great video, thanks for the wise words, Dave!

@1981ilyha 2 года назад

Love this format! Thank you for this video.

@ContinuousDelivery 2 года назад

Glad you enjoyed it!

@Yoy077 2 года назад

That's a great video ! Maybe one of the most important of your channel, and yet maybe the one with the most misleading title ! I almost missed it because of that, since I don't want / need to manage up. But yeah, I really DO need to convince my teammates every single day ! Maybe you should have named your video "3 strategies to convince your team to embrace continuous delivery" or something like that. Great great video though 👌

@gabrielvilchesalves6406 2 года назад

Everything that's not done needs to be done. The problems are there for the people willing to say a few noes around wasteful work and tackling work that will create efficiency for the whole team. That's usually a good way to grow professionally, in my experience. :) But also a very simplistic view. There's much involved in how to express "saying no" properly. It's not just about the negative, its about the questions and the investigation and growth process.

@GustavoHJ6 2 года назад

Hey Dave, awesome content as usual. I'm curious about your insights on big changes. An example could be a major architectural upgrade and refactoring, something you would do to replace an old architecture that was enough up to that point but can no longer support increasing demand. When and how to do it? How gradual should it be?

@CosasCotidianas 2 года назад

What a great and inspirational content. Thanks Dave.

@ContinuousDelivery 2 года назад

My pleasure!

@Kevinf63 2 года назад

Thanks Dave, an excellent and very well timed video for me, with loads of information to help!... given the business questions I sheepishly sent to Dave and Co last week haha 😅 It seems I must experiment by collecting empirical evidence in a cost effective way to prove my points, but I still need to sell the story that goes with the evidence. Based on this, my experiment will ultimately be to collect metrics on the Four Keys described in the state of DevOps/DORA reports, using existing DevOps tooling that thankfully requires minimal effort, tracked over a period of time to compare current vs experimental development workflows.

@Pedritox0953 2 года назад

Wonderful video!

@MikeStock88 2 года назад

Great advice!

@MarcoS-bx5uk 2 года назад

This is one of your best videos. I really like this channel, sir.

@ContinuousDelivery 2 года назад

Thanks! 😎

@thePuntoD 2 года назад

Hi Dave! Thanks for the video as always, have been following your channel for quite a while and I must say it’s a lot of help. I wanted to ask you a question, how do you set the price of a software that follows a BDD methodology? I know is not correct to estimate capacities that you don’t have much information about, but clients often ask for a price and time estimate of their entire project, how do you deal with this? Any advice?

@dekkard79 10 месяцев назад

Lol, I got to this video while wearing the same T-shirt as Dave

@marna_li 2 года назад

I feel like I've never known what the goal is. Just finish as many "User Stories" as possible? In many teams it seems like people have never been humble enough. I have felt like I've been in a machine where no one really has dared to take a risk - or they have even been to adversarial to new ideas. I'm a person who likes to experiment - build my own stuff. I get ideas all the time.

@axehero123 2 года назад

Feedback: you should put more text in your videos. You said here's three strategies. I watch the video, I can't restate the strategies. Should appear in text: 1. 2. 3. Then together at the end. Thanks for your content and knowledge!

@ContinuousDelivery 2 года назад

Thanks for the tips!

@Tinutaja 2 года назад

Can you share refrences to the state of devops document you mentioned? I realized there are multiple "state of devops" released yearly by different organizations.

@ContinuousDelivery 2 года назад

Various versions, but the DORA version is the one that is best. Here are a few topics from a couple of the reports: 50% Less Time Spent Fixing Security Defects 50% Lower Change-Failure Rate 21% Less Time Spent on Unplanned Work and Rework 44% more time spent on new features 50% higher market cap growth over 3 years No. 1 Predictor of High-Performance is Job Satisfaction Source: 2017 State of DevOps Report 8000x Faster Deployment Lead Times! Source: 2014 State of DevOps Report

@gonzajuarez4918 2 года назад

Hello! This video came just in time for my current situation. But i've got one more question tho, how much change is too much change? I'm working in an embedded project where basically I'm the only one with formal software education. The group is not so large (about 10 people). The current project does not have a defined code-style, proper build system (it uses a vendor tool) that allows as the flexibility to use a proper static-analysis tool and testing suite (proper == not vendor && proper == flexible && proper == allows automation). In fact, there is no static-analysis (other than compiler errors) and no unit-testing at all. In the near future we are having a design meeting for the next project, and I'd like to put out some or all of these ideas. But I know introducing so many concepts and tools at once to a team of non-software people (and even if they were software people) is just going to fail. Even if I'm willing to be in charge of the automation of all of this as much as possible so there isn't much of a learning curve, it might feel like a bit too much. The lead of the group supports some if not all my ideas, but the problem is more of a "how will the group take this" kind of thing. I believe I might have to pick and choose some of the ideas and try to add more of them over time. Any recommendations on how to choose what (static analysis, unit-testing, code-style) would have the greater impact so that it is valid and accepted to propose their immediate application?

@ContinuousDelivery 2 года назад

For the next project my advice is start as you mean to go on and do everything that you need to go fast. The data says that working the way that I recommend is the fastest, most efficient way to work. So spending time on getting a working deployment pipeline in place for new work, isn't a cost, it is an investment. If there is only you working on things, the things that you think will help you - as a minimum, my advice is to create a deployment pipeline that includes Commit Stage, Acceptance Stage and Production Stage. The start of a new project is the best/easiest time to get all of this in-place. I cover a lot of this stuff in my book "CD Pipelines" leanpub.com/cd-pipelines. The other question is wether it is work retro-fitting this to old projects. My advice, is do this for the new project first, it will be easier. Once you have seen it in use, and what it takes to get it up and running for you, you will be better placed to decide wether or not to retro-fit.

@gonzajuarez4918 2 года назад

@@ContinuousDelivery Thanks a lot. I'll certainly take a read of CD-Pipelines