It can often be a struggle to align engineering talent and resources with an organization’s overarching business goals. Let’s use this scenario, for example, to demonstrate how a lack of alignment becomes problematic:
- One of your engineers spends 6 weeks working on a new design revision. During the design review, the team finds out he was building for USB, but your customer is only using RS-485. Because of this, the engineer now has to completely start the design over, setting everyone back 6 weeks. The customer is not pleased.
- Internally, there are consequences as well. There is an additional 2-week delay for teams other than your own, such as firmware and mechanical engineering. They also have to go back and modify their designs to match the new RS-485 spec from the USB that they had been working off of until the miscommunication was discovered during the design review.
Compare that with this drastically different scenario:
- The same engineer logs into their work home base and sees his tasks for the day and an overview of the entire week. He notices that there have been new customer requests and checks the attached specs to see a USB requirement. His manager has entered this information into the ticket that the engineer is now working on. The design takes 4 weeks to complete. During the design review, there are no unpleasant surprises. Rather than the design review setting everyone into crisis mode, it is now a calmer form of due diligence. All of the issues have been addressed through daily and weekly tasks, with everyone on board along the way.
What are some of the principles for alignment?
A simple miscommunication or lost update can cause a domino effect that spreads across huge portions of an organization and its stakeholders within multiple teams. Its impact can throw business goals off the rails; stalling new projects, delaying other customer orders, and frustrating employees. Alignment is far more than a buzzword – taking these steps to keep everyone on the same page is well worth the effort.
Granting visibility
Secondary stakeholders are important in the design review process. As are firmware teams. Make it easy for these coworkers to see your designs. By granting them visibility into the design process, people gain an understanding of what to prepare for down the road, as well as catching problems at the intersections earlier on.
Keeping clear paths
You shouldn’t assume everyone always knows what they should be working on at any given time. If your team has a clearer scope of the work, this will help prevent confusion. Use the functionality of issues, tickets, or some clear structure in your digital designs. This will strengthen your project management skills. Label issues by priority level – 1, 2, 3 or by urgency – High, Medium, Low, for example.
Minimizing reporting
Effective reporting is based on the quality of the reports, not the quantity of them. Minimize the amount of time engineers spend updating tickets. Beyond the excess time this takes, is everyone working on and resolving these tickets? Even if this is the case, chances are that this ranks last on the list of your team’s favorite tasks.
Breaking down your overhead into smaller chunks
If your engineers were able to capture everything in real-time, each issue that arises can be worked on in smaller pieces. Instead of spending 2 weeks every 2 months on paperwork alone, build a process where engineers spend an average of 2 extra minutes each day.
Many engineers prefer this over having to resolve a massive amount of tickets that have built up over the previous several months. This also allows for continuous testing and feedback instead of a hastened design review at the end.
