Transforming an Engineering Organization
The five-year story of the Ziglar Tribe at Brinks Home Security — from order-takers to a product-minded engineering organization that became a model for the company.
The Starting State
When I joined Brinks Home Security in 2018, the Sales and Marketing engineering team was a capable group of tenured developers who knew their systems well. But there was a fundamental dysfunction: they were pure order-takers.
Business unit leaders wrote tickets. Whoever had the most organizational influence got priority. A BA collected requirements and handed them to engineering. Nobody evaluated ideas, validated hypotheses, prioritized by value, or measured whether the work moved the needle.
The team was busy — but frequently working on the wrong things. Not because they weren't skilled, but because there was no mechanism to question what was asked, propose alternatives, or measure whether their output actually delivered business value. The result was massive opportunity cost.
The 3-Stage Strategy
I diagnosed the problem, designed a strategy, and formally presented it to the team, the business, and my leadership. This wasn't a retrospective framework — I named it and pitched it as a deliberate change agenda.
Stage 1 — Empower Agile Teams
Give the team a voice. Create a mechanism for engineers to push back, ask why, and propose alternative approaches. If the team understood what the business was actually trying to accomplish, they could offer better paths — less effort, more value — rather than just executing what they were told.
This required building enough trust with the business that engineering input was welcomed, not resented.
Stage 2 — Promote Product Mindset
Replace the BA-collecting-requirements model with a true product function. This meant finding or developing someone the business trusted to evaluate ideas, facilitate discovery, create hypotheses, and measure outcomes.
It also required significant teaching on the business side. Stakeholders accustomed to writing requirements had to learn a new way of interacting: working with a product partner to define goals, design experiments, and compare the value of competing ideas before committing engineering resources.
Stage 3 — Transparent Delivery
Make the work visible. Sprint reviews with business stakeholders. Progress radiators showing what's being worked on, how far along, and what's next. The insight: requirements change constantly — the only reliable response is to surface what's happening so that when direction needs to change, everyone can see it and adapt quickly.
The team shifted from doing work quietly to over-communicating, which eliminated the ambient anxiety stakeholders had about whether things were on track.
Building the Product Function
Getting from "BA collecting requirements" to a mature product organization took roughly a year and unfolded in three deliberate stages:
Model the role with a consultant. I brought in an experienced product consultant and explicitly framed his role as product owner — not just a BA with a new title. I introduced him to stakeholders, explained the new interaction model, and used his presence to demonstrate what product thinking looked like in practice.
Develop from within. While the consultant modeled the role, we coached the existing BA. Over time, her work shifted: less requirements transcription, more goal clarification. Less "what did they ask for," more "what are they trying to accomplish and how would we validate success?" She earned the product owner role and continued to grow — she's now a senior product owner/manager. Her career transformation is one of the outcomes I'm most proud of.
Make the strategic hire. When the consultant moved on, I hired a former colleague I'd worked with for years — someone I specifically knew had the skill set not just to fill the role, but to build and lead a product organization. I created a small product team within my engineering organization, with the two product owners reporting to this new hire. That structure became the seed of what eventually grew into a Director of Product Management role and a company-wide product organization spanning all software teams.
That hire was a long game. I knew when I brought him on that he had the potential to run a product organization — not just the immediate role he was hired for.
Product Discovery and Delivery Flow
I formalized the transformation into a framework I presented to the team and stakeholders: the Product Discovery and Delivery Flow.
The framework distinguished two phases that Agile/Scrum conflates:
Discovery — the work before the work:
- Is this a real problem? Is it our problem to solve?
- How would we know if we solved it?
- Is this the most valuable thing to work on right now?
- Is the proposed solution the right one, or is there a better path?
Delivery — the work itself:
- Organized execution via Agile/Scrum sprints
- Regular feedback loops with stakeholders
- Transparent progress and predictable commitments
The core insight: the absence of discovery is what turns a capable engineering team into an order-taker. Discovery is what gives engineering a legitimate voice in what gets built.
PI Planning: Making Commitments Visible
I introduced Program Increment Planning — borrowed from SAFe's "big room planning" concept without adopting SAFe wholesale.
Each quarter, all stakeholders gathered to see what the team was committing to — and what was not on the list. The explicit visibility of what wasn't committed was as important as what was: stakeholders could see their items, understand where they fell in priority, and either accept the plan or trigger a replan with explicit trade-offs.
This created the accountability loop that made the product mindset real: commitments the team could actually keep, made transparently, with a clear mechanism for replanning when circumstances changed. Once the team started consistently delivering on their commitments, the business stopped pushing on the process and started trusting the team.
The Sales System Migration
The highest-profile application of the discovery toolkit: a complete replacement of the sales system at Brinks — a complex initiative involving multiple business processes, dozens of workflows, and significant organizational risk.
Before a line of code was written, I facilitated a three-day user story mapping session with engineers, product owners, business stakeholders, and end users. Not requirements gathering — shared understanding. Everyone in the same room, talking through the process repeatedly, building a single artifact that captured what we were building, in what order, and why.
The result: a wildly successful project. Value delivered quickly, iterated over time, with a shared mental model that kept the team aligned through the inevitable changes and discoveries of a complex migration.
The Chief Sales Officer's assessment: it was the most successful sales system migration he had ever experienced.
I've used story mapping repeatedly since then for large, complex projects and have taught the methodology to at least half a dozen people. It's become a standard tool in my toolkit for starting high-stakes projects right.
What It Became
Over five years, a team of 8 grew to a tribe of 30 across four stream-aligned development teams. The results compounded:
- Release cadence: every 6 weeks → twice per week — delivering value faster, reducing release risk, demonstrating momentum
- The tribe became known for predictable delivery, engineering quality, and business alignment
- Innovation flowed from empowerment: the team pioneered company-wide adoption of synthetic production testing, one-button releases, Confluence for knowledge management, and Jira for workflow visibility
- AI/ML work within the tribe produced quantified business outcomes — AI-driven retention campaigns and targeted marketing that moved real revenue numbers
- The product function I seeded grew into a 10-person product management organization
Remote-First by Design
Before COVID forced everyone remote, I had already established a norm: if anyone on a team was remote, the meeting was run as if the entire team was remote. No side conversations. No whiteboard the remote people couldn't see. Everyone on a level playing field. COVID validated the approach and made it the standard.
Financial Outcomes
The Ziglar Tribe's engineering work connected directly to measurable business value:
- AI-driven retention campaigns produced significant revenue uplift through ML-powered customer targeting
- AI email targeting drove measurable conversion improvements
- A cross-functional consumer financing initiative eliminated over $1M in debt and doubled sales within six months
- Annual labor efficiency improved through restructuring from contractor-heavy to employee-based teams — sustainable teams that cost less and perform better over time
- Eliminated Salesforce consultant dependency by training employees to make their own platform enhancements
What I'm Most Proud Of
The culture change. The camaraderie. The fact that the Ziglar Tribe became a North Star — and that other software groups wanted to emulate what we were doing not because they were told to, but because it was working and the team was visibly having a good time solving problems together.
"Controlling our fate a little bit" — the team could understand what the business wanted and design solutions to get them there, rather than just executing what arrived in a ticket.
The product function spinoff. A hire I made years earlier with a future in mind, growing into the organizational structure the company needed. Not by directive, but by growing a model worth replicating.
And a BA who became a senior product owner — because someone pushed her outside her comfort zone, made it safe to fail, and kept at it until she saw her own capability.