MIC

Established Company

Show all Videos

How our career paths help you grow as a Software Engineer

David Theil von MIC erläutert in seinem devjobs.at TechTalk die grundlegenden Gedanken, welche hinter den verschiedenen Rollen als Software Engineer im Unternehmen stehen.

By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.

Video Summary

In "How our career paths help you grow as a Software Engineer," David Theil explains how MIC develops engineers to handle rising complexity, using a technician story to contrast tenure with true maturity. He outlines a non-hierarchical framework from (Junior) Software Engineer into two tracks—Senior (technical excellence) and Lead (technical team enablement)—culminating in Principal, supported by a 27-skill “Skills Spiderweb,” recurring 180-degree feedback, the MIC Academy, mentoring, and coaching. Viewers can apply this by defining clear role expectations, measuring skills, and creating a feedback-driven development plan to progress toward real seniority.

From Features to Systemic Impact: How MIC’s Career Paths Turn Engineers into Problem Solvers

A winter heater, a blown fuse, and the meaning of seniority

David Theil opens with a scene you can’t unsee: It’s winter, your heater dies, and you urgently call a technician. The first one replaces a blown fuse and leaves. Two weeks later, the heat fails again. The second technician – younger, laptop out, diagnostics in hand – also finds the burned fuse but traces it to the true cause: a corroded sensor triggered by a leak. He fixes the leak, replaces the sensor and the fuse, and the system stays up.

The lesson? Seniority isn’t tenure. It’s the ability to diagnose root causes, choose the right tools, and implement durable fixes.

That metaphor frames the entire session “How our career paths help you grow as a Software Engineer” by David Theil (MIC). From our DevJobs.at vantage point, MIC’s approach to engineering careers is built to grow exactly that capability: to move from symptom-chasing to systemic problem-solving, in an environment where complexity keeps rising.

The problem space: a cloud platform for customs and trade compliance

To understand the roles and paths, you need the product context. MIC operates a cloud platform used by globally operating customers to produce and ship goods across borders, managing international customs, trade compliance, and filings. The domain is inherently complex: multi-country regulations, high-stakes data flows, and distributed processes.

David also references a tech radar (presented in detail elsewhere) to show the breadth engineers navigate daily: languages, frameworks, techniques, platforms, and tools. The clear message: not just MIC, but the whole software industry is facing an ever-increasing complexity profile.

In a world of expanding toolchains and intricate domains, growth can’t be accidental. Without deliberate skill-building, we keep swapping fuses and miss the leak.

Why time served doesn’t make you senior

David calls out a familiar pattern: after five years, many engineers ask for the “senior” title and a raise. His counterpoint is sharp:

“If you do something for 30 years, day in and day out, the same way — and you don’t adapt your skills and tools to industry change — you don’t grow, you don’t get mature.”

MIC’s answer is a structured development system that ties seniority to competencies, responsibility, and impact, not just to years in seat. In practice, that means elevating diagnosis over patching, designing systems not just features, and enabling others to deliver — consistently.

The career map at MIC: development axes, not a hierarchy

David presents a non-hierarchical map spanning two axes: operational-to-strategic work and emphasis on lead responsibilities versus technical excellence. Most engineers start as Junior Software Engineer or Software Engineer and then choose one of two directions, both of which can lead to the most mature role in the ladder:

Technical track: Software Engineer → Senior Software Engineer (technical excellence)
Leadership track: Software Engineer → Lead Software Engineer (technical leadership for the team)
Culmination: Principal Software Engineer (the most mature role at MIC)

The distinctions are deliberate. A Lead Software Engineer is a technical lead, not a people manager. A Senior Software Engineer intensifies technical excellence and raises the bar in design and tooling. Both trajectories matter. Both can scale impact across teams and into strategy.

Role deep dives: scope, behaviors, impact

Junior/Software Engineer: deliver value and professionalize learning

In the entry roles, the emphasis is on delivering customer value and building a strong learning habit:

Develop features
Fix bugs
Understand user needs and requirements
Write automated tests

Equally important: learn on the job. The domain is dense, the architecture multi-layered, and the toolset wide. Treat learning as part of the role, not an afterthought.

Senior Software Engineer: technical excellence and role modeling

Seniors still deliver customer value — but expand their impact:

Coach and mentor others
Act as a role model for code quality, design, and tool choices
Shape system architecture and system design
Strive for technical excellence and set the bar for the team

This is the shift from “swap the fuse” to tracing root causes and creating the right environment and tools so problems stay solved.

Lead Software Engineer: build a viable team environment

Lead Software Engineers also ship value but operate as the team’s technical lead — explicitly not the boss or manager. Their focus:

Technical leadership without formal personnel management
Creating and fostering an environment where others can grow
Improving processes, practices, and collaboration to lift team performance

The work pivots toward shaping the system around delivery while remaining connected to actual product outcomes.

Principal Software Engineer: scale knowledge and drive change

The most mature role blends technical excellence with change leadership across teams:

Introducing new techniques and tools across multiple teams and departments
Scaling knowledge beyond a single team
Helping to shape the company’s tech strategy, which teams then implement

A Principal is an expert and a change manager — someone who aligns technique with organizational reality and moves both forward together.

The competency model: a 27‑skill “Skills Spiderweb”

MIC grounds its roles in a detailed competency framework they call the Skills Spiderweb. It covers 27 core skills engineers should bring and build. David doesn’t enumerate them; the point is the mechanism:

Understand your role
Identify the skills your role requires
Build those skills deliberately and track progress

This creates a shared language for development: where you are, where you’re heading, and which actions meaningfully close the gap.

Feedback as the engine: repeating 180‑degree cycles

Growth requires cadence. David describes recurring 180‑degree feedback processes that surface specific, high-signal input and translate it into action. His concrete example: someone wants to strengthen test-driven development — the team identifies measures and a plan to improve that skill.

What matters to us editorially is the orientation: feedback loops serve decisions and outcomes — code, architecture, collaboration, and uplift of others — rather than generic performance talk. That makes feedback navigational, not ceremonial.

The learning stack: MIC Academy, conferences, mentoring and coaching

To make development stick, David outlines a system of enablers:

A training framework (“MIC Academy”) that provides the right content
Conference attendance to absorb practices and fresh context
Mentoring and coaching by more senior engineers — part of their job description

The upshot: learning is individually owned and organizationally supported. Seniority includes lifting others.

Operational vs. strategic: why both matter

David keeps bringing the conversation back to two axes: operational-to-strategic work and lead-to-technical excellence. In day-to-day terms:

Operational work ships value now: features, bug fixes, stabilization
Strategic work improves the system: design guardrails, tooling, practices, and knowledge distribution

As engineers mature, their strategic footprint grows without losing the operational thread. Seniors and Leads still deliver — but increase the leverage by addressing root causes, raising standards, and enabling teams.

What engineers can apply right away

The session offers a set of practices you can adopt, regardless of company or current title:

Chase root causes, not only symptoms: Reserve time for diagnosis, instrumentation, and durable fixes. The goal is to keep problems solved.
Make learning part of the job: Block recurring time and treat it like delivery work. In complex domains, growth requires schedule and ritual.
Choose your trajectory: Decide whether your next step is deeper technical excellence or technical leadership for the team. Both are valid, both require different patterns.
Make skills visible: Sketch a simple spiderweb for your core skills. Visibility drives focus and progress.
Institutionalize feedback: Run recurring 180‑degree cycles with concrete observations and concrete actions. Revisit and adjust.
Scale knowledge: Ask how you can move a practice beyond your team — this is the Principal direction.
Build team viability: Technical leadership is the craft of creating an environment where others thrive — processes, rituals, tooling, culture.

A brief word on the tech radar — without tool bingo

David’s reference to a tech radar underscores the breadth engineers face: languages, frameworks, techniques, platforms, tools. We see a clear takeaway: without structured roles and feedback, such breadth becomes noise. With a career framework and competency model, the breadth turns into a navigable map — who owns which decisions, how learning scales, and how standards evolve.

Measuring maturity: impact over years

By tying roles to skills and feedback, the model anchors seniority to outcomes rather than tenure:

Individual level: technical depth, diagnostic ability, architecture decisions, mentoring
Team level: delivery capability, quality, learning culture, stability
Organizational level: standardized practices, shared knowledge, technical direction

“Senior” and “Principal” stop being labels and become descriptions of lived responsibility.

Practical transfer: implement the ideas in your context

Even outside MIC, the structure maps well to everyday engineering:

Draw your own skill spiderweb of 10–15 core skills relevant to your role (domain understanding, system design, test automation, incident diagnosis, mentoring). Mark current and target levels.
Run 8–12‑week growth cycles: one skill goal, two to three measures (katas, pairing, internal talk), a review with feedback.
Clarify decision ownership: which decisions are prepared by Leads vs. Seniors? How are they documented?
Reserve monthly sessions for root-cause work (postmortems, architecture reviews, toolchain improvements) — not shipping features, but improving the system that ships them.
Keep operational vs. strategic work visible on your team board and protect strategic slots.

These steps echo David’s core message: growth needs structure. Structure makes learning repeatable and impact measurable.

What MIC provides — and why it matters

David highlights the building blocks MIC has put in place:

Clearly defined roles (Software/Junior, Senior, Lead, Principal)
The 27‑skill “Skills Spiderweb”
Regular 180‑degree feedback with actionable measures
MIC Academy, conferences, mentoring and coaching as explicit growth enablers

Together, roles, skills, and feedback turn career paths into a system — precisely what complex products and organizations require to avoid getting trapped in day-to-day firefighting.

Quotable moments

A few lines we noted during the talk:

“How do you develop yourself — and how do you adjust to this complexity?”

“It’s not a hierarchical diagram — it shows your development.”

“A Lead Software Engineer is a technical lead — not the boss or manager.”

“A Principal Software Engineer is a great change manager … introducing new techniques and tools to multiple teams and shaping tech strategy.”

They frame seniority as system-level impact rather than narrow individual contribution.

Conclusion and takeaways

“How our career paths help you grow as a Software Engineer” by David Theil (MIC) condenses into a clear formula: combine well-defined roles, a visible skill model, and recurring feedback loops with a learning stack of training, conferences, mentoring, and coaching. In a domain as complex as customs and trade compliance, that is not optional — it is the only way to evolve from fixing fuses to fixing systems.

Key reminders for your next step:

Choose your next role orientation (Senior vs. Lead) and the impact it implies
Make your skills visible and plan concrete measures in 8–12‑week cycles
Run feedback that speaks to decisions and outcomes — not just impressions
Hunt causes, not just symptoms — in code, process, and team practice
Scale knowledge across teams — that’s the path to Principal

David closes by pointing to MIC’s career site for those who want more detail. If the heater metaphor sticks, the lesson will too: seniority isn’t a date on the calendar; it’s a practice you repeat until durable results become your default.

More Tech Talks

More Tech Lead Stories