Building Tools for the Builders: Understanding Developer Pain Points at Scale
Summary
Led comprehensive internal user research with 20 frontend engineers to understand developer workflows and pain points, enabling the Software Delivery team to create targeted tools and processes. Research revealed distinct patterns between junior and senior developers, leading to company-wide persona adoption and strategic improvements in onboarding and cross-team communication.
Key Impact: Research directly informed creation of structured onboarding program for junior engineers and new communication platform for senior engineers, later adopted company-wide for better developer support.
The Challenge: Building Tools Without Understanding Users
Business Context
The Software Delivery team was tasked with creating tools to improve the development process, but they faced a fundamental problem: they didn't deeply understand their internal users, the engineers whose productivity they were meant to optimize. Without this understanding, they risked building tools that solved theoretical problems rather than actual workflow pain points.
The Strategic Problem
The Blind Spot: How can you improve developer productivity when you don't understand what actually slows developers down?
My Hypothesis: Developer needs vary significantly based on experience level, and one-size-fits-all solutions likely miss critical use cases.
The Stakes: Poor internal tools don't just waste development resources, they compound daily, affecting every feature shipped and every engineer's job satisfaction.
My Approach: Treating Internal Users as Seriously as External Ones
Advocating for Internal User Research
While many organizations focus exclusively on external user research, I pushed for treating internal developers with the same rigor:
The Case I Made: Engineers are users too. If we're building tools for them, we need to understand their mental models, workflows, and pain points just like we would for any product user.
Research Strategy: Beyond Surface-Level Feedback
Instead of: "What tools do you want us to build?"
I asked: "Walk me through your actual development process and where you get stuck."
Instead of: "What's frustrating about your job?"
I asked: "Tell me about a recent project that didn't go as smoothly as expected."
My Methodology:
20 in-depth 1:1 sessions with frontend engineers across experience levels
Day-in-the-life workflow mapping to understand actual vs. intended processes
Follow-up surveys to quantify patterns discovered in qualitative sessions
Journey mapping to visualize frustration intensity across development lifecycle
Critical Discovery: Experience Level Shapes Everything
1. Two Distinct User Segments Emerged
Key Finding: Junior and senior developers weren't just on a linear progression, they had fundamentally different challenges requiring different solutions.
Junior Developer Pain Points:
Lack confidence in their coding abilities
Struggle with insufficient documentation and knowledge sharing
Feel lost navigating Sumo Logic's proprietary query language
Need more structured learning and support systems
Senior Developer Pain Points:
Frustrated by cross-team communication breakdowns
Struggle with project prioritization and resource allocation
Blocked by technical dependencies and team coordination issues
Waste time on repetitive explanations to junior developers
2. The Intensity Pattern Discovery
Critical Insight: Both groups experienced similar types of frustrations (communication, technical roadblocks, knowledge gaps), but the intensity and focus varied dramatically.
Junior developers: Frustration with technical knowledge gaps, medium frustration with communication
Senior developers: Frustration with process inefficiencies, medium frustration with knowledge transfer responsibilities
Why This Mattered: This meant we could address both segments with overlapping but tailored solutions rather than completely separate approaches.
3. The Hidden Mentorship Burden
Unexpected Finding: Senior developers were spending significant time on informal mentoring and knowledge transfer, but lacked structured ways to do this efficiently.
Quote (Senior Engineer): "I want to help junior developers succeed, but explaining the same concepts over and over takes time away from my actual development work. We need better ways to share knowledge systematically."
Cross-Functional Collaboration: Scaling Research Impact
Working with the Software Delivery Team
My Role: Translated user insights into specific tool requirements and success metrics
The Collaboration: Worked with engineers to understand technical feasibility while maintaining user-centered priorities
Key Output: Created detailed persona documentation that became the foundation for all tool development decisions
Expanding Beyond the Initial Team
Strategic Decision: Recognized that developer experience insights had value beyond just the Software Delivery team
My Approach: Created compelling, actionable personas that other teams could use to better support engineers
The Result: Company-wide adoption of developer personas for improved cross-functional collaboration
Impact & Measurable Outcomes
Immediate Tool Development
Structured onboarding program designed specifically for junior engineer confidence-building
Cross-team communication platform that reduced senior engineer coordination friction
Knowledge sharing system that captured senior developer expertise in accessible formats
Strategic Organizational Impact
Company-wide persona adoption improved how all teams interact with and support engineers
Shifted internal tool strategy from technology-first to user-need-first approach
Established framework for ongoing developer experience measurement and improvement
Created shared language for discussing developer needs across different organizational functions
What I Learned: Internal Users Deserve the Same Rigor
1. Internal Research Has Compound Impact
Unlike external user research that improves one product, internal research improves the productivity of everyone who builds products. The ROI multiplies across every project and feature.
2. Experience Level Is a Critical Segmentation
Age and years of experience weren't as important as comfort level and confidence. Some junior developers with strong foundations progressed quickly, while some senior developers struggled with company-specific processes.
3. Personas Drive Organizational Empathy
The most valuable outcome wasn't just better tools, it was better understanding across teams about what engineers actually experience daily.
4. Process Problems Masquerade as Technical Problems
Many "technical" frustrations were actually process and communication issues that could be solved without building new tools.
Systems Thinking: Developer Experience as Competitive Advantage
The Broader Business Impact
Product Quality: How do developer pain points affect the features customers experience?
Retention and Hiring: How does developer experience affect our ability to attract and retain engineering talent?
Innovation Velocity: How do workflow inefficiencies slow down our ability to compete in the market?
Knowledge Management: How do we scale institutional knowledge as the team grows?
Long-term Strategic Considerations
Scalability: How will these insights apply as the engineering team doubles or triples in size?
Tool Evolution: How do we continue measuring and improving developer experience over time?
Cultural Impact: How does better internal user research change how we approach all internal process decisions?
Validation Through Adoption
The research's value was validated by company-wide adoption of the personas and continued use in tool development decisions. The Software Delivery team continues to reference these insights for new initiatives, demonstrating the lasting impact of foundational user research.
Future Considerations
Continuous Measurement: How do we track developer experience over time as tools and processes evolve?
Remote Work Impact: How have distributed work patterns changed developer pain points and collaboration needs?
Tool Integration: How can we better connect the various tools developers use into cohesive workflows?
Strategic Thinking: From Research to Organizational Impact
My Framework for Internal Tool Strategy
Workflow Integration: Tools must fit into existing processes, not replace them
Experience-Level Appropriate: Different experience levels need different types of support
Scalable Knowledge Transfer: Solutions should reduce repetitive explanations while improving learning
Cross-Team Visibility: Communication issues often stem from lack of shared context
Challenging the "One Tool for All" Assumption
The Pushback: Some stakeholders wanted simple, universal solutions that would work for everyone.
My advocacy: Treating all engineers the same actually serves no one well. Junior developers need structured learning paths, while senior developers need efficient collaboration tools. We can create complementary solutions that serve both groups.