Senior Python SDK Engineer (m/f/d)

The role

We’re looking for a   Senior Python SDK Engineer   (m/f/d) to own the software our connectors are built on. Every instrument we bring online gets a connector, and every connector runs on our shared libraries: Bus, our Connector Development Kit (CDK), and the stack underneath them.

Our mission is to empower researchers and engineers by bridging the gap between lab equipment and cloud-based automation. Our customers are solving critical challenges like curing diseases, developing sustainable materials, and addressing global food security. We give them the tools to connect their devices, automate workflows, and open up new possibilities in R&D.

Until now, our libraries have been maintained alongside connector projects. This role makes them a product of their own. You’ll sit in the team that builds and maintains connectors, but your focus and your outcomes are the SDK. That means Bus, the CDK and the core Python libraries first, plus SiLA-JS, our Rust SiLA library, the bundler and the SiLA Gateway. Within 12 months, our connector engineers should build new connectors measurably faster, without solving the same problems again.

Why you'll love this role

Your users are engineers.   Your work decides how fast other people ship connectors. It’s a different craft from shipping features, and it’s the one we’re hiring for.

Real hardware, real failure modes.   You’ll work on live connector projects alongside the team and test against physical devices in our Munich workshop. What goes into the libraries comes from problems that actually exist.

Open source on purpose.   Our CDK and our standardization work (SiLA 2) are public. What you build gets used and criticized by people outside the company.

Senior scope, small team.   You own the SDK end to end: API design, tests, CI, releases and docs. There’s no layer between you and those decisions.

Your mission

Own the SDK as a product:

• Own Bus, the CDK and the core Python libraries, plus SiLA-JS, the Rust SiLA library, the bundler and the SiLA Gateway. That covers API design, features, tests, CI, releases and deprecations across the connectors already running in production.
• Automate releases. Every library release goes through CI with versioning, a changelog and a deprecation policy, and needs no manual steps.
• Test library releases against the connectors that depend on them, so a change to Bus or the CDK can’t silently break a connector in production.
• Make the docs good enough to remove yourself. A mid-level engineer or an outside contributor should be able to build a connector on our libraries without help.

Turn connector work into library features:

• Work on live connector projects with our connector engineers, and turn what you see into a ranked list of duplicated patterns and library gaps.
• Extract abstractions from real work. When the same pattern shows up in the third connector, it becomes a library feature.
• Bring COM and DLL communication into Bus, from design through a prototype on a real device, and move existing connectors that built their own COM solution onto it.

Set the quality bar:

• Build an automated testing environment that runs every connector end to end in CI before each release. It should test against simulated devices and, where possible, real instruments.
• Track the time it takes to build the first connector for a new instrument class, and bring it down.

Your profile

• Deep Python: 5+ years of writing production Python other people depend on. Async, typing, packaging, testing. Not scripting-level.
• Has owned a library others build on. An SDK, a library or an internal platform, with real versioning, releases, deprecations and backwards compatibility. This role is judged on other people's throughput, not on its own commits.
• Abstraction judgment. Pulls abstractions out of real use instead of designing them up front. Knows when to generalise and when to leave the duplication alone, and can explain why.
• Writes for developers:  t reats docs, examples and migration guides as part of the product, not as an afterthought.
• Works with their users.  Pulls requirements from the engineers who use the libraries, writes proposals before big changes, and communicates without being chased. Hybrid and remote work only work if this comes naturally.

Nice to have

• TypeScript and npm packaging, for owning SiLA-JS
• Rust, for the tooling around the libraries: our Rust SiLA implementation, the bundler that packages Python connectors into executables, and the SiLA Gateway that proxies local connections to the cloud. We expect the hire to be strong enough to learn it on the job.
• Hardware or protocol experience: gRPC, serial, TCP, OPC UA, CAN, USB
• SiLA 2 or a similar device-abstraction or interoperability standard
• Open source maintainership, ideally with real external contributors
• Code generation, plugin architectures, or gRPC and protobuf tooling
• Test infrastructure: device simulators, hardware-in-the-loop …