BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations Psychologically Safe Process Evolution in a Flat Structure

Psychologically Safe Process Evolution in a Flat Structure

Bookmarks
47:41

Summary

Christopher Lucian shares practical ideas on how to add evolutionary management and process iteration into a company, such as establishing a safe environment for collaboration, encouraging new ideas to emerge, decentralizing the process, identifying good and bad patterns by relating to successes and failures, escape complacency by allowing the good ideas to flourish, and more.

Bio

Christopher Lucian is the director of software development at Hunter Industries and a founder of mob programming. He is passionate about the advancement of software craftsmanship and machine learning.

About the conference

Software is changing the world. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.

Transcript

Lucian: I intend to talk about "Psychologically Safe Process Evolution in a Flat Structure." That's a lot to say.

We'll get started, talk a little bit about the environment today. We mob program full time, teams are regularly recombined, reformed. The processes come and go as needed, and innovation happens on a regular basis. I'll talk a little bit about what that means to us. Also, another big thing is that safety is a prerequisite for all forward movement and we can get into that a little bit more in a bit. You'll also see a couple of elements about our environment there, lots of physical artifacts on the walls, things along those lines. We communicate pretty rapidly, information's available right away.

This is where we started, we were just in cubicles. There was primarily waterfall process before mob programming came about and other things along those lines. They were a serendipitous history. Woody Zuill ended up becoming the manager three months after Mark Hayes had become the director and then he hired me three months after he was there. There's a couple of people that were put in place that eventually created an environment where an agile transformation could happen and we had the right people in the place to have a lot of maybe synergy to create some rapid change in that space.

This is actually a little bit after we had started mobbing, we can get into that a little bit more. This is what mob programming looks like, so four developers to a computer at any one time. If you're pair programming or mobbing, you'll be familiar with this. If you're working by yourself, this might look a little bit scary and there are lots of ways to make this safe going forward. Actually, I feel like mob programming feels safer than necessarily pairing, because having a third person there feels much more of a collaboration and much less of a, one person's better than the other, something along those lines. We work like this all the time, and we find this is much more effective for us than delivery, things along those lines.

We also formed the flat structure through retrospectives. We had originally started with a mob and Woody was the manager of that team and he was protecting what was happening as far evolution goes. We're doing regular retrospectives. Woody went independent, and then we started retrospecting about how things should go forward. We decided not to replace him as a manager, and instead, we just started reporting to the director of IS. Then gradually, over the next six months, the team actually had an external consultant come in and evaluate software practices at Hunter and they determined the result of that evaluation was that our team was doing continuous delivery and had zero bugs in production for long periods of time and things along those lines. They recommended that we grow and I became the director.

Establishing a Safe Environment

From the takeaways on the talk of the title, I have the key takeaways. One of them is establishing a safe environment, this talk is essentially broken up into that. That was a little bit about context, about where we are today and where I'm getting these ideas from. When I talked about becoming director, we went from a team of 5 people to a team of 27, and so there's a lot in here that came from just necessity through our growth and I think a few key concepts that come out of that is the idea that our process is always evolving and so that's a little bit about what's next, which is complacency with the status and status quo.

I think there's nothing more dangerous to a team than keeping your process and practices the same forever. This is just an example of the manager up in your face shaking their finger at you or something along those lines. That style of management has long since been proven that that's not as effective. I think the first thing that is core to this, is to unlodge the status-quo so that we can make things safer, we can move things forward a little bit more. A big part of creating that environment is to make sure that the old stuff isn't as prominent, or doesn't have a strong of a hold.

I should go into this talking a little bit about forming, storming, and norming, and then my next slide's a little bit about Satir Change Model. If you've worked with teams that have to get together or accept change often, then there's forming, storming, and norming periods. Performing is the next stage. What I want to say here is that if you're in the process of scaling, there's a point at which you've grown so big that you might stay in storming for longer and longer periods of time, and a lot of this is written by Virginia Satir and the Satir Change Model. It's all like family psychology stuff, but I highly recommend that you look that stuff up.

The way that the model goes is that there's a late status quo, a foreign element either new process, a new team member, something along those lines that gets put into the team. Then the team's performance will actually go down for a period of time and it will remain rocky for a while and then go back up. What I've seen from the speed at which we scaled or in cases of high levels of turnover all at once or something along those lines, is that you can't expect to preserve that culture that you have and at some point, you've reach this piece of diminishing returns that you have to then work on a new culture. It might be close to what you had but it's important to pay attention to those things.

Another key concept is don't try and change your entire organization to believe things. One thing about creating a safe environment that's really important is to pay attention to the diffusion of innovation. At Hunter, there are multiple software teams, we were the only ones doing mob programming. We were the only ones doing agile, we were the only ones doing lean for software environment. That works to our advantage because we were the ones that were happy to work with it. I think if we had everyone, then we would have very high levels of resistance. Then I purposely added the next slide just because I saw this just before the keynote, the InfoQ graph is actually the distribution of innovation.

You see the innovators, early adopters, early majority and later majority and then you'll see that piece where the chasm is. That chasm is the place that you need to cross with a new process. If you want to foster, for example, a safe environment or a flat structure, some really important stuff that you pay need attention to is this diffusion of innovation theory because I think it's shown itself to me over and over again. I also especially like that mob programming was in the early adoptors phase and no longer in the 'look, that guy's crazy' phase, so it's pretty good.

The primary goal is getting your early adoptors together. This is a big piece letting people choose their own teams, for example. If you do that, then you might get a group of people that all think alike in the sense of, "I believe we should be safe, I believe we should be doing continuous delivery, unit testing, all those things." There are probably people in your organization that really wanted to be doing awesome stuff but they're all in different teams. How do you make this successful? If you consider that there's going to be essentially like the corporate antibody personality or what is referred to as laggards in the diffusion of innovation theory, then you can take that information and use it to your advantage. It's like, "Who's interested in being candid with each other and caring personally about each other, let's get them all into the same team."

Another piece of this is basing everything off of kindness, consideration and respect. When Woody started at Hunter, he asked for everyone to agree to a core working agreement and that working agreement was, treat everybody with kindness, consideration and respect. Everybody outside your group, everybody inside your group, everything along those lines. I think that that was foundationally an extremely important feature of our team today. We kept that going forward and we built on it. I don't believe that you can get to psychological safety unless you have kindness, consideration and respect. While candid feedback is a piece of respect, I think that if you are disrespectful to someone then you will never be able to reach that place of psychological safety.

Gradually, over time, I think we acquired the idea of vulnerability, trust, and appreciation and this is maybe the next level up in my mind. If you're treating each other with kindness, consideration and respect, maybe now it's ok to be vulnerable, trust each other, and show each other appreciation. Then beyond that, I think that can lead you to having really candid conversations and breaking down problems independently of each other. Who would be able to take a selfie with a selfie stick in the middle of the office unless they trusted each other and were vulnerable.

Psychological safety is defined as being able to show and employ oneself without a fear of negative consequences, self-image, status or career, and that comes from an easily googleable research study. A lot of people misinterpret psychological safety as being polite to each other or something along those lines, but that's not actually it. It's being able to say your opinion and not fear retaliation and make things ok. Establishing a safe environment is at its core, candid, respectful feedback where people can be vulnerable with each other. Setting those things up as you move forward can help establish a safe environment.

Woody's often in the right there. One thing that he did also is, he provided space. He did what was called holding space, which is essentially protecting the team from outside negative influences from disrupting its progress and instead, nurturing what was going inside the team. If you're a leader, you have to pay attention to this. One of those negative things coming in and disrupting the team and helping the team manage that through, the things like not taking things personally, things along those lines. That's also really important.

We have a couple of things that we do to establish safety. A lot of things are done through groups of people making decisions - I'll explain a little bit later about more of our decision making. In this picture, for example, they're doing Roman voting at that end of a round of a discussion. If you've done any lean coffees, for example, you might see a lot of agreements to go on with this topic. You might even get situations where people have a hard time giving feedback about how long somebody is talking. Maybe somebody is really long-winded about some topic and giving opportunities and space for those things to occur.

I'll talk a little about the decision making and decentralization thereof. For large decisions that we need a lot of people involved but we don't have a lot of time because I think timeboxing is really important, we use one of two strategies. We use liberating structures which is a talk on later, and we also basically manage decisions at a local level and then aggregate the responses.

Liberating structures is a series of exercises that can help either facilitate feedback from large group of people to each other or do other things like provide feedback in an easy way. Then the local decision making is basically providing a common interface or a common goal to multiple teams and let each team decide independently how they're going to achieve that. If that becomes unmanageable, then making managing that easy as part of the goal and that seems to work itself out very well as well. That makes it scalable.

Another big piece is decentralization of decision making. What I really mean by that is more about the servant leadership side of things. A very important thing is to, as leaders, make decisions where the information exists. That means pushing down responsibility for the decision making to the local areas. As a director, I might make decisions that are based off of global trends, not micromanage-y type behaviors.

Encourage New Ideas to Emerge and Treat Them like Experiments

The next section is encouraging new ideas to emerge and treat them like experiments. There's this series of behaviors that I believe will lead anybody to acquire a better state tomorrow than what you have today. Everybody has a different starting point, and so, it's really important not to try to take all of these practices and then start using them. Instead, create a virtuous cycle that will then build things up - I will talk a little bit more about that later.

Learning sessions, in particular, we do seven hours of learning a week. That's an hour at the beginning of the day every day and then two hours at the end of the day on Friday. This is dedicated learning time. Sometimes, this is done in mobs, sometimes this is done individually. The goal there is, either learn something that you know you need to learn for the project that you're on or go learn something that you know you might need for a project that you're on, or, if those aren't satisfied, then go learn something that is new and interesting. I like to use the example of how of tSQLt store procedure unit testing made an indoor stack was purely through learning sessions. Then eventually, we were able to unit test our store procedures.

Also, retrospectives as experiments. I see a lot of retrospectives happen in teams where they do them maybe once a month and they have 27 action items out of that 1 retrospective and then no one did any of them. Some people may have had that - I see some people smiling - some people may have had that in your environments. I would encourage you to try this, instead of having many action items out of your retrospectives, go ahead and just say, "We can only have one." Then don't do your next retrospective until you have data about how that one change affected your process.

With the learning sessions, and retrospectives with one action item as a hypothesis that you then run experiments on and then you come back, what do you come up with? You get this virtuous cycle of improvement. If we talk about continuous improvement gradually improving your process over time as you go, then again, you'll make leaps and bounds. You won't notice it because it's a very slow and iterative process, but if you have somebody going “Come into the team” maybe as consultants, they come into the team for a little a while and then they leave and then maybe years later, they come back. We've had consultants like that and they've been shocked at the progress.

That was actually one reason why we decided to name mob programming as we had a consultant who had done some test development training and then he went away and then he came back later and he's, "Oh, my gosh, the level of improvement. You should really name this thing whatever you're doing here." This is me in Japan with all the mob programmers that are doing mob programming in Japan. It's just amazing how it can spread globally like that and reflecting back on where you were. We do a lot of timelines and chronicling. It might be the anthropologist of the team. You say, "Here's where we were and here's where we are now."

I think one really important thing that I didn't harp on in previous talks that I've done - and I got this feedback, I should make this much more prominent - is decide now how you're going to stop doing a bad practice if the team agrees that it's bad. How many teams have existed where they just kept doing the thing? Decisions that we've made this way, just examples, like we've stopped doing internal emails, we've stopped calling things projects, instead we refer to them as projects. We've stopped doing solo development, we've stopped doing estimation, we stopped doing manual testing, and we've stopped doing releases that are huge and other things along those lines. Those are ideas, how do you stop doing things that are just accepted as the status quo?

I'm going to go back to the idea a little bit about emerging ideas and experimentation and nurturing. As this is all happening, there's a lot of negativity that can creep into the system. There's a book "The Four Agreements" which has a lot of great and interesting concepts about not taking things personally, being accountable, holding yourself to your word. There are things that an individual can do to stop propagating negativity and in that, if you have enough of people, a critical mass of people acting like that, then you'll nurture that. Another thing to look up is "Expedition Behavior" which is a set of 12, 15 principles that are really great.

Decentralize the Process and Avoid Deferring to "the Bosses' Ideas"

We'll get into a little bit about how we decentralize the process and avoid deferring to the bosses' ideas. Quickly after I became the director, I've noticed a trend of people just like going along with what I'm saying and so I stopped saying stuff for a while. Then I wanted to contribute technically still, but I didn't want people to defer to me. Now each time I'd give a technical recommendation, I'm, "I encourage you not to do this, but this is what I would do." That's a big piece of it in the servant leadership side of things, it's like the HiPPO effect, the highest-paid person in the office, there's a lot of pain that can come from that.

Instead, we decentralize based off of the league of interested individuals or what we used to call homeowners associations. Since homeowners associations are not really viewed in the best of light - I've heard some people ask what are homeowners association, so it's like in housing development, there are lot of houses and people can pay money to a central organization and then that central organization will do grounds keeping or maintain a pool or something like that. That's a homeowners association, it's like the voting process for that. People go into a committee, they make decisions and then everybody has to live by the decision whether or not it was a good decision.

We take that and we turn into a series of experiments and so we decide how we do our budgeting, how we do our promotions, how we do recognition. Every manager decision comes out of one of these league of interested individuals. It'll be interest groups, getting together and saying, "Ok, budgeting went this way last time, let's do a retrospective, let's do it differently this time." Of course, that becomes very complex with the complexity of interpersonal networks and so a big piece of that is using things like liberating structures and agile retrospectives as ways to facilitate decision making. Then, in some cases, there needs to be a tiebreaker, but not many.

When it all falls apart, those are the cases where you might experience since this is where people can't come to an agreement or maybe there's some large level of interpersonal conflict. I think at that point, that's when a servant leader might step in. I think one of the only times where there might be some command and control stuff is when people can't come to that decision easily together themselves. It's ok for those events to happen, but they need to have a strong way of being rebuilt from. You're not going to not fail by doing what I'm talking about, but what you need to think about now is have a plan for recovery if there is strong interpersonal conflict in those situations.

Just to go down to the computer science-y/machine learning route, which is a theme for today - evolutionary algorithms use Darwinian evolution to grow a new solution. Why not use the same thing for our teams? You have a process evolution happening for each of the population and you can see that these things are gradually evolving to better and better, so why not share those patterns between the teams? Then those patterns get cross-pollinate and then you get new generations of that existing team. If you think about it as an evolutionary process and this is my strong points to keep things iterative. If you want a purely technical example, look up evolutionary algorithms for that.

If things become too big, if you have a team of 30 people and there's strong disagreement between groups about how work should be done, allow them to do the work in the way that they decide on their local level. You can let that process fracture. Microservices architecture can be really strong for this or even serverless and this idea of using ETLs and service buses to then support different functions. If you have groups of people working independently on different areas of your application or applications, then providing a acknowledgment to Conway's law, to split out your architecture depending on the way that the teams want to manage themselves, that's ok as long as you have that common interface like the service bus, for example.

Patterns, Antipatterns, Successes, and Failures

I have a lot of antipatterns, patterns, successes and failures. This is just stuff that we've experienced in our journey of getting here. I want to highlight the patterns and antipatterns because it's been a very iterative process. All these things are things that you can try, I don't think that everything will work for everyone. It's just different things, like when we started talking about mob programming - mob programming won't work for everyone, but it's stuff that teams can try to get better collaboration, better full-stack development, vertical sizes, things along those lines.

One of them that has worked really for us is peer-reviewed goal setting, and so we have a couple of processes that we've gone through over the years. One of them has been a timeline retrospective with good events, bad events, force field diagrams, things pushing us forward, things holding us back and then, making goals out of that, so that was self-directed. Then we wanted a safe way to provide feedback, and so what we did is we did this mob feedback retro which was essentially - think of everybody on your team and write a sticky note for the topmost needed skill for each person on the team. Then put that on a board, and then you prune it by just removing things that are duplicates and things along those lines, then put that on a survey and then rank those skills for each person on your team. Now all the skills are out there and it's safe and things along those lines and that has helped us create goals, you see the best thing and the worst thing.

Many times throughout my career, I've done a lot of process change in organizations that I have been a part of and it's usually all of the biggest progress moments have been the emergencies. If you have an emergency you're dealing with now, or maybe you see an emergency coming down the path, when things totally blow out for a company, that's when management is most interested in hearing somebody with a new idea, and you can always bring things like this. Maybe the next time you throw away a six-year-old code base and if you have to start over from scratch, you say, "Maybe we do retrospectives and learning sessions" - not that I'm telling you what to do.

Another thing is keep a list of lofty goals. These are on my blog if you want to see them more closely, and they will be in the slides, but the top one on how do we interact were slides in here already, which is the kindness, consideration, respect, vulnerability, trust, appreciation, and psychological safety. My main point for having this slide in here is create a set of lofty goals. What does everybody agree on is something that maybe isn't totally attainable today for everyone, but something that we should strive for as a group, because that provides a unified focus for where you want to go and will really have a very strong impact on your team over a long term. It's good to create this out of the group.

Another thing is making failures common, inexpensive and informative. My father does lots and lots of pottery, he did 13 years straight of making 8 or 9 pieces a day. He failed a lot, but then he started making some beautiful stuff even to the point where, floor to ceiling in his apartment and every wall is covered in pottery, and I have to give pottery away at Christmas hundreds of pieces at a time. My point here though is that, that failure, that fast, small, inexpensive failure that he was able to accomplish made his pieces better and better, and that will work for the team. Making failure ok is like a key point in all of this.

Inclusivity and sharing credit. A big antipattern that I've seen in the past is people taking credit or saying, "I'm the sole originator of this idea," even though it was innovated on by other people. The pattern of not being inclusive is actually really quite a negative thing. This is a behavior you can model for other people and it will gradually become infectious. But saying, "We worked on this together," you might be the originator of the idea, but acknowledge the contributions of others around you, that will establish trust. I think I see trust falling apart in very weird situations where multiple people think that they're the beginning of some pattern or some great thing.

Frequent experimentation. This is a mob programming session in a car I think at the mob programming conference. It was a remote mob programming in a tunnel over a cellphone connection. It was an experiment, it didn't work so great. The idea of just trying crazy things here and there and seeing what sticks. Fast, inexpensive failures is really a big thing, but have that hypothesis. You could even say, this week or today, what was my hypothesis today that I'd come up with? Did I validate it? What was the experiment that played out in front of me?

Everything on wheels. This is just a purely practical thing. Our whole office can be re-arranged at any time. I encourage you to do the same having cubicle, there's nothing more disempowering than a cubicle that you have to call another department to move. In fact, there have been times where I have been in trouble for disassembling cubicles when I shouldn't have been. Just clear the stuff that can't be moved around out of your offices, and you'll see a lot of great things happen. Just like being able to select your own teams and producing an environment that's flexible, I think you want to be able rearrange just about everything in the environment. In fact, I think this station right here is no longer even there today.

The Antipattern: Management Kanban. You hear me talk about HOAs, the league of interested individuals. This is an antipattern which is, we started throwing management tasks upon a Kanban board, we just try to execute on them. We have no managers because it's flat structure, so our capacity for doing management work grew uncontrollably. A lot of people are saying, "I don't have enough time." That's the point of this picture - no one's actually programming right now. A big piece of it is you want to be able to have some mechanism to rate limit the amount of management task that you have in your system, because management is a minimum necessary sort of idea.

Exclusive meeting invites. This is another one that happened, people with the same title started getting invited to the same meetings or something along those lines and that created a different thing. What would happen today if you just said, "Every meeting is optional and you're invited to every meeting," and we just call every meeting? Certain people would just ignore it, some people just want to develop all day, everyday. In fact, we have developers that have one hour of required meetings a month. They're development or learning the rest of the time. That's a big piece of why we can get so much done so quickly, we're not spending a lot of time on those things, but we can if we need to.

Another one is inappropriate gamification. I'm a big fan of gamification and I make little video games and things like that in my free time, but there's definitely an antipattern to that. We try to gamify learning with learning guilds and things like that and it all just went horribly wrong. I think that even today, I learned from the talk that I just went to about self-selection that there's probably a very appropriate place for gamification and then there's probably a very inappropriate places for gamification. The appropriate place is getting people to accept the process that they maybe are afraid of. Anything that you try to say like, "We need to do more of this thing, let's gamify it," is maybe the wrong place as a mandate. Games should always be available to get to.

I'll just sum this one up really quick. Software developers are really good at automating things and to estimate something well, you need have done it many times before. For a software developer something well, they must have done it many times before and not automated it. It's the pure antithetical thing that you could possibly be doing. That's all that I'm going to say about this, you can find more about that at the Software Estimation Paradox if you look that up. Essentially, this is one of the key areas where safety gets diminished. If you're looking for other KPIs, there's things like cycle time and bug count that you can track that is much more important that a burndown.

Another thing, practice envy, this is what I was talking about earlier. Don't say, "We're going to all of this tomorrow and it's going to be great." Pay attention to the diffusion of innovation, I can't stress that enough. The practice envy - we take a lot of visitors at Hunter to come see our software development environment and talk about software development, things along those lines, and we learn a lot from our visitors and they learn a lot from us. The thing that I see a lot of them do is they just say, "We're going to..." Either they'll be like, "There's no way we can get to where you are. We're so far over here and you're so far over there." Or it will be, "We're going to be doing everything you're doing tomorrow and then we're going to get back to the office and tell everyone." Both of those things are totally wrong, just pay attention to diffusion of innovation, picking one experiment at a time.

Another antipattern is low-frequency contact with critical relationships. This is a big one, let’s say we have four product owners and one shows up monthly, one shows up weekly, one shows up daily, or one is there all the time. Which team do you think will have the fastest cycle time? It's probably the one that's there all the time and in fact, we've seen this. The project with the monthly available product owner ended going to six hours of meeting time a day for some weeks. Charting meeting time based on product owner availability actually has some pretty significant data trends and you can convince people to be around more just by showing that data.

Prolonged feelings of inequality. Whenever you have an environment that a lot of people can choose what they want to do, or you can pick your own team or go there or you can set a policy for everyone else, there may be situations where people are afraid to speak up and might only talk in a one-on-one or something along those lines. You need a facility to identify those prolonged feelings of inequality and address them because if you don't, then it will fester, and it will cause turnover and things along those lines. You can maybe restructure your goals for the team, address a single symptom, or come in and do the command and control if you have no other option. That's a big thing.

Escaping Complacency in an Organization

I'll talk a little bit more about escaping complacency in an organization. At the beginning, you saw my slide on the status quo. The status quo is really hard to break, but there are couple of ways that I found to make things move a little bit faster as far as an organizational change standpoint. I think one of the biggest ones that had helped me during the transition over into a flat structure in a hierarchical organization, doing things completely different in different ways is this idea of transparency, results, and consistency.

We have two graphs here, the top one there, we're using GoCD which I saw was one of the vendors. I called into the API and then I basically said, "Did our dev development deploy today? Did our stage development deploy today? Did our product development deploy today?" It's like a "Guitar Hero" stream. Everything that doesn't have a dot is a business day that didn't see a production deployment, or the bottom row is a production deployment. That's one of the key measurements. Can we deploy every day? Did we deploy today? That's a big thing. Then the one underneath there, I'll just a little bit about. That is an automated Gantt chart based on end-to-end test scenarios. Did we make a feature today? Did we deploy today? Is that feature viewable to customers? That historic Gantt chart actually gives the business a lot of confidence.

I have this slide, feed them what they enjoy eating. If you have executives that you need to convince, this helps me a lot in my organizational change journey. That was, find out what your executives read and then find articles that support your ideas from those publications and then feed them back to them. If your executives really like "Harvard Business Review" then go and get "Harvard Business Review" articles about not estimating and things along those lines. Or you want to transition to agile and you're in a waterfall environment, go look at "Forbes" and look at their top chart about why should turn to agile. They are less likely to trust a Martin Fowler Blog for example because Martin Fowler isn't a developer community and it's just more of that isolated ecosystem, so what you need to do is to go out to broader ecosystems.

The third-party practices audit, you might imagine that for most teams, that was really uncomfortable. One thing that we did is we just said, "We'll invite them in. We'll just show them what they're doing. We're proud of what they're doing and we're going to bring that in." If you ever have an auditor there, call out, be very transparent. Just say, "We know that this is an issue, we're working on this. We are doing this well, and this how we're doing things." That transparency is actually very refreshing to anybody who's doing an audit because the major antipattern there when dealing with an audit is people trying to hide information. If you're an auditor and you're incentivized to find things that are funky, then you'd be much more upset to find out that somebody was actually had hundreds of bugs rather than one day I'd told you that they had hundreds of bugs.

Second-order effects of money tied to the team, or tied to them. Second-order effects comes from complexity theory and it's most easily boiled down to a side effect of a side effect. Here we're teaching kids how to program and we have a 8th Grade school class come in and program with us for a couple of hours. That costs us money to do, but, what are the side effects of the side effects? You can extrapolate from that, that people are happier with their jobs. We have kids that are interested long term in coming back to Hunter to work for them. You have a better view of the world.

I encourage you to take a picture of this slide if you want things to look up in those. I've said a lot of other topics as well, but some of those are very important for this type of work.

Today we covered establishing a safe environment, encouraging new experiments, decentralizing the process, identifying good and bad patterns, escaping complacency, but my key takeaway, my number one thing that I want you to leave here with is make your process iterative and iterate quickly. None of that stuff is as important as actually just dislodging, saying we're going to go years working like this and never change our process.

Questions and Answers

Participant 1: One of the things you talked about was making failure ok. Do you have any advice for a servant leader on how to make that? I forget your exact words, but making it easy.

Lucian: Common, inexpensive, and informative. The easiest thing to say is don't punish the failures and instead use language of learning. A big problem and a big antipattern in trying to establish psychological safety is this idea of forming problems as execution problems versus learning problems. Even the model that you can use when you first talking to a team about a new initiative, rather than saying, "We need to get this done," just shift your language and say, "We need to learn how to accomplish this." The learning implies that level of safety. Using that language over a period of time, not punishing the failures, getting examples of learning them, that will all end up really helping in going forward.

Participant 2: If your team is experimenting with something more collaborative, but your upper-level management is very into attributing IC work as a way to get promoted, how do you bridge that gap? An example would be, if I paired with someone, but maybe they deployed the final PR, my name's not on it, then how do you make sure that I get the credit for that accordingly?

Lucian: Inclusivity and sharing credit is hard to establish especially when you're monitoring that. From leadership standpoint, the metrics need to be changed. You need to measure the value produced by the teams, not the value produced by the individuals and then the teams can self-regulate based on that. Strategies for accomplishing that might relate to diffusion of innovation.

Depending on where are in the organization you might find people that agree to share credit, like maybe do one PR from one and then do another from another. Then you try and diffuse that innovation - diffusion of innovation. You build up support for that, those ideas and you get the early adoptors together to work on those ideas together that way. Higher up in the organization, I'd suggest executives read books like "Turn This Ship Around" and "The Answer to How is Yes," things along those lines.

Participant 3: It seems that most of your experience comes with co-located teams. In our case, it's a team of 10, no one in the same city in Europe, Asia, and the U.S. and some people don't overlap at all. Except for the tone of communication, any other comments in that scenario?

Lucian: I have a few groups in Australia and we have some of the time zone stuff. I think the main thing there is common interface and being able to manage things on a local level is really important. Setting common goals for the team and making feedback available for the teams and for those goals, but making it so that they can decide how they accomplish those goals can be a really powerful thing, like showing trust in them to make those decisions, but outline what outcomes we want to see.

I think that people will work towards whatever they're incentivized by, if it's individual contribution then that will destroy teamwork. If they're incentivized towards teamwork then that will incentivize collaboration. As long as you have the iteration process for actually iterating on those things, I think the most important thing is saying, "Do you have a way for them to retrospect and do you have a way for them to learn?"

Participant 4: What techniques do you use to deal with things that are outside of your control? For example, you talked about removing bad parts of process, from my point of view, almost all of the bad parts of my team's process are imposed on us by the company. I'm interested in that.

Lucian: Two things I'd recommend, number one is look up and employ all aspects of expedition behavior. NASA makes all of their astronauts go through an expedition behavior training because when you go up into space, with zero gravity, you can't use the bathroom the same way and everything locks up. You're really uncomfortable for the first I don't know how many hours, but then you're really uncomfortable for long periods of time. You close your eyes and then lights flicker because the radiation passing through the International Space Station. You have prolonged irritations that exist and that's what expedition behavior addresses. Anybody that's discontent themselves or has teams that are discontent, expedition for things that are outside of your control, expedition behavior is my recommendation for them.

One more things that I'd recommend is be more agile than the rest of the company, and so find ways to satisfy all those requirements as quickly as possible. If you have to enter into a ticketing system, automate it. Get access to the API and automate the entry to the ticketing system. Things along those lines will help show that those things actually have no value and then value stream mapping, having a value stream map of your team's value stream up in the office will really help, if somebody passes by ends, "What's this?" I'd be, "This is all the time that we spent not actually doing work." That can be a really powerful conversation to have and you just need to make it transparent.

 

See more presentations with transcripts

 

Recorded at:

Aug 17, 2019

BT