EngineeringFlorida
VP of Engineering
Own how the software gets built and whether it stays up. The first engineering seat, reporting to the President, with the stack, the architecture and the standards still unset.
The research here is applied. A product constraint raises a question, the question gets studied, and what comes back changes what we build. This seat owns the building half of that loop.
What you own
§How the software gets built, and whether it stays up. Architecture, code quality, infrastructure, release process, uptime, the technical hiring bar, and the engineering estimates the rest of the company plans against.
What you decide without asking
§The stack, the architecture, the tooling, the technical standards, and how work is broken down and delivered. These are yours. The expectation is that you use that authority rather than bring the decisions back for review.
Three things go to the President: a platform rewrite, a migration that pauses feature work, and any vendor or dependency that commits us long term. Inside the lane, the call is yours.
What is not yours
§What gets built and why belongs to Product. What data is retained and who can reach it belongs to Data & Privacy. You will have views on both, and they are worth hearing, but the decisions sit elsewhere, and a seat that quietly takes them anyway is the failure we would be watching for.
What this actually looks like now
§No seat below President is filled. You would be the first, which means:
- The architecture is not inherited. There is very little to maintain and almost nothing to defend.
- You will write code, and for a while most of it.
- The engineering hiring bar is one you set rather than one you apply.
- Product and Data & Privacy are unfilled, so those boundaries get drawn with the President directly until the seats exist.
We would rather say that here than have you discover it in week two.
What you would have to be able to defend
§Every system we ship is measured against whether the person who used it is more capable afterwards. That is a design requirement rather than a value statement: it decides what counts as working. If a person could not do the thing better after using it, we have not built what we set out to build, however good the output looks.
You do not need to have built something like that before. You do need to be willing to have your architecture judged against it, including when the judgement is inconvenient.
How to apply
§Tell us about a system you built and what it cost. The architecture you would defend, the one you would not, and how you knew the difference. We would rather read two honest paragraphs than a list of technologies.