How my intent to change my team actually changed myself
Context:
I had moved from a big startup to an early stage startup working in marketing-tech. One of the significant challenges in any startup is to ship things on time, if not early.
My new company had its fair share of unpredictability in the timeline in which a feature is shipped to the customer (internal as well as external). The new startup was a rapidly growing organisation. Regarding new features in the product, revenue as well as new team members. Like any growing cross-functional team without a strictly defined process, it had its fair share of challenges.
Engineering team were waiting for the final copy texts in the feature. Product team was waiting for engineers to do feasibility, but features were getting shipped without their knowledge. All teams were hiring and growing fast. Marketing team didn’t know how to use that feature.
Worldview of the team members:
The size of the company was 35. The team members are technically super skilled, humble and extremely motivated. For most of the team, it was the first startup experience, and they had worked in a different setup where there was no “process” or “scrum” or “agile” way of doing things. Their previous company was a very well established company with its way of working and structure. It was neither agile or scrum way of working, but products/features were shipped and customers were paying.
Their previous company was a successful bootstrapped company, which has its way of shipping and addressing the customers problems. The current company was a venture-backed startup, which has a completely different dynamic and intervention from the stakeholders.
What was the change:
Split teams into a smaller self-sufficient team (pods) to ship faster (Not more than 5 to 6 people in a team and it is called as 2-pizza-team by Jeff Bezos)
Have a daily 15-min-standup meeting among the pods to know what they did yesterday, what they are planning to do today, are they any roadblocks for the team member.
Have a 2-week sprint for shipping feature and fixing bugs instead of intermittent/sporadic shipping
Who is it for:
Individual team members who are coding, designing and writing the features.
Senior team members who are leading and managing the teams.
What is this for:
To ship things to customers in a faster and predictable manner
To ship things in a better way by having all the team members (product, engineering, marketing) on the same page
To achieve the rapid growth that any startup eyes for as the company had enough stakeholders waiting for its growth.
Where there is a fit:
A smaller, nimble team with a clear goal for what to ship in the next two weeks is always a better approach. It gives more clarity for the team members on what is expected out of them, instead of firefighting and solving the issues in an ad-hoc manner.
Having a clear deliverable and a roadmap is extremely comfortable for all the other teams like marketing, sales too. They can plan the campaigns and promise the customers accordingly.
Where there is a mismatch:
All the things planned are perfectly right, but when the rubber-hits-the-road moment of implementation, there was a problem. People are not willing to change and adopt new habits.
Suddenly they feel there are too much of meetings (standup meeting, planning meeting, review meeting). The team is a close-knit team that dines and parties together. Things were getting shipped on time when the close-knit team was of size 5 or 6. But once the team started growing, the team was still reluctant to change.
Suddenly someone from outside, who is not part of the close-knit group joins the company. Says something like a 2-pizza team, scrum and blah blah. What if he is wrong? What if he is trying to constrain themselves with this “process” from a big company. We have been working this way for years in the previous company making millions in revenue, why suddenly this change.
My lessons and learnings:
Importance of semiotics: The title “manager” is a symbol of some authority. The concept of adult supervision has its bad rap (thanks to John Sculley and Steve Jobs). As a “manager” trying to impose something from top-down works out rarely.
Importance of pattern matching: If there is a pattern of work that is completely strange to my style of working, I will be sceptical about it. As a manager, I need to make sure that I provide an option that matches their current mindset of work but solve the bigger problem. If I try to impose, I will be just burning my finger.
Importance of framing: Instead of framing it as 2-pizzas-team and “Scrum”, I should tone down and make the “phrases” much more accessible. Assuming that the vocabulary of scrum and agile is known to everyone is wrong.
