Scaling Your Engineering Team for Growth: Insights from DroneDeploy’s Head of Engineering

Amir Bormand · Mar 17, 2025

Engineering teams are built to solve problems, but as they grow, so do the challenges. What worked with a small team won’t always scale, and without the right structure, processes can slow down, communication gaps form, and velocity takes a hit.

In a recent conversation, Jeremy Eastwood, Head of Engineering at DroneDeploy, shared real-world insights on scaling engineering teams without losing efficiency. From structuring teams for autonomy to balancing velocity with process, Jeremy broke down what works, what doesn’t, and how leaders can adapt as their teams expand.

He also touched on how managers handle process changes, why flexibility matters, and the importance of leadership trust. If you’re growing an engineering team, these lessons will help you scale without unnecessary bottlenecks.

Let’s dive into Jeremy’s strategies for structuring teams, maintaining high velocity, and making process changes that actually work.

How DroneDeploy Structures Its Engineering Teams

Why Clear Team Structure Matters in Scaling

Scaling a fast-moving engineering team requires clear ownership and well-defined roles. Without structure, growing teams can experience communication breakdowns, slower decision-making, and misaligned priorities. DroneDeploy’s approach ensures autonomy, efficiency, and alignment with business goals.

The 6 Engineering Teams and Their Focus

To support its expanding product and customer needs, DroneDeploy organizes its engineers into six specialized teams:

—DevOps Team – Manages infrastructure and ensures platform reliability.

—Mobile Product Team – Develops the mobile experience for on-site users.

—Computer Vision Team – Builds AI-driven mapping technology and image analysis.

—Construction Team – Focuses on solutions for large-scale construction projects.

—Energy & Emerging Industries Team – Works on applications for solar, roofing, and energy sectors.

—Growth Team – Enhances user adoption and improves product engagement.

Each team operates with autonomy while staying aligned with the company’s long-term strategy.

How This Structure Reduces Bottlenecks

—Minimized Cross-Team Dependencies – Each team owns a specific product or function, preventing bottlenecks caused by overlapping responsibilities.

—Faster Decision-Making – With clear team ownership, engineers can act quickly without waiting for approvals across multiple groups.

—Alignment Without Overhead – While teams work independently, they share a common sprint cadence to stay in sync.

By structuring teams this way, DroneDeploy keeps engineering velocity high while ensuring smooth collaboration across departments.

Measuring and Maintaining Engineering Team Velocity

How DroneDeploy Defines Velocity

Velocity isn’t just about speed—it’s about delivering what was promised. At DroneDeploy, success is measured by how much of the committed quarterly roadmap gets shipped on time.

Jeremy emphasized that velocity isn’t about tracking every team’s sprint metrics in isolation—it’s about ensuring that the product moves forward reliably. Instead of micromanaging the day-to-day velocity of each engineering team, leadership focuses on high-level progress and overall product stability.

“Are we actually shipping what we committed to? That’s what matters,” Jeremy explained. The goal is to balance speed with long-term reliability, ensuring the team isn't just working fast, but working effectively.

Tracking Progress and Course-Correcting

To maintain steady progress without burning out teams, DroneDeploy uses:

—Sprint Check-ins: Leadership regularly assesses whether teams are on track to meet quarterly goals.

—Adjusting Priorities: If a project is taking 20% longer than expected, other initiatives may be adjusted to prevent overload.

—Empowering Engineering Managers: Each team tracks its own velocity using the most relevant metrics—without enforcing a rigid, one-size-fits-all system.

Jeremy pointed out that the best leaders know when to course-correct and when to let teams find their own rhythm. Instead of forcing teams to stick to strict deadlines at all costs, they adjust expectations based on real progress.

Why Alignment Matters More Than Uniformity

Not every team measures velocity the same way—and that’s intentional.

While some teams track standard scrum metrics like story points, others focus on broader business outcomes. The key isn’t forcing a one-size-fits-all measurement system—it’s ensuring that all teams are delivering on their commitments.

To maintain alignment without unnecessary overhead, DroneDeploy follows these principles:

—Quarterly reviews track company-wide objectives rather than just sprint-level metrics.

—Teams have flexibility in how they measure progress but must stay accountable for what they deliver.

Jeremy explained it simply:

“The goal isn’t to make sure every team reports the same numbers—it’s to make sure we’re all delivering on what we set out to do.”

By focusing on outcomes over rigid processes, DroneDeploy ensures teams stay efficient, adaptable, and motivated—all while delivering real value.

Avoiding Over-Engineering: Balancing Process and Speed

How to Balance Structure and Speed Without Slowing Down

As engineering teams grow, adding structure is necessary—but too much process can slow things down instead of improving efficiency. The challenge is finding the right balance between structure and speed without creating unnecessary bottlenecks.

Jeremy emphasized that process should act as a guardrail, not a roadblock. At DroneDeploy, some level of standardization—like sprint schedules—keeps teams aligned. But at the same time, teams have the flexibility to adjust their workflows to fit their needs.

The key question is always: Does this process help us move faster, or does it just create extra overhead?

For example, if a new manager suggests changing sprint lengths or introducing additional meetings, leadership first evaluates whether the change adds real value. Jeremy shared:

“If one team suddenly wants to switch to three-week sprints instead of two, we ask: Does this actually improve efficiency, or is it just process for the sake of process?”

Encouraging Experimentation Without Creating Chaos

DroneDeploy encourages experimentation, but not at the cost of efficiency. Rather than allowing unrestricted changes, the company sets clear guardrails:

—Test new processes before scaling them – Teams experiment at a small scale first before a broader rollout.

—Measure actual impact – Before introducing a change, leaders ask: Will this make us more efficient, or is it unnecessary overhead?

—Adopt successful changes organically – Instead of forcing new processes across all teams, DroneDeploy lets teams learn from each other and adopt what works.

Example: Reliability Engineer Experiment
One team assigned an engineer to focus purely on reliability for an entire sprint. This cut distractions for feature developers while improving bug resolution speeds. Once proven successful, other teams adopted the model at their own pace.

Jeremy’s key takeaway: “Not every experiment needs to become a permanent process. If it works, it sticks. If not, we move on.”

Encouraging Ownership and Decision-Making in Engineering Teams

Creating a Culture of Experimentation with Guardrails

How do you encourage innovation without creating instability?

Jeremy believes in giving teams the freedom to experiment—without letting things spiral into chaos. The key is simple:

—Teams can test new processes, but they need a clear way to measure effectiveness.

—Managers aren’t just allowed—they’re encouraged—to introduce changes if they can show measurable improvements.

—Experiments should have clear goals, so teams know if they’re making progress or just adding unnecessary complexity.

Jeremy’s Take:

"Process changes should serve the team, not the other way around. If it makes us more efficient, great. If it’s just extra work, we scrap it."

How DroneDeploy Tests New Process Changes

At DroneDeploy, managers don’t just roll out changes randomly—they present new ideas, test them in real-world conditions, and track their impact.

Before any process shift, they ask one key question, “How will we measure whether this actually improves productivity?”

One success story came from a reliability-focused engineer experiment:

—Instead of splitting reliability tasks across the team, one engineer took ownership for an entire sprint.

—This reduced distractions for feature development while also improving bug response times.

—After proving successful, other teams started adopting the model.

Jeremy emphasized that not every experiment needs to be a permanent change. If it works, it sticks. If not, teams move on.

Organic Adoption vs. Mandated Changes

DroneDeploy doesn’t believe in forcing process changes from the top down—they prefer a peer-driven approach.

—When one team finds a better way to work, others see the results and adopt it naturally.

—Instead of “Everyone must do this now,” it’s “This really helped us—give it a shot if it fits your team.”

—However, certain processes (like security checklists) are mandatory to maintain quality and compliance.

“People don’t like being told to change,” Jeremy noted. “But when they see a better way working, they want to try it for themselves.”

By encouraging ownership over decision-making, DroneDeploy creates a culture where teams don’t just follow rules—they actively improve how they work.

What Onboarding Strategies Can Help Scale Your Engineering Team for Growth?

Effective onboarding engineers in startups involves immersive training programs that foster collaboration and knowledge sharing. Implementing mentorship systems can accelerate integration, while utilizing project-based learning helps new hires engage with real challenges. This approach not only equips engineers with necessary skills but also enhances team cohesion, essential for scalable growth.

Leadership, Trust, and Scaling an Engineering Organization

The Role of Engineering Leadership in Scaling Teams

Leading a fast-growing engineering team isn’t about controlling every detail—it’s about knowing when to step back.

Jeremy explained that one of the hardest parts of leadership is resisting the urge to micromanage.

—As teams expand, it’s tempting to stay deeply involved in every decision.

—But real scalability comes from trusting managers to lead effectively without constant oversight.

—The challenge? Maintaining visibility without getting in the way.

Jeremy shared, “The goal isn’t to make every decision—it’s to make sure the right decisions are being made.”

When to Step In vs. When to Let Teams Learn

Jeremy’s Leadership Approach to Scaling Teams

—Let managers take ownership—give them space to lead without constant oversight.

—Step in only when necessary—correct course only if there’s a risk to the team or company goals.

—Ask yourself before intervening:

—Is this just a different style of leadership? If so, let it go.

—Is there a real risk that hasn’t been accounted for? If so, step in.

—Encourage problem-solving—leaders should guide, not dictate, to help teams grow independently.

By allowing managers to make decisions and only stepping in when truly needed, DroneDeploy avoids bottlenecks and empowers teams to scale efficiently.

Scaling While Maintaining Engineering Culture

As companies scale, culture can either evolve intentionally or get lost in process and bureaucracy. DroneDeploy prioritizes culture retention at scale by:

—Keeping teams connected to the company’s mission – Engineers aren’t just solving technical problems; they see how their work impacts customers and industries.

—Empowering teams to shape their own workflows – Instead of enforcing rigid rules, leaders encourage teams to refine and own their processes, communication styles, and decision-making approaches.

—Emphasizing learning over punishment – When teams view mistakes as learning opportunities instead of career risks, they feel safer to innovate.

Jeremy’s philosophy: “Scaling isn’t just about hiring more people—it’s about making sure they still feel like part of something bigger.”

Final Thoughts: Scaling with Trust, Not Just Processes

Scaling an engineering team isn’t just about adding more people or enforcing more rules—it’s about creating an environment where teams can thrive, innovate, and make decisions with confidence.

As Jeremy Eastwood shared, structure matters, but flexibility is key. DroneDeploy has built a system that prioritizes autonomy while maintaining alignment, ensuring teams move fast without unnecessary bottlenecks.

The most effective engineering leaders know when to step back and trust their teams, balance structure with adaptability, and focus on outcomes over rigid processes.

“The best engineering teams don’t scale through more rules—they scale through trust, autonomy, and a culture that encourages smart decision-making at every level.”

By fostering a culture of ownership, accountability, and continuous learning, engineering leaders can scale their teams without sacrificing efficiency or innovation—and ultimately, build a company that moves fast and stays resilient.