1. Why We Wrote This Story
Every start‑up eventually discovers that its technology is only half the product; the other half is the knowledge of the engineers who bring that technology to life. At Tohum AB—operating from Göteborg, Sweden and İzmir, Türkiye—we design field‑ready soil‑measurement nodes that pair an ESP32 brain with precision NPK sensors, Li‑ion batteries, high‑efficiency solar panels, SIM‑based back‑haul, and MQTT data pipelines. As the feature list grew, we found ourselves juggling firmware forks, hurried PCB revisions, and an ever‑lengthening “things we’ll fix later” backlog.
This article is a retrospective on how we:
- Defined our technical requirements in a way that balanced agronomic accuracy, ultra‑low‑power needs, and manufacturing constraints.
- Audited and quantified our technical debt, from buggy BLE drivers to duplicated power‑tree schematics.
- Built a skill‑matrix learning plan that turns gaps into growth opportunities rather than stress points.
- Embedded career development into our daily engineering rhythm so that the future of every employee is treated as seriously as the future of each product.
We hope the playbook is useful whether you’re architecting your first sensor node or scaling a fleet of tens of thousands of devices.
2. Framing the Mission—From “A Cool Gadget” to Measurable Outcomes
Our founding vision was straightforward: Give farmers affordable, telemetry‑rich insight into soil health so they can optimize fertilizer and irrigation with scientific precision. Turning that vision into an engineering backlog required a language all stakeholders could understand—marketing, field agronomists, firmware hackers, and hardware designers alike.
We therefore wrote each top‑level requirement as a user‑visible outcome followed by engineering metrics:
- “A field technician can install a probe and see data in the dashboard within 5 min.”
- 2.4 GHz Wi‑Fi provisioning or BLE Soft‑AP; fallback to pre‑loaded APN for cellular.
- Initial soil pH, EC, temperature values must appear in Grafana within 300 s.
- “Nodes must operate unattended for one full Nordic winter without battery replacement.”
- Average current draw ≤ 80 µA over 24 h; deep‑sleep quiescent ≤ 5 µA.
- 6 W panel + 3 500 mAh 18650 must meet energy budget at 55° N with 2 h insolation.
- “Data gaps caused by coverage loss must be backfilled automatically.”
- 4 MiB LittleFS ring buffer; SD card optional.
- MQTT QoS 1 resend with exponential back‑off on reconnect.
With outcomes clear, trade‑offs became explicit: a bigger local buffer adds BOM cost; more frequent sampling increases agronomic resolution but drains the battery. Because every requirement could be traced to concrete numbers, we avoided the trap of “nice‑to‑have” features sneaking into revision A boards.
3. Breaking Down the Technology Stack
Next, we decomposed the solution into six focus areas, each championed by a “tech steward” who owned requirements, risk registers, and Jira epics:
| Focus Area | Core Technology | Success Metric |
|---|---|---|
| Processing & RTOS | ESP32‑S3, FreeRTOS, ESP‑IDF | 100 % CPU utilization < 20 ms per cycle |
| Soil Sensors | Ion‑selective electrode array | ±2 % full‑scale accuracy vs lab ref. |
| Energy | 3.7 V Li‑ion, MPPT buck‑boost solar charger | ≥95 % charge efficiency at 250 mA |
| Connectivity | SIM7600 LTE‑CAT‑M1 + Wi‑Fi | > 98 % successful publish ratio |
| Cloud & Protocol | MQTT/TLS to AWS IoT Core | Latency < 3 s p95 |
| Enclosure & Compliance | IP67 PC‑ABS + potting | Pass CE, FCC, ROHS, IP67 spray |
A single‑page “Architecture Canvas” visualized dependencies: the soil sensor board feeds I²C data to the MCU; the power subsystem reports SoC via coulomb counter; the modem shares the UART bus with RS‑485 debugging; the cloud rules engine fans data into InfluxDB for Grafana.
This canvas became the table of contents for all subsequent design docs, preventing siloed thinking and ensuring every engineer knew who to ping when a spec changed.
4. Quantifying Technical Debt—Turning Anecdotes into Numbers
Like many start‑ups, we had accumulated “we’ll fix this after demo day” shortcuts:
- Firmware
- Hard‑coded APNs in three different source trees.
- Copy‑pasted ADC routines with magic scaling constants.
- Hardware
- Three resistor value changes patched with blue‑wire in pilot batch.
- No consistent naming convention for test points.
- Process
- One‑off Bash scripts to flash 50 units on the production line.
- Tribal knowledge about which SDK commit worked with which board revision.
We adopted a three‑step audit similar to Ward Cunningham’s technical‑debt metaphor:
- Inventory – an all‑hands “debt safari” produced 126 items in a Confluence page.
- Severity & Interest Rate – each item scored 1‑5 for impact and 1‑5 for cost to fix later.
- Principal Estimate – hours required if fixed immediately.
The result looked like:
| Debt Item | Impact | Interest | Principal (h) | Weighted Score |
|---|---|---|---|---|
| BLE driver fork | 5 | 5 | 40 | 1 000 |
| Inconsistent ADC scale | 4 | 3 | 8 | 96 |
| Flash script | 2 | 2 | 6 | 24 |
High‑scoring items were promoted to sprint backlogs. Lower ones remained in the “snow‑bank” but with explicit expiry dates. This quantitative lens depersonalized discussions: the numbers decided priority, not the loudest voice.
5. Mapping Skills to the Product—The T‑Shaped Matrix
Parallel to the debt audit, we realized some “debt” was really a skill deficit. We borrowed the five‑level framework you saw earlier (Absolute Beginner → Expert) and listed 25 competencies (C/C++, ESP‑IDF, FreeRTOS, Git, PlatformIO, Linux CLI, Unity Test, CI/CD, Jira/Confluence, Electronics, PCB design, Power budgeting, Battery management, Cellular comms, IoT protocols, TLS, Sensor calibration, Data logging, OTA, Control theory, Python/Bash, Cloud dashboards, Regulatory compliance, Documentation tooling).
Each engineer self‑assessed and a tech lead moderated for calibration. The outcomes formed a heat map:
Name C/C++ ESP‑IDF LTE PCB MQTT Cloud ...
Ali 4 3 2 5 4 2
Elif 2 2 4 3 3 5
Mert 5 4 1 2 3 2
We call this the T‑shaped Matrix—everyone deep in one spike, broad in the basics. It instantly highlighted risk: if Ali (LTE level 2) went on vacation, cellular issues might stall a sprint. It also illuminated growth paths: Elif could mentor cloud while learning ESP‑IDF from Mert.
6. Crafting the Learning Plan—From Gaps to Goals
A learning plan is credible only if it ties back to product needs and individual motivation. We took three concrete steps:
- Skill Buckets Aligned to Road‑map Milestones
Q3: secure boot and flash encryption → everyone to Level 3 in mbedTLS.
Q4: delta‑OTA rollout → two firmware devs to Level 4 in data logging and partition artistry. - Embedded Practice
– Pair‑programming sessions twice a week rotating mentor/mentee.
– “Friday Spike”: 4‑hour sandbox to hack on anything related to the weekly theme—Kalman filter mock‑ups, PlantUML board diagrams, etc. - Visible Progress Metrics
– Monthly “show the thing you learned” lightning talks.
– Jira Goals board with personal epics like “Elif Level‑up ESP‑IDF to 3: OTA example shipped.”
We allocated 10 % of sprint velocity explicitly to learning tasks. Finance initially blinked at the capacity hit, but retention numbers improved: voluntary turnover dropped to 0 % over 18 months.
7. The Career Development Loop—Engineering, Not HR, First
Traditional appraisal cycles felt inadequate. We replaced them with a lightweight Career Kanban:
| Column | Definition of Done |
|---|---|
| Explore | Identify learning goal tied to product milestone |
| Plan | Pick mentor, resources, deadline |
| Execute | Complete course/book/pair‑task |
| Demonstrate | Show working code, schematic, or doc |
| Reflect | 15‑min retro with mentor; update skill matrix |
Engineers move cards at their own pace; leads step in only to unblock or celebrate. This fluidity mirrors how pull requests work—learning is just another branch.
8. Results in the Field—Fewer Downtimes, Happier Farmers
Twelve months after launching the framework:
- Bug backlog shrank by 48 %.
- Firmware release cadence improved from quarterly to monthly.
- Battery runtime exceeded the original winter target by 18 %.
- Support tickets for cellular dropouts fell by 60 %.
Most tellingly, time from spec to first validated prototype went from eight weeks to 4.5. Engineers credited cross‑training: the PCB designer who reached Level 3 in Python wrote a calibration script that saved a week of test‑bench labor.
9. Caring for the Future—Why Learning Is Part of Our ESG Charter
We position continuous learning not just as an HR perk but as an environmental and social imperative:
- Environmental – Better‑designed firmware means fewer field visits and lower CO₂ footprint.
- Social – Upskilled employees become local tech ambassadors, boosting regional innovation.
- Governance – Documented skill matrices and transparent promotions reduce bias and strengthen compliance.
Each quarter we publish an internal “Learning Impact Report” showing correlations between training hours and key OKRs (bug density, energy efficiency). The board reviews it alongside revenue numbers—proof that people metrics earn equal board‑room airtime.
10. Lessons Learned & Tips for Other Teams
- Write outcome‑driven requirements first; technology choices follow naturally.
- Quantify technical debt so arguments become math, not emotion.
- Visual skill matrices surface talent bottlenecks faster than org charts.
- Allocate focused time (we chose 10 %) to make learning credible.
- Tie learning to live code—a merged PR teaches more than any MOOC.
- Celebrate small wins; lightning talks trump slide decks for sharing tacit know‑how.
- Publicly connect learning to product KPIs to win executive sponsorship.
11. What’s Next for Tohum AB
Our 2026 road map includes NB‑IoT + LoRa dual connectivity, AI‑driven nutrient predictions, and a rugged v6 enclosure targeting IP69K wash‑down farming operations. Each frontier spawns new skill‑matrix columns—ultra‑low‑power ML, LoRaWAN MAC deep dives, high‑pressure ingress labs. The framework lives on: we’ll repeat the requirement‑debt‑learning cycle with every leap.
12. A Final Word on People
Silicon chips age; solar panels degrade; even the richest soil eventually needs replenishment. The only asset that compounds value indefinitely is human potential. By engineering our learning process with the same rigor we apply to schematics and code, we discovered a virtuous loop: better products fund more learning, which yields better careers, which in turn produce better products.
If you take one thing from our story, let it be this: invest in your engineers like you invest in your battery chemistry. Both store energy, but only one can invent the future.