There’s been a lot of discussion about T-shaped engineers in the vertical SaaS thread, so I wanted to share how we’re actually building this at scale in our EdTech organization.
What Is a T-Shaped Engineer? (Quick Recap)
The T-shaped model:
- Horizontal bar: Broad technical skills across multiple areas
- Vertical bar: Deep expertise in one specialized domain
In our case:
- Horizontal: Cloud infrastructure, databases, APIs, testing, security fundamentals
- Vertical: EdTech-specific knowledge (LMS integration, student data privacy, accessibility, pedagogy)
How We Build T-Shaped Engineers at Scale
We’re scaling from 25 to 80+ engineers. I can’t hire 80 engineers who already have perfect T-shaped profiles. So we have to build it.
Our Training Program (First 90 Days)
Weeks 1-4: Technical Foundation Assessment
- Evaluate horizontal bar: system design, coding practices, testing
- Identify gaps in fundamentals
- Pair with senior engineers on technical skills
Weeks 5-8: EdTech Domain Immersion
- Shadow customer success calls with educators
- Learn FERPA (student data privacy regulations)
- Understand LMS integration patterns (Canvas, Blackboard, Schoology)
- Study accessibility standards (WCAG, ARIA)
Weeks 9-12: Applied Learning
- First significant feature: Must combine technical skills + domain knowledge
- Example: Building gradebook sync requires understanding both technical APIs AND grading workflows that teachers use
Ongoing Development
Monthly domain learning:
- Lunch & learns with educators (understanding their pain points)
- Accessibility audits (hands-on learning)
- Compliance deep-dives (FERPA, COPPA for children’s privacy)
Quarterly technical skill building:
- Architecture reviews
- Security training
- Performance optimization workshops
The balance: 70% technical skills, 30% domain knowledge
Real Example: Accessibility Feature
Last month, we built a new assessment feature. Here’s how T-shaped engineering made the difference:
Engineer with only technical skills would have:
- Built accessible HTML (technical checkbox)
- Met WCAG standards (compliance)
- Shipped on time
T-shaped engineer with EdTech domain knowledge:
- Built accessible HTML (technical checkbox)
- Met WCAG standards (compliance)
- ALSO understood that middle school students using screen readers need extra time for assessments (domain insight)
- ALSO knew that teachers need bulk accommodation tools, not individual student settings (domain knowledge from shadowing)
- ALSO designed for IEP (Individualized Education Programs) workflow integration (domain expertise)
The result: A better product that teachers actually wanted.
The Hiring Rubric
When we hire, we look for:
Must-haves (Horizontal bar):
- Strong coding fundamentals
- System design thinking
- Testing and quality mindset
- Communication skills
Nice-to-haves (Vertical bar):
- EdTech experience
- Understanding of education workflows
- Teaching background (career switchers)
We can train the vertical. We can’t easily train weak fundamentals.
The Career Ladder Includes Both Dimensions
Junior Engineers (IC1-IC2):
- Focus: Build technical fundamentals (horizontal bar)
- Domain exposure: Shadow calls, learn basics
Mid-Level Engineers (IC3-IC4):
- Expectation: Solid horizontals + developing vertical
- Can independently ship features that require domain judgment
Senior Engineers (IC5+):
- Requirement: Strong horizontal + deep vertical
- Influences product decisions based on domain expertise
- Mentors others on both technical and domain topics
Question for the Group
How do other orgs build T-shaped engineers?
- What’s your ratio of technical training vs domain training?
- Do you require domain expertise for promotions, or just encourage it?
- How do you help generalist engineers develop vertical expertise?
- What domains have you found easier or harder to teach?
Curious how this works in other verticals – healthcare, fintech, legal tech, etc.