 I'm a DevOps engineer at HelloSign and I'm going to talk to you today about culture shock and small team agile. I call this an immigration talk because there is a big difference between traditional IT and small team agile and software organizations are getting a net migration inbound from these traditional IT teams as the nature of traditional IT has changed. I myself have made this migration about five years ago. I failed at it. I got asshole rule fired and I learned a heck of a lot so this is what me trying to give back to the community to help people like me integrate better into this software world that we have that is incredibly optimistic. But first I wanted to talk about what some of the cultural differences are and help build some empathy about what the nature of traditional IT if you've never worked in there it looks like because traditional IT is an incredibly different thing here. We have on one side it's a service organization it's quite simply you do things for other parts of the organization at the direction of those other parts and experts are charged with keeping things running but have to ask to improve to ask to have to have any improvements approved whereas in the small team an agile environment is generative it creates stuff you create a product continually make it better in collaboration with the entire product group. Working in a group to keep things running and continually improve them these are very different viewpoints there's a reason that drew a big gulf between those two is because they're completely different viewpoints and some of the extra ways that we can do that is traditional IT organizations as I list here are different they are extremely heterogeneous and supported technologies and one group that I worked previously we had one during one audit we had 250 different server instances supporting 125 different independent services it's not one product we're keeping going it's a whole handful of them which makes for some differences in how you keep everything running there's not as much commonalities there also many different platforms software frameworks even databases you have to keep running it is actually fairly common to have both Oracle SQL server Postgres and MySQL running in some part of the architecture at some point and typically there's a lot of separation of duties there too you have your discrete system in department your development team may or may not even be in the IT service organization if they truly are old school maybe this department way over there that we never actually talked to and the database administrators are off in their own corner and the network people are in a basement that you never talked to even though it's their fault most of the time but not really and it's also very mixed ownership again going back to that 125 services thing only a small handful of those are fully owned by the IT organization things like the email system work other things that were supporting individual department applications well some of it was ours perhaps we maintained the server but they maintained everything above the server or except sometimes they didn't and it makes for very unclear ownership about who's responsible for which parts of things and these organizations habitually end up being very bureaucratic and path sometimes pathologic and organizational culture rarely generative to unpack some of those terms of bureaucratic culture is rules-based the whole point of that is to follow the rules innovation in there is definitely possible in there but it has to follow this rigid step of processes and approvals to actually get approved in pathologic organizations it's all power-based if you've ever had that manager who is completely controlling and nothing got done unless it whatever you were doing was supporting them that's where the pathological organization is so the only these sorts of organizations aren't very aren't very amenable to large parts of creativity but especially in pathologic the only way you get anything approved is if it supports the local boss in what they're doing that is the only way you'll get any change approved if it doesn't it'll be squashed completely and unfortunately this means there are different ways of maintaining psychological safety because there is a Google report out about a couple months ago that talked a lot about effective teams and some of you may have read it and one of the things that they found out at the end of the report was that the one thing that makes an effect a team effective is if all the members of that team feel psychologically safe and the other thing they discovered in that is that there is no one technique or process tree that will make a team effective by imposing it from within teams come to their own methods psychological safety independently we're interfacing this sort of hostile environment you come up with different methods of maintaining psychological safety than you would on say the generative software agile side and that's the kind of the key of what I'm talking about here is that the those of us who've made the migration are coming from a different place of what it is acceptable environment and what I have to do to keep my mind safe and that's it's here and the final thing about this one about service space or architectures for people is that Americans are absolute crap at treating our service workers with respect even those of us who have been highly trained I'm an entrusted with very large environments to keep running we're still treated like crap taken for granted and the other thing Americans are great at is feeling entitled I'm highly trained I have a right to be at the table and yet these architectures are designed to make sure that those of us who are the service providers just have to say yes we will do that even though we're privately thinking this is a very bad idea and I wish you hadn't done that but we have to do this anyway because the person who's telling us what to do tells us what to do and frankly little makes for a toxic environment faster than being a highly trained professional standards and no one listens to you it's microaggressions oh my goodness the microaggressions because thing is it comes from all sides this is that one of the points I do want to bring up here is that there's another difference between traditional IT and generative organizations traditional IT is very much focused on keeping things up in spite of everything and generative organizations are about making things better this is a pessimistic point of view and an optimistic point of view when you bring them together you get culture conflicts and it doesn't get better but some along in the microaggressions because it does really come from all sides for those of us doing direct IT and supporting our direct users or everything else there's a whole cloud of things that come into sort of make our lives not happy malware that happy thing comes in and hoses up people's machines and make us lose ours as we have to reformat them Mr. Helpful usually a Mr. who takes it upon himself to help optimize their fellow users workstations to be faster and better because central IT doesn't know what they're doing or perhaps maybe take out some of those bits at central IT wants in there because they're looking after you man we don't like Mr. Helpful because he does makes more work for us and that's bad and unauthorized VPNs those firewall rules are there for a reason bypassing them with an unauthorized VPN is sometimes grounds for termination and we really don't want to make that decision but yes we will have to talk to you if that's the case DMCA notices please do not bit torrent from the company network because most companies are not set up to deal with this sort of thing and it raises a huge panic when someone says yeah some DVD was caught from the company IP address so this is less of a problem now because homeite home internet is typically faster than what you get in the office this wasn't always the case but it still happens from time to time and our least favorite thing porn collections because when you're reformatting machine because of malware one of the nice customer service things you can do is take the user's data off of the hard driver bought in nuke do your thing and put the data back on both windows and Mac make this fairly easy now it's taken some time but when you're doing that migration you see this stream of porn going by it makes for hostile work environment so and it's not just from the people that were servicing it also comes from the sides because one of the unwritten rules about systems administration and off stuff is while there may be standards and we all think we have professional standards about how things are supposed to be done there is no standard setting body outside of eyes hill saying this is how it shall be done and these are the standards to which the entire industry shall be held accountable which means that it's up to local definition unfortunately that means that me and my little department but my coworkers we think the other department over there the other side of the screen are doing it wrong because they're incompetent bozos because they are they they make some decisions and they interpret the general standards in ways that we don't agree with so we think they're incompetent bozos and they think the same of us because that's kind of how it works. Now let's take it back a minute and talk about our porn collection and the reformatting of hard drives one more time. What if instead of a porn collection that particular laptop I had been to been to that particular user five times in the last month because that particular user have we haven't found a way to break a certain feedback loop to go to certain sites that host Mac based malware and this particular user can't help but keep clicking on it so you have to keep going back to that station rebuilding it for them and giving it back to them knowing I'll be back within a week. But here's the kicker what if that workstation was not my user what if it was in the department of that other bozo department over there and the reason I was doing that machine is because I have the literacy to deal with Mac based re-imaging and the windows bigots over there because they're incompetent bozos won't touch the thing but the reason I'm over there at all is because I need to keep those people happy in the coordination meetings. So we've got this little micro aggression coming in this way I'm I'm doing something I don't particularly find I don't particularly like because I have to keep people I don't particularly like happy because I need them happy in the meetings in which I need to get things approved but as it stopped there as I said it comes from all sides willful ignorance from on high you know. Oh great gods of budget please hear my prayer we have a malware problem it is costing us $100,000 a month $100,000 a year and lost staff time to reformat these drives for the low price of $15,000 a year we can cut the problem by 90% please may we have the money and there's deliberation and three months of lag and they come back with Macintosh is 20% of our fleet that is not worth that level investment request denied but so how can you survive the sea of hostility and that that works with an island of sanity because I have a team of awesome here and as soon as it'll go as I have a team of awesome my coworkers they know what they're doing we know what they're doing and they have my back I have their back when I come back from having to reimage that laptop the fifth time I sit down and say okay five times and the other person in the chair goes yeah well this is not a time to start sharing stories and we feel a little bit better about our lives because we're awesome we are the thin line between the duct tape infrastructure and the chaos monkeys that would wreck it because like I said before a lot of what we do is seems like a lot of what we do is keep the infrastructure running in spite of itself but it's still this team of awesome that makes it work now this also leads to several methods of psychological safety in addition to having your island of sanity and the next one here and this I put this one as number one for a very good reason reflexive change resistance fear of change not initiated by me or my team of awesome because it's not initiated by me or my team of awesome it's coming from that sea of hostility around me it's probably going to be badly implemented and it is probably going to make our stability problem worse so how you deal with this when you're not empowered to actually be in the discussion loop at the time of how shall we solve this problem but at the end when they're when you're given this product someone walks up to the teller when you say hi we just bought this software for $30,000 here and you have $40,000 to buy hardware we need it in three weeks three months go that's not how it works how it almost always works as we look at this you go this afterwards crap anybody who knows this particular problem knows that this is an unmaintainable piece of crap why did this get approved this is bad and it goes on from there it's all this pushback by pitching a fit sometimes you can make positive change so yes this software purchase is somewhat fade a complete but as we all know those of us who've worked in purchasing large contracts there's always a little wiggle room and who bought what when and what sort of horse trading you can do to change options at the last minute even if it isn't the different amount of money and sometimes you can maybe swap some options in to make it slightly more maintainable and slightly less likely to make everybody's hair go away and frustration and perhaps maybe involve us in the process earlier next time we're perfectly willing to help involve us please but sometimes that doesn't work and that leaves to intentional the investment so we do all this thing to try to do the horse trading thing and they come back and says tough I want to do it anyway and this is the point which intentionally the investment I no longer care how this turns out it is not worth my sanity to worry about how this advice piece of software is going to be involved installed and how it's going to be maintained to save my sanity I no longer care this leads to a decrease in service levels in the end because you're by doing this you purposely take away the professionalism on the software so it actually is going to be harder to maintain in the long run because of this but the people are doing this as a way to maintain sanity within it's a symptom of a broken culture but unfortunately some of us so much of us have lived through this one and the next one compartmentalization getting steam row ice the DBAs over there whom we don't talk to because their DBAs and where it's technically separated they just got told hi I'm changing out all of our oracle stuff and move it all postgres meanwhile they're up doing that's throwing chairs around and all we really will do is like they're there pat pat pat stroke stroke squeeze it'll be better and walk off we don't actually help the problem because we don't borrow troubles we don't already have because we have enough of our own it's compartmentalization and for example if that department of the bozos over there who don't know what they're doing have a similar problem will sympathize with the meetings we won't actually offer help because again you have enough on and on plate compartmentalization and the third one bombing through negativity because pain shared is pain divided I gave a little example of that earlier when I got back from reimagining that laptop sat down on my co-worker shared a story of their own problems you see this kind of thing happen all the time in IT organizations in other areas as well but it's also leads to a certain type of humor and here's a few tweets that show kind of what I'm talking about these are the fairly kind ones and it all shares a certain theme kind of goes back to that tweet I showed earlier everything is fun everything is on fire including me and this is okay you'll see a certain theme I mean this is very common there's a lot of Twitter out there for you want to follow this kind of thing this is really crack so this kind of fun to actually gather this list but thing is it's not just IT types police departments firefighters ER professionals animal control officers all deal with the same kind of thing in some way it's dealing with humanity and all of its ill advisedness police officers you did what to your wife and the firefighters you set what on fire you are professionals you cut what off and the animal control officers you did what to the dog now the eight animal control officers are some of the most humane people I know simply because they deal with such amazing cruelty and a daily basis but when you get all four of these people together in their own groups and I've hung out with all four various parts of my life how they bond amongst themselves is extremely familiar to those of us who lived in IT based service organizations it's that sort of handshake of yeah I know everything sucks but we're together I have similar shared experience it's not just you alone it's that sort of mutual support society that comes in and it's not always healthy especially in IT one of the ways to do that is the stupid user story it goes back back to the 70s frankly the various weird things that users do we swap stories scrub the names off we're still laughing at this stupid it's not very healthy but it's again what kind of what's done so here we are at the end and how are we going to get out of this because this is a circle of this is a circle of whoa and as I mentioned before the markets changed and we're getting migration and what did it with softwares of service 10 to 15 years ago traditional IT was a lot like what I described earlier someone coming up to the teller window at the big conca software and a big bank check saying buy a bunch of hardware that we didn't have to spack out order actually figure out how much we need of the right kind work with vendors install it integrate it into our whole lot of systems and a whole bunch of other stuff these days it's far easier someone comes up to the teller window and says I just spent $30,000 for a software as a service application I don't need any software I don't need any hardware purchase I just need to figure out how to put a single sign on system in front of it and how to map the data flows into our other systems in other words you're managing data flows at this point and trying to front end a web service with a single service framework it's web development frankly and a lot of and a lot of data manipulation that's code and it starts making people think because if you've been working on code for the last five years writing scripts and things to do database translations and writing scripts to do ETL processes and a bunch of other stuff you think you know I actually know some of this code stuff and we actually have some Jenkins things around here I've helped some of our other our developers work for some issues I'm actually maintaining a Git server now and why do I have to stay here what if I moved one of these SaaS companies and have only one single products to maintain one not 125 one product that I can focus fully on and make awesome leave leave us leave behind me this toxic cess put of disrespect and things I hate and move off to this wonderland of promise of not hating my job and so we go out we job hunt we post a resume we make sure we mention all the dev opsy things we've done because we see the industry rags too and we go the interviews and you know have you spent many time in a slightly pathological environments you know how to manage an in-person interview so you pass that with flying colors and you get a new job hey new job we are leaving this cess bit that we hate we now have a new thing and wow is it different because the first day of the job you have a nice fancy workstation and you spend a day or two and spend a day setting up your dev workstation and you may do your commit on the first day which is useful to do because it teaches you how the commit process works in a given environment you're going to need to do and there's a whole lot of learning that has to happen because soft organizations function very differently than what traditional ideas but this was done intentionally I was leaving behind this I'm purposely embracing this new world and for the first few weeks it's all learning we're quiet and we're just picking things up increasing our comfort with our fellow co-workers and at some point it will happen someone will mention a fairly big change I think it's time to replace a reticent environment with a Kafka cluster because we're going to need the scalability requirements and this is when the problem starts because this is a developer proposing this this is someone who doesn't have the ops background historically this has been in the circle of bozos around the island of safety so this is what happens what no can't do this we don't know how now here's a key thing because this type of proposal with the kind of thing that would likely come up during a sprint planning meeting or possibly during a stand-up kind of depends on the local culture of what particular company is but if you look at how these these particular organizations work and these particular meetings work it's a lot more free-flow what do you think about this we should do this or not and it's very back and forth and it's very collaborative and very dynamic and here's somebody saying wait stop stop stop stop we can't do this it stops everything cold and there's a couple of ways to do this one and the healthy way to do that one is to actually challenge it okay so the scrum leader whoever says what challenges are you seeing okay okay we can make some user stories about that can you work with the person to propose it we can part together a list and probably flesh out these user stories so they can appropriately size this particular epic because he knows it's going to be an epic and away you go that's how it's supposed to happen all too often when someone says no that flatly what happens is is people stare at the person who just did the very strange thing quietly ignore it and the scrum master whoever says okay looks like we're not ready for that now let's you and me talk after the meeting and okay what about your update and then quietly drop it meanwhile after the meeting they talk we start building things and these two work out the issues that are the operations problems that probably cause a new person to throw throw a big monkey rich into things and come the next sprint meeting or sprint planning meeting and it's still on the agenda the person who got cut out is going to go okay they're not listening to me anymore all right I know how to handle that the investment it's sort of shut up now this is the challenging part of managing an agile team with some of one of these digital immigrants because if someone said no so forcefully in the planning meeting and suddenly shuts up and doesn't input into the process at all that's actually a bad signal negative signals like that are hard to interpret so pay attention to them and the way you deal with this one is to actually sit down with them okay I see you had some big problems with this when he initially proposed it but I haven't heard anything from since what kind of problems are you seeing now and you're going to get told because these are people who are not used to being asked their opinion and when they do that typically do it fairly voluminously because it's been building up for a while the whole thing here is to start retraining these people and that you can contribute you don't have to wait back and sort of throw these verbal elbows in you can actually just say you know I think this is not I don't think we have this fully fleshed out yet the ultimate goal is when someone brings up a big problem like this a big task like this one is is I can see a lot of operation side effects of that one I'd be happy to work with you and flush out those user stories and actually volunteer that at the front instead of having haven't drawn out of them by the scrum master whoever's meeting the meeting but you have to get them to that point and it can take a couple of years to get this sort of deep history of trauma behind them and actually get them comfortable with the way the social dynamics work in an agile system it can happen and bonding through negativity now this one would actually happen before the big problem this is when someone who's been in this IT organization this completed dysfunctional type stuff tries to make friends with the fellow co-workers everybody loves a good use stupid user story I got lots and starts bagging on our users bagging on our managers and bagging on the other dev teams if there is one because under the midst of her under the misconception that that's how teams like ours work that's not how we when you're in a large product group I have yet to meet the product manager who likes that sort of combativeness between each development groups and especially with with a negative attitude towards our users no you don't want that you're trying to build up it's optimistic and focus so yes we're trying to support our users this is a additive we're trying to focus and you really do need to check that check it signpost your office culture this sort of negativity is not acceptable and I say even you upper Midwesterners because I grew up in Minnesota and the way this sort of problem is handled is sort of quietly not in smile never talk to that person again and they just sort of slowly shun and you walk away and you've never actually talked to them again and they may not even notice they're being cut out especially if they're coming from another part of the country where that sort of language isn't really understood but this is something that if you're not comfortable with conflict this is one of those things where you really need to actually get up and do it stop that it's not acceptable this is the thing that you may actually have to figure out the real assholes that are coming in through the hiring pipeline because a true asshole when you check them on that or either fire return fire with further hostility and double down that's a true asshole fire that person they're an asshole get rid of them but the adapted assholes the ones who figured out this is how you talk in the workplace but fundamentally are nice people will start dialing it down and start adapting to the environment they now find themselves in because you've given them a hard jerk on the job on the leash on their job saying hi you keep doing this they'll not have this job anymore if they respond to that particular input you have someone you can work with so and the next thing I want to talk about here is my summary slide I got quick so that three three things you want to do and this is the one slide you want to take a screen shot of this is the one you want to do because there's three things to do when you're dealing with these digital migrants and the first one is to redirect them you want to turn that reflexive negativity an option to provide feedback and what this does is it teaches that they can provide feedback safely without having to use excessive verbal elbow and discomboting all the other people in the entire in the room and the second thing is to make sure to re-engage them because these are people who are especially if they're the lone ops person in a dev team they're already used to working by themselves and it may take repeated attempts to bring them back over and communicating and integration and it may require having to explicitly pair them with a developer like that Kafka thing I was talking about earlier okay I need you the ops the ex ops person and you the developer proposed it to sit down together for a week or whatever and work together some of the issues of what this deployment would look like and start getting them integrated and instead of just being off a service island by themselves what you're teaching them is that they are a person they are not a service they are a person this can be amazingly hard to pound out of some heads it took a while for me and then of course stop the hurtful negativity because IT people can be cynical bastards and it's not always the happy cynical it's sometimes a hurtful negative kind to need to very clearly signpost that that is not acceptable check that shit and fire the assholes who don't adapt and that's that's time we need to come to questions so if you have any questions about office culture if not I can start going on about the Google study so any problems you've had in scrum meetings that you may want to help some sociological advice on now one thing I do want to talk about here see if I can will it do it yes awesome so there was a slide this morning see if I can make it do the thing oh you're not gonna do that all right so we'll have to do there turn you off do over here this was a slide that came up this morning uh from Catherine Daniels at the keynote she gave for continuous lifecycle London now this one slide again this was delivered this morning by someone who was not me was part of a larger discussion about effective DevOps culture and I want to look at this one specifically because the Google study that I mentioned earlier it went through a lot of iterations before they finally figured out what's going on and their first try was to like engineers drill down to the very bottom essence of what it is to be an effective team what is the one thing that they all have figure out what it is and pose it from without on the non-effective teams and make them effective teams and they couldn't find it there is no tool there is no process one process that will do that what they found ultimately is that there are tools and processes that are conducive to maybe fostering this environment in most cases which is not the case which is not the absolutist thing they were looking for what they had to do is they had to go up a couple of levels on the stack out of the tools and processes layer into the people layer because people are delightfully analog very analog in fact you can't just teach them as digital units that get slotted into buckets and it ended up being psychological safety so was the thing that actually made things work and for some some groups it very much is eight people sitting at a table throwing ideas at each other ripping them to shreds as they come across and this the robust exchange of ideas that can be completely vicious works for them and everybody at that table is perfectly happy that sort of thing and they're a very effective team until someone new has to come in and integrate with it in which case it may not work so well because they don't deal well with being eviscerated by their new co-workers but you know sometimes it works and other groups such as those Minnesotans I was talking about where that sort of robust exchange of ideas is eight people staring in a room someone throws out I think maybe we should do that there's three or four seconds of silence someone says how about if we do this other thing instead and slowly and carefully they work through this problem just because of the communication styles of different regions actually work so when you're looking at your agile agile teams the planning meetings the stand-ups be aware of this you're looking for psychological safety ultimately and the problems that I've identified are very much ways to help ease someone into the software engineering type of optimistic environment scrub off the cynicism or at least repress it into helpful ways and actually help contribute you are not a you are not a service you are a person please talk to us we like hearing from you you have good ideas so any other questions and I got done fast all right in that case I don't have anything else to say so I guess we get to go to break early hopefully get the snacks fast so thank you