The Actors in Training Development: Learning Designer

Article: The Actors in Training Development: Learning Designer

Human brains are amazing things. They’re power-hungry biological machines that consume 20 to 30 percent of the blood’s glucose while being only two to three percent of the overall mass of the body. As complex engines for our cognition, it’s no surprise that we need people who are specifically focused on the tuning of these powerful engines. Those specialists are learning designers, also called instructional designers. These brain mechanics have a set of tools in their internal toolbox that allows them to identify how to improve the brain’s performance in new and novel areas.

This series on the actors in training development explores how the various roles in the training development process work together to create training that reduces the effort it takes for a student to learn a new skill. The learning designer is the central actor in making a subject easier to learn.

What Is a Learning Designer?

A learning designer is someone who uses his or her knowledge of how brains work and how people work to make the learning process easier. Learning designers turn the leaps from one topic to the next into small steps that anyone can easily take. Their job is often to reduce the cognitive load on the student by sequencing topics, simplification and elimination of extraneous information.

Part of the TrainingIndustry.com series, The Actors in Training Development. Read more…

The Actors in Training Development: Subject Matter Expert

Article: The Actors in Training Development: Subject Matter Expert

Since we don’t have the ability to read minds, enabling us to learn quickly from experts, we must settle for subject matter experts (SMEs), who can help us understand what employees need to learn to reach the desired outcomes and how to sequence that training effectively.

Among the actors in training development, the subject matter expert is second in importance only to the business owner, who provides the funding for the process. If you don’t have a subject matter expert available for your training development project, the project team is not complete, and it’s incumbent on the team to select someone to become the SME through self-education, to hire or contract with an SME, or to purchase content in which the SME expertise is already “baked in.”

Content produced without the benefit of a strong SME feels bland and unremarkable. It’s the result of a system designed to turn any starting content into training, but without the SME, the raw materials can’t make truly great training.

Part of the TrainingIndustry.com series, The Actors in Training Development. Read more…

The Actors in Training Development: Business Owners

Article: The Actors in Training Development: Business Owners

Any training process starts with a business need. That is, someone in the business wants or needs their employees to be more productive than they currently are and looks to training or a job aid to generate that productivity. The business owner is that person, who starts the process of improving productivity.

In this series on the actors in training development, we’re walking through the roles in the process and why they’re important. Ultimately, training services the needs of a business. Training needs a champion, and that champion has to own the development of training by providing funding, gentle guidance and sometimes a swift kick to keep it moving. The business owner role is the genesis of the training project and the person with whom we start.

What Is a Business Owner?

Literally, a “business owner” can be the owner of a business, but in the training development process, the business owner is the person who is responsible for the need and who typically has the budget to support the development of training. They ultimately set the goals and decide whether the progress made with the training meets the goals they set. As the final arbiter of what they want and believe they need, they’re the ultimate customer, but likely not the ultimate consumer, of the training.

Part of the TrainingIndustry.com series, the Actors in Training Development. Read more…

trainer

Article: The Actors in Training Development

There’s a lot of attention on new delivery models, the desire to create shorter courses and the attempt to apply metrics to the training process. However, relatively little is being said about the fundamentals of the content development process. While there are absolutely differences in the way content is generated from one medium to another and from one organization to another, there are more similarities than there are differences. This article is the first in a series that will walk through the roles in the process, including how the process fits together and how the individual roles add to the result.

What is Training Development?

Training development refers to the creation of a training course or program designed to address a skill or cultural need. It’s development and not creation because, in some cases, the development of the training program will involve sourcing rather than creating. Sometimes, it will mean sourcing raw materials and customizing them to meet the specific organizational needs.

It’s always best to start with a search for off-the-shelf training. Much like how software developers often start coding before looking for existing tools and resources, training professionals often know they can create the training themselves. However, in many cases, that’s not what’s best for the consumer.

The start of the TrainingIndustry.com series, the Actors in Training Development. Read more…

deploy-devops

Article: Anatomy of a Software Development Role: DevOps

It’s been nearly a dozen years since I first wrote “Cracking the Code: Breaking Down the Software Development Roles” and the associated specific role articles. The world has changed substantially in the last dozen years, but strangely, relatively little has changed in the roles for software development—except in the transformation of the deployment role into what is now being called “DevOps”—a contraction of Development-Operations. In short, we’ve changed how we operationalize the deployment of our code into our environments and into customer systems. It’s time to address the changes that have come to the world of software deployment.

Part of the developer.com series, Anatomy of a Software Development Role. Read more…

Developer Productivity: Managing Cycle Times in Iterative Development

Article: Developer Productivity: Managing Cycle Times in Iterative Development

Thus far in the series, we’ve focused on managing productivity at an individual developer level. However, sometimes developer productivity results from the best management of the developers and the rest of the team. Measuring individual developer productivity is convenient because it tells you how well a single developer is performing. However, even the best developers can perform poorly when they’re put into a cadence that doesn’t work for the project or the organization. Here we’ll look at iterations, and how quickly we cycle can make a big difference.

Iterative Development

It’s important to realize that even waterfall development was initially designed to be iterative. The idea wasn’t that you’d do something once and then never work on it again. However, if you have project managers on the team, for example, who are used to building a bridge, some of their experiences might get brought along. When building a bridge, it has to be built right and built just the one time. Thus, very early on, projects were pushed into one iteration and long cycles of design, development, testing, and release.

The agile movement has revived the need for iteration, and focuses on quick turns of innovation. Whether your iteration is a week, two weeks, or a month, this is a substantially faster iteration pattern than the monolithic waterfall projects from the distant past.

A Lesson from Manufacturing

It’s no secret that American car manufacturing got its clock cleaned in the 1980s and 1990s by the Japanese. Much has been made of the Toyota Production System—what is now most frequently called “lean manufacturing.” One of the often-overlooked components of the system was the ability to change over from manufacturing one item to another very quickly.

Part of the developer.com series, Developer Productivity. Read more…

projmanager

Article: Developer Productivity: Ensuring Productive Meetings

If you work in an organization, you’ve experienced bad meetings. These soul-sucking, time-crushing meetings leave you deflated and wondering if you’ll ever be able to get anything done. Learning how to make sure that developers are only in the meetings they need to be in—and that the meetings that they’re in are productive—is a key way to maintain developer productivity.

It really doesn’t matter whether you’re using an agile software development methodology, waterfall, or a blending of the two that you call something like “Agile-Fall.” In truth, the meetings that you experience as a developer share common characteristics no matter what the methodology. Let’s look at agile meetings first.

Agile Meeting Types

Developers working in agile projects typically experience four basic kinds of meetings. The daily standup meeting is the most frequent, and therefore potentially the most time-consuming. The backlog, or estimating meeting, occurs each sprint or iteration so that developers can estimate the effort for each task and determine dependencies. Show and tell meetings occur each sprint to help demonstrate what’s working. These meetings are primarily designed for the clients, but often developers are asked to join to “show off” their features. The other meetings are “traditional” meetings, which may include organizational meetings as well as requirements-gathering meetings that developers get pulled into.

Standup Meetings

Everyone is supposed to stand up to keep the meeting short. Three questions are designed to elicit commitment and create opportunities for support.

Part of the series on developer.com, Developer Productivity. Read more…

flow

Article: Developer Productivity: Eliminating Distractions and Finding Flow

Every new development tool promises improved productivity. New languages promise better developer productivity; but, sometimes, the key factors for developer productivity aren’t the tools, the computer, or even the additional monitors. Sometimes, the keys to allowing developers to get more done are psychological factors that we’ve known about for decades.

Deliberate Distractions

In our world, we’re constantly interrupted. Our phone goes off with that latest alert from ESPN. It’s constantly vibrating from the stream of incoming messages, chirping from the latest text with our friends, and more. We ignore the phone vibrations from emails because Outlook conveniently pops up a toast notification telling us about the latest message. It’s stacked full of messages from the corporate HR department telling us about something we don’t care about, the thread of inane comments, and the SPAM that has become a part of our daily lives. More toast from our instant messaging tools pop up with notifications when our colleagues and friends become available.

Many developers feel the need to keep a social media feed open so they don’t miss out on something important. Whether it’s Twitter, Facebook, or something more business-related like Slack, we’re concerned that we’ll miss out on something important if we’re not connected. These channels generate more distractions.

Part of the series on developer.com, Developer Productivity. Read more…

 

trainer

Article: Ten Technical Trainer Interview Questions You Should Know

At the tail end of the process, the criticality of training and user assistance is often lost.  The role is often underfunded and overworked – but intensely valuable to making the software work for the users.  The Anatomy of a Software Development Role: Training shows how the role brings the development home to the users.

From the developer.com series, Top Ten Interview Questions. Read more…

deploy-devops

Article: Ten Deployment/DevOps Interview Questions You Should Know

Bridging the gap between development and the infrastructure teams is the deployment specialist.  These days the job is often titled DevOps specialist, indicating how these two worlds are being merged.  You can see how this role started in Anatomy of a Software Development Role: Deployment.

From the developer.com series, Top Ten Interview Questions. Read more…