In an effort to reduce rework and its associated costs, many software teams have implemented test-driven development (TDD). The rationale: The earlier you catch a problem in the software development lifecycle (SDLC), the less expensive it is to fix.

The premise of TDD: You write the test before you write the code

With TDD, testing is at the forefront of people’s minds during product architecture, design and development. Software developers define upfront what and how to test. To be considered complete, what does the feature (code) need to be able to do successfully? What tests need to pass for the code to be called good?

Developers write these tests one at a time, starting with an easy case and building complexity from there, before coding the feature. This enables developers to make sure every possible scenario is covered. The feature must pass both the old and new tests before a developer commits it to the code base.

How does TDD differ from earlier development approaches?

Before TDD, developers wrote code and QA wrote tests. These functions were silos. Even within a single team, developers used varied criteria to decide when to commit code to the base. Some developers felt testing was 100 percent QA’s job. Others wanted to make sure their code worked before sending it to QA. The individual developer decided how much testing to do (or not).

This led to inconsistent quality levels coming out of development, resulting in considerable rework, which impacted schedules and budgets.

What are the benefits of adopting TDD?

TDD is less expensive than the siloed approach. Here’s why: When developers add new code to the base, the code works and doesn’t break the base.

The TDD mantra, “Keep it green,” means the test result is always green before submitting code to the base (where it impacts others). If it’s not green, the developer keeps working on the code while it’s top-of-mind until it passes the test.

The silo approach where developers toss code over the wall to QA means that coders have already moved on to new functionality when QA finds bugs. The delay in finding the bugs can have downstream consequences. Anything built later that relies on the problematic code may also need rework.

Another benefit: Tests document the code. When you read a test, you understand what the code should be doing, so you can validate that it’s working correctly.

Are there any downsides?

Some managers perceive that TDD takes longer, and they worry about how that will affect schedules for shipping new functionality.

Yes, it’s true that TDD requires extra time when building features. Software developers now have additional code (tests) to write and maintain. However, executives benefit from taking the long view. By spending a little more time on the front end of the SDLC, it’s possible to shorten the full SDLC significantly. Additionally, TDD improves the quality of software releases, which can lead to higher customer satisfaction and more revenue.

Another downside: Complex product development efforts may require writing additional proprietary frameworks to test how the product interacts with third-party tools, utilities and so forth. If you have a utility that you’ve customized in a specific way, for example, you need to create tests to make sure your product uses the utility correctly.

Common barriers to TDD adoption

The biggest barriers to adoption are engineering culture, individual developers’ preferences and the pressure to get products to market quickly.

In some organizations, TDD requires a significant shift in mindset. A change management expert can take the “temperature” of an engineering team to identify openness to TDD, areas of resistance, concerns and so forth. Sometimes, senior developers will say, “Testing is not my job. My super power is creating new stuff, and I don’t want to be slowed down by writing tests.”

Some managers balk at TDD, feeling it will slow their team’s velocity. They want a high-quality, robust product but sometimes are willing to take shortcuts to get a release out the door.

To implement TDD successfully, management cannot allow elitist and speed-at-all-costs attitudes to persist. Engineering leaders need to set the expectation that all developers—even architects—are responsible for testing and code quality. If the architect is writing production code, then the architect is writing tests. Training can help get all team members on the same page and establish the testing ground rules everyone must follow.

Some organizations also wonder how to implement TDD on legacy projects. In this situation, start with the new features. And then, when refactoring portions of the legacy code, add tests for the newly refactored segments.

What mistakes do organizations make when implementing TDD?

There are three common errors that leaders can prevent with the right planning and communication:

1. Writing sloppy test code: Software developers need to treat test code and test utilities as production-level code. The test is going to live as long as the production code, so it needs to be well-written. Taking shortcuts can come back to bite you in the future.
2. Relegating testing to junior staff members: Many organizations put newer engineers on testing and senior people on production. In TDD, the testing is as important as the coding and needs oversight by experienced developers who can spot problems quickly. As a code base grows and becomes more complex, you want someone who knows what to look for and how to organize code. New-to-career programmers don’t have the experience to do this effectively, and you can end up with a mess.
3. Allowing broken tests to stay broken: Look up The Pragmatic Programmer or read Malcolm Gladwell’s book, The Tipping Point. Both offer examples of how ignoring something bad can cascade into a bigger problem. Some teams allow tests to break and then leave them broken, sprint after sprint. The damage from this approach compounds over time, and the longer you allow this to continue, the more expensive and time consuming it is to fix.

TDD solves a human limitation

Airline pilots use preflight checklists to eliminate the possibility of overlooking or forgetting something important. TDD serves a similar purpose.

Before TDD, a developer might have tested code manually, determined it passed and submitted it to the code base. But often, there was some interaction that the developer didn’t think to test for. So, submitting the code broke the base or caused other features not to work properly.

Lines of code execute based on different situations. It doesn’t take long to reach the point where developers can’t keep in their heads all the code and all the scenarios the code is supposed to handle. If multiple people on a team are contributing to the code base, no individual can track all the ways the software interacts.

TDD runs all the tests, old and new, on any new code. Some tests have interactions with the new code; others don’t. But developers do not have to keep this information in their heads, which reduces human errors and oversights. TDD frees developers’ working memory for other important problem-solving activities.

If a test is green, developers know their code works correctly and hasn’t broken anything. These tests confirm both the old and new functionality work properly.

For more information on TDD and virtual instructor-led courses on testing, email info@developintelligence.com.

Image credits: istock.com/Eisenlohr and istock.com/jojoo64

Many enterprise organizations offer employees a catalog of software courses as part of company learning initiatives. This approach can work well for developers who want to upskill or learn adjacent technologies. But for people who are brand new to coding, it’s vital to make sure they get the right foundation. That foundation starts with understanding the difference between courses that teach languages—and courses that teach employees how to code.

Learning to program versus learning a programming language

There’s a widespread assumption that beginner level courses in programming languages are a great launch pad for learning to code in general. Unfortunately, this assumption can lead to frustrated, dissatisfied course participants.

Imagine a class called Introduction to Automobiles. Suppose the registration blurb doesn’t include a lot of detail or (as is often the case) registrants don’t read it thoroughly. Participants arrive at the first session, and some expect driving lessons. A second group thinks the course will cover the basics of auto mechanics. And a third segment wants tips for buying the right car. This analogy is uncomfortably similar to what sometimes happens in an Introduction to Python class.

Because Python is easy to learn, many view a beginning Python course as a great place to start a coding career. If the curriculum is specifically tailored for students who have never programmed before, Intro to Python can work well. However, a course with an “Introduction to ____” title will often attract distinctly separate audiences, such as:

• People who are brand new to coding and believe “Intro to Python” is equivalent to “learn to code.”
• Experienced software developers who already know one or more languages and want to add Python to their toolkit.
• Data scientists who want to leverage off-the-shelf Python packages for their analysis work. While this audience needs some rudimentary coding and Python knowledge, their main focus is using prebuilt data science tools.
• DevOps and QA engineers who want to use Python to automate tasks they’ve previously done by hand. They often are writing scripts, not programs.

These four groups have vastly different learning goals and expectations that cannot be met with one-size-fits-all software courses.

People who’ve never programmed before need a learn-to-code foundation

Many organizations choose Python to lay the foundation for coding skills. But the language itself is not the foundation. Learning to code and learning a programming language are not synonymous. This distinction is important when designing or selecting training programs for people who are brand new to software development.

“When people learn their first programming language, they also must learn how to program,” said Dave Wade-Stein, senior instructor at DevelopIntelligence, in a recent post. “Typical Intro to Python software courses do not cover coding principles. In addition to the syntax of a new language, these students need instruction on why programmers use certain constructs and how they combine those constructs to solve problems.”

Double check the curriculum for foundational elements

Learners who are completely new to coding will benefit from practicing two activities, according to Wade-Stein:

1. Breaking down a problem into a series of written steps.
2. Converting each step into Python or another programming language.

As software developers gain experience, these two activities become more automatic, and coders may do them in their head. Beginners, however, learn best by writing down all the steps of the problem they are trying to solve. This way, if their code doesn’t produce the expected result, they have a tool for troubleshooting. They learn to spot where they may have introduced errors into the process by asking questions such as:

• Have I articulated all the steps correctly and completely? A human brain might do a step so automatically that a new coder might not think to add it as a discrete step.
• Is the sequence of the steps correct? New coders need instruction and practice to execute steps in the correct order.
• Did I leave out a step? Maybe the step is on the written list, but the learner didn’t translate it into code.
• Is a mistranslation causing the problem? Perhaps the individual got the steps right, but wrote code that does not actually perform the step.

This foundational practice reduces frustration for new developers, builds confidence and speeds the learning process.

Experienced software developers, data scientists and DevOps/QA engineers, however, may not appreciate having content like this in their Intro to Python class.

Striking the right balance in software courses

To the degree possible, monitor the composition of open enrollment classes. Think carefully about the ramifications of mixing varied audiences. Ideal cohorts should have participants with similar experience levels, focusing on the use cases they’ll be working on in their jobs.

When you have beginners and experienced students in the same course, it’s hard to serve both groups effectively. Participants who lack a foundation in coding principles can get discouraged quickly, while seasoned developers become impatient, craving more challenge. In contrast, enthusiasm soars when you match learners to the right course. And when employees can apply their new learning on the job with confidence, your training investment yields better results.

Interested in learning more? Employers are taking a fresh look at their open enrollment strategies to boost ROI on training investments. For more information, email info@developintelligence.com. 

Photo credit: istock.com/robynmac

Suppose you’re contemplating a Learn-To-Code program to reskill people from non-technical backgrounds for upcoming software projects. You’re considering this approach, because you’ve scoured the landscape for computer science grads and can’t find enough qualified candidates. Tapping non-tech talent seems like a viable and intriguing option. But how do you identify employees who will thrive—or at least persevere—in an intense reskilling curriculum?

“Finding candidates who are both interested in a coding career and well-suited for it can be the most challenging part of running a reskilling program,” says Jessica Schneider, VP-Product Development at DevelopIntelligence.

You’re looking for people who have the aptitude and grit to make a radical, swift career change into software development. Learn-To-Code programs are like drinking from a fire hose. In 14 to 16 weeks, participants will be ready to write code in an entry-level developer position. They need the drive, endurance and frustration tolerance to handle a steep learning curve.

Think of a backpacking expedition with substantial elevation gain. For your trip, you want people with the motivation and commitment to reach the top, even if parts of the journey are tough.

Finding these candidates involves three distinct phases

Phase 1: Recruit

“Begin with a clear goal for the number of candidates you want to recruit, as well as minimum qualifications,” advises Allison Freedman, Implementation Program Manager with DevelopIntelligence. “Also, track the application source, so you can focus your efforts on sources that are driving the best results.”

What groups do you want to target for your Learn-To-Code program? If you’re recruiting from the outside, are you looking for people from a particular background, such as musicians? Are you aiming to increase diversity in your tech workforce? Is there a geographic requirement?

Where will you find these candidates? Through workforce development centers? University alumni offices? Recruiting websites?

If you plan to reskill internal candidates, who can apply? Some organizations ask managers to recommend potential participants. Other companies invite applications from anyone who is interested.

Most important, how will you screen for applicants’ motivations, aptitude and commitment? Asking for mini-essays can help you understand why a candidate is interested in the program. What do they hope to get out of it? Recruiters: Is the candidate’s reasoning realistic, authentic and compelling?

These applicants do not have coding experience, but you need to assess basic computer literacy. Additionally, cognitive assessments can reveal how candidates approach challenges and solve problems. Do they have the right aptitude for coding and the rigor of a Learn-To-Code program?

In this initial screening, some candidates will stand out, and you’ll want to take a more in-depth look. Others will wash out, because of low assessment scores. Or, they didn’t complete the requested steps by the assigned deadlines. If candidates don’t have the drive to meet commitments during the recruitment phase, they are not the right fit.

“If you find you’re not getting the right kind of applicant, go back to the drawing board and revise your recruiting strategy,” says Freedman.

Phase 2: Evaluate

The evaluation phase is two-way. You want to get a feel for how well the candidates are able to learn and apply new skills. And you want to give them a taste of what the program will be like.

What does it mean to “learn to code” or “learn to be a developer”? What kind of content and curriculum does a Learn-To-Code program cover? A well-designed evaluation phase helps candidates answer these questions, so they can make an informed decision about fit. Is this the right opportunity for them?

Assign basic learning material—self-paced pre-work and/or an exercise. This gives applicants a feel for what they’ll be doing and lets you see how they tackle problems. They may not get everything right, but you’ll get a sense for how they approach problem solving. As well, you need to test their knowledge retention.

If a candidate is brimming with excitement after this evaluation, that’s a great indicator of potential fit. “By successfully completing this portion of the recruiting process, they’ve also demonstrated they are committed to learning and able to follow through on deadlines,” notes Schneider.

At the end of this phase, you’ll have a short list of highly qualified candidates.

Phase 3: Select

The final leg of the recruiting journey involves a behavioral assessment and one or more interviews.

Schneider says, “You would never hire job candidates without interviewing them. The same is true for a Learn-To-Code program. You want to determine fit and commitment. Really think about the engineering culture that candidates will be going into after the reskilling program.”

Involve a variety of people in the interview process—software engineers, managers, people on the program team and at least one professional recruiter. If you get green lights from these interviewers, you likely have the right candidate for your program.

Because a Learn-To-Code program represents a dramatic career shift for many candidates, consider building in a grace period for opting out. Candidates can go through this extensive vetting process and think they understand what’s involved in the curriculum. But two weeks into the program, they realize, “This isn’t what I expected and it’s not for me.”

Accepting a spot in a Learn-To-Code program represents a big change for the candidate. While no one wants to see attrition, employers need to plan for this contingency.

Knowing there’s an option to bow out without penalty by a specific date can make the decision process easier. An opt-out provision helps reduce the fear factor and stress involved in making a career leap.

Things to keep in mind when recruiting for a Learn-To-Code program

“Allow more time than you think you need for each step in the recruiting and selection process,” advises Freedman. “Make sure to build in time to review the results of each phase with your selection committee.”

Even if you have a compressed schedule, resist the temptation to take shortcuts. You want to get the most from your reskilling investment, and this requires having the right candidates in your program. You want people who will stay with the program through graduation and become full contributors to your software projects.

Though recruiting for Learn-To-Code programs is a challenge, it becomes easier over time as you refine your process. Many employers are now utilizing this type of reskilling program to create a dependable candidate pipeline for upcoming projects.

For more information on reskilling non-technical talent for software development and IT roles, email info@developintelligence.com. 

Photo credit: istock.com/Svetlana_Mokrova

“Insourcing” may be a trending term but the concept isn’t new. Akin to “internal promotions” and “internal transfers,” it refers to selecting from current employees to fill open positions. But organizations today aren’t just focused on moving a customer service representative from one department to another. An increasing number of employers are completely reskilling internal candidates, equipping them for radical career changes. Particularly, they are preparing non-technical employees to move into software development and IT roles.

What’s fueling this insourcing and reskilling trend?

There are eight common motivations for reskilling internal candidates:

1. Solve a tech talent shortage

In many regions, the demand for software developers outpaces the supply. The competition for talent is intense, making it hard to find a pool of applicants. Organizations are looking for innovative ways to fill staffing needs.

2. Create a dependable, predictable talent pipeline

If you know you’re going to need software developers by specific dates for upcoming projects, you can launch a formal insourcing or reskilling initiative so that you have the right skill sets available at the right time.

3. Staff mission-critical projects with invested employees

Internal candidates are a known quantity. You’ve had a chance to assess their work ethic and culture fit, as well as how they communicate and collaborate. They’ve already proven their commitment to your organization’s mission and values.

4. Retain and leverage institutional knowledge

Because current employees have a history with your company, they know things that new hires won’t. They understand the customer, as well as your products and services. And they’re familiar with:

• Alternative processes
• Where documentation exists
• The history of decisions
• Who to go to with questions
• What’s been tried, what’s worked and what hasn’t worked
• Why past projects failed or succeeded

This knowledge can translate to valuable contributions on software teams.

5. Offer a new career option to employees whose roles are phasing out

Some businesses are streamlining workflows and costs by automating functions previously done by employees. Rather than lay off dedicated team members, a growing number of organizations want to provide an attractive new career path for these individuals.

6. Counter competitive threats

It’s hard to stand out when so many companies are hiring. How do you retain top talent when recruiters are contacting them to discuss higher pay or better benefits? Insourcing and reskilling initiatives can be important elements in a retention strategy—a way to differentiate yourself from other employers. For many employees, your investment in their career growth is a powerful motivator to stay aboard.

7. Infuse a software team with deeper domain knowledge

Suppose you’re building a claim software system. A claim processor who has been a long-time end user of claim-related software can bring an important lens to your project. This person understands the workflow, stakeholders and the types of problems that crop up when processing a claim. Imagine having this expertise on your team when you’re eliciting software requirements. This detailed domain knowledge also can help with spotting opportunities and flaws in the architecture and code. And you’ll get priceless input during testing and deployment.

8. Expand a team’s perspective

How do you help a software team gain a “voice of the customer” perspective if they are not in direct contact with customers? Have you considered reskilling a rockstar customer service representative for a software development role? Insourcing provides a great avenue for cross-pollinating teams. Someone from a non-technical background will think about software projects in a different way, which can lead to new ideas for features and functionality. This person can help expand a team’s knowledge and improve the products and services you are providing to your customers.

If you’re interested in exploring insourcing and reskilling in more depth, Pluralsight and DevelopIntelligence recently hosted a webinar on this topic. It’s available without charge in two formats: video and podcast. Also, check out this blog post. If you have additional questions, please reach out.

Image credit: istock.com/wildpixel

You’re contemplating something radical: reskilling non-tech employees to fill software and IT positions. But where do you begin? How do you prepare a cashier, customer service representative or claim processor to contribute on a software development team?

Don Jones, Head of Developer Skills at Pluralsight, and DevelopIntelligence VP Jessica Schneider unpacked this topic in a recent webinar. Reskilling non-tech employees can “seem a little daunting,” said Schneider. These individuals do not have computer science degrees or foundational knowledge in coding. They are changing careers completely, embarking on a brave new journey.

The planning effort for a reskilling endeavor like this “involves multiple stakeholders across many departments and is packed with moving pieces,” she noted. As a starting point, Scheider recommended this three-step foundation:

1. Begin with the end in mind

Think ahead to the end of the reskilling program—when graduates step into their new tech roles. What specific tasks will they need to be able to accomplish on their own? What will their team and manager expect them to know and do? What project will they be working on? Will they be fixing bugs? Building feature enhancements?

Getting precise, detailed answers to these questions is similar to the requirements phase of a software development project. Before you build software, you carefully articulate what the software needs to do.

Once you’ve defined the end goal for your reskilling endeavor, it’s easier to determine what technologies to cover in your program and at what depth. From there, you can begin making decisions about program length, structure and content.

2. Decide how you will select participants

Finding candidates who are both interested in a coding career and well-suited for it can be the most challenging part of a reskilling endeavor. You’ll need a recruitment strategy before you can establish a timeline for your training program.

Start with the graduate in mind. The teams who will receive these reskilling graduates can help you define the attributes and skills needed for success.

Before you can start recruiting, you need to know where the graduates will land. Applicants will want a clear picture of what they’ll be doing afterwards if they take part in the reskilling program. They need to be able to weigh the pros and cons. The more specifics you can provide about what happens after the program, the more comfortable employees will feel when deciding whether to apply.

Where are you going to find these employees? If they are coming from an internal department, what’s your strategy for getting buy-in from managers who may be reluctant to let a star performer transfer into your reskilling program? What’s your plan for filling positions left vacant by reskilling participants?

How are you going to evaluate reskilling applicants? Which candidates are likely to thrive—or at least persevere—as they climb the steep learning curve of a reskilling program?

3. Identify and engage champions

“The step that might be overlooked the most is to recruit champions within the business to support you in this initiative,” said Schneider. The ideal champion is passionate about the reskilling vision. Champions help with brainstorming, decision making and removing barriers as you move through the planning and implementation journey.

“Get support early and keep your champions engaged. They can help with internal communication, recruit mentors to support students through the program and collaborate on curriculum.”

Closing thought: Programs for reskilling non-tech employees are multi-layered

With these three elements in place—program requirements, recruiting strategy and champions—organizations can proceed with designing the actual reskilling program.

Schneider called these “multi-layer programs,” because they involve more than just technical training. In addition to building technical know-how specific to the jobs they’re destined for, participants must learn how to think like programmers.

“If you’re a cashier or work in a call center, your day-to-day interactions and the way you work is different from the way developers work on a development team,” explained Schneider. Effective reskilling programs model how to approach and solve problems, research issues, collaborate on a software team and more.

For organizations interested in reskilling non-tech employees, it’s important to have realistic expectations. “You’re not trying to create experts by the end of the program,” said Schneider. “You are preparing entry level developers. So, you want to give them the skills that they need to get started, and then the confidence they need to be successful and to continue to grow those skills as they move into their jobs.”

For more information on reskilling non-tech employees for tech roles, email info@developintelligence.com.

Image credit: istock.com/gustavofrazao

We’ve all met code hoarders and “heroes.” Like basketball players who hog the ball, hoarders work alone, reluctant to share their code, while heroes jump in at the last minute to fix other people’s code. These software developers think they’re helping, but their actions damage morale, slow down team development and limit innovation.

Pluralsight developer advocate Jeremy Morgan explored these behaviors in a recent podcast with DevelopIntelligence CEO Kelby Zorgdrager. Here are three takeaways from their conversation on how code hoarders and heroes impact teams—and how to resolve those conflicts:

1. “Heroes” might save the day in the short-term, but at a long-term cost

A software developer who dives in at the 11th hour to fix other people’s work may get credit for helping a team meet an important deadline. But swooping in like this on a regular basis has a dark side, worse than backseat driving. When “someone comes in, pushes you aside, takes over your keyboard and says, ‘Let me fix this for you…let me make it better,’ as Zorgdrager said, it can create trust issues for the team.” As a developer, you don’t really want to give up your keyboard. It’s like the steering wheel for your car.”

For the person receiving this “help,” heroing creates self-doubt. As Zorgdrager explained, it causes developers to ask themselves, “Do I really suck at writing code? Or did I not understand the problem that I’m supposed to be working on?”

As Morgan pointed out, the “hero” might feel good about his or her contribution, but other team members experience an incremental erosion of confidence.

“You know how confidence builds slowly and then starts growing like a snowball?” Morgan said. “Unfortunately, the process works the same way in reverse.”

2. Code hoarders prevent others from learning and growing

Morgan described hoarders this way: “Someone starts saying, ‘This is my code; this is my section; this is my class method; or even this is my whole entire project. Don’t touch it.”

Why is this problematic? Zorgdrager offered two vivid examples from his own career of how this dynamic plays out. At a startup where he served as interim CTO, the founder and CEO had written a fair amount of the code. “Our CEO still wanted to write code, as well as control and dictate the direction of the architecture and code we were building.”

“In the first six months, we probably lost half of our engineering team,” said Zorgdrager. “The founder wouldn’t get his fingers out of the cookie jar. It was a very negative experience.”

The second company, a telecommunications giant, had engineers who had been there 30 years and weren’t interested in sharing code with new hires. “This was frustrating,” he recalled, “because as a younger person working in the tech field, you want to create something cool. The more senior engineers didn’t want to share the ‘secret sauce,’ limiting innovation.”

3. Both code hoarders and heroes need to understand their effect on others

Because these behaviors damage team development and morale, coworkers and managers need to speak up. Instead of saying, “Jeremy, quit hoarding your code,” Zorgdrager recommends focusing on how the behavior affects team members. How does it make people feel? What’s the impact on others’ ability to do their jobs? “This approach leads to a more productive conversation than saying, ‘Hey, you shouldn’t do this.’”

Ideally, a meeting like this would happen face-to-face. With so many people working from home due to COVID restrictions, however, this may not be feasible.

“In the remote environment, we too often use Slack or email for a conversation that should be in-person or over the phone,” said Zorgdrager. If the topic is sensitive, with a potential for conflict, misunderstanding or hard feelings, you ideally want to be able to see body language. Without this, you are missing an important component of the dialogue.

Zoom isn’t perfect, but a private Zoom meeting is certainly better than making snarky comments in public Slack channels.

Code hoarders and heroes are two of the profiles described in the free e-book 20 patterns to watch for in your engineering team. Check it out and take an honest look at your engineers. Are certain well-intentioned behaviors sabotaging your digital transformation efforts?

Image credit: istock.com/gorodenkoff

DevelopIntelligence recently hosted a L&D Roundtable to explore tech onboarding best practices. One of the takeaways? Effective onboarding programs for software developers and IT professionals have eight key elements, shown in the illustration below. Four of the elements take place sequentially. The other four span the entire onboarding process and beyond:

These tech onboarding best practices help achieve two overarching goals:

1. Boost retention by accelerating personal, cultural, role and team assimilation.
2. Ensure engineering excellence from new hires.

Take stock of each area. Does your organization have a well-developed plan for all eight elements?

Element 1: Company overview

Often orchestrated by HR, the overview helps new hires understand your organization’s reason for being. Who are your customers? How do you add value for them? What is your company culture, and how do your cultural tenets play out on a day-to-day basis? What are your behavioral expectations?

Your goal: To show new hires the big picture—the vision of the “cathedral” they’ll be building. When done well, this portion of the onboarding process helps employees see that they are more than “bricklayers.”

Element 2: Technology immersion

Though it’s counterintuitive, sometimes you need to go slow in order to go fast. “Managers want their folks to start working. And engineers want to get their hands dirty, not sit in a classroom,” says Jennifer Silbermann of VMware. That said, software developers and IT professionals need a formal introduction to your company-specific terminology, technologies, workflows, business processes and tools. In the absence of this nuanced information, they may act based on their historical knowledge—what they’ve learned at other companies and in other industries. This can lead to on-the-job mistakes and expensive rework.

Technology immersion introduces employees to the actual type of work they will be doing for your organization. Ideally, it allows them to practice in a no-risk or low-risk way, where they can learn from mistakes before jumping into live projects. You want new hires to become comfortable with your tools, tech and use cases before they start tinkering with your code.

Of the tech onboarding best practices, this element tends to require the most time and resources. However, it enables employees to become productive more quickly. Both short and long term, this can save you money and headaches. It also helps employees feel more confident as they step into their new roles.

Element 3: Team integration

New hires need a clear understanding of who-does-what on their team. Who will they interact with on a day-to-day basis and how? Who is the best resource for particular topics if the employee has questions? The best onboarding programs include opportunities for formal introductions, job shadowing and/or peer mentoring, so that new hires feel like a valued part of the team from the outset.

Element 4: Ongoing education

After the formal onboarding program is complete, new hires will still be on a learning curve. They benefit from ongoing opportunities to build their knowledge and skills, as well as encouragement to engage in continuous learning. Offering expansive education resources shows new hires that you care about their career growth, which improves retention.

Element 5: Culture modeling

Emphasize what you want employees to “bake” into their day-to-day thinking. For example, do you want them to “step into the customer’s shoes” in every decision? How and when do you want them to think about cybersecurity? And how do you help them practice this thinking so it becomes second nature?

If you want employees to embody a particular mindset, then executives, managers and team members need to model this mindset in their day-to-day actions. New hires will emulate what they see others doing. If your formal policies say one thing but your leadership is doing something else, your new hires likely will adopt the “something else.”

Organizations with the best onboarding practices tend to place a high cultural value on continuous learning. “It’s a brilliant catalyst when leaders are passionate about learning,” says Silbermann. “If I see my leaders making time and it’s a priority, I feel safe to make it a priority for myself.”

Element 6: Relationship-building activities

Tech onboarding best practices include activities that foster an immediate sense of community. Research shows that having a “best friend” at work can improve retention, employee engagement, productivity and other measures. Partner-based learning or a buddy system enables new hires to cultivate peer relationships quickly. The employees compare notes and learn from each other.

Element 7: Frequent check-ins 

Designate a manager or mentor to check in with a new hire every day for the first week or two. As employees become more settled in their roles, managers can let more time pass between check-ins—but rarely more than a week. Software developers and IT professionals need a regular opportunity to connect with their managers. These one-on-one meetings give employees a chance to ask questions, express concerns, share ideas and get feedback on projects. It’s a chance for a manager to acknowledge work well done and provide coaching where needed. New hires need to know what they are doing right so they can do more of it. Conversely, they need timely guidance on what they can improve, so they can modify an ineffective approach.

Element 8: Results measurement

Measure effectiveness in several ways and from several perspectives. Learner satisfaction. Knowledge gain. Reduction in job errors. Time to full productivity. Employee engagement. Retention.

Find out from hiring managers whether their newly onboarded tech employees are able to jump right into projects. If not, where are the gaps?

“Actively engage new hires in the betterment of the program,” advises Michael Kohanfars of Salesforce. “Find out from them what worked and didn’t work. Ask what they used and didn’t use.”

Tracking your results enables you to demonstrate the ROI of your formal onboarding initiatives. Further, these measures show where you can fine tune your program to make it even more effective.

Again, the goals of tech onboarding best practices include boosting retention and ensuring engineering excellence.

“Coming to a new company is hard…learning the right terminology and who to talk to…The investment you put into an onboarding program will make people feel taken care of and valued,” says Kohanfars. “It also helps the teams they’re going into feel less burdened.”

Don’t try to “boil the ocean,” though, advises Silbermann. When she first stepped into her role, she “tried to put too much” into her onboarding programs. “Talk to your audience and make sure you get to what’s important and what’s effective.”

Start with tightly-scoped onboarding initiatives to solve well-defined needs. Once you’ve implemented those and started measuring results, you can adjust your program from there—adding on as you have time and resources.

Interested in learning more? For additional information on how enterprise organizations are onboarding software developers and IT professionals, contact info@developintelligence.com. 

When employees need new tech skills to support a significant digital transformation, does your organization gravitate toward self-paced learning options? Videos. Interactive online content. Reading. Assessments and so forth. If yes, how are you ensuring that all these resources create a cohesive learning experience? What steps are you taking to confirm that every employee can translate what they learned through self-study into their day-to-day work?

Organizations pursuing digital transformations are realizing they can’t afford to take chances. They need to make sure every employee can hit the ground running on mission-critical endeavors. Toward this end, many companies are augmenting their self-paced learning with more comprehensive opportunities for application and feedback.

Why do organizations opt for self-paced learning?

Self-paced resources are tremendously valuable for accommodating the needs of a diverse, multi-location workforce across time zones. People have different learning preferences and they learn at different speeds. Having self-paced options available 24/7 allows employees to learn new tech skills on their own schedule, from anywhere in the world.

Additionally, some organizations pursue self-paced programs in response to resource constraints. For example, managers may not be able to give employees dedicated time for instructor-led training, due to project deadlines. Or they may perceive the cost of instructor-led training to be prohibitive.

However, when supporting large-scale transformations, you can increase the return on a self-paced investment exponentially by adding instructor or mentor reinforcement.

Ways to connect asynchronous learning to current projects

While some employees find it easy to apply new tech skills to their projects at work, others don’t. Or worse, they think they’re ready, but they have knowledge gaps that lead to on-the-job mistakes. Simulations, exercises, labs and other hands-on opportunities, coupled with personalized guidance from an expert, can help reinforce self-paced learning. If someone has a knowledge gap or misunderstands a concept, the expert can spot that and provide support.

Personalized guidance can take many forms: A mentor within the organization. A peer with more experience. Virtual office hours with a subject matter expert. Job shadowing. Sometimes, the best option is an outside instructor, since this maximizes the amount of time internal SMEs can devote to their own project work.

The best support includes these five elements:

1. A safe setting to ask questions. Employees can ask any question without fear of ridicule from peers or others.
2. Ways to practice that weave multiple concepts together. Learners need to be able to try out their new skills in ways that mirror the specific technical work they’ll be doing on the job.
3. Opportunities to fail without adverse consequences. Sometimes, the best learning comes from making mistakes and examining what went wrong.
4. Individualized feedback. Employees want specific input on what they are doing well and what needs adjustment. This nuanced feedback helps them hone their new tech skills, equipping them to perform better at work.
5. A chance to collaborate with peers. People learn by working together, exchanging knowledge and batting around ideas. One employee may be an expert in an area where another is a beginner, and vice versa. They can learn from each other by pairing up on projects and taking part in discussion forums.

Building new tech skills: the right type and amount of support differs by learning objective

Employers vary their support depending on the goals of the asynchronous learning program and the type of learner. For example, a new-to-the-workforce employee needs more guidance. So does a person who is making a career change from a non-technical field into software development.

Generally, the more time-sensitive and mission-critical a project is, the more support an organization should provide to reinforce self-paced learning. Engineering managers and CIOs want error-free performance, not people who are learning by trial and error on vital projects.

Instructor support in action

Converting instructor-led programs into self-paced sessions with support can take many forms. The two sample designs below rely primarily on self-paced learning, while including a touchpoint with participants at least once per week. The touchpoint can be a webinar, office hours or group projects that allow participants to collaborate with each other.

Employees work together on exercises that mimic their organization’s specific projects, receiving valuable guidance from an expert. A capstone project demonstrates readiness to transition from practice to on-the-job application. In both models below, participants have access to expert practitioners, yet are learning at their own pace, on their own schedule.

Design 1: Learn to Code Reskilling Program

How do you convert an immersive, bootcamp experience into a virtual, self-paced program? Carefully select online content and spread the topics over a longer period of time, augmented with weekly instructor check-ins. In this model, participants work consistently over time to acquire, practice and apply their new knowledge.

These two sample designs are variations on a theme. Both reinforce self-paced skill acquisition by infusing instructor support at key points in the learning process. The main difference is program length.

Reinforcement helps learning stick

Programs such as the two examples above enable companies to maintain the majority of their training in a self-paced format. But they leverage instructors to pull the learning together and provide feedback to students, improving the overall course effectiveness. This human touch helps boost mastery, and most importantly, it ensures employees can perform the work you need them to accomplish. In the end, instructor or mentor support protects your training and technical investments, improving ROI for both.

If you’re interested in hearing how other organizations are weaving in support for asynchronous learning, email info@developintelligence.com.

About the author

Jessica Schneider, VP, and her team at DevelopIntelligence design Reinforced Self-Paced Learning programs for Fortune 500 companies. 

Photo credit: istock.com/fizkes