|For novel ideas about building embedded systems (both hardware and firmware), join the 40,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
By Jack Ganssle
Treat Them Well
I recently worked with a company embarking on a big firmware project, one whose success was critical to the company's future viability. They're fortunate in having a dedicated group of smart engineers, nearly all of whom had been with the outfit for many years. Though the developers were supportive of the new effort, most were wary, concerned about the intense pressure associated with such an important and high-visibility project. Worse, management historically treated software as a necessary evil, not as a core component of their product. The firmware team got little respect and was usually blamed for schedule slippages.
Over a couple of days of discussion we hashed out a development process, tools, designs, schedules and more. The bosses saw a clear path to success and were happy. Team leads were raring to go.
The developers were still wary.
New techniques and tools weren't enough to overcome an ingrained culture that treated the engineers as second-class citizens. Without an intellectual - and more importantly, an emotional - commitment from the developers, there's no chance of succeeding in any aggressive product design. Treat engineers like unimportant cogs in a giant software factory and they'll respond like robotic automatons mindlessly slogging through the day's grind. Maybe an assembly line populated by dispirited laborers works when cranking out widgets, but programmers must be entirely engaged - mind and soul - to produce great products.
Management's primary role in any company is to help people be productive. They must devise ways to get the team excited, committed, and generally gung-ho about projects. Yet in far too many organizations the bosses confuse paperwork and meetings with managing people.
Apple Computer understood this in their early years. Music, rec areas, free sodas and a sense of fun pervaded the company. Software engineers really didn't want to go home. They were treated like kings and performed brilliantly as a result.
So I made some suggestions. After layering on process, tools and techniques pour on a coating of caring. Have the big big boss meet with the team and wax poetic how important these people are to the project and the company.
Give the team special status: comp time, free meals, provide pizza on weekends (not from the cafeteria but delivered from the best place in town), flex time, maybe hot new computers. The idea is to elevate them in their minds, and by implication in the minds of the rest of the company, to a special level.
Call the effort a skunkworks project. People like to feel special. Issue them special badges for the duration of the project. People like to be part of an "in" group.
Do unexpected things for the team. If an engineer is working late, once in a while deliver flowers to his wife with a note of appreciation from the big boss. Surprise the developers with little tokens of appreciation for extra effort.
The big boss can paint a picture - in positive terms - of the importance of the project to the rest of the company. That will, or course, create a little peer pressure to help motivate the team. Negative motivation, like "if this fails we're doomed" does not work.
Do these ideas seem silly or sophomoric? Perhaps, but in my experience it's the little things that get engineers wired about their work. Motivating engineers is one of the hardest of all management challenges, yet the one that provides the greatest benefits to producing awesome products on time.
Engineers are quick to see through the disingenuous. Authentic appreciation, demonstrated often, is a powerful force. The costs are amazingly low. The benefits stunning.
What do you think? How important is feel appreciated to getting good products out the door?