Summarized using AI

Scaling Happy Engineering Teams

Zaid Zawaideh • November 08, 2021 • Denver, CO • Talk

The video titled "Scaling Happy Engineering Teams" features Zaid Zawaideh at RubyConf 2021, where he discusses strategies for growing engineering teams while maintaining a positive and productive work environment. Zawaideh leverages over a decade of experience in engineering leadership and emphasizes the importance of fostering happiness and impact within teams.

Key points discussed throughout the talk include:

- Principles of Engineering Happiness: Zawaideh emphasizes that engineers desire impactful work, timely feedback, supportive co-workers, opportunities for their voices to be heard, and access to the best tools for their tasks.
- Remote Work Dynamics: He suggests that remote work isn't fundamentally different from in-office work but requires conscious efforts to build trust and communication. Essential practices include writing down information and establishing intentional spaces for relationship building, as informal interactions differ in remote settings.
- Decision-Making Frameworks: As teams grow, it becomes harder to achieve consensus, leading to paralysis. Zawaideh advocates for empowering engineers to make decisions responsibly while establishing clear accountability and providing frameworks around code reviews and technical decisions.
- Designing Organizational Processes: Organizations should be treated as products. Zawaideh illustrates that undesirable outcomes can be addressed by redesigning processes and removing hidden problems. Making problems visible within the organization encourages collaborative solutions.
- Building Strong Teams: Zawaideh argues that small teams enhance communication and proficiency. He advocates for a culture of constructive disagreement to allow clarity in decision-making and goal commitment. He instructs on the importance of the team lifecycle stages: forming, norming, storming, performing, and mourning.
- Hiring and Onboarding Practices: Zawaideh shares that hiring processes should be transparent and respectful, and highlights the necessity of effective onboarding practices to help new hires integrate smoothly into the team.

In conclusion, Zawaideh stresses that companies should prioritize adaptable processes aligned with clear goals over rigid methodologies. This flexibility, combined with a culture of trust and accountability, ultimately leads to happier engineers and successful organizational growth. He invites attendees to rethink organizations as systems needing continuous observation and improvements that can be driven by engineers’ insights and engagements.

Scaling Happy Engineering Teams
Zaid Zawaideh • November 08, 2021 • Denver, CO • Talk

Scaling engineering organizations doesn't have to mean chaos, stress or losing the ability to have impact. In this talk I'll explain the principles we are applying at Wrapbook for scaling our Engineering teams to provide a healthy, happy and productive environment for people to do their best work.

RubyConf 2021

00:00:10.400 My name is Zaid, and I'm here to talk to you about scaling happy engineering teams.
00:00:16.720 This talk will provide a set of guidelines and tools that you can apply in your team and organization to ensure that as you're growing, our engineering teams remain happy.
00:00:29.519 A bit about me: I'm an engineering leader with over a decade of experience in building strong teams.
00:00:35.760 I currently lead engineering at Wrapbook. Previously, I was an individual contributor and a manager at GitHub.
00:00:42.000 Before that, I founded my own company called Sunglass. It was actually at Sunglass that I learned Ruby and Ruby on Rails to build the product.
00:00:48.000 That experience served as my introduction to web development. I fell in love with Ruby back then, and I'm still in love with it.
00:00:58.719 My journey of learning involved jumping into the deep end, immersing myself in Ruby.
00:01:05.680 My passion for Ruby and its contributions to the ecosystem continues, and I hope to share some of my learnings from the past decade to help build and grow happy engineering teams.
00:01:20.720 Before preparing for this talk, I asked people around me what makes an engineer happy.
00:01:27.840 I received a variety of answers. While these responses may not represent what makes every engineer happy, I hope they capture the sentiments of many.
00:01:39.840 One key aspect I heard is having the space to do impactful work—things that improve the lives of our customers and elevate their experiences.
00:01:52.960 Having the necessary time and focus to flow into that work is crucial.
00:02:05.200 Another important factor is receiving timely feedback, as well as the ability to learn and grow during our tasks.
00:02:10.479 It's also vital to have great co-workers and mentors supporting us in that journey of learning.
00:02:21.680 We need an environment where our voices can be heard—where we can express our opinions and feel genuinely listened to.
00:02:31.920 Lastly, being able to utilize the best tools available for our work significantly contributes to our success.
00:02:41.599 Now, regarding remote work, I find it not fundamentally different from working in an office.
00:02:47.760 The main difference is that remote work necessitates making the implicit explicit.
00:02:59.200 We must consciously foster trust and ensure that we communicate the right information with the right people at the right times.
00:03:06.319 We should not rely on informal channels to guarantee that information circulates within the organization.
00:03:11.920 It's important to create space for building relationships in a remote environment. Without physical spaces like water coolers or coffee machines, spontaneous interactions become rare.
00:03:28.080 Thus, we need to cultivate intentional spaces for connections.
00:03:38.640 Another note about remote work is to document decisions and communicate them through multiple channels to accommodate differing personalities and communication styles.
00:03:58.879 There are entire books dedicated to remote work, but that's the essence of what I think.
00:04:09.120 I want to highlight some general principles I like to follow when solving problems, which also apply to creating happy organizations.
00:04:14.720 When making a change, start small and ensure there is a built-in feedback loop to iterate and improve, whether things are proceeding as planned or not.
00:04:35.520 By starting small, sometimes you may do things that don't scale to learn.
00:04:42.560 Prioritize qualitative one-on-one conversations before optimizing, automating, and delegating, and remember that premature optimization can hinder an organization.
00:05:08.000 One fundamental principle I adhere to is that trust must come first. It forms the foundation for everything we do.
00:05:20.080 We need to build trust in all our actions.
00:05:25.600 To implement meaningful change in your organization, it’s crucial to make decisions collectively as a team.
00:05:39.840 I'll begin by discussing how to make those decisions.
00:05:46.240 In small teams of two or three, decision-making by consensus is straightforward; a few conversations can lead to quick resolutions.
00:06:04.639 However, as teams grow, reaching consensus becomes increasingly difficult and can cause progress to stall.
00:06:16.960 Instead of progressing toward goals, we often find ourselves stuck in endless meetings trying to achieve consensus, resulting in feelings of paralysis and demoralization.
00:06:29.199 We should empower team members to make decisions independently, with the expectation that they will be accountable for those choices.
00:06:41.759 This involves knowing who to consult and who should be informed about each decision.
00:07:07.039 It's perfectly fine for disagreements to occur; we must know when to disagree and commit. To facilitate this process, it's a good practice to provide guidelines for code reviews.
00:07:21.199 Establish conventions for the organization, determining where flexibility exists and where specifics are set. We can have endless debates about tabs versus spaces, but we can save effort by adopting a single convention and adhering to it.
00:07:51.120 We should also articulate how technical decisions are made, including whether a technical design document is needed, what it should contain, and how meetings around it should be structured.
00:08:37.680 Having clear processes helps newcomers and seasoned staff alike navigate technical reviews and code evaluations smoothly.
00:08:50.000 Remember that it's crucial never to penalize mistakes unless they stem from repeated carelessness; instead, use them as learning opportunities.
00:09:03.120 Identifying the root cause of mistakes and exploring ways to avoid them in the future is essential.
00:09:16.720 Moreover, use strong disagreements as coaching opportunities. Ensure all perspectives are heard and document the trade-offs involved in decisions.
00:09:38.000 There's no perfect decision in a vacuum; context matters greatly.
00:09:44.720 Understand the context behind decisions, consider the trade-offs, and if a consensus cannot be reached, make a choice, recommit, and move forward.
00:10:06.399 An important point to emphasize: Don’t give one individual veto power over the team. Even if they’re often right, this can stifle the learning process around decision-making.
00:10:21.279 A culture of fear can emerge, discouraging team members from voicing their opinions and undermining the team's ability to scale.
00:10:27.600 This prevents team members from feeling a sense of ownership and pride in their decisions.
00:10:49.600 Now that we know how to make decisions, let’s explore redesigning our engineering organization.
00:10:54.640 I like to think of organizations as products that need design. The way you interface with an organization is through its processes, policies, and the tools that are in place.
00:11:06.480 These elements act as the user interface to the organization, and just like with software, we have the power to design its interactions. If negative behaviors or outcomes repeatedly arise, you can design them away by adjusting processes or triggers.
00:11:25.920 For example, if code review takes an excessively long time due to poor accountability, establish clear expectations for turnaround times.
00:11:38.240 Designate individuals responsible for driving pull request reviews forward, rather than tagging everyone, which leads to bystander effects.
00:11:49.760 Once these changes are made, monitor outcomes to see if PR reviews improve and adapt as necessary.
00:12:03.200 Another critical aspect of organizational design is ensuring problems are not hidden. Engineers tend to solve issues around them, but this can lead to unrecognized dependencies.
00:12:31.200 Beware of scenarios where one individual monopolizes knowledge. When problems are invisible, the organization cannot address the root causes.
00:12:43.920 For instance, avoid trying to review all pull requests without addressing the fundamental problem. Make issues visible to your organization to foster a culture of transparency.
00:12:56.080 Next, let’s consider how to design the software delivery process.
00:13:13.280 Often, companies operate within an agile framework, but there is no one-size-fits-all solution; the right process depends on the unique challenges you're facing.
00:13:30.159 Select processes that match the level of confidence you have in the work being done. For instance, straightforward tasks like updating webpage copy can be estimated confidently.
00:13:43.439 However, complex tasks like creating a self-driving car algorithm involve much uncertainty, making rigid processes excessively restrictive.
00:13:58.880 I advocate for maintaining lightweight, flexible processes that can adapt to new information.
00:14:15.360 Remember that aligning on shared goals is far more important than striving for a perfect process.
00:14:29.120 If your team is not aligned on goals, even a perfectly executed process can lead to achieving wrong objectives.
00:14:35.920 In formulating processes, consider parameters such as cadence and how to scope set priorities and remove friction points from the workflow.
00:14:58.480 At Wrapbook, we found weekly cadence suits our SaaS application well. We conduct weekly meetings for goal-setting and scoping work.
00:15:07.840 In addition, we utilize weekly retrospectives and one-on-ones to ensure a feedback loop for continual improvement.
00:15:19.680 We also implement daily asynchronous touchpoints via Slack to maintain alignment.
00:15:28.679 Aspects to consider include the unit of work, obtaining feedback and how often you deploy changes—these decisions profoundly impact your process.
00:15:46.400 At Wrapbook, we define a pull request as a unit of work that typically spans no more than three days. This makes reviews manageable and feedback easier to obtain.
00:16:07.760 With a comprehensive CI test suite, each pull request receives quality testing and is subject to peer review by two engineers.
00:16:15.200 We deploy multiple times per day and utilize feature flags for changes that shouldn’t be immediately visible to customers.
00:16:30.880 Strong teams are essential. A cohesive team often outperforms a group of individual superstars.
00:16:39.680 Key behaviors to cultivate within your team include a results-oriented focus.
00:16:51.840 Accountability for delivering results directly depends on the team’s commitment to those goals.
00:17:04.240 If team members do not feel committed to the goals, they are more likely to deflect blame onto others and become disengaged.
00:17:16.960 One reason for a lack of commitment can stem from not having open discussions about goals, leading to unvoiced disagreements.
00:17:29.200 Allowing for respectful but unfiltered conversations around differing ideas fosters healthy conflict.
00:17:42.000 Common concerns arise around creating silos when breaking down organizations into smaller teams.
00:17:56.560 Smaller teams reduce communication overhead and facilitate swifter alignment to goals.
00:18:09.440 To counteract the potential negative impact of silos, emphasize the concept of first teams—peers collaborating towards shared organizational goals.
00:18:34.160 In the visual representation on the slides, colored circles denote teams working cohesively towards company objectives.
00:18:55.040 If a customer problem emerges that isn't neatly confined within a single team, the focus should shift toward collaboration and cooperation.
00:19:12.160 In forming new teams, I recommend understanding that each team goes through various phases: forming, norming, storming, performing, and mourning.
00:19:30.560 Enabling these stages helps minimize disruption and maximizes efficiency and productivity in your organization.
00:19:51.120 At Wrapbook, we apply the concept of mitosis when splitting teams, allowing smooth transitions when teams grow too large.
00:20:00.800 Next, hire the right individuals for team growth. I believe in focusing on three distinct tracks for career development.
00:20:12.960 These tracks encompass individual contributors from junior to senior levels, technical leadership (like staff or principal engineers), and people leadership roles.
00:20:19.680 Clear structures foster understanding of expectations and transitions among team members.
00:20:34.720 To effectively hire, design an interview process aligned to the specific needs of your organization.
00:20:44.320 Eliminate biases in the hiring process and seek candidates that complement the team’s strengths.
00:20:58.560 Once hired, establish a repeatable onboarding process where new hires are paired with onboarding buddies to assist them.
00:21:11.680 Develop unfamiliarity with processes and structures through onboarding checklists.
00:21:24.640 In summary, regardless of your role, consider understanding your organization as a coherent system—a network of decisions and flows.
00:21:37.440 When you encounter problems, approach them like debugging.
00:21:44.480 Ensure visibility into organizational issues, a practice we call observability.
00:21:57.840 And consistently adhere to key principles: start small, establish feedback loops, iterate, and prioritize qualitative conversations before automating.
00:22:14.240 A bit about us at Wrapbook: we utilize Ruby on Rails as a monolith.
00:22:36.960 Our frontend and backend development uses Rails and Stimulus, keeping our tech stack simple to maximize impact.
00:22:46.240 Our five core values at Wrapbook include being compassionately direct with each other.
00:22:57.920 We celebrate individuality and diversity, enabling everyone to bring their authentic self to work.
00:23:06.560 We encourage a bias towards action, delighting customers with each interaction, and fostering accountability for one’s work.
00:23:30.320 We are careful about our hiring process, seeking empathetic, curious individuals who are excited to build modern software tools.
00:23:42.840 Currently, we are hiring for numerous roles, including managers, staff engineers, platform system engineers, and positions in marketing and sales.
00:23:50.560 We offer competitive benefits, and I encourage you to check our career website or reach out to me directly if you're interested in joining Wrapbook.
00:24:03.680 Thank you for your attention, and I look forward to answering any questions you may have.
Explore all talks recorded at RubyConf 2021
+95