Dissonance on autonomy

I was speaking to a tech lead who was inspired by Dan Pink’s drive and motivation video. This person was speaking great lengths about how to motivate team members, how to set them goals etc and also went on to say that only if this person’s managers showed same consideration and handover more autonomy, then there are so many more things that can be done.

Below is the link for the nice presentation by Dan Pink, about his work on Drive

I asked a few questions to understand what kind of autonomy was working for this tech lead. The team size was around 8 with a mix of Developers, QA and BA. The team members were given a free hand on when to take a day off, go on vacation, flexible timings etc. The flexibility in working and taking a time off is not directly related to autonomy so I asked my favourite question next.

Given your team size is small, what is your version control process? The answer was that everyone works on their own branches, they will then raise a pull request to the tech lead, the tech lead will review the piece of work, some back and forth happens before it can be merged to the master. The tech lead controls the merge to master and it is a privilege to commit to master.

Where is the autonomy in this process? Code for developers is like a habitat, they should feel connected and own the place they are considering it as their habitat. By putting a very strong gated process that too in a small team is removing the autonomy away from the members. Will members be connected and own the code they are developing or is it just that they are following their tech lead says?

Then the question arises on ‘how to ensure quality’; in our teams we never gate someone’s commits as a merge request/pull request is not the only safety check we have in place. We have a huddle every morning and people demonstrate what they have coded & committed to main along with any observations they have on other’s code. This is repeated every day and this mob review works a lot better than a gating PR review because the learning as a group is much stronger and less hierarchical. This activity also enforces the collective ownership and every individual takes up the challenge of living upto the expectations. The only catch is, it has to be moderated well in the initial days before the new found inertia can take over and run without the chaperone.

I started following this style after reading the chapter “Habitability and Piecemeal Growth” in the book Patterns of software architecture by Richard Gabriel. Autonomy is not just about working from home, flexible timings or casual holidays, it is about the ability to own things at grass roots level.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s