Building a successful team -Discussion on Why, How and When

In my previous blog the point of being inclusive was emphasized. Now being part of the team is very important, however even more important is how you participate within team. If the participation is primarily from the point of giving direction and orders then we might not see the intended results.

Every team member give their best when they have the feeling of ownership. And that feeling of ownership only comes when there is clarity and information sharing. An ownership without underlying details is merely an assigned task. Don’t expect any innovative out of the box thinking in this case.

The best way to share the underlying details is to encourage the Why, How and When discussion. The idea is that any new idea, design, proposal has to have ‘Why’ information associated with it. The idea can come from any team member (Engineer, QA or Product Manager). There has to be a problem statement which this idea is intended to solve. Let additional team members provide their thoughts which might help in expanding the definition of Why.

Once there is an agreement on Why, the next steps is to brainstorm on How. There is a tendency among engineers to immediately provide solution to a problem. My recommendation would be to take sometime to digest the information on Why before coming out with solution. A break in between Why and How discussion is highly recommended. The idea is to come up with a high level technical design to the solve the problem. This detail helps in determining the high level effort (Story Points).

By this time we have the Why and How part reasonably covered. The high level effort helps in prioritizing the work by following the priority matrix.



One of the key attribute of having successful open discussion around Why, How and When is trust between Product Management and Engineering. We will see great result when these two groups open up their mind to understand each other’s view to take a decision which is right for the Product.


Building a successful team – Be Inclusive

Building software which solves business problems is a great experience. Having a team who takes pride in delivering these results is key to success. The question is how to make it happen.

Developing software is an Art. I have seen great results specially when you have very senior team members in your team when you give them some problem, explain the business value associated with it, do some level of technical design discussion with him and then allow them to come back to you with their proposal.

The above is only possible when there is a trust and respect for each other. To build this trust and respect  it is very important to keep up with with our technical knowledge and discuss with your team member at that level to acknowledge and appreciate the challenges of the software design.

As a manager having a technical background also helps you to ensure that even though you are allowing your team members to think freely on the problem statement but at the same time they are not taking their own sweet time to come back. If that happens then you certainly need to check on that. Personally I have not experienced this.

Team members take great pride in solving technical problems and they will feel more happy when they see that their manager understands the problem they have solved and the complexity behind it and acknowledge their effort.

When you work at this level with your team, you will find yourself more closer to your team. Team will find you more approachable with a mindset that they can discuss technical challenges with you. And this transparent communication allows you to constantly coach your team members with real life problem statements and guide them along on the path of success.

Use Feature Toggle – Not Feature Branch

Feature toggle is a great approach for releasing features which are big in nature and takes longer time to develop, test and release. It also gives flexibility to release the feature in a gradual manner and helps reducing the risk.

Incorporating feature toggle approach is simple. In the application infrastructure have a simple repository of feature list with their toggle status Enabled / Disabled. Any new feature we start to develop, we add the record to this repository with status Disabled. Now from the day one we ensure that the feature function impact on product at every touch point considers the global setting and simply branches out without any impact if it is Disabled.

This approach helps in many way. First the whole development if happening on the same branch which eliminates the headache and fear of big bang code merging during end of feature development cycle. Second, the in progress feature codebase is continuously being tested during daily automation to ensure it is not breaking existing functionality.

Once the feature development is completed and tested the feature repository flag for this feature can be Enabled for release. Now we also recommend having a second level control of this flag at much granular level (depending upon the business need) which allows to rollout this feature in a much control way to get early feedback before rolling out to all the customers / users.

E.g. in our business it makes sense to have this second level control at customer level where we selectively expose the feature to few customers to get their feedback.

In Google the same approach is used to first release features to their own employees / users for early feedback before rolling out to wider use base.

I would recommend this approach anytime over creating feature branch.