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.