Engineering Culture at Easee: We Test, We Build, We Own

Open any article about the electrification of transport and energy, and you'll find the same thing: predictions. Forecasts for adoption curves, projections for grid load, best-guesses about what regulation will require next year. It's an industry that spends a lot of time speculating about the future. 

At Easee, we've tried to build a different habit. When we hit a question we can't answer with confidence such as how a component behaves after five years in a Norwegian winter, what actually happens to a charger during a real-world short circuit, whether a new grid configuration holds up under load, our answer isn't to model it and move on. It's to test it. 

That instinct shows up in three places that we think make Easee an exciting place for engineers to work: how we test, how we build, and how much of both we let you own. 

We test past the point where the standard stops 

Every product in this industry must pass regulatory and safety testing. That's non-negotiable, and we do it rigorously. But a few years ago, we ran into something worth learning from: passing the required tests doesn't guarantee a product holds up to everything that happens to it in the field. Standards are written to a baseline; the field doesn't know about the baseline. 

So, beyond what's required, we run extended testing of our own design for longevity, for robustness, and specifically for safety after the kind of edge-case events that regulations don't fully anticipate (unusual fault conditions, degraded installations, years of thermal cycling). Where the equipment to run those tests didn't exist off the shelf, we've built it ourselves, because building it was faster and got us a test that matched the failure mode we were worried about, rather than the closest commercial approximation of it. If you're an engineer who wants to work somewhere that treats "it passed compliance" as a floor rather than a finish line, that's the environment we're describing. 

We build the parts that don't exist yet, not just the products around them 

Most companies in our industry follow a similar playbook: take proven, off-the-shelf components, including connectors, meters, power electronics, and integrate them into a well-designed final product. That's a perfectly reasonable way to build a charger. However, it's not always enough to build the charger we wanted to build. 

We kept running into the same wall: the components available on the market weren't good enough for the reliability and safety bar we were holding ourselves to. So, in several cases, we've gone further up the stack than most of our peers and designed components ourselves, not just the finished product around them. Our MID-certified energy meter is a good example: building a legal-for-trade metrology component from scratch, rather than sourcing one, is something very few companies in the Nordics have taken on, and it's the kind of multi-year, get-it-exactly-right engineering problem that doesn't show up on a spec sheet but matters to whether a product is dependable. 

The same philosophy sits behind our approach to load and phase balancing. Our chargers balance power across phases and across other chargers using our own protocol, running fully locally without cloud dependency required for the balancing itself. The patent behind that system was filed roughly eight years ago and was only granted in the past few weeks. Some engineering bets take a long time to pay off; we've been comfortable making them anyway. 

We put our chargers where the hard, unresolved problems in energy are 

We'd rather point to what we've shipped to solve real, unresolved problems than talk in the abstract. Right now, our engineers are working on live vehicle-to-everything (V2X) integration: getting a charger and a car to talk to each other reliably enough, and fast enough, that a fleet of vehicles can function as a virtual power plant instead of a lab demo.  

Vehicle-to-everything, bidirectional power, and dynamic phase balancing at scale are still open, actively-being-solved problems in this industry, not solved ones we're merely productizing. That's the kind of problem space we want engineers who like solving open problems to be looking at. 

What it's like to build with us at Easee 

Ownership is the word our engineers use most when they describe this place. You're not handed a spec and a Jira board disconnected from why any of it matters. Hardware, firmware, and software engineers work in close proximity to each other and to the lab, and if you have an idea worth testing, the lab is there for you to go test it, not just to validate what's already been decided elsewhere. Software at Easee doesn't stop at the API boundary. If you're writing the logic that schedules a V2X session or balances load across chargers, the hardware it runs against is a walk away, not a device farm you request access to. That shortens the loop from "does this work in theory" to "does this work," and it means the software team ships with the same test-first instinct as hardware: fewer assumptions, more verification against the real thing. That's true whether you're deep in embedded firmware, building the backend services and APIs that serve our customers, partners and the power grid, or out on the bench characterizing how a new design behaves under fault conditions. 

We're not the biggest engineering org in this space, and we believe that is our advantage. We think the combination of a real test culture, a willingness to build our own components when the market's aren't good enough, and problems like V2X that are still unsolved, adds up to a place where the engineering work is real. 

We're hiring for problems like these 

We're hiring across software, hardware, and embedded engineering. If the way we've described testing, building, and ownership here sounds like how you'd want to work, we'd like to hear from you: https://career.easee.com/jobs