One architect, and twenty years of people worth calling.
Twenty years in this industry produces two assets. One is what I know how to build. The other is knowing who builds the rest properly - and being willing to say so.
How this practice is structured
I help you build the team, or I introduce you to people who can.
From the first call I am in the team, not across the table from it. There is no pitch, no qualification stage and no proposal theater. We work out what you are actually trying to build, and then one of two things happens. Mostly I help you put the team together and then sit in it in an advisory seat, contributing to the work rather than taking it over. The team is the whole function, not just engineers. Roles defined, candidates sifted, the technical calls judged, across engineering, project and account management, research, compliance, technical writing, and sales if you are taking the thing to market. A build with nobody running delivery and nobody writing the documentation fails just as reliably as one with bad architecture.
Occasionally the honest answer is that somebody else should do it, and then I say so and make the introduction. That is the minority case, not the default.
Inside the team, what I add is research support when a choice needs evidence rather than a vendor deck, prototyping when an argument is better settled by something running, and a straight read when you want one from someone with no stake in the answer. The people I bring are engineers, integrators, test houses and auditors I have actually worked with over twenty years, not a directory I bought.
That is deliberate. A team that hands its judgment to an outsider never develops any, and the outsider leaves. Working through the problem together is slower in the first month and much faster in the second year, because the people who will still be there are the ones who built it.
There is no firm behind the name and no bench waiting to be filled. When this site says "we", it means you, me, and the specific people we agree to bring in - friends and former colleagues I have worked alongside for twenty years and can vouch for personally. Every one of them is named before you commit to anything, not after. It is never a logo standing in for people you will not meet.
Referrals here run on trust in both directions. The people I would send you to have known me for years, and a referral costs them time whether or not it turns into work. So I do not forward leads to see what sticks. If I make the introduction, it is because I think it genuinely fits, and I have told them why.
- Where I start
- In the team, from the first call. No pitch, no qualification stage.
- Building the team
- The whole function: engineering, delivery, account management, compliance, writing
- What I add
- Research support, prototyping, a straight read - done alongside your engineers
- Introductions
- No charge, and no fee taken from them either
- Bench to keep busy
- None - which is why I can tell you not to buy
How this actually starts
-
You describe the problem
Not a specification. What you are building, the constraint that makes it hard, and the decision you are stuck on. Usually a paragraph is enough to tell which way it goes.
-
We work on it, straight away
The first call is not a sales call, it is the first working session. We look for the problem under the problem, which is often not the one in the email. It costs nothing and sometimes ends with you not needing to buy anything.
-
We scope it, including the budget
Before anyone commits, we work out what it actually takes and what that costs. This is senior engineering time and it is not cheap, so the number comes before the contract rather than after it. If the budget and the problem do not match, that is worth knowing in week one.
-
We build it, and I bring in who it needs
Most of the time we build it, and I stay in the team while we do. Where it needs a semiconductor test house, a water chemist, a controls integrator or a specialist auditor, I bring in the firm I would call myself - at no charge, and with no fee taken from them either. When the whole job genuinely belongs to somebody else, I will say that too.
-
I stay on the seam
Where several parties are involved, the failures happen between them. I hold the architecture across the whole job, which is usually exactly when most of the work belongs to somebody else.
The span
From the fab to the VAR.
The same network reaches from a gallium nitride process to a reseller's professional services team. It accumulated rather than got assembled: every stretch of my career left people behind in a different band, and I kept calling them. Most practices live in one band of this and subcontract the rest, which is fine until the problem crosses a boundary and nobody owns the seam.
- Process and fab MMIC and gallium nitride processes, compound semiconductor foundries, mask and packaging partners
- Device and RF Power amplifier and antenna design, load-pull characterization, microwave and millimeter-wave test
- Digital silicon ASIC and FPGA design, verification, timing closure, design for test
- Boards and manufacture Board design, design for manufacture, ODM relationships, EMC, environmental and certification laboratories
- Embedded and controls Firmware and drivers, industrial automation, machine builders, safety assessors
- Platform and cloud Infrastructure engineering, SRE, DevSecOps, the delivery practice around them
- Security and assurance Assessors, penetration testers, auditors and attestation partners
- VARs and professional services Vendor relationships, licensing and procurement, deployment teams, managed services
Every one of these is a firm or an engineer I have worked with, or who has done work for me. None of them are listed by name here, because that is their business to announce rather than mine.
Why I would rather refer you than keep you.
A firm that answers yes to everything ends up staffing your problem with whoever is available from the bench. I would rather be the person you come back to for the next decade because the first answer was straight, including when the answer was "not me."
That only works if the network is real, so I keep it small enough to vouch for personally.
Start a conversationAnd across all of it
- US-based delivery teams, including people who have worked SBIR, where the research has to stay in the United States
- Nearshore and offshore teams where there is a reason - Poland, the UK, India, Mexico, Colombia, Brazil
- Project and account managers who have run regulated delivery
- Technical writers, compliance specialists and research support
- Hydrogeologists, water scientists and power engineers
- Investors, fractional CFOs and go-to-market operators
Joining the network
I am always interested in engineers and firms who are excellent at one narrow thing and straight about its limits. If that is you, write and tell me what you do and what you decline to do - the second part is more informative than the first.