Culture Shock: Agile and Individual Engineering Accountability

May 24, 2019 Chad Jackson

An engineer's prime responsibility has traditionally been to design products for form, fit, and function. It's worked just fine, or well enough, up to this point, right? Well, that depends on how you look at it. A substantial percentage of organizations today report missed deadlines, delayed projects, or canceled projects altogether.

Products are changing, and this brings new challenges to the industry. They're becoming less mechanized and more computerized. Traditional hardware is taking a backseat, and more electronics are coming in. With products becoming more complicated, engineers have to find new ways to deliver high-quality items within shorter timespans. Agile methodologies are one way to do that. One defining characteristic of Agile is the distribution of tasks from one day to the next, and the allocation of resources. There is a shift away from an emphasis on individual responsibility, and that's what we will discuss in this post.

The Traditional Approach to Hardware Design

The engineering industry has always been one of high personal accountability. For instance, engineers have their signatures on drawings and blueprints to signify their approval of the designs. If something goes wrong, the organization knows where to go for troubleshooting. The engineer in question can defend their decision.

But this enduring culture of accountability is beginning to shift. It's another consequence of products becoming smarter and more connected. With the increase of electrical hardware and software in these items, lead engineers work with specialized engineers to look at design alternatives. There is a lot more collaboration involved with products of this complexity. Few engineers have the expertise in mechanical, electrical, and software disciplines necessary to make design decisions autonomously.

Increased collaboration isn't just happening between engineers. These engineers have an opportunity to collaborate with non-engineering stakeholders throughout the development process. There is far more to consider than the functionality of the product only. Things like pricing, manufacturability, and service procedures must be taken into account as well. Although these factors lie outside the engineering domain, they do influence the product design. All of these parts must come together to create the best possible device.

In the past, engineers were responsible for taking on much more responsibility alone. When an engineer signed off on a drawing, their reputation was on the line. If things didn't go as planned, managers and executives would come to that individual, which led to a lot of conservative design decisions. No one wanted to take the blame for a faulty product. Instead of trying for something more innovative, it was better to play it safe.

The Agile Approach to Hardware Design

Engineering executives know that the project management approaches they've used in the past for mechanically-oriented will not be efficient for smart, connected products. They need a development process with more speed and flexibility. There needs to be an increased team effort. Agile focuses on increased collaboration to complete tasks in a shorter amount of time.

Agile is an approach to project management that was initially geared towards software development but has been making its way into hardware development more and more. It ignores the "one person for one job" mindset and focuses more on a team-based approach. It also shifts away from documentation in general and aims for more face-to-face interaction.

With this increasing collaboration, today's engineers have new responsibilities. Their roles require more soft skills, including social skills and habits that effectively influence others. In the agile approach, no one "owns" any part of the design because everything is a collaborative effort. In Agile, there are periods called sprints (usually two weeks) where everyone works to complete an established set of goals. Scrum is the framework for this process. The Scrum Master is someone who's in charge of assigning tasks, deadlines, and who works on what.

In Scrum, one person might be assigned to work on one part of a product one day and then assigned something different the next day. Daily meetings review finished tasks and what is still incomplete. If one assignment requires more attention, the Scrum Master can redistribute resources.  Although there is less individual accountability, there is still accountability as a team.

This new approach allows for greater flexibility, adaptability, and speed. It's much easier to redistribute work if needed. The Agile system takes up less time and enables teams to perform more frequent checks throughout the product development process. It's useful not just for the engineers, but for the clients as well. More frequent checks mean keeping the client in the loop with new changes. Instead of waiting until the last minute to change direction, engineers can receive feedback and make adjustments early on. When different people rotate through various assignments, it leaves room for new perspectives and ideas. A fresh set of eyes can offer a different solution or catch a mistake that no one else did.

Summary

As products continue to change, so do the jobs of engineers. Companies must find new ways to stay ahead of the competition, and this means changing the development process. Assigning one task to one person may have made sense in the past, but it's no longer sustainable. Organizations need to be able to adapt quickly and demonstrate flexibility. This collaboration component of Agile can assist in making product development more efficient.

About the Author

Chad Jackson

Chad Jackson is an analyst, researcher and blogger providing insights on technologies used to enable engineers. As a prolific writer, he has published educational thought leadership topics hundreds of times. As a sought-after speaker, he has presented dozens of times both domestically and internationally. As an astute researcher, he has surveyed thousands of engineering organization.

More Content by Chad Jackson
Previous Article
Hardware and Software Co-Exist Due to Model-Based Software Development
Hardware and Software Co-Exist Due to Model-Based Software Development

Waiting months for a prototype IC or board system to develop software code simply no longer works. In this ...

Next Article
Implications of Embedded Software Everywhere
Implications of Embedded Software Everywhere

In this post, we explore the demand for smart product features and how they drive demand for ICs.