ResourcesLeadership

Developer Education Challenges

13 min read

Developer Education(DevEd) faces many obstacles to ensure successful engineer onboarding and continuous learning. These are topics that you could spend hours discussing on a high level, and they are ubiquitous for most DevEd teams. This list is also a work in progress, and I will continue to add to it as I have time.

Blocker Reduction

Productivity in engineering naturally increases when you remove the blockers getting in the way of the engineering teams. Instead of measuring the approximation of engineering output, learning teams should measure actual, observable metrics that directly correlate to effectiveness.  One method would be identifying engineering blockers and measuring the reduction because even minor blockers can evolve into 10,000 papercuts over time.

Considerations

  • Proactive Learning Solutions to Prevent Engineering Blockers
  • Incorporate Learning into the SDLC
  • Ensure Quick Discovery of Solutions and Context Sharing
  • Automate the Identification of Gaps in Documentation
  • Compile Support Requests into Searchable FAQs for Self-Service Support
  • Personalize Learning to User & Reduce Noise
  • Create Learning Templates for Common Activities
  • Allow Feedback Loops to Improve Engineer Experience

Recommended Reading

Building a Culture of Learning

Identify the Importance of a culture of learning within an organization, then build and nurture the learning culture within your organization. It is also essential to recognize that “learning” happens throughout the day and is not isolated to physical training.  Informal learning is "the unofficial, unscheduled, impromptu way people learn to do their jobs" Informal learning tends to be where most fast-changing knowledge is disseminated because formal training requires too much planning. We need to seamlessly capture learning that is already happening, allow for effortless content creation for new learnings and easy discovery.

Considerations

  • Discoverability of Knowledge
  • Encouraging Growth Mindsets
  • Identifying Learning Leverage Points within the Engineering Culture
  • Informal Learning Examples: Institutional Knowledge, documentation, paired programming, incident reports, debugging chats, ticket system & Jira solutions, questions answered during meetings
  • Incentivizing Learning & Facilitation
  • Just-in-Time/Integrated Learning
  • Reducing Knowledge Debt
  • Social Learning

Centralized or Embedded

A common challenge is determining if your Developer Education team should be centralized for engineering or embedded into individual engineering teams to provide more focused support.  You may also have the Developer Education team rotating between engineering teams based on immediate needs as engineering priorities shift.

Considerations

  • Defining a Reasonable List of DevEd Services
  • First Principle Thinking and identifying what would be in the best interest of the company.
  • Identifying Learning Value Streams

Content Creation

Typically there are two methods for Developer Education.

  1. The Developer Education Team Includes Instructional Designers, Content Builders, and Technical Writers to generate learning materials.
  2. The Developer Education Team provides guidance, conducts train-the-trainer sessions, and documents best practices for generating learning materials.

Considerations

  • Engineer Bandwidth
  • Outsourcing
  • Resource Allocation and Scaling to the Engineer Learning Demands

Recommended Reading

Cross-Functional Relationships

DevEd may have a more holistic view of the engineering organization and have documentation for solutions that span across many engineering teams.  This is why many Developer Education Teams include Technical Program Managers because collaboration and coordination across orgs to create learning solutions require program/product/project management expertise.

Considerations

  • Collaboration with the company learning teams to centralize the toolset.
  • Working with L&D or Human Resources on soft skill training targeted to engineers such as IC Growth or Engineering Leadership Training.
  • Creating training that spans multiple teams, such as migrations or building full-stack applications.

Engineering Culture Models

Every company has a unique “engineering culture” that is a subset of the company culture with its own secret sauce.  Knowing and Understanding these different methods for engineer success is beneficial to a Developer Education team.

Recommended Reading

Engineering Happiness & Retention

Developer Education should understand why Engineers leave and if there is anything that the team can do to enhance engineering quality of life and longevity.

Considerations

  • Feeling part of a vibrant engineering community. Engineers are happiest when cross-functional teaming is happening. Hackathons are a good example.
  • Being Surrounded by Genius. Engineers are happiest when they feel they are surrounded by the best in their fields, and there are knowledge transfer opportunities.

Recommended Readings

Engineer Leadership Training

Responsibility for onboarding new leaders or helping develop engineers into future leaders may also belong to the Developer Education team.  Although leadership resources are abundant, it is essential to apply them specifically to the unique challenges faced within engineering.  For example, engineering recruitment has its unique challenges, and hiring the best talent is a significant portion of a leadership role.

Considerations

  • Leading Engineers
  • Hiring a Team
  • Leading a Team
  • Building Cross-Functional Partnerships
  • Leadership Forum

Recommended Readings

Engineer Learner Engagement

Engineers lack time and need targeted learning solutions that will immediately provide benefits. Examples are using learning as a way to reduce engineering blockers to increase productivity.

Considerations

  • Attention Management
  • Engineer Persona Building
  • Engineer Career Paths and Identifying their Educational Gaps

Recommended Readings

Engineer Techniques

Developer education should understand standard engineering techniques and how they are applied within your company.  These are valuable insights to share in the engineering onboarding process as well.

Considerations

  • A/B Testing
  • Agile
  • Chaos Engineering
  • Containers/Base Images/Immutable
  • Continuous Integration/Continuous Deployment
  • Deployment Methods
  • Developer Portal
  • Monolithic vs MicroServices
  • Paved Road
  • Resilience
  • Serverless
  • Software Development Lifecycle

Recommended Reads

Global Challenges

With global companies, you face various challenges, and awareness of potential issues can help you proactively address them.

Considerations

  • Cultural Differences
  • Effective Asynchronous Communication
  • Language Barriers
  • Software Limitations (Example: Google is not available in China)
  • Translations of Learning Materials
  • Travel

Hack Days (Hackathons)

Hack Day is an engineering community-building opportunity to experiment with new ideas/technologies, engage with your colleagues, and potentially create serendipitous innovation that may result in a production product.  Hack Days help foster relationships across engineering teams, who may not ordinarily engage with each other, and create connections that may help increase future productivity. Plus, it’s fun!

Considerations

  • Event Website
  • Hack Criteria
  • Swag
  • Event Registration
  • Event Location,  Food, Photography
  • Hack Presentations
  • Hack Judging
  • Awards Ceremony
  • You can “a-thon” almost any engineering topic. Example: stack-a-thon, documentation-a-thon, bug-fix-a-thon.

Recommended Reading

5 Reasons why Hack Days are a valuable use of Company $

Hiring

Recruiting for developer education positions can be challenging since the role may be new or evolving at your company.  You will need to have a vision for the team to define the open roles. Often, we are looking for the rare unicorn who possesses a trifecta of talent, including Technical, Instructional & Leadership skills.

Considerations

  • Job Descriptions
  • Long-Term Hiring Strategies & Recruitment
  • Networking

Engineer Growth

Although Engineering growth should be a personal journey that is not forced on engineers, it is essential that there be opportunities for those who wish to expand their horizons. Examples of engineer growth opportunities would be providing an array of training opportunities and offering structured mentorship and coaching programs with skill matching. Allowing engineers to embed or rotate teams to help with their development, increase cross-training, build empathy across engineering teams and enhance teams.

Considerations

  • Classes
  • Conferences
  • Mentorship
  • Embedding/Rotating Teams

Recommended Reading

Inclusion & Diversity

Diverse teams are more robust, more effective teams at solving complex problems because having a diverse set of points of view, approaches, and skillsets will get to the best solution faster. It is vital that we provide an inclusive environment where diversity can flourish and that we apply universal design best practices in our tools so no one is excluded from delivering value.

  • Accessibility & Universal Design
  • Additive Hiring
  • Allyship
  • Cognitive Diversity and Collective Intelligence
  • Neurodiversity

Recommended Reading

Integrated Learning

Integrated learning can have multiple meanings, but as it pertains to engineering, I am referring to integrating learning opportunities into the engineers’ applications and proactively providing just-in-time resources as engineers hit potential blockers.

  • Application Walk-throughs
  • Bots for Self-Service Support
  • Embed FAQs from systems like Stack Overflow into Manual pages, Software Help and Chat Systems (Slack)
  • Informative Error messages with Built in Debugging and Links to Relevant Documentation
  • Learning Embedded in Developer Portal

Instructional Design Methods & Pedagogy

A big part of your role will either be creating a training or empowering others with the knowledge and tools they need to create training.

Considerations

  • Andragogy (adult learning)
  • Cognitive Overload - Top Engineering Training Mistake
  • Engineering Philosophies/Eponymous Laws
  • Learning Methods - ADDIE Model, Bloom’s Taxonomy, Merrill’s Principles of Instruction
  • Presentation Styles - Examples:  Ignite Talks, Lightning Decision Jams
  • SODOTO (See One, Do One, Teach One)
  • Overcoming Engineering Cognitive Biases (Example: Complexity Bias)
  • Learning from Mistakes (Post-Mortems)

Recommended Reads

Internal Communication

There are the internal communications that happen within your team, such as newsletters, a team website, slack channels, etc.… It is also likely you will be pulled in to assist engineering teams on their own communication, which may include slide decks, presentations, roadshows, etc.…  Whenever context is shared amongst engineers, it is a form of learning, and the DevEd team can provide best practices to ensure understanding and retention of information shared.

Considerations

  • Internal Team Communication (staying aligned)
  • Communication amongst Engineers (more technical)
  • Communication between Engineers and Customers (more user-friendly)
  • Increasing Context Flow
  • Reducing Action Without Context
  • Reducing Noise to Signal Ratio
  • Being Concise is Time Consuming
  • Cognitive Bias
  • Communication Consistency & Standards
  • Creating Feedback Loops
  • Retention of Communication
  • Engineers Need Shared Understanding of Engineering Contributions & the Business Value

Knowledge Management

Making engineering content discoverable and ensuring the democratizing knowledge may also fall within the DevEd scope.  You may find solutions such as Federated Search and an Internal Documentation Front Door help facilitate knowledge management.  You may also be asked to assist with documenting requirements, standards and creating tutorials on paved path solutions that span multiple engineering teams. The Developer Education team will often work closely with the technical writers and may fall under the same org umbrella.

Considerations

  • Challenges: Accuracy, Analytics, Automated Checks, Consistent tagging system system-wide, Discoverability, Gaps, Integrations, Quality, Ownership, Maintenance, Prioritizing, Standardization & Templates
  • Types of Documentation: Overview, Getting Started Guide, Tutorial, Cookbook, Concepts and Architecture, Reference Guide, Runbook, Contributor Guide, FAQ, Team Overview, OKRs, Roadmap, Proposal, Service Level Objectives, Technical Design Document, Technical Product Strategy Document.
  • Knowledge Opportunities
  • Identity Management and Access Controls on Knowledge
  • Language and/or Writing Skills/Communication Skills to pursue
  • Natural Language Processing & Automation
  • Portals, Unified Search, Landing Pages
  • Video Transcription & Searching

Recommended Reading

Learning Communities

Learning communities connect people, organizations, and systems that are eager to learn and work across boundaries in pursuit of a shared goal.  Learning communities offer tremendous value within organizations and as well as building networks externally.  I have seen learning communities benefit engineers who may be using non-paved road solutions because their needs are not prioritized over the more adopted solutions.

Considerations

  • Building & Fostering
  • Cohorts
  • Communities of Practices
  • Guild Model
  • Learning Collective
  • Skill Exchange System
  • Squads

Recommended Reading

Learning Toolkit

The term “toolkit” describes performance-driven a broad set of related activities and tools necessary to operate the Developer Education program.

Considerations

  • Collaboration Tools
  • Content Providers (Linked in Learning, O'Reilly, Pluralsight)
  • Event Registration Platform
  • Learning Experience Platform
  • Mentorship
  • Surveys
  • Newsletters
  • Project Management

Measuring Impact & Effectiveness

Measuring the impact of your learning initiatives within your organization can be challenging.

Considerations

  • Defining Impact & Effectiveness
  • Measuring Engineer Productivity
  • Kirkpatrick Model
  • Measurement Tools
  • Quantitative and qualitative analysis of participant feedback
  • Participation, Impact & Satisfaction
  • ROI
  • Survey Fatigue
  • Types of Measurements (Google Analytics for site visits to measure conversion, Newsletter conversion, LXP reports, Event Enrollment Reports, PR turnaround time, Pull request size, Work in progress, Time to open, Change Adoption Rate, Support Signals)

Recommended Readings

Mentorship & Coaching

Coaching is more performance driven, designed to improve the professional's on-the-job performance. Mentoring is more development-driven, looking not just at the professional's current job function but beyond, taking a more holistic approach to career development. Frequently companies will have mentorship programs to help develop the skills set of their engineers.  This also helps distribute institutional knowledge and builds stronger working relationships across the organization.

Considerations

  • Engagement
  • Internal/External Mentoring
  • ROI
  • Skill Exchange
  • Tools/Tracking

Recommended Readings

Onboarding Engineers

The goal is to provide engineers with the information they need to deliver value as quickly as possible.  This includes introducing them to the engineering culture, systems, processes, and tools.  Providing them with a support system through a buddy, helping them understand how they fit into the organization’s engineering ecosystem,  how the various players generate value, and introducing them to common barriers is critical to their success.  Companies have multiple strategies for onboarding their engineers, and it is fascinating to compare.

Considerations

  • Branding - Bootcamp, Flight School, etc.…
  • Cadence & Duration
  • CTO Welcoming New Hires
  • Ease of initiation, clear documentation, available support, and consistent communication.
  • Engineering Buddies
  • Engineering Culture & Techniques
  • Keeping Content Relevant & Current
  • Systems, Processes & Workflows

Recommended Readings

Personalization

Learning should be personalized based on your immediate needs, and your systems should be smart enough to make quality recommendations that result in less time searching for learning solutions.  Using Netflix as an example, if you do not immediately see content that sparks joy without scrolling, then the personalization algorithm fails.

Considerations

  • Efficiency
  • Decision Fatigue
  • Recommendation System
  • Targeted

Recommended Reading

Prioritizing

There will always be more work that can be done than is possible by the developer education team resulting in the need to prioritize initiatives based on impact efficiently.

Considerations

  • Aligning with Company Strategy & Goals
  • Business Value
  • Content Working Groups
  • Eisenhower Matrix
  • Gauge Interests (Painted door)
  • Metrics/ROI
  • Reciprocity
  • Team Capacity
  • Urgency

Recognition

Encouraging and reinforcing positive engineering behavior through some type of public acknowledgment creates intrinsic rewards, leads to increased learning engagement. You do not need to recognize the person directly, but you can realize what was made due to their learning efforts.

Considerations

  • Badging/Certificates
  • Celebrate the Small Wins
  • Email to Managers
  • Newsletter Mentions
  • Performance Review Acknowledgement
  • Multiplier Parties
  • Recognition Ceremonies

Remote vs. In-Person

As the world has moved towards remote-friendly or even remote-first opportunities for engineers, you are faced with many new challenges to ensure that the remote experience is equivalent to the in-person experience.  Colleges and universities had a head-start on this, many offering online courses for over twenty years.

Considerations

  • Physical Distance, Operational Distance & Affinity Distance
  • Challenges, Obstacles & Pitfalls
  • Blended Learning Experiences
  • Learning Tools (learning experience platforms and learning content creation tools)
  • Remote Opportunities for Casual Collisions, Spontaneous Meetings & Serendipity Knowledge Transfer

Removing Crutches

When determining if you should teach a workshop or creating a self-service learning module, consider your motivation. Are your users having challenges with your application that you feel the training could solve? Can you solve it by offering a better user experience? Avoid providing training as a crutch for a poorly designed system. Also, avoid in-person training as a means of avoiding having to create proper documentation.

Considerations

  • Intuitive Design
  • Make the implicit, explicit
  • UI/UX
  • Usability Testing

Simplicity & Automation

In order to reduce cognitive overload, how can you simplify communication and learning into digestible chunks?  Can you automate the creation of learning content? Can you integrate all your learning systems? Can you automate any manual tasks?

Considerations

  • APIs
  • Bots
  • Queries
  • Integrations
  • Micro-Learning
  • Notebooks
  • Widgets

Subject Matter Experts, Internal Trainers or Outsourced

Determining who creates and facilitates internal training will shape the goals and priorities of the Developer Education teams.

Considerations

  • Advantages of SMEs Facilitating Training - Product Experts, Homegrown Systems, Builds Empathy, Builds Community, Enhances Communication Skills, Increases Customer-First Mentality, Scalability
  • Disadvantages of SMEs Facilitating Training - Maximizing Engineer Time, Not Professional Trainers

Team Effectiveness

Specific to your DevEd team and typically the role of the leader but may also be a shared responsibility of the team.

Considerations

  • Budgeting, Resource Allocation & Hiring
  • Evangelizing Efforts and Radiate Intent
  • Forming Mission and Branding
  • Identifying Opportunities, Value Stream Mapping, Setting Priorities, and Managing Expectations based on Resources
  • Creating & Aligning Strategies, OKRs,
  • Relationship Building with Stakeholders
  • Team Member Career Ladders
  • Your System is not a Sports Team
  • Team Working Agreements (TWA)

Technology Acceptance Model (TAM)

If you want an Engineer to utilize your tool or service, they need to believe that it is valuable and not painful. For every tool, solution, or shift that the Developer Team creates training, we need to express the answers to these four questions:

  • Is the new tool genuinely useful?
  • If it is useful, how will the learner know that?
  • Is the tool easy to use?
  • If it's not easy to use, is there anything that can be done to help that?

Training Level Challenges

You may have various levels of engineers with varying areas of expertise.  Not only will you need to provide general engineering training, but you will likely need to go into the specifics of cloud, security, backend, frontend, and data. Also, you may need to have training specific to independent contributors as well as engineering leadership.

Considerations

Training for Recruitment

Another branch of developer education could be strategic partnerships with colleges and bootcamps to help increase the pool of future engineers with the skill set necessary to be successful in your organization.

Considerations

Vendor Management

You will likely purchase several SaaS subscriptions as well as contract with various service providers.  There are multiple facets of vendor management, including creating needs assessment, facilitating vendor selection, implementing vendor solutions, administering systems, ongoing vendor meetings with customer success teams, and assisting with roadmaps or paying for professional services.

Considerations

  • Creating Internal Needs Assessment
  • Vendor Evaluation & Selection
  • Facilitating Vendor Purchase (Security and Legal Vetting)
  • Implementing Vendor Solutions
  • Single Sign On
  • Integrations to Other Systems
  • Administering Systems (User Management)
  • Ongoing Vendor Meetings with Customer Success Teams
  • Assisting with Roadmaps
  • Paying for Professional Services
  • Marketing Solution Internally

Engineering Leadership Training Topics

3 min read

Training Checklist

2 min read