BLOG

Best Practices for Communication Between Technical Groups

  •  

Working with others is easy for some, difficult for others.  Engineers, in particular, often have a difficult time communicating clearly.  For many firms, the end goal (a finished product) isn’t finished until many, many engineers get their hands on the design.  Naturally, in the corporate world, this mandates that teams of technical gurus are created under the glorious umbrella of hierarchical chain of command.

Aside:  The standard corporate structure is assessed and subsequently destroyed by Paul Graham here.

How these groups of engineers interact with one another has a direct impact on the success of the design.  Schedules are either hit or missed.  Product features are achieved or abandoned.  New design techniques are developed or left by the wayside.  Companies that smoothly navigate the group to group design flow are the most successful in driving products to market quickly and efficiently.

So, what can engineers and managers do to avoid the usual pitfalls and ensure an efficient, clean design process?

1. Play Nice!
This seems so simple, but it can be difficult for some under pressure and stress.  In my experience, most people are friendly and polite within their own teams.  It’s the communication with other teams that becomes strained.  Most often – and this is a theme throughout this blog – the nasty attitudes occur when teams blame one another for mistakes and schedule slips.

The solution is as simple as the problem:  Be honest and direct with a nice attitude when working with other teams.  It goes a long way, particularly when upper management is deciding which teams should be around for the next project.  A history of working well together is good for everyone involved.

2. Honesty is the Best Policy
Front-line managers will rarely accept blame on their teams when designs go awry.  Protecting the team’s best interest is part of the job description for managers.  But, as updates filter up and down the chain of command, rumors swirl, and engineers doing the lion’s share of the technical work naturally get nervous.  The defensive tactics of front-line managers, coupled with inefficient (borderline faulty) communication between managers and executives, indirectly leads to angst between the engineering groups.  Needless to say, this is toxic.

The lifeblood of the company depends squarely on products getting out the door.  When groups don’t trust each other, work suffers.  The solution to this depends on two groups:  the front-line managers and the upper management to which they report.

It is imperative that honesty – even the bad news – is demanded up the chain of command.  For VP’s who know their stuff, this isn’t as big an issue.  Their “BS” meters go nuts when managers are less than truthful.  Nevertheless, the company will never iteratively improve it’s design flow if the problems are not clearly reported.  Promoting from within and maintaining a low-level of management turnover really helps here.

3. What Time is it Over There?
There are definitely advantages to having multiple engineering sites.  Most importantly, you tap different talent bases around the world.  Other advantages include reducing cost in less expensive regions, new business relationships to foster, and getting access to the world’s top research universities.  For these reasons, it is inevitable that large firms will distribute their technical expertise all over the world.  Further, modern networking techniques can make 3000 miles seem like a few feet.

However, there is no substitute for working in the same office with others.  There is nothing easier than walking over to someone’s cube and drawing on a whiteboard to solve complex issues.  Email and conference calls are decidedly less effective.  Time differences can cause massive headaches communicating between sites as well.  For these reasons, it is much better to keep entire design cycles in the same building.  Teams learn what is needed from each other to get things done.  Most importantly, though, is the sense of camaraderie that the engineers share in the same building.  Everyone feels like they’re in the same boat, fighting the same fight.  This will absolutely reduce schedule slips and design mistakes.

4. Handoff that Pigskin!
Allow me to digress with a brief football analogy.  Let’s consider a very simple football play:  the quarterback hands the ball to the running back for a rush up the middle.  For this play to occur without a hitch, the quarterback must successfully hand the ball to the running back without dropping the ball, and without the running back breaking stride.  From the earliest of pee-wee football leagues, it is taught that the quarterback is responsible for securely placing the ball where it needs to go.  In other words, the person handing off the responsibility to the next must make sure everything is perfect, where it needs to be.

That’s not to say the person receiving the ball does not have responsibilities.  Football strategics have preached a “design flow” for these plays.  The running back must have his shoulders even with his knees, his inside arm at his shoulder level parallel to the ground, and his outside arm below this at his mid-section – this forms a perfect pocket for which the handoff can occur.  If the running back does not have this pocket well-defined, the handoff will be a failure.  If the quarterback doesn’t put the ball where it needs to be, the handoff will be a failure.  And remember, this is just the start of the play.  The running back has to worry about 300-lb defenders ready to tackle him to the ground the second he receives that football.  If the handoff is unsuccessful, the play is dead before it even got started.

It should be semi-clear how this applies to engineering groups, even for those readers not familiar with football minutiae.  Handoff points are the most important aspect of any interaction between design groups.  First of all, it must be very well-defined what is required from the team that is doing the “handing off”.  Whether it is a design spec, constraints, drawings for manufacturing, marketing requirements for future design, parts and services that must be acquired, shipping addresses, etc etc.  It is up to company management to clearly define WHAT is required, WHO requires it, and WHEN it must be delivered.

Companies that have what I call “gray area” handoffs suffer.  Schedules will slip, and the folks at the end of the design flow (when product must be available to market) will suffer greatly.  This is equivalent to a running back having his arms in the perfect location, ready to accept the ball, except the quarterback has tripped and the ball drops to the ground.  If the handoff fails, the design cycle fails.

What are your tips for working with other groups?  What worked best?  What didn’t work at all?  Managers, really looking for your feedback here.

Category: Efficiency, Engineering & Design, Industrial B2B Sales, Tips and Tutorials for our Users

Tagged: , , , ,

One Response

  1. [...] processes to nail down is a complex design handoff from one team to another.  Awhile back, I discussed this briefly using a football analogy.  I want to expand on that a little [...]

Leave a Reply