Three years ago, Kaltura expanded its portfolio by acquiring a company specializing in online classes and webinars—a product already serving hundreds of thousands of users daily. As is often the case when startups transition into enterprise environments, we faced the challenge of scaling the product while aligning it with Kaltura's standards.

At the time, I was serving as the frontend architect for our group. My boss approached me with an intriguing proposition: to temporarily step away from my architectural duties and spearhead the frontend development of this newly acquired product.

Now, having achieved the goals we set out to accomplish, I'm transitioning back to my original role. Along the way, I've collected insights and guidelines that I thought worth sharing.

In this article, I've broken down my mind map on team leadership into a structured format, covering Team Dynamics, Communication Strategies, and Time Management. In the second article I dive into Product Interactions, Backend & QA Collaboration, and Managerial Relationships.

Team Dynamics

Team Autonomy and Leadership

• Feature Leaders and Ownership in Team Dynamics: emphasize the role of 'Feature Leaders.' Assign each feature to a specific team member who will take the lead. This designated leader becomes your go-to person for any stakeholder inquiries and is responsible for the entire process, from grooming the ticket to securing QA approval. Adopting this strategy can be beneficial for everyone: the feature leader gains valuable experience and responsibilities, while it also helps distribute the workload more evenly, reducing pressure on you as the team leader.
• Keep the Team Informed and Prepared: Ensure that each team member is aware of their prioritized tasks and next steps. Maintain an individual backlog for each developer to serve as a backup plan. This allows team members to continue working autonomously and make context switches as needed, without being overly dependent on the team leader for direction.
• Minimize Distractions, Maximize Autonomy: Empower developers to work directly with peers from other teams, product, or design. Regular touchpoints keep everyone aligned, but the goal is to allow team members the freedom to resolve issues and make decisions without constant interruptions.
• Distribute Work Evenly: Strive to balance the workload among team members by ensuring that everyone has a mix of tasks—ranging from feature development and bug fixes to support chores. This approach not only helps prevent burnout but also allows each team member to contribute to various aspects of the project. That being said, aim to assign specific features to individual team members for ownership, so they can feel a direct impact on the product.
• Enable Autonomy, Stay Informed: Empower your team to take initiative, while keeping yourself updated and ready to step in when guidance is needed.

Conversational Dynamics

• Daily Touchpoints: Engage with the team daily, even if briefly, to maintain a pulse on progress and morale.
• Team Over Individual: Frame discussions around collective successes rather than individual contributions.

Collaborative Culture

• Encourage Cross-Functional Recognition: Advocate for team members to be acknowledged by peers from other roles such as QA, product, designers, and developers from other teams.
• Support Professional Growth: Recognize and support the team's aspirations for career development. It's important to note that growth isn't solely about ascending the management ladder; it can also mean expanding development capabilities, taking on more complex tasks, or assuming additional responsibilities within the team.
• Promote Iterative Collaboration: Encourage developers to engage frequently with product and design teams. Hidden requirements often surface during development or testing phases. Releasing features in small, quick milestones is more effective than delivering a fully completed feature at the end of a timeframe.
  • Note: This approach may require adjustments to the QA environment to facilitate testing of multiple pre-released features, a topic beyond the scope of this article.
• Foster a Culture of 'Good Enough': Promote a mindset that values meaningful progress over unattainable perfection. More on this in Part 2 of the series.

From the Team Experience: How We Manage Individual Backlogs with Notion and Jira

In our team, we've adopted Notion as an unofficial tool for managing individual backlogs. We chose Notion for its robust capabilities to structure data effortlessly, allowing us to focus more on the tasks at hand. Each developer has a set of tasks listed in Notion, which cross-references the official stories in Jira. This dual-system approach enables us to maintain agility in our internal processes while ensuring seamless communication with other teams.

Adopting this approach has yielded another significant benefit: a unified platform for collaborative note-taking and feature planning. In Notion, each item exists as a distinct page within a hierarchical tree structure. This setup provides us with a centralized, shareable space for drafting designs, setting milestones, listing actionable items, commenting, and compiling questions. Without such a system, notes often remain siloed in individual notebooks, which can easily be misplaced, hindering the collaborative process.

Communication Strategies

Synchronous Communication

• Opt for Chats Over Meetings for Syncing: While meetings are great for initiating feature development or brainstorming designs, they can be time-consuming for daily updates. For ongoing work, it's more efficient to establish a dedicated chat channel for each feature. Include all key stakeholders—developers, product managers, delivery teams, and QA—in these chats. This approach not only boosts productivity but also saves the team a significant amount of time compared to holding daily sync meetings for every active feature.
• Feature-Specific Chats: Just as you modularize code by context, create a chat for each feature. The chat's lifespan should align with the feature's development cycle.
• Feature Leader Ownership: While you may be in the chat, your role is to mediate and provide guidance. Engage when necessary, but otherwise, let the feature leader own the conversation.
• Ad-Hoc Chats for Quick Resolutions: When issues arise that require immediate attention, create ad-hoc chats to resolve them swiftly and keep the feature chat noise-free.

Meeting Protocols

• Efficient Scheduling:
  • Keep meetings short and always share an agenda in advance.
  • End meetings on time and summarize with a list of actionable items.
  • Invite only essential participants to minimize time wastage, especially for your team.
• Team Representation: You don't need to attend every meeting. Empower team members to represent the team in specific contexts, like STP meetings or feature sync-ups.
• Meeting Attendance: Feel free to decline meetings or request agendas if you think your presence isn't necessary.

Written Communication

• Address Defensive Messaging Promptly: If chat messages seem to carry a defensive or aggressive tone, initiate a call to resolve misunderstandings directly.

Product Requirements Tickets

• Tickets as the Single Source of Truth: Ensure that tickets are well-groomed and clear to all stakeholders before development begins.
  • Developer Ownership: Once approved, tickets are owned by the developer, subject to your and the product manager's oversight.
  • Idle Tickets: Any team tickets not assigned to a sprint should default back to you.
  • Flexibility Levels: Make sure the team knows how much leeway they have with requirements, so they can make informed decisions or raise concerns as needed.
  • Adapting to Change: Requirements may evolve; developers should be prepared to adapt, but they should also feel free to engage you if they're uncomfortable with the changes.

From the Team Experience: Why Feature-Specific Chats Beat Daily Syncs

In the fast-paced world of frontend development, striking the right balance between effective communication and avoiding meeting fatigue is crucial. In our team, we've cracked the code with "🧩 - feature-specific" chats. We use Microsoft Teams for internal communication, and it's incredibly easy to spin up new chat groups. Each chat kicks off with a smiley, chosen by the feature leader, which adds a fun and personal touch while making the chats easy to locate. Ownership of these chats lies with the feature leader, and I step in only when necessary.

Time Management

Sprint Planning Meeting

• Prioritize Quarterly Commitments: These aren't just your own commitments; they're your team's as well.
• Delegate the Promotion of Support Tickets and Bugs: It's neither realistic nor necessary to address all support tickets and bugs immediately. Some may be rejected, while others may require further input from product teams or may not align with the quarter's commitments. Product, delivery, and QA teams are often the experts in these areas. They're best positioned to identify and flag urgent issues, so let them take the lead.
• Tip: If the sprint seems to be bug-heavy, ensure it doesn't jeopardize your quarterly goals and communicate any concerns.

Team Dailies

While I have a lot to say about dailies, I'll stick to the highlights here:

• Engage the Team: Consider kicking off with small talk or a quick interactive activity, like a Miro board. I was skeptical at first, but it's become second nature and has actually made our meetings more enjoyable and less of a chore.
• Punctuality Matters: Always start on time.
• Keep It Brief: Our dailies are scheduled for 30 minutes but usually wrap up in just 6-10. Keep in mind that time spent in meetings adds up, affecting everyone's productivity. Plus, team members often have multiple meetings each day, which can disrupt their focus on actual work.
• Be Concise: Keep the daily focused on reviewing ongoing developments, identifying bottlenecks, and clarifying any ambiguous requirements. Make sure there's room for team members to voice their concerns. Remember, this isn't the time to dwell on past efforts; it's about paving a smooth path for the day ahead.
• Take Irrelevant Discussions Offline: If a topic isn't relevant to everyone, politely pause the discussion and suggest taking it offline with the relevant parties.

From the Team Experience: Navigating 650+ Joint Dailies

In our team, we've put the principles outlined earlier into practice. Our daily stand-ups are quite inclusive, featuring a product manager, a delivery manager, five QA professionals, an occasional backend team representative, and our four-member frontend team, myself included. We have the unique advantage of "dogfooding" our own collaborative meeting product, which allows us to test new features during these dailies.

Given the diverse attendance, we aim to wrap up the core discussion quickly without sacrificing small talk. We employ a "funnel approach," where attendees gradually exit the meeting as we narrow down to topics relevant to smaller subsets of the group. Ultimately, only the frontend team remains, and we use that time to focus on team-specific issues. The entire meeting can range from 6 to 20 minutes, and thanks to this structured, funnel-like approach, our dailies remain efficient and far from burdensome.

Product Showoff Meetings

These meetings usually kick off a new sprint and celebrate the achievements of the previous quarter.

• Let the Team Shine: Encourage team members to present the features they've been working on.

Quarterly Planning

This can vary from team to team, but here are some insights tailored to highly communicative and proficient teams like mine:

• Allocate Time for Unknowns: Reserve some bandwidth for support tickets and requests from the server team.
• Limit Ambiguous Features: Aim to include no more than one or two features that require extensive R&D or lack clear requirements.
• Use the 'Stretch Goal' Tag Wisely: Only tag tasks you genuinely believe can be completed within the quarter.
• Identify and Communicate Risks: Make sure the product team is aware of challenging features so they can allocate resources more effectively.

In this first part, we've delved into the intricacies of team dynamics, communication strategies, and time management. These foundational elements set the stage for a high-performing frontend team. But the journey doesn't end here. In the next article, we'll explore how to navigate relationships with managerial staff, the product team, and peer development & QA teams. As you apply these insights, remember that the key to effective leadership is adaptability and a commitment to continuous improvement.

Thanks to Anna, Tornike and Stas for the joyful journey. Luckily it is not a good bye, as we will continue to work together on the product architecture.

Cover image crafted with Picsart.