BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Lee Thomas and Nick Cahill on Self Organizing Organizations

Lee Thomas and Nick Cahill on Self Organizing Organizations

Bookmarks

At the recent Agile New Zealand conference Lee Thomas and Nick Cahill gave a talk titled the Self Organizing Organization in which they explained the journey that Fraedom has undertaken to empower teams and support true self organization where the teams define their own practices and approaches rather than following an imposed agile method. Afterwards they spoke to InfoQ about the talk and their involvement in the transition.

InfoQ: This is Shane Hastie for InfoQ we are at the Agile New Zeeland conference; I am talking to Lee Thomas and Nick Cahill. Lee you are the Agile Lean Practice Lead at Fraedom.

Lee Thomas: That’s correct.

InfoQ: And Nick you are an independent delivery consultant but you have worked with Fraedom through their journey?

Nick Cahill: Yes, I’ve been there for eight years. Not as an independent consultant, as a full time employee but there has been a recent transition nine months ago to be a consultant lead.

InfoQ: Great. Now you’ve just given a great talk on the self organizing organization, which has been the story of Fraedom’s transition from an imposed Agile approach to a true team driven one, could you say that?

Nick: Yes it’s definitely that the latest step in our journey on an Agile evolution, so we did start off with a top down driven approach five years ago and we have evolved to much more of a grass routes sort of self driven organization by removing constraints, so we have taken a lot out. The model is much more about what’s not there than what is actually there.

InfoQ: Ok, so for organizations that are looking at trying to achieve the same sort of outcomes for themselves, because one of the things you were clear about is don’t copy but use these as ideas, what are some of the good ideas and / or things to avoid?

Lee: Good ideas, let me see, the change manager coming in, she really helped us around some of the harder conversations for some of the marginal people, who were really unsure, very unclear if their roles were affected, how we redeploy them, and really helped them work through the challenge and of their own personal changes. That was very successful.

Nick: The key idea is still identifying those constraints inside your organization. So remember the goal of this model is self organization and allowing that to happen at the org level and the team level. In doing that you got to work out which constraints are primarily working against self organization, and they could be organizational or they could be team level, so we had the team level ones that we had removed most of, but we had a couple of stuff left over from our legacy org structure which we go “What do we need that for? Why do we need that? How can we restructure that?” So it is more fluid, less constraints and I think that is the key point, and everyone’s constraints are different so that’s why we say “don’t copy ours, because you have a different set of constraints, a different set of goals”.

Lee: It was kind of deliberation as well of some of our technical people to focus on the stuff that they are truly good at, to free them, for a better word, some of our tech leads were saying that twenty-thirty percent of the time they’ve got other issues that they’re dealing with but it’s giving them the head-space in order to do that.

InfoQ: So freeing technical people to focus on technical things. You mentioned a couple of interesting anti-patterns, or things that might not work too well. Do you want to take us through a couple of those?

Nick: I guess the anti-patterns are in the context of self organization again so they are not anti-patterns from a business perspective, some businesses can probably use those patterns quite effectively but if you are trying to get self organization to be a goal of your organization then these patterns were true anti-patterns. The key one that we had was the management influence on the teams, so the teams themselves, we had to delivery teams that were self-organizing and yet we had four or five managers that were trying to tell different parts of those teams what they should be doing and our job was to say well let’s remove those influences all together, some of them were artificial and they were just there because they had to be there, ie someone had to report to someone so we gave them that reporting line; others were true influencers, but if the team is first then you can’t have a set of managers telling them what they should be doing. Instead we’ve got a coaching layer at the top, whether it be a coaching layer for how they should behave in the Agile practice - ie how they should self organize, or whether it is coaching in skills, ie the practice leads who coach and mentor them through the technical practices they have to be effective in.

Lee: It wasn’t just a decoupling of the management and people responsibilities also, for me the performance bonus, linking that to the commercial development; Dan Pink’s work and all of that stuff has of driven my thinking of the past few years. I think that is an essential part of it to deliberately spread it apart.

Nick: That was a key anti-pattern, the annual performance bonus tied to the individuals’ performance. That was the anti-pattern that we have removed.

InfoQ: So what are some of the things, after removing things, what are some of the stuff you’ve been putting in?

Nick: The key one is in the name, is the practices, so these are a set of largely technically focused practices, but the key subtlety of those practices is twofold and one is that no individual belongs to a practice, every delivery team is influenced by every practice in different proportions. We are not saying you own a practice or you belong to a practice, we are saying your team is first, your delivery team is first, your practice is an external influence that you can both leverage and they will also influence you.

Lee: For example a developer might be aligned to the DevOps, Continuous Delivery and Development a practices because he needs all of those aspects to deliver a product for his team.

Nick: And rather than going to their manager for all of those concerns, and their manager going “Oh I am not an expert in those so you have to find someone else”, you go to the practice lead or the practice specialist that is going to help you. You’ve got a different path depending on what you are trying to achieve.

InfoQ: How do those practice leads then coordinate?

Nick: Yes that is a great question that is something that we as a group are working on right now because the alignment of that group is so critical to success, because they have overlapping initiatives where the initiative has to be supported by at least three or four of them at different times, in a broad practice it might be the complete set. They have to understand it’s happening and then they have to influence the teams so they can all play their parts. Something like Continuous Delivery is such a broad practice that you can’t really adopt it without everyone being on board. So they are a group that we spent a lot of time trying to align, to make sure, obviously self-organization being the theme, we encourage them to align themselves. And the CTO is there to help them align and of course give them the business context so that they can actually align in the direction that is needed.

InfoQ: One of the things that you showed that was quite interesting was inverting the hierarchy model and you had the CTO at the bottom.

Nick: Yes, we didn’t tell him that.

Lee: He hasn’t see that diagram.

Nick: But that’s exactly right and we are kind of saying that the delivery teams are what our business is trying to make as effective as possible. We are a product company, if our delivery teams are not delivering the product effectively, than that’s our business right? They are the core of our business so that’s the engine room and we are supporting them with the foundational group of practice leads, as opposed to saying practices, practices are only there to service the delivery teams, there is no other reason for them to exist.

InfoQ: The other role that you mentioned was something that you called an HR Advisor. What are they doing?

Nick: Yes that’s a good question, the role of the HR advisor is as a key facilitator, they deal with some of the administrivia of basic HR stuff, so they are accountable for counting leave balances and things like that. Then they go through to the much more coaching style and facilitative style of career development, so these are not people who are skilled in any particular practice, they are skilled in HR and people, they are obviously people who like working with people as opposed to some of our technical leads. The difference is, what they are trying to achieve is facilitate that person’s growth, so while that’s working with the Agile practice, whether that’s working with a much more hard skilled practice, they will come up with a plan, that the person has bought into as well as the practice leads. So they are making sure that conversation is happening. But we have to be careful there because we still say as any healthy company the individual is in charge of their career it’s not anyone’s job to make their career blossom, it’s their job.

Lee: They’ve helped greatly with the administration as well, the coordination of leave and the less attractive things for technical folks, but they also helped greatly with our business cases for training; as managers it’s always an arduous task to write a business case, these guys are exceptionally efficient at doing it and I think as a result we’ve actually spent more on training in this period because we’ve been getting more stuff approved. Because it’s just moving faster.

Nick: And to support that it is that they can focus on it. A technical lead in a delivery team does not want to focus on any of that stuff, they’ll always deprioritize that over delivering our product outcome.

InfoQ: The other thing that you spoke about was removing that annual review process, but you replaced it with bi-monthly peer feedback, do you want to tell us a bit more about that?

Nick: Definitely, so it’s a much lenear lightweight process so, as I said in the presentation, we are looking at two minutes per person, and we are asking somewhere between four and eight of an individual peers, will every two months get together and will answer a very, very simple set of questions around that person’s performance, and their team membership. These range from how the person is actually tracking, to how much collaboration and team work they are doing; it’s subjective, but subjective times eight, does give you actually quite a decent metric. You can use that metric, trends over time, you can actually see patterns in people’s behavior, whether they are trending up, trending down or they’re having a bad couple of months, all of those things will then be used by the HR advisor to spark the right conversations at the right time.

Lee: And there is enough time to actually make a difference until the next one, to see the trends.

InfoQ: Short rapid feedback, learning and adapting. How Agile.

Lee: It is so key is that it has been decoupled from any form of individual bonus. Your peers do not affect your bonus by saying you are great or by saying you need to improve.

InfoQ: Hopefully that removes the gameification.

Lee: Exactly.

InfoQ: Gentlemen thank you very much; it’s been really good and enjoy the rest of the conference.

Lee: We will now. Thanks.

Nick: Thank you Shane.

About the Interviewees

Nick Cahill is an independent software delivery consultant working with a variety of predominantly SaaS clients within Australia and New Zealand, focussing on delivery teams, practices and application architectures.

Rate this Article

Adoption
Style

BT