How To Avoid TOXIC Team Culture In Software Development
One of the strongest predictors of success in software development is team culture, but that is such an ephemeral idea that it can be hard to nail down what we mean when we say one development team has a strong culture and another doesn’t and it can be even more difficult to work out how to change something as broad as “team culture” for the better. So how do we lead teams to cultures that help them to achieve better results and what are the attributes of team culture that high-performing teams share?
In this episode, Dave Farley author of best-selling books “Continuous Delivery”, “CD Pipelines” and “Modern Software Engineering” explores what team culture is, why it matters, and what sorts of culture predict more success for the teams that have it, and goes on to recommend how we can change from whatever our development culture is now to something that the data says will be more productive.
-
2️⃣ PAIR PROGRAMMING GUIDE:
Understand the benefits of different pair partnerships, learn how to introduce pairing as an option for your team and identify anti-patterns and how to avoid them. All FOR FREE, download your copy HERE ➡️ www.subscribepage.com/cd-pair...
-
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content! ➡️ bit.ly/ContinuousDeliveryPatreon
-
🗣️ THE ENGINEERING ROOM PODCAST:
Apple - apple.co/43s2e0h
Spotify - spoti.fi/3VqZVIV
Amazon - amzn.to/43nkkRl
Audible - bit.ly/TERaudible
-
👕 T-SHIRTS:
A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!
🔗 Check out their collection HERE: ➡️ bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
-
🔗 LINKS:
Dev Ops Culture ➡️ martinfowler.com/bliki/DevOps...
CALMS ➡️ www.atlassian.com/devops/fram...
Genius or development culture? ➡️ www.linkedin.com/pulse/genius...
"Building a Healthy Software Engineering Culture" ➡️ www.modernanalyst.com/Resourc...
"Creating a SW Engineering Culture" ➡️ www.shakebugs.com/blog/creati...
"Westrum Model of Org Culture" ➡️ itrevolution.com/articles/wes...
-
BOOKS:
Accelerate, The Science of Lean Software and DevOps, by Nicole Fosgren, Jez Humble & Gene Kim ➡️ amzn.to/2YYf5Z8
The DevOps Handbook, by Gene Kim, Jez Humble, Patrick Debois & John Willis ➡️ amzn.to/2LsoPmr
Team Topologies: Organizing Business and Technology Teams for Fast Flow - Matthew Skelton & Manuel Pais ➡️ amzn.to/2Y0NdSO
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here ➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
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.
-
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
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com
#softwareengineer #developer
2⃣ PAIR PROGRAMMING GUIDE: Understand the benefits of different pair partnerships, learn how to introduce pairing as an option for your team and identify anti-patterns and how to avoid them. All FOR FREE, download your copy HERE ➡ www.subscribepage.com/cd-pair-guide
The easy answer is: change jobs. My experience shows that it is always the tone the manager sets which the team picks up as a whole.
What happens if you are the team lead though? If you get promoted, how do you change the culture?
@@robinbennett5994In that situation you may have the ability to shield your team. If that is so, then the culture can change. Showing vulnerability helps
It will take time if the culture id toxic. The core of a toxic culture is mistrust. Trust will build back very slowly. A lot slower than many managers would like.
@@robinbennett5994 You can influence it only up to some degree. If you don't have solid backing from the management and are not given the ability to fire people you can't.
@@rosomak8244 my work environment is a good example of what you said. One delinquent dominant developer wreaked havoc in our culture. Many attempts to get his buy in but their doesn’t seem to be another option but to have a team without him in it.
Nitpicking: 7:38 "If the goal of our software development is to ..." 8:01 "If the goal of our software development is to ..." It seems you have recorded two takes of the same words, but forgot to filter out one of them. - also, there is a typo in 4:46 in the Bureaucratic "Bridging Tolerated". --- Thanks for your insights. You have made me a *WAY* better software developer over the years 🙂
Great video! I stumbled upon this video just when I realized how much I dislike the way technical management in my company treats engineers. They dictate absolutely everything down to the smallest details and don't trust the engineers' decisions. Instead of clearly setting goals, establishing boundaries, and allowing us engineers to create solutions that work for the client, they completely discourage any desire to invest in and improve the product. You become as uninitiated as possible. I definitely need to reflect on this topic and clearly form in my mind an image of the team culture in which I would feel comfortable working.
this is gold to anyone in a leadership position. I'm not sure how it gets 13k views and only 610 upvotes. Do your duty people.
This is a mind blowing video Dave! Thank you very much for the contribution to the software community :)
Another good nugget of a video. Thanks so much for this Dave 🙏
Another brilliant video. Thanks Dave! Anyone got tips on how to determine if a company has this kind of culture when interviewing for a job with them?
Introducing Pairing to the way we create software together is an underrated practice by most teams.
but i'm an introvert
In my first internship last May, me and my team lead were given the same task. But on different pages. So 90% the same. For two weeks we got on a call for an hour daily. That helped us bond. Loved that guy
Stating that there is one process that will solve software development problems is exactly how this industry got dysfunctional. Pairing is simply a tool set can be used, But it has to be the choice of the development team itself. And they have to be given the option to try it and if they don't like it to do something else. That is, the fundamental of process improvement is to try something and see if it works. Making a statement like all you need to do is pairing and everything will be better is how dysfunction starts
Great video, Dave. Would be lovely to add some numbers in from studies on the matter, should they be available. They would help with the "convincing the mamooths" but, heh 😊
Team autonomy does not work if inside the team micro teams form where some people work against the rest. If they form a majority, then they will easily convince management that they were and are right about anything.
A lot of focus on bad managemwnt but was hoping for something about those toxic 10x tyrant developers who have a 10/ effect on the rest of the team, stifling innovation, confidence and joy... We've all had one!
Isn't that also a management problem? Fire them.
Don't worry co pilot will disrupt
Check the corncob antipattern. Practically they have to be get out of the company.
The problem is management and owners.
Hi, great video as always. A challenge I face in my company (which does not sell software or IT services as its primary product, IT teams are here to support other business operations) is that most (80%) of IT workers are contractors - from various specialised IT & consulting companies or even freelancers. So 1 product team is often made of employees from 3 or 4 different companies, where commitment to the goals is first an issues dealt with through contract management / commercial relationship with contractors. Is this model doomed to stay in a bureaucratic stage (it is not toxic, but also far from generative...) ?
Dictatorial managers and HR which makes them like that is the weakest link in Continuous Delivery because they can write code that they can put into production without credible code review. Who writes a bad review for their manager’s code? Who tells their manager to desist from writing code? Who argues with a dodgy code review comment coming from their manager or endorsed/enforced by their manager?
Coders are expected to comply with laws and professional good practice and proper design like GDPR and good practice security, but HR ideas of managers being dictatorial undermines all this completely. If the manager cannot see the need for security aspects or legal compliance they often do not allow the coders to incorporate such things with proper discretion. The law breaks down. Security breaks down. But HR is happy because they can understand the hierarchy and chain of command.
That's awesome. Just collect all of those orders in writing and meet them in court whenever they get uppity and claim mobbing.
I think you need a new job. I know a lot of managers (like me) that take all of those things extremely seriously
@@TimJW But then you get promoted and …
@@stephendgreen1502 then you don't become part of the problem. It's not hard
@@TimJW I agree. I retired.
It particularly concerns me on Freedom Software. Often project founders attack each other for visibility instead of working together for the common good. There are people who only care about creating a public profile and I get it, but that's a very sad thing.
7:25 by my understanding, management has focused too much on trying to become technical leads. This results in managers getting in the way of team members who would otherwise be technical leads.
You just described my job exactly. I'm surrounded by managers who weigh in on every technical aspect, but lack skills and experience to do so, and ignore everything I say. Lol?
If you ask someone about DevOps you are surely getting an answer describing an Ops role, not culture. It's amazing how few people understand that it's a culture. Somehow it's become to mean an Ops person who does automation in the cloud.
I did say "DevOps expert" not "Someone who read the word once, and misunderstood it"
Unfortunately not only sometimes, but quite often. Devops is the new ops, and the (con)sultant companies try to sell them for a higher rate per hour calling them devops engineers. It is just a scam, nothing more.
what a great shirt
Very good principles but you also need good hires for this to work, because it requires trust. Management does not trust most workers to understand what's required at each step. So they won't let them get their full autonomy.
Well the point of establishing a better dev culture is to change people to being "good hires". On average the people out there are just as great or just as bad as the people in here, so changing the culture is how you promote better behaviours, rather than only seeking the people that have them already. Adrian Cockroft, former CTO at Netflix was alway asked by the Silicon Valley leaders "where do you get your great people from" and used to answer "we hire them from you, and teach them to be better".
@@ContinuousDelivery It's not about culture. It's about team cohesion. Plenty of lessons from the army apply in general to managing teams of people.
Good vid, and good takes, but... let's face it, in most places, it falls flat because it always ends like this : "We should do this because{insert reason(s) here}" > "No, we will do it like this {insert BadIdeaTM}" > "But that will make things worse because {insert all the shortcomings of that approach}" > "It's how I (emphasis) want it and it how it's gonna be" > Business wins because developers need to pay bills. You can have UI/UX tell them it's a s**tshow without reason, you can have devs tell them it's a nightmare to implement, business still powers through and wins. As for pair programming... YES! Very few things can have such a big impact on a developer as PP. Less experienced (with language and codebase) people can ask questions and get answers on spot, no latency. More experienced devs can be kept "honest and in check" into NOT developing something nobody else will grep.
As Martin Fowler has been known to say, "you either change the company that you work in, or you change the company that you work in!" 😉 The stuff I talk about are along the route to changing "toxic culture" which is why I recommend them, sure changing them is hard, but "you either change, or you change"...
Dave, that is not a scrum example you described. That is anti-scrum. What you described in the beginning is the real scrum. Great videos, cheers
I know but what I described is what EVERYONE who practices it calls it! Scrum is ok, it is nowhere near enough to do a good job, and I believe that it is mostly the most popular version of agile development because it is the easiest to subvert and cheat.
6:10 teams metrics to be performant
The author completely ignores how important for management in esp. in larger projects/organizations predictability of results is. However I absolutely agree that providing well done specs is paramount.
If you want predictability of result make sure your people are experienced in relation to the challenge ahead. Also make sure you’re not aiming for innovation (innovation is unpredictable), but adoption of proven methods and technologies.
Me pregunto si aplicando todo eso se puede convertir a un desarrollador mediocre o que no le gusta lo que hace en alguien bueno. Y en este momento trabajo en una empresa altamente burocratica donde es mas importante el proceso que las buenas practicas.
How do your hold up people to that greater responsibility? Especially if now the responsibility is more the team's and less of a single person's. Does the team get reprimanded for one guy's bad acting?
"Promiscuous pairing" sounds naughty, and I want it.
I dont think promiscuous pairing is the right way. This is because you generally want to finish the stuff you are doing before switching pairs. I also believe that pairing should be done in two sessions/day, each being about two hours as pairing is draining and takes a lot of effort. Say one session in the early morning and one session directly after lunch. In practice you will need to do some other stuff also during a work-day.
The problem is that software "engineering" is not treated anything like ACTUAL engineering as in building bridges or infrastructure. In those fields there is much more of a discipline behind how things are done vs in software where there is a lot more hazy/fuzzy, happy/feely approach to design and decision making because there isn't always a single "right" way to do something. And there is no solution to this at a high level without more specific goals and discipline in defining the key requirement that must be implemented which in turn drive more of the decision making for the solution. But sometimes people think that agile means not having requirements or making up requirements as you go and "discovering" a solution which in a sense is the total opposite of traditional engineering techniques. And ultimately that cuts down on the churn and battling of egos that often happens in less mature environments.
Though I've never had the pleasure of seeing it applied to this degree, I think that Agile really just means agile. It's not a case of discovering a solution. It think it's more of a case of being agile enough to adjust when you discover that the solution is wrong. But Agile doesn't define how a team is agile. This is were good software engineering principles come into play. It's things like Dave's Modern Software Engineering principles with High Cohesion, Low Coupling, Modularity, etc. It's also SOLID design principles. It's using Design Patterns correctly. It's automated testing. It's TDD. It's DDD. It's keeping technical debt in check by always refactoring to make the code cleaner. In order to be agile, we need a code base that doesn't work against us in being agile.
@@jimhumelsine9187 I can understand what you mean as "agile" when I first heard just meant being flexible. But that is part of the problem because there is no one size fits all way of defining "being flexible". Which is how you get these dogmatic approaches to "agile" which defeat the whole purpose in a general sense. Keeping in mind that "software engineering principles" keep fluctuating with new programming paradigms. Anybody remember the gang of 4?
It is actively treated "like ACTUAL engineering" in the places that are really good at software development! That's not a coincidence.
It is definitionally impossible to be both "dogmatic" and "agile" because being dogmatic is refusing to change in the face of evidence, agile is being willing to change. Sure there is no "one size fits all" which is why "agile" talks about being adaptable, that is the point, but that doesn't mean that there aren't things that do work generically. Working in small steps, gathering evidence of your progress or lack of and using it as feedback to correct what is wrong , trying out ideas and working experimentally all work generically, whatever you are doing, and we have the data that shows that to be true, WHATEVER THE NATURE OF THE SOFTWARE. Building more modular, more cohesive systems, with better separation of concerns, better seams of abstraction between the pieces and looser coupling is BETTER THAN ANY ALTERNATIVE and that is a significant part of what the gang of 4 books was describing, though not in those terms. The gang of 4 book wasn't wrong, and still isn't, it is just that people don't pay attention to it much any more, but if you did, you'd build better software than if you didn't.
@@ContinuousDelivery Learning Design Patterns completely changed my views out OO design when I started to learn them 20 years ago. I felt as if I had only known the rules of OO before, and now I had learned the tactics and strategies. Bob Martin said that the design patterns are a crystallization of the SOLID design principles. I view the relationship as SOLID being the theory and the design patterns as being the practice of that theory. Once I saw Martin's statement, I viewed the design patterns in yet another light, and I started to understand the underlying principles that allowed them to work. FWIW, I couldn't learn the design patterns from the Gang of Four book. I got completely lost by page 80. I learned the design patterns from online resources. Once I understood them a bit, then the GoF book made much more sense. I also agree that GoF design patterns may not be effective with other programming paradigms, such as functional programming and possibly even with Generative AI. But the GoF's patterns were intended for an OO paradigm and they still apply there. I suspect that there are patterns for functional programming and GenAI, or they are in the process of emerging. I also agree that principles and practices are going to change. Just because we feel that some practice is the best now doesn't mean that it's going to be the best in the future. I remember waterfall being the standard practice all too well. And it did work at one time, when we were first porting well known domains, such as accounting, inventory, scientific calculations, etc. We were replacing human computers performing well defined processes with electronic computers. Now the domains are a bit more fuzzy/hazy, but most aren't completely foreign. Most have their roots in the real world. eBay is an auction. Amazon is a bookstore. Twitter/X is a street corner/bulletin board. Match.com is a match making service. Computers and the internet allowed these domains to scale. The Modern Software Engineering principles and practices that Dave promotes almost weekly are among the best we know for now. Some of these may be so rock solid and foundational that they never change. Some may go away as the technology changes or the industry discovers a better practice. And when that happens ... we still need to be AGILE.
As W. Edwards Deming said, "Drive out fear." Deadlines are the enemy of software quality. There is no good reason to set deadlines. Never. Not even once. New features should never be made public until they are ready to ship, and should never ever be promised ready by any specific date. Setting deadlines in order to pressure developers to be more productive is stupid; it hurts the workers and doesn't do the company any good. Only God knows how long things will take, and He isn't on the payroll.
I was thinking "paring" for most of the video hah.
Why do consultants make everything sound more complicated?
Maybe the only way to save us from a dystopia of powerful technology is a tower of babel of dysfunctional teams. Social credit, mind implants, digital money, inability to wrest back control of nuclear power stations from future dangerous AI, autonomous military drones going rogue, all these kinds of software dystopias might be our nemesis if we keep working well together to build such a future.
Another advertisement from Dave for pair programming, but with a 13 minute introduction. What if members of your team have tried pairing and rejected it? You don't improve the culture by demanding that your highly intelligent, self-organizing people self-organize to do pair programming. One way to avoid toxic culture is to avoid consultants and "rock stars".
Which is helped by pair programming. Sure if people have tried it and rejected it, that is fine. My point in general is that people should try these things. I have not seen a team really "try" pair programming and then reject it, if they do I have no comment. Most orgs and teams and individuals reject it without trying it. They may have sat together on something for a few minutes, but it is not the same thing. My experience is that about 80% of people who try pairing, doing real work full time for at least a couple of weeks, not only don't reject it, but they love it. Then there is a small group, about 1 in 10 who really hate it can can't cope. I don't advocate forcing anyone to do anything, not least because it is counter productive, but that doesn't mean that there aren't good ideas, that would benefit people that they reject anyway. Pair programming works very well indeed in strengthening team culture.
@@ContinuousDelivery - What is your estimate for the software industry world wide of how many teams actually do pair programming? In my career of nearly three decades I only know of two.
@@ContinuousDelivery It is a really positive way of developing and I think the burn-out goes down and generally what is produced is subjectively "better" but I think 10% who "hate it" is low. In my experience anywhere from 15-30% of a given team of engineers will be introverts and will find the idea at least uncomfortable and even exhausting. Often these same people will be among the most productive developers on the team. I think presenting peer programming as a "best practice" but making it optional is the way forward. At a minimum the team should make the expectation peers are expected to know and review each others code, peer programming isn't the only way to achieve these goals and you have to allow people to discover what methods of collaboration are effective but less uncomfortable for more introverted team members. Leaders should define the "what" and not the "how", there can be best practices or examples but ultimately it is easier to get teams to do the right "things" by making it the easy thing to do rather than dictating it. Unfortunately I'd say less than 10% of senior management are supportive of peer programming, to them they see "waste". These are the same orgs mindlessly implementing SCRUM, SAFe, flow metrics and generally work with the notion that if we squeeze more hours out of our developers there will be more productivity.
I dont like pair programming per se. We can talk about solutions but the rest is alone