How engagements work
Software got its lean practices. We built the network's.
The network is the least forgiving layer in IT. Our methods were built for it.
Palo Alto Networks Innovator reseller · Founded 2019 · Brea, CA
Engagement path
Start where you are
1
Buy the hardware.
Firewalls and network gear on their own. Installation and cutover are available when you want them, not required to place the order.
2
Scope a project.
When the work is bigger than a box, we do technical discovery during the needs discussion, before any statement of work is signed, so the scope is real. The project then runs against the quoted timeline.
3
Add ongoing work, if you need it.
A flat monthly rate for a set number of engineering hours each week, on a one-year term. A project does not require it.
Each step stands on its own. You decide whether to take the next one.
Before the quote
Before we price a project
Questions that change scope
Some questions only change an estimate. Others change what the project is. We ask the second kind before we quote: how many domains are involved, how your sites trust each other, whether address ranges overlap. Each answer can move the scope, so we would rather find it during discovery than partway through the work.
Risk, agreed up front
When moving faster means accepting some risk, we agree on the risk and how it's covered with you before the work starts.
Schedules
Our schedules get more precise as we learn your environment. We build buffer into the plan where the project waits on approvals, vendor tickets or shipping, and protect the end date with it, so delays are planned for rather than discovered.
The method, where the setup allows
How a project runs
We plan every change so it can be undone, and we make it in the smallest steps the project allows.
01
Build beside
New infrastructure is built beside what's already running.
02
Prove on low-risk systems
It runs first on low-risk systems, to build trust in it before business-critical systems move.
03
Move one piece at a time
Then the work moves over one piece at a time: a site, a subnet, a device.
04
Look back, improve the next
Each piece is planned in full. After each one we look back and improve the next, so the first pieces take longer on purpose and the later ones go faster.
How much of this a project gets depends on the hardware, the budget and the risk. Where a step doesn't fit, the scope says so, and we agree with you how that risk is covered before the work starts.
A way back is planned before every cutover, and tested where the hardware allows.
When there's room to run new gear beside the old, we prove it on low-risk systems first and move the rest a piece at a time, so the first pieces take longer on purpose and the later ones go faster. When there isn't (one firewall in the path, one maintenance window, no budget for temporary hardware), the change is planned in full, the backout is written before we start, and you know which steps were skipped and why.
The team
Who does the work
Senior judgment where it matters, a trained bench for the rest.
Same method, every engineer
Every engineer follows the same method, so your work doesn't change with who's assigned.
The method: trace a problem the way a packet travels, list the possible causes before touching anything, change one thing at a time, and write down what was ruled out. Work that's new to us, or isn't routine, gets project management and senior review at the design stage. Routine work gets a peer review of the configuration before it goes live. Engineers escalate before acting on anything they aren't sure of, and what one engineer learns becomes how the team works.
Founders on the hard parts
Founders still lead architecture and the hardest technical escalations.
Reporting
How you'll know where things stand
Status
We work in your project tool if you'd like us there, or report to you at the level of detail you choose. Progress is measured by the work left to do, not by how many tasks are checked off.
Change process
We match the change process to the system and to how you want to balance speed and stability.
After hours
After-hours work is scheduled with your engineer ahead of time, with critical (P1) outages as the exception.
Ongoing work
Ongoing work, if you want it
Ongoing work sits on a flat monthly rate for a set number of engineering hours each week, agreed up front, on a one-year term. We track hours weekly and look at a four-week average, so a busy week or two evens out. If the average runs over, you choose: hold lower-priority work, add weekly hours, or scope the extra as its own project.
We prefer ongoing work because being in your network every week makes our project work better, and it pays down technical debt as we go.
Network ManagementOwnership
What stays with you
Documentation
We document in the tools your team already uses, as we go, so the documentation is yours from day one. If we can't get access, we send you everything we make.
Standards
The standards our engineers work from stay with your team. Your process gets better while we're in it, and it stays better after.
The next year
We'd like to be your network team for the long haul, and we plan to earn that every year rather than lock you into it.
For procurement
If your procurement team calls this staff augmentation, here is how it differs: we bring a trained team, not a single contractor, and we scope the work in writing before it starts.
Summary
The short version
e-Mayhem embeds network engineers into midsize IT teams. Projects are scoped in writing after technical discovery, before any work starts, so you know the scope before you sign. Changes are made in the smallest steps the project allows, each with a way back. The documentation we build is yours from day one. Hardware can be bought on its own; projects and ongoing work are options, each on its own terms.