# George Ntoutsos — Professional Profile > Last updated: 2026-03-24 --- ## Current role - **Title:** Software Engineer - **Company:** Power Factors - **Team:** Soda (part of the Platform org) - **Tenure:** ~5 months (joined ~October/November 2025) - **Department OKR classification:** Product_RD ## What I own ### Commloss Service (CLS) — primary ownership The Commloss Service determines when a data source (ingestion data source) is not available. It is used across the entire ingestion layer and surfaced in the UI to show customers the operational status of their power plants (wind and solar). - **Sole engineer** on CLS since my former team lead (the only other person who worked on it) departed shortly after onboarding me (~1-2 weeks of knowledge transfer) - Inherited the service in an under-invested state: bugs, technical debt, sparse implementation history, limited documentation - CLS is in production with ~10 sites for a single customer, out of 500+ total possible sites - Not yet widely used by customers — no L3S support tickets exist for it yet - The service is pre-GA in terms of customer adoption; Product drives decisions on which sites/customers come online **Technical stack:** Go, Kafka, PostgreSQL, gRPC, Kubernetes (EKS), Helm, CI/CD pipelines **Key CLS concepts:** - Ingestion has signal-level and feed-level granularity; CLS correlates and rolls up commloss indicators from signal → feed → device → segment - Produces events consumed by the Event Service, FATA (automation framework), Data Studio, and operator dashboards - Handles both inferred comm loss (data absence detection) and inbound/actively detected comm loss (adapter-reported) - Supports drilldown for detailed cause information - Uses in-memory and storage-based replay mechanisms with periodic snapshots ### Key Jira references - **SQUID-12992** — Main CLS epic ("Data Ingestion - Comm Loss Service (technical items)"). Contains the full design history, requirements, architecture decisions, and BRP milestones. ~50 child tickets spanning the service's entire lifecycle. - **SQUID-41341** — CLS Improvements epic (DB migration automation). Fully completed by George. - **SQUID-42662** — UWM/ADR-057 data model integration (P1, upcoming work) - **SQUID-40056** — Decouple indicator consumption from processing/replaying (Analysis stage) - **SQUID-42012** — Open bug: comm loss signals show as active when they should be closed ### CLS product milestones (from epic) - **BRP Jan 2025:** Comm loss events in production without drilldown capability; design inbound comm loss for N3uron - **BRP June 2025:** Inferred comm loss enabled for all data feeds in production; design session with events team on drilldown functionality - **Future:** Drilldown UI, broader site rollout, potential integration with automation framework (FATA) and Data Studio ### Broader team contributions - **SQL Ingestor:** Occasional contributions — bug fixes, CI/CD improvements, tasks as needed. Not a primary owner. - **Code reviews:** Actively reviews PRs for all 3 teammates on the Soda team - **Team scope:** The Soda team also owns N3uron Ingestor, Tel3 Ingestor, and a remote control system for Tel3/Telos --- ## Career history & technical background ### Before Power Factors 1. **First role (junior full-stack):** Django websites, HTML pages, Python scripts — foundational web development 2. **Second role (backend/systems):** Developed **urunc**, a custom OCI runtime that spawns unikernels inside microVMs, written in Go. This involved deep systems work: - Container runtimes and OCI specification - Kubernetes internals - Linux networking - CI/CD pipelines - Unikernels and microVMs ### Trajectory - Started as a very junior full-stack developer, pivoted to backend - Progressed from web applications to low-level systems engineering - Comfortable across the stack but identifies primarily as backend/systems --- ## Skills & technical strengths ### Languages & frameworks - **Go** — primary language, used for CLS and urunc - **Python** — Django, scripting (earlier career) - Familiar with full-stack web development (HTML, frontend basics) ### Infrastructure & DevOps - Kubernetes (EKS), Helm charts, container runtimes (OCI) - CI/CD pipeline design and optimization - Linux systems, networking - Docker, containerization - AWS (EKS, credentials management, ECR) ### Data & messaging - PostgreSQL (including migration tooling — goose) - Kafka (producer/consumer patterns, topic management) - gRPC / Protobuf ### Practices - Test-driven development, test coverage enforcement - Database migration automation - Monitoring/observability (Grafana dashboards) --- ## Achievements at Power Factors (first 5 months) Despite being new and the sole engineer on an inherited, under-invested service: 1. **Automated database migrations** — Replaced a manual process (extracting AWS credentials from EKS pods, logging into Postgres interactively, executing SQL by hand) with automated goose-based migrations running as a Kubernetes initContainer. Created the migration tool, converted existing migrations, set up CI, and coordinated the rollout. 2. **CI/CD improvements across the team:** - Added linters to CI pipelines - Made tests run in parallel - Implemented conditional test execution in monorepo - Developed Claude Code skills for release and deployment 3. **Bug fixes and stability work:** - Fixed comm loss indicators being produced from disabled datafeeds (SQUID-42032) - Working on signals showing as active when they should be closed (SQUID-42012) - Addressed Wiz security issues 4. **Documentation:** Writing docs where they were missing, filling knowledge gaps left by departed team lead 5. **Test coverage:** Established and maintained solid coverage for core packages — `internal/app` at 83.1%, `internal/pkg/postgres` at 77.5% --- ## Working style & preferences ### What energizes me - Owning a service end-to-end and seeing it go from messy to solid - Automating boring, error-prone, or time-consuming processes — but not as the only type of work - Solving real problems with practical solutions - Hands-on engineering work ### How I approach work - Pragmatic: fixes inefficiencies when there's time and management support, doesn't chase tooling for its own sake - Honest about constraints: won't commit to goals that depend on other people's decisions or permission not yet granted - Prefers authentic commitments over corporate performance theater — will push back on OKRs or values demonstrations that don't reflect reality - Self-directed: capable of working independently on a service with minimal guidance (proven by CLS ownership after early departure of team lead) - Leverages AI tooling (Claude Code) as a genuine part of the workflow — skills, memory files, code generation — not as a gimmick but to encode knowledge and accelerate work ### Collaboration patterns - Mostly works within own team or independently on CLS - Cross-team interaction happens organically when needed: chats with UI team, PM, directors for bug investigations or feature design - Notes that PM is very busy and rarely responsive; UI team is in a different region and mostly reaches out with questions - Active code reviewer for teammates --- ## Career goals ### Short-term (1-2 years) - Stay hands-on as an engineer - Deepen expertise in backend systems, DevOps, and the renewable energy/APM domain - See CLS transform from under-invested to production-ready and widely adopted - Build a track record of delivering measurable impact ### Medium-term (2-3+ years) - Could see two paths: - **Senior Engineer / Architect** — deeper technical leadership, system design, architectural decisions - **Business/Management oriented** — leveraging technical background in a more strategic role - Not yet committed to either path; wants to stay hands-on first and let the direction emerge --- ## Context for future use ### For CV/resume updates - Emphasize: sole ownership of a production service at a renewable energy platform company, systems-level Go experience (urunc + CLS), automation and DX contributions, cross-cutting infrastructure impact - Quantifiable: automated migration process saving X hours per deployment, CI improvements (parallel tests, conditional execution, linters), test coverage numbers ### For manager conversations - Key narrative: inherited an under-invested service with minimal onboarding, took full ownership, stabilized it, reduced tech debt, and is driving it toward production readiness - Bus-factor risk is real and recognized — documentation and tooling work addresses this - Contributions extend beyond CLS: CI/CD improvements, code reviews, SQL Ingestor support ### For learning path recommendations - Current gaps to explore: deeper APM/renewable energy domain knowledge, observability/monitoring practices, system design at scale - Strengths to build on: Go, Kubernetes, CI/CD, database management, systems thinking - Interests: automation, backend architecture, potentially architectural decision-making ### For project involvement suggestions - Good fit: infrastructure/platform work, service reliability, developer tooling, backend services - Natural extensions: other ingestion services, platform-wide observability, CI/CD standardization - Less natural fit (currently): frontend work, SCADA-specific projects, customer-facing product design ### For OKR/goal-setting sessions - Prefers interview-style discovery over filling forms - Pushes back on vague or uncontrollable KRs — every KR must be scorable and within influence - Wary of OKRs that require permission or time allocation not yet granted - Values demonstrations should reflect real behavior, not aspirational corporate language - Responds well to being shown a draft and iterating, rather than being asked to write from scratch - Full OKR drafting process and skill available at: `.claude/skills/okr-setting/`