Forming Self-Organizing teams

Most of us work in an organization where we deliver software in an “agile” manner - let’s just have that understanding with a pinch of salt. There are many benefits of being agile. The one thing that has stood out to me is the idea of self-organizing teams that was hugely popularized by Agile development. However, I see very little to almost nothing of this practice being followed today.

Most organizations that I know follow the Scrum based model, but keeping that aside the whole point of Agile (be it Scrub, Kanban or Pomodoro) teams is the lack of hierarchy within the team. Rather then relying on top-down direction, Agile teams are meant to be self-organizing, collaborating and communicating to deliver work and decide what to focus on next.

Now you see my context to “Agile”.

I see most agile team collaborating and communicating, but the self-organizing aspect it seems to be missing. Mainly because a self-organizing team needs the autonomy to decide as a group how they will work together, take ownership or processes, decisions along the way and ultimately get the work done.

Agile teams are cross-functional - which means members of the team have the necessary skills to create value for each delivery as well as have the ability to decide who does what, when and how.

So why not provide the autonomy to self organize?

Role of Product Managers in a self-organizing team

An important aspect of a product manager is to build a team over the course of building a product. Now, if you are lucky enough to build a self-organizing team, keeping in mind the extensive freedom and autonomy this team is exposed; you as a Product Manager have to provide direction which ultimately makes your team successful.

As a product manager, you start with putting your team together - typically engineering, QA, designers, etc.

Once you have the team settled, clarify your product goals - typically your Vision and Mission statements. Along with this, if there are any constraints, this is a good time to communicate this (set the boundaries).

Since your are agile, you have a team that is efficiently and effectively communicating and collaborating.

And now, your sole job is to remove any obstacles, barriers, etc that comes due to the lack of autonomy to make your product succeed - You are there for the team, helping them self organize effectively while stepping back to give the team members room to problem solve and make decisions themselves.

I love this quote from Ken Norton at Google Ventures:

Too often PMs try to impress their engineers with their technical acumen, but in my experience engineers are much more impressed with PMs who are willing to ask questions and say ‘I don’t understand that.

It the chaos of managing your product and its roadmap, we tend to forget that our growth as a product leader is important. You have to grow along with the team and most important, you have to learn to let go. This is key to your growth.

Steve Sinofsky on building teams:

The most interesting thing about being a product manager and scaling over time is you. You have to figure out a way to scale yourself.

Every self-organizing team I have worked on, started with myself and a handful of team members. Based on the success, these teams will tend to grow and you will have several self-organizing teams to work with. So learning the art to let go and delegate is key. Give your team they autonomy they need and control the chaos.