Liberating Responsibility

All of the thoughts below are based solely on my experience and are not universal, just something that works under current circumstances and from my point of view. It’s ok to disagree.

At Dodo Engineering I conduct some interviews from time to time. Once I met the candidate who was working as a team lead while applying for the software engineer position. So at the end we stumbled upon quite an interesting topic.

No managers

“So I’ve heard you guys have no managers”, he asked me. The time for the interview was overdue, but it was the end of the day, so we decided to talk a bit more.

“Umm, yes”, I said. “We kinda rely on teams being autonomous and keep the structure flat enough. Inside the teams we have an thing called Product Leadership Team (article in Russian). It has roles inside like Product Owner, People, Tech or Process Lead that help team in certain aspects. These roles can be assigned to different people in any ratio - it may be one person doing all four, or one role may be distributed between several team members - in any way certain team would prefer”.

“So basically you have managers, you just call them differently”, he smiled a bit. “These guys or one specific person is telling you what to do. I can’t speak for everyone, but in my experience it works only when someone have the guidance to tell the others what to do, otherwise it all falls apart”.

“Well, not exactly”, I defended, “in our case the team decides what to do and how to do it by themselves. The people in the roles I mentioned can help and guide you how to do it in case we face issues.”

“I don’t get it. Who takes the responsibility for the apps, when something’s happening with the services? ”, he remained on his own.

“The team. We have a thing called Component Owners which indicates which guys to contact in case some service is acting weird.” I thought a bit. “And well, yes, the team with the Product Owner is also responsible for doing things the way they forecasted. But we do not blame if something goes bad, just trying to retrospect it all over to avoid same mistakes in the future”.

He remained silent for a while, thinking it all over.

“So how does it work for you guys”?

It turned out I was answering this question in my head for a while afterwards — in the corner of the background mind. The ‘click’ feeling came to me at the middle of my shopping list in the grocery store. So figured it’s time to write it all down.

I’m happy and I own it

In general, — and that’s what I answered — it works great. And please trust me when I say this post is not sponsored :]

The important part of making it work is the company culture. But usually when someone tells someone else just that, the first response is “sounds like yet another corporate bullshit”. So let's dig in a bit.

When speaking of culture, Accelerate (the book that deserves all the glory it receives) mentions Westrum organization culture as a way to determine how organization spreads information. According to Westrum, organizations can be:

• Pathologic — based on dominance. The boss tells it employees what to do and how to do it, people are driven by fear, threats and power. Usually it relies on strict deadlines without well-defined integrations — ‘everyone on his own’.
• Bureaucratic — based on rules. It’s usually some hierarchy of set-up rules and strict processes that guide you to your team's specific goals. It creates a lot of really specialized teams and planned integrations between them, but they are rarely driven by some common goal, mostly interested in making it better for their part.
• Generative — based on result. The team needs to do something, and they are in charge of understanding how. They have full set of options for assistance, but no one’s going to make sure it works but them.

Please note if you found your organization in here! (image from ‘Accelerate’)

I consider Dodo Engineering culture to be generative. So let me try to answer why autonomy works for generative organizations.

What happens when you know the fate of the product is in your hands?

• Each and every one of your team members treat your services in a much more careful way. You start to think not in terms of nowaday tasks, but in terms of strategy: what will happen if a backing service X goes down and communication was lost? How should the system behave if business would like to follow opportunity Y? It turns out that you embed reliability and other non-functional requirements as part of what you do on everyday basis, because you cannot avoid it — your hands are full in it, you see the problems and edge cases from much different angles.
• This enables transparency on what you do. If you know the cost of error and you know there's no ultimate figure behind your back to doublecheck it all over, you want to make the results of your efforts clear enough so that other people can check it out and may give some advices.
• This generates trust. As you see, you need to have more stuff on your mind and it’s quite possible you can’t carry it all alone. So you need to act together with your team to auto-distribute the needs based on what you figure will be optimal.
• This enables alignment. Well, yes, Spotify Model claims it works otherwise - "alignment creates autonomy", but in this case it’s mutual — the more you act responsible, the more you need to know you’re not doing bullshit. So as a result you need to have some shared understanding of importance not only with your team members, but in terms of how the organization sees it. And the following questions if we're moving into the right direction enables discussion and collaboration.
• You treat your product much more carefully. You question the changes, see how they fit the big picture and what will happen if you do it differently. You do not longer see your Product Owner as a person that tells you what’s important, you start to have your own discussions and trade-offs, which is a key to the healthy product collaboration — you need to be on the one page with everything, otherwise the users may be disappointed. If you don’t own the services, there are more chances you get lost in code and miss the reason we’re all doing things and the alignment that has been mentioned before will disappear.
• Last but not least, it enables the diversity of views and ramps up the skills to constructively discuss all points of views together. The more people have their own background and understanding on how certain things should be carried on, the more chances you have to make it work altogether.
• Last but not least, it gives you the motivation to actually change how what you do affect people's lives, since it's actually you making the change. Netflix have something called informed captains to decentralize the decision-making, so sometimes you need to face a choice that will change everything - or you have the power to affect the choice of others.

So if this is so great, you may ask, why this has not become an industry standart yet?

Leadership at your service

It must be mentioned to changing the organization culture to result-oriented requires not only a leap of faith, but also the attitude that the people in the organization should share. So, in other words, one tiny thing should happen:

“Everyone should become leaders”

The things that sound simple might not be so straightforward after all. This means that people would need to change the way the do things and set their own system of priorities. If some person used to act as an advanced typewriter, or, as the internet likes to quote, ‘turn coffee into code’, this attitude may derail from the other questions one may need to ask — how my product is doing, what’s happening — and going to happen. This is no longer responsibility of some guy that’s gonna tell you what to do, it’s some inside motivation that should hopefully emerge.

And again, it pretty much relies on personalities. One would like to access services from reliability perspective and adapt SRE practices to team routine, the other will be more focused on the product future and user experience, the third would concentrate more on quality, or understanding law changes, or release optimization, or process enhancements, or system design, or hiring, or whatever else you understand the team needs. Of course, you could enable specific role or title for each and every one of them, but usually all those strong parts are mixed together between different people. The important part is the same — every person in the team needs to have the urge, the desire to change things and guide each other.

Usually this is the part that we assess on the final interview — if the candidate can show these skills or is ready for such changes. From my experience, it’s very important to be candid and tell the candidate that this the part of the expectations that comes with a job, so that one will acknowledge it and decide if one wants to pursue it.

So, apart from that, no trade-offs?

Or course not.

This bit of leadership transformation I mentioned above is what usually happens in the majority of the companies when the engineer becomes the team lead. So since these set of challenged as somewhat known and shared within the comminity, there are some guides on how to follow it — to prefer team value over personal one, to delegate, to facilitate, to mentor, to apply decision-making. Mastering these parts takes practice and time. And some of the problems I mentioned below are pretty typical for the new teamleads, while others are tightly interlinked.

And also, last but not least, it should be reminded that the engineering team still needs to deliver value. Imagine the engineers as lumberjacks. So of course they may need to learn how to grow trees, select the best axes and navigate by the sun, but they still need to chop some wood. So in between facilitation and system thinking we still need to ‘turn coffee into code’. And this is the right-balancing part where it gets more complicated.

So as you may notice, when this is happening faster on much larger scale there are some growth issues. Again, they might be considered pretty typical, but they are no joke on company level, and we at Dodo Engineering have the data from the pulse surveys to assure it.

Image from an artist https://vk.com/by_duran

• Distress and Burnout. As modern scientists claim, stress is something natural driven by desire to resist change. However, in always changing environment like this one the organism may not be able to adapt to the stress factors which can lead to burnout - you always feel you are in some buzzed state, you cannot rechange. Again, this bit is somewhat familiar in the software engineer's community and some may consider it a matter of fashion, but I think in general modern society bumped into the burnout in a pretty hard way recently and it’s good to acknowledge the problem at a large scale. So the advice is to do things based on what gives you joy, go on long vacations. There’s no point in working in sake of it if you can’t and it doesn’t give you joy. Talk about it, address it, determine it at the early stages, don't be afraid to tell someone that you feel that way.

• Cannot focus. This can be detected as a symptom of the distress as well, but I wanted to address the general feeling of overwhelming. When you have something else has just happened in the middle of your routine gives you a small piece of joy, so you want to drop everything you do and go there. So the feeling of being 'in the zone' is something very helpful in performing complex activities, like software engineering, and unability to focus onto them makes it very hard for you to perform them. The usual recommendation would be to forecast you efforts in advance, to use your calendar wisely, to be able to say 'no'. In our team we started a duty practice for the requests of external development teams or support, so that the other people have more time to spend on something without context switches.

  

  (I find it very amusing that the term 'context switchcing' originated from software engineering matches that good to what actual engineers feel in their everyday work)

• Anxiety. Lots of it! You cannot be sure you’re doing a good job — are your products good? Are you following product vision fine? Haven’t we forgotten something essential? Of couse there’s no universal recipe for this, but good metrics, team support, enough sleep time and therapy sessions can help.

• Hard to let it go. The more you assign on you, the harder it becomes to let something go, to not remain the best at it. The only thing I could recommend here is to figure out what you want to do, then rationalize your areas based on it - and trust the people around you to help you. If this activity won’t help, this may happen naturally over time.

• Responsibility bias. It's something similar to what cognitives sciences like to call bystander effect - if a person have some accident in the middle of the street, the more people you have around, the less chance the person will receive help - because everyone expects in from someone else. This is something that is very observable in big teams - some nasty bug in legacy system would likely receive less attention because everyone expect anyone else to step up. In this case, the smaller the team is and the more accountable their members are, then there are way less chances that this would be happening on a regular basis.

• "Not my job" attitude. This is an extremely complex topic that deserves a separate article. The more your company scales, the more complicated it becomes to understand how all parts of your service behaves. Usually there's some kind of platform team that shares the expertize in this, but depending on how it's implemented the service ownership not always fully remains on the team. The point of DevOps as a culture to remove this 'us and them' barrier is something the engineers would need to pay attention to, especially in modern cloud-based development. If the team is not aware on how your application works in production, regarding the way it's deployed, hosted and configured, the more the real ownership and responsibility is diffused. This may lead to the scenario when engineers are not responsible on the way their service operates, which kind of brings down all of the whole autonomy and responsibility ideas. But breaking this particular wheel requires some kind of cultural shift to happen, which may not come out naturally.

• Feature/Ownership duality. My favourite one! The longer you dwell on both technical excellence and product changes impacting business value, the harder it becomes to balance it out. Imagine you have two hats on you that you juggle on while deciding what better to do next sprint. I personally consider it normal and something worth adjusting for, but it may feel different from most of the approaches based on personalized role-based discussion. For example, American judicial system have representative for the People (prosecutor) against the defendant (defence attorney). Usually I either witnessed similar 'count hearings' or the huge leap into specific direction, but in the metaphor I presented the whole count including the jury rests on the team members.

• Finally, all of it takes time. You need much more alignment! You need to talk not only by your regular Scrum routine, but based on what you do, and you get eventully tired of it. I have a friend that shifted to leadership position recently, and he was saying to me 'I don't get it why I'm getting paid so much, I work like three hours a day'. And when I asked why he's late after work to meet up all the time, he answered: 'Well, I'm talking about my actual work, not meetings and stuff'.

  'Meetings and stuff' become part of what you do, you need to control its amount, make sure it doesn't blow your work time to the extremes, treat it as a part of you job responsbilities to **deliver value and see if the meetings are short, actionable and help you in your everyday work.** If they are not, it can become the problem.

So what about Product Leadership Team?

After all the obstacles shared, you may ask me, if it's that hard to make autonomous teams work, then what's the point? And here's the missing piece - we have the Product Leadership Team I mentioned at the top of the article. Their role is to ensure and guide the team in being productive. In a way, if the team is mature enough or trade-offs are something that does not apply to them, they may not need this team 'as is' or some of the roles*.

I tried to match what roles can assist in which areas:

• People lead
  • Distress, Anxiety, Burnout, Fear of letting go, Lack of time
• Process lead
  • Burnout, Lack of Focus, Responsibility Bias, Feature/Ownership duality, Lack of time, Lack of focus
• Product Owner
  • Responsibility Bias, Feature/Ownership duality, Lack of focus, Lack of time
• Tech Lead
  • Anxiety, Feature/Ownership duality, Fear of letting go, 'Not my job', Lack of focus

Usually roles are assigned to people with some experience who have been through all this stuff, so that the engineers would feel safer addressing there problems.

Also, different teams require different kind of help. These roles can perform all sorts of activities, including organizational, administrative, facilitative, coaching, visionary, servant leadership, expertize enabling, team forming and so many more. But note - I don't say in specifics what these roles should do. I merely wanted to show what they can do, including in scope of engineering obstacles from above.

And the fun part - as you may see, since the obstacles are tightly coupled, the needs of the leadership team are coupled as well, so they need to talk to each other and address the issues from different angles, to work as a team on another level.

• All I said is true, apart from the Product Owners who act as a main person responsible on how the product works. The things one can do varies, but the role stays on.

So tell me, was it worth it?

Another topic I have to mention. So yes, I tell you guys that it's all great or whatever, but how can I prove it?

The straightforward way would be to track the team velocity and the set of metrics from State of DevOps as lead time, change failure rate and so on. But in order to do that, we need to have some teams that work differently within one company and ideally in the same product. So you won't see any metrics comparison from me, because I don't have this data.

But I can try to identify the circumstances when it can work better than the traditional manager-based teams. Here's what I have in mind:

• Clear product vision. If you don't have a product that you work on and improve on, the whole idea falls apart.
• Your team is small. The more people you have, the harder it would be to communicate and take ownership without stepping on each other's toes. The chances are some sub-teams would emerge organically. Scrum recommends team size between 3 and 9, I'd lower it down to 6. Unless you're using things like LeSS, then still consider small feature teams as an outcome.
• Everything may change. If the nature of your activity is pretty monotonous and easily predictable, the desire to take and change ownership areas and responsibility may be smaller. Cynefin framework call it 'Simple' quadrant - if everything that your would need and do is determined with a very good prediction rates, the pros of extended autonomy won't that easily overwhelm the odds.
• Your team needs to delivery value frequently. If your stakeholders and C-level guys prefer to operate in large release cycles with vast stabilisation phases and predefined schedule, the value of autonomous teams is significantly reduced.
• Your services' health is critical for the stakeholders. Usually tradiditional managers do a lot of communication and planning and team-related activities, so the technical excellence still relies on the team. And the more your company is interested in the reliability and availability of your services, the more proactive assistance you may need.
• Your company culture supports autonomy. That's all great, but if it gets active resisistance from within, consider wisely on your ability to change the way the company operates. It's possible, but usually beraucratic and especially pathologic companies resist it, and takes great motivation and teammate support to change it - if it's worth it.

I cannot say we have a magic potion to overcome the trade-offs I mentioned and we still have some work to do while we grow. But I think we're moving at right direction and I did a fair job answering the original question.

We are currently hiring engineers to join our team - visit https://dodo.dev/ to learn more and see if what I'm telling is true.